To my non-webdev ears this sounds like "having only pegs and square holes isn't a problem because otherwise how would you try to fit one in the other?"
Could it be that this whole paradigm (which by the way has been devised for a different and much simpler use case, and abused forever since) isn't sustainable anymore?
I think the article missed an important “why” here that is confusing people here: JavaScript objects and the DOM are fundamentally different, and JavaScript is providing an API via the DOM for reading and writing HTML, which is essentially an XML document. We shouldn’t expect the objects in JavaScript to perfectly translate to their HTML counterparts or vice versa.
If anything, it’s odd that they added these conveniences like reflection that make it more magical than it should be.
That's definitely one of the main original use cases, but it would have been a bad decision to base the entire language around the limitations of HTML, and I doubt JavaScript today would be the most popular programming language today if they had. You can read the original ECMAScript 1 standard here, which is titled: "A general purpose, cross-platform programming language"[1].
I wonder why the web technologies are not fully integrated like the Smalltalk and Self graphical environments... Is it impossible or did it just end up that way and it's too late to change it now?
The DOM API is not designed as a JavaScript API (at least originally). It was designed to be language independent and to be more natural for a language like Java rather than JavaScript.
The reason for NodeList instead of Array is the same
For example the Event interface definition[0] contains parts like
I did not mean to disparage the DOM API, I intended to show that the DOM API was not (initially) designed as a Javascript API and was instead expressed in a language independent (but Java inspired) IDL.
I would not surprise me if modern addition or revisions to the spec were more JS inspired
What do you mean by not sustainable? What has been more sustainable than web dev and web tech lol? Also, being flexible isn't trying to fit a square peg in a hole, it's the opposite actually.
I agree, except with the “simply” part. This is not simple at all, unless you also demand that every property can only ever be a string. Otherwise, you need to think of conversions (eg from and to numbers), and what about properties that can be set to objects? Or properies that don’t correspond to attributes at all?
I agree that any sort of convention/rule here that’d be 100% fixed would’ve been better, but it wouldn’t be simple.
In what way is that not an issue? What happens when you use .outerHTML to get a string representation of the element? Not to mention that, unavoidably, the entire page HTML arrives to the browser as a string.
I do want to point out for those who don't know, on objects with a prototype (such as a class) you can control how JSON.stringify works by adding a special method `toJSON`[0] which will control how that object is serialized.
Right… and that’s an issue people have to work around every day. Non string values in HTML world similarly be an issue everyone would have to work around.
Making attributes and properties symmetric to one another would be difficult for the existing DOM API: methods like `addEventListener` are (prototype) properties on individual DOM elements, but would be nonsensical string attributes. Making your idea concrete:
// our document is like:
// <foo bar="asdf">
let foo = document.querySelector('foo');
console.log('bar', foo.bar); // cool, prints asdf
foo.bar = 'nice'; // <foo> element is now <foo bar="nice">
foo.addEventListener('some-event', e => console.log(e)); // wait, what?
So DOM element methods would instead be free functions like:
HTMLElement.addEventListener(foo, 'some-event', e => console.log(e));
It's a matter of taste, but I for one appreciate having object method calls in JavaScript.
I don’t know why they would be different? It seems cool, but the DOM elements have a very specific interface, where ‘setAttribute’ is required to modify state. If you just hang some property off a JavaScript object - that you created to send messages to the DOM using that interface - then why would you expect it to get routed there? Again, that would be a much better API/experience, some challenges but cleaner.
Maybe I’ve just been writing backend code for too long. I see an interface like this and I figure there’s some weird shit going on under the hood, and some kind developer from the past gave me the best and safest wrapper she could.
> all of the things in this article represent complexity and behaviours that don't add anything to anyone's lives.
A cynic might point out it added a lot of makework to the lives of its creators. And that this is why we can't have nice things like proper specs instead of 'living' ones.
This behaviour is all downside and no upside.
The spec should have simply defined a dom object and a javascript object to be one and the same, with attributes and properties being the same thing.