Hacker News Reader

Comment by londons_explore | Hacker News Reader

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.

View on HN

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.

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.

(Edited for clarity)

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

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

I think a lot of people dislike that JavaScript is a general purpose programming language, rather than being a scripting engine for browsers.

A lot of people dislike any tool that actually has wide spread usage. No one complains about tools that have been abandoned.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrop

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?

Mostly the latter. The web wasn’t designed to become an application platform.

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

  const unsigned short NONE = 0;

[0] https://dom.spec.whatwg.org/#interface-event

That's used as a constant for eventPhase https://dom.spec.whatwg.org/#ref-for-dom-event-none%E2%91%A2

In modern DOM APIs, it would be a string enum.

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.

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.

That doesn't make any sense. DOM attributes are serialized as a fundamental part of their expression.

So is JavaScript. Granted, it would be more straightforward if it were a Lisp.

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.

Same is true of real javascript objects vs JSON. For example, you can't put Date() in JSON. Nor objects with a prototype.

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.

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

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.

Good point, but HTML already has a workaround by using strings:

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.

Yeah, that works, but it requires func() to be on the global scope. It doesn't scale as a solution.

Does that matter now that we've got (possibly declarative) shadow roots as the units of DOM encapsulation?

Yes, even more so. You end up with encapsulated DOM without encapsulated script.

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.

It's all "state"...

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

Reply on news.ycombinator.com