3 ms·

The success of jQuery, React, Angular, etc. makes it mostly unnecessary. There is no need to avoid JavaScript wrappers to the DOM API, and lots of good reasons

The success of jQuery, React, Angular, etc. makes it mostly unnecessary. There is no need to avoid JavaScript wrappers to the DOM API, and lots of good reasons to have them. External libs are more flexible and fixable than web platform APIs. Very few people need to write directly to the DOM API nowadays and the ones who do don't need more abstractions or a bunch of renamings. Those things generally just complicate the code in frameworks and libraries because they create multiple code paths for years.

BinaryIdiot 11y ago
> External libs are more flexible and fixable than web platform APIs. This isn't true. If you're only talking about jQuery then fine, it has a performance hit to its usage but it's not that big of a deal. But React, Angular and some of the frameworks out there? They abstract a lot more away from the DOM and can cause some serious performance issues (even if you're not careless they all incur a performance hit which can be noticeable in mobile web browsers if you're not careful). Many have had to rewrite portions (or entire) web applications when they hit certain scale and use far more native DOM APIs than before just to get the necessary performance. Atom is one example but there are plenty more. So no improvements to the DOM API are not unnecessary; in fact I think they are a bit necessary. You wouldn't have nearly as many people abstracting away from it if it were far more approachable and there is nothing wrong with making it easier to use.
- dmethvin 11y ago
  So if the current DOM APIs already solve those problems, what changes would you make? As I mentioned, renaming them just makes things harder.
  - BinaryIdiot 11y ago
    Renaming wouldn't be a good idea (best to keep the existing API and create a DOM 2.0 API for backwards compatibility) plus it wouldn't really solve any problems anyway. For me I'd need to do some research to create a good, comprehensive list but some of the things off the top of my head: - Simplified ways for creating HTML elements. jQuery's way is nice and I think chainable, while a double edge sword in some cases, can make this a little nicer (doesn't have to be chainable to the extent that I can make 10 elements in one line but being able to set the properties in the creation step would be nice). In fact even allowing a simple JS Object to be used for setting properties in the creation step would be handy. - Templating needs to be built in. Practically every single framework has its own way of templating and they all suck to a degree because you have to take the huge tradeoff of either doing the templating server-side, loading the HTML then replacing the values or loading the JS then generating the HTML. All of it is slow. A browser native solution could be orders of magnitude faster than dealing with the last two and makes it easier to leave the front end as purely static versus having some dynamically generated items. - HTML and ECMAScript committees needs to get together and create clear separations of functionality between what the HTML and the ECMAScript standards provide. AJAX was great but this is an HTML standard; HTTP needs to be baked directly into the ECMAScript standard since JavaScript can run anywhere now. Eventing too needs to be moved from HTML standards (as far as the eventing itself is described; the events individual elements use most certainly should stay in the HTML standards) and build eventing right into ECMAScript. Right now node and the browser both provide their own event handling. Obviously those items are far more nuanced than my real fast list but you asked me to give you answers to a hard problem :). I could make them far more detailed and nuanced with some time and research (I have other ideas but I need to investigate them more).

BinaryIdiot 11y ago

> External libs are more flexible and fixable than web platform APIs. This isn't true. If you're only talking about jQuery then fine, it has a performance hit to its usage but it's not that big of a deal. But React, Angular and some of the frameworks out there? They abstract a lot more away from the DOM and can cause some serious performance issues (even if you're not careless they all incur a performance hit which can be noticeable in mobile web browsers if you're not careful). Many have had to rewrite portions (or entire) web applications when they hit certain scale and use far more native DOM APIs than before just to get the necessary performance. Atom is one example but there are plenty more. So no improvements to the DOM API are not unnecessary; in fact I think they are a bit necessary. You wouldn't have nearly as many people abstracting away from it if it were far more approachable and there is nothing wrong with making it easier to use.

dmethvin 11y ago
So if the current DOM APIs already solve those problems, what changes would you make? As I mentioned, renaming them just makes things harder.
- BinaryIdiot 11y ago
  Renaming wouldn't be a good idea (best to keep the existing API and create a DOM 2.0 API for backwards compatibility) plus it wouldn't really solve any problems anyway. For me I'd need to do some research to create a good, comprehensive list but some of the things off the top of my head: - Simplified ways for creating HTML elements. jQuery's way is nice and I think chainable, while a double edge sword in some cases, can make this a little nicer (doesn't have to be chainable to the extent that I can make 10 elements in one line but being able to set the properties in the creation step would be nice). In fact even allowing a simple JS Object to be used for setting properties in the creation step would be handy. - Templating needs to be built in. Practically every single framework has its own way of templating and they all suck to a degree because you have to take the huge tradeoff of either doing the templating server-side, loading the HTML then replacing the values or loading the JS then generating the HTML. All of it is slow. A browser native solution could be orders of magnitude faster than dealing with the last two and makes it easier to leave the front end as purely static versus having some dynamically generated items. - HTML and ECMAScript committees needs to get together and create clear separations of functionality between what the HTML and the ECMAScript standards provide. AJAX was great but this is an HTML standard; HTTP needs to be baked directly into the ECMAScript standard since JavaScript can run anywhere now. Eventing too needs to be moved from HTML standards (as far as the eventing itself is described; the events individual elements use most certainly should stay in the HTML standards) and build eventing right into ECMAScript. Right now node and the browser both provide their own event handling. Obviously those items are far more nuanced than my real fast list but you asked me to give you answers to a hard problem :). I could make them far more detailed and nuanced with some time and research (I have other ideas but I need to investigate them more).