4 ms·

So it's been 10 years of jQuery being a preferred way of interacting with the DOM API...where are the changes to the DOM API to make the DOM easier like jQuery?

So it's been 10 years of jQuery being a preferred way of interacting with the DOM API...where are the changes to the DOM API to make the DOM easier like jQuery? Sure we got a few new things like querySelectorAll(), etc but nothing that makes things quite as elegant to create as jQuery's API. Why wouldn't the HTML standards committees follow the trend and improve the API? Edit: removed 'chainable' as a descriptor of jQuery's API as I didn't mean to focus on it; was simply just calling its API chainable but it's led to confusion.

ergothus 11y ago
Actually, I don't think the chainable API is terribly important. The things that keep jquery alive and well in mind are: * A convenient way to add to the DOM. While SELECTING elements has gotten way better than the Bad Old Days, ADDING elements is still painful. (one element isn't bad, but if you're trying to add, say, a UL with a number of LI elements, it's...tedious.) * A good wrapper for Ajax calls. Not that there aren't better, but jquery has a perfectly good one. Heck, I've jqueryified a page to test calls I'm making outside of jquery because doing a call via console is...tedious. * Promises. We'll soon have them native (and better), but for a long time jquery has been super convenient for this.
- skrebbel 11y ago
  for HTTP calls from the console, you might appreciate the relatively new fetch api: https://developer.mozilla.org/en/docs/Web/API/Fetch_API https://developer.mozilla.org/en/docs/Web/API/Fetch_API if you ask me, it's impressively well designed. it looks so boring and straight forward yet somehow nearly all "simple" http libraries (not to mention builtins) in nearly all popular languages are more convoluted.
  - amirmansour 11y ago
    I'm really greatfull for the new Fetch API. For now we need to use a pollyfill for it which just uses XHR underneath. Safari and modern versions of IE/Edge are lacking support.
  - ergothus 11y ago
    Thanks! I didn't know this was actually out there yet, awesome.
- BinaryIdiot 11y ago
  > Actually, I don't think the chainable API is terribly important. jQuery's API is chainable; that's all I meant by it. Their API overall just simplifies everything. I'd like to see the standards committees take ideas from development trends and work to simplify the DOM API. Honestly as far as AJAX goes I really think HTTP needs to be put into the JavaScript standard itself; not just the HTML standards. It's hard finding good libraries that can make HTTP calls in the exact same way in both the browser and node (which is important to me because much of my library type code can run in either environment). I had to write this myself and while my implementation is limited it makes my life easier.
- LoSboccacc 11y ago
  I've recently switched from jQuery to mustache to create elements for DOM insertion; I like that a lot, especially because it works linearly like a good old library, instead of being a huge ass framework - it's a good fit for the programming model.
- DCoder 11y ago
  > Promises Careful with that axe... Before jQuery 3.0, its promises API is not compatible with the Promises/A+ spec: http://stackoverflow.com/q/23744612/1233508 http://stackoverflow.com/q/23744612/1233508 If you're used to jQuery's promises, you can be in for a few surprises when trying to use other libraries (or even when updating to jQuery 3).
untog 11y ago
IMO the important part is that the DOM API is now consistent across browsers. I don't really have any problem using document.getElementById instead of $, the issue was handling events and so on. These days, addEventListener works in every browser. New additions like classList.add/classList.remove are just bonuses. As for the chainable syntax, I'm honestly in two minds about it. It's incredibly powerful, but some of the worst JS I've ever seen has been written in endless jQuery chain statements.
- lostPixels 11y ago
  I found out recently how much of a nightmare removeEventListener is compared to namespaced events in jQuery.
  - DonHopkins 11y ago
    jQuery has a nice efficient event delegation mechanism, that lets you listen for events on elements that don't even exist yet, by specifying selector patterns and listening on the root element with a few global event handlers, instead of adding listeners to every leaf element as it's created. It does all the bookkeeping and event handling in one place, so it saves a lot of memory and time. So not only does it work consistently across all browsers, but it also doesn't suck! https://learn.jquery.com/events/handling-events/#binding-events-to-elements-that-don-39-t-exist-yet https://learn.jquery.com/events/handling-events/#binding-eve... https://learn.jquery.com/events/event-delegation/ https://learn.jquery.com/events/event-delegation/
