5 ms·

And all of the things in this article represent complexity and behaviours that don't add anything to anyone's lives. This behaviour is all downside and no upsi

And all of the things in this article represent complexity and behaviours that don't add anything to anyone's lives. 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.

skrebbel 3y ago
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.
- londons_explore 3y ago
  think the other way round... allow DOM attribute values to be of any javascript type... Sure, they maybe can't be serialized, but that isn't an issue.
  - strix_varius 3y ago
    That doesn't make any sense. DOM attributes are serialized as a fundamental part of their expression.
    - layer8 3y ago
      So is JavaScript. Granted, it would be more straightforward if it were a Lisp.
  - afavour 3y ago
    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.
    - londons_explore 3y ago
      Same is true of real javascript objects vs JSON. For example, you can't put Date() in JSON. Nor objects with a prototype.
      - afavour 3y ago
        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.
      - no_wizard 3y ago
        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. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#:~:text=If%20the%20value%20has%20a%20toJSON()%20method%2C%20it%27s%20responsible%20to%20define%20what%20data%20will%20be%20serialized https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
jaffathecake 3y ago
This means you couldn't non-string values on DOM interfaces, and that includes methods, so most of the DOM's functionality goes out the window.
- noam_k 3y ago
  Good point, but HTML already has a workaround by using strings: <div onClick="func()">...</div> Now, I'm not a JS developer, so my opinion shouldn't count for much, but that looks like a much less usable standard to me.
  - jaffathecake 3y ago
    Yeah, that works, but it requires func() to be on the global scope. It doesn't scale as a solution.
    - debugnik 3y ago
      Does that matter now that we've got (possibly declarative) shadow roots as the units of DOM encapsulation?
      - jaffathecake 3y ago
        Yes, even more so. You end up with encapsulated DOM without encapsulated script.
romellem 3y ago
Most modern UI frameworks wouldn’t work at all if this limitation “simply” existed. Being able to store non-string values on DOM nodes is an upside. Acting this flippant isn’t helpful.
- ezst 3y ago
  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?
  - jacobsimon 3y ago
    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. (Edited for clarity)
    - naasking 3y ago
      > We shouldn’t expect the objects in JavaScript to perfectly translate to their DOM counterparts or vice versa. Since JavaScript was invented specifically to manipulate the DOM, I'm not sure that that follows.
      - jacobsimon 3y ago
        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]. https://ecma-international.org/wp-content/uploads/ECMA-262_1st_edition_june_1997.pdf https://ecma-international.org/wp-content/uploads/ECMA-262_1...
tomjakubowski 3y ago
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.
chrisjj 3y ago
> 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.
threecheese 3y ago
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.
- remram 3y ago
  It's all "state"...

skrebbel 3y ago

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.

londons_explore 3y ago
think the other way round... allow DOM attribute values to be of any javascript type... Sure, they maybe can't be serialized, but that isn't an issue.
- strix_varius 3y ago
  That doesn't make any sense. DOM attributes are serialized as a fundamental part of their expression.
  - layer8 3y ago
    So is JavaScript. Granted, it would be more straightforward if it were a Lisp.
- afavour 3y ago
  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.
  - londons_explore 3y ago
    Same is true of real javascript objects vs JSON. For example, you can't put Date() in JSON. Nor objects with a prototype.
    - afavour 3y ago
      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.
    - no_wizard 3y ago
      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. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#:~:text=If%20the%20value%20has%20a%20toJSON()%20method%2C%20it%27s%20responsible%20to%20define%20what%20data%20will%20be%20serialized https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

jaffathecake 3y ago

This means you couldn't non-string values on DOM interfaces, and that includes methods, so most of the DOM's functionality goes out the window.

noam_k 3y ago
Good point, but HTML already has a workaround by using strings: <div onClick="func()">...</div> Now, I'm not a JS developer, so my opinion shouldn't count for much, but that looks like a much less usable standard to me.
- jaffathecake 3y ago
  Yeah, that works, but it requires func() to be on the global scope. It doesn't scale as a solution.
  - debugnik 3y ago
    Does that matter now that we've got (possibly declarative) shadow roots as the units of DOM encapsulation?
    - jaffathecake 3y ago
      Yes, even more so. You end up with encapsulated DOM without encapsulated script.

romellem 3y ago

Most modern UI frameworks wouldn’t work at all if this limitation “simply” existed. Being able to store non-string values on DOM nodes is an upside. Acting this flippant isn’t helpful.

ezst 3y ago
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?
- jacobsimon 3y ago
  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. (Edited for clarity)
  - naasking 3y ago
    > We shouldn’t expect the objects in JavaScript to perfectly translate to their DOM counterparts or vice versa. Since JavaScript was invented specifically to manipulate the DOM, I'm not sure that that follows.
    - jacobsimon 3y ago
      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]. https://ecma-international.org/wp-content/uploads/ECMA-262_1st_edition_june_1997.pdf https://ecma-international.org/wp-content/uploads/ECMA-262_1...

tomjakubowski 3y ago

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.

chrisjj 3y ago

> 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.

threecheese 3y ago

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.

remram 3y ago
It's all "state"...