deleted 11y ago
[deleted]
dmethvin 11y ago
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).
dlandis 11y ago
That's exactly my thought as well. Even if you look at some of those sites like: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ the main thing they highlight to me is how incredibly superior jQuery's API still is for many basic operations. It's kind of sad 10 years later the standard DOM API is so clumsy and there is no significant update in sight that I'm aware of.

ergothus 11y ago

Actually, I don't think the chainable API is terribly important. The things that keep jquery alive and well in mind are: * A convenient way to add to the DOM. While SELECTING elements has gotten way better than the Bad Old Days, ADDING elements is still painful. (one element isn't bad, but if you're trying to add, say, a UL with a number of LI elements, it's...tedious.) * A good wrapper for Ajax calls. Not that there aren't better, but jquery has a perfectly good one. Heck, I've jqueryified a page to test calls I'm making outside of jquery because doing a call via console is...tedious. * Promises. We'll soon have them native (and better), but for a long time jquery has been super convenient for this.

skrebbel 11y ago
for HTTP calls from the console, you might appreciate the relatively new fetch api: https://developer.mozilla.org/en/docs/Web/API/Fetch_API https://developer.mozilla.org/en/docs/Web/API/Fetch_API if you ask me, it's impressively well designed. it looks so boring and straight forward yet somehow nearly all "simple" http libraries (not to mention builtins) in nearly all popular languages are more convoluted.
- amirmansour 11y ago
  I'm really greatfull for the new Fetch API. For now we need to use a pollyfill for it which just uses XHR underneath. Safari and modern versions of IE/Edge are lacking support.
- ergothus 11y ago
  Thanks! I didn't know this was actually out there yet, awesome.
BinaryIdiot 11y ago
> Actually, I don't think the chainable API is terribly important. jQuery's API is chainable; that's all I meant by it. Their API overall just simplifies everything. I'd like to see the standards committees take ideas from development trends and work to simplify the DOM API. Honestly as far as AJAX goes I really think HTTP needs to be put into the JavaScript standard itself; not just the HTML standards. It's hard finding good libraries that can make HTTP calls in the exact same way in both the browser and node (which is important to me because much of my library type code can run in either environment). I had to write this myself and while my implementation is limited it makes my life easier.
LoSboccacc 11y ago
I've recently switched from jQuery to mustache to create elements for DOM insertion; I like that a lot, especially because it works linearly like a good old library, instead of being a huge ass framework - it's a good fit for the programming model.
DCoder 11y ago
> Promises Careful with that axe... Before jQuery 3.0, its promises API is not compatible with the Promises/A+ spec: http://stackoverflow.com/q/23744612/1233508 http://stackoverflow.com/q/23744612/1233508 If you're used to jQuery's promises, you can be in for a few surprises when trying to use other libraries (or even when updating to jQuery 3).

untog 11y ago

IMO the important part is that the DOM API is now consistent across browsers. I don't really have any problem using document.getElementById instead of $, the issue was handling events and so on. These days, addEventListener works in every browser. New additions like classList.add/classList.remove are just bonuses. As for the chainable syntax, I'm honestly in two minds about it. It's incredibly powerful, but some of the worst JS I've ever seen has been written in endless jQuery chain statements.

lostPixels 11y ago
I found out recently how much of a nightmare removeEventListener is compared to namespaced events in jQuery.
- DonHopkins 11y ago
  jQuery has a nice efficient event delegation mechanism, that lets you listen for events on elements that don't even exist yet, by specifying selector patterns and listening on the root element with a few global event handlers, instead of adding listeners to every leaf element as it's created. It does all the bookkeeping and event handling in one place, so it saves a lot of memory and time. So not only does it work consistently across all browsers, but it also doesn't suck! https://learn.jquery.com/events/handling-events/#binding-events-to-elements-that-don-39-t-exist-yet https://learn.jquery.com/events/handling-events/#binding-eve... https://learn.jquery.com/events/event-delegation/ https://learn.jquery.com/events/event-delegation/

deleted 11y ago

[deleted]

dmethvin 11y ago

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

dlandis 11y ago

That's exactly my thought as well. Even if you look at some of those sites like: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ the main thing they highlight to me is how incredibly superior jQuery's API still is for many basic operations. It's kind of sad 10 years later the standard DOM API is so clumsy and there is no significant update in sight that I'm aware of.