6 ms·

Your JS knowledge appears to be severely outdated. Instead of the first you can now write: Object.assign(target, object1, objectN); The second: eleme

by twhb 9y ago

Your JS knowledge appears to be severely outdated. Instead of the first you can now write: Object.assign(target, object1, objectN); The second: element.classList.add(className); element.classList.contains(className); And the third has been fixed at a community level, as we've learned the value of API strictness, obviating such checks. I don't think anybody was against jQuery back when the alternative was helper functions, I certainly wasn't. But that's five years ago at this point. Modern JavaScript looks nothing like the code you posted, it's actually been built up into a pretty good language.

sosuke 9y ago
Perhaps the examples are just a reflection of having to support Internet Explorer?
csomar 9y ago
You are ignoring browsers support. One of the main reasons I suggest using jQuery is browser support. Another solution is to use a transpiler like Bable.
- ctrl-j 9y ago
  > Another solution is to use a transpiler like Bable. At this point in front-end development something like Babel is a must. If you aren't using Babel/Flow/Typescript in your workflow, you are putting yourself at disadvantage for no good reason. For better or worse, transpiling is a fact of life.
  - platz 9y ago
    If you're not using a framework that requires you to transpile, jQuery basically takes care of the most common bits.
- loganfsmyth 9y ago
  Babel on its own only addresses syntactic functionality and wouldn't cover this, but it is indeed extremely easily to polyfill `classList`.
- twhb 9y ago
  "Five years ago" refers to across-the-board browser support, the spec is older. You can use caniuse.com, https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/, and/or MDN compatibility tables to quickly check browser support. Browsers are now grinding away at new APIs constantly - don't let your memory of "not safe to use" last more than a year.
  - couchand 9y ago
    It may be hard to imagine, but even today not every user is running a browser built in the last year.
    - hnzix 9y ago
      Corporate and government SOE machines are often running versions 7+ years out of date. I'm still EOL'ing XP machines for government clients. Seniors are another group who often run, well, senior versions. If your Uber-for-toothpaste startup doesn't care then fine. But crusty old browsers are still a crucial factor in many markets.
      - dvfjsdhgfv 9y ago
        Many companies and developers simply decide this group is insignificant and just don't care.
    - twhb 9y ago
      If you explore the first of the links you're replying to, you'll see that I make my conclusions about what people are using based on country-adjusted analytics from millions of websites, not imagination. This situation is actually improving too. Chrome's "evergreen" development cycle has made a world of difference to feature adoption rate, and it's spread to every other major browser vendor. Once IE11 dies out, we'll have no non-evergreen browsers over 1% market share, and it makes me so happy to say that.
padseeker 9y ago
Are you absolutely certain that everything that jQuery does can now be done in a clear and concise way using plain Javascript? I've written some fairly complex jQuery selector over the years, perhaps I'm wrong but I something tells me that while the simple use cases can be done with plain old js the more complex selectors might not be so easy. I find this debate so aggravating. I'm glad you can do some of the stuff jQuery does using modern vanilla js. Perhaps jQuery is overkill for doing one hide/show (or toggle) action on the page. But what about the more complex stuff. What is primary motivation behind this nagging issue, of the load time of jQuery? I suspect it is that many developers have some obsession over shaving a few milliseconds on their load time. For jQuery? One library? Is it that bad that you need to write vanilla js? So you can save a few milliseconds? Can you have a sophisticated selector for Event Delegation without using jQuery but make the code concise and easy to read? What about child selectors ("ul.thisClass > li.thatClass" > span.otherClass"). I like jQuery because the syntax makes sense, its clear and concise, you can do complex things with less code. Maybe some of the new stuff can be clean and concise and easy to read, but all of it? I have my doubts.
- josephg 9y ago
  > Are you absolutely certain that everything that jQuery does can now be done in a clear and concise way using plain Javascript? Can you give us some examples of things that you're worried can't be written clearly using plain JS? Obviously everything you can do with jquery you can do without jquery. Its just a library. > Can you have a sophisticated selector for Event Delegation without using jQuery but make the code concise and easy to read? What do you mean by event delegation in this context? > What about child selectors ("ul.thisClass > li.thatClass" > span.otherClass") document.querySelector / querySelectorAll supports this. Its available in all browsers on all platforms if thats how you chose to make web apps: http://caniuse.com/#feat=queryselector http://caniuse.com/#feat=queryselector
  - paulddraper 9y ago
    Make an HTTP request. Parse the JSON body if a 200, otherwise log an error.

by twhb 9y ago

sosuke 9y ago

Perhaps the examples are just a reflection of having to support Internet Explorer?

csomar 9y ago

You are ignoring browsers support. One of the main reasons I suggest using jQuery is browser support. Another solution is to use a transpiler like Bable.

ctrl-j 9y ago
> Another solution is to use a transpiler like Bable. At this point in front-end development something like Babel is a must. If you aren't using Babel/Flow/Typescript in your workflow, you are putting yourself at disadvantage for no good reason. For better or worse, transpiling is a fact of life.
- platz 9y ago
  If you're not using a framework that requires you to transpile, jQuery basically takes care of the most common bits.
loganfsmyth 9y ago
Babel on its own only addresses syntactic functionality and wouldn't cover this, but it is indeed extremely easily to polyfill `classList`.
twhb 9y ago
"Five years ago" refers to across-the-board browser support, the spec is older. You can use caniuse.com, https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/, and/or MDN compatibility tables to quickly check browser support. Browsers are now grinding away at new APIs constantly - don't let your memory of "not safe to use" last more than a year.
- couchand 9y ago
  It may be hard to imagine, but even today not every user is running a browser built in the last year.
  - hnzix 9y ago
    Corporate and government SOE machines are often running versions 7+ years out of date. I'm still EOL'ing XP machines for government clients. Seniors are another group who often run, well, senior versions. If your Uber-for-toothpaste startup doesn't care then fine. But crusty old browsers are still a crucial factor in many markets.
    - dvfjsdhgfv 9y ago
      Many companies and developers simply decide this group is insignificant and just don't care.
  - twhb 9y ago
    If you explore the first of the links you're replying to, you'll see that I make my conclusions about what people are using based on country-adjusted analytics from millions of websites, not imagination. This situation is actually improving too. Chrome's "evergreen" development cycle has made a world of difference to feature adoption rate, and it's spread to every other major browser vendor. Once IE11 dies out, we'll have no non-evergreen browsers over 1% market share, and it makes me so happy to say that.

padseeker 9y ago

Are you absolutely certain that everything that jQuery does can now be done in a clear and concise way using plain Javascript? I've written some fairly complex jQuery selector over the years, perhaps I'm wrong but I something tells me that while the simple use cases can be done with plain old js the more complex selectors might not be so easy. I find this debate so aggravating. I'm glad you can do some of the stuff jQuery does using modern vanilla js. Perhaps jQuery is overkill for doing one hide/show (or toggle) action on the page. But what about the more complex stuff. What is primary motivation behind this nagging issue, of the load time of jQuery? I suspect it is that many developers have some obsession over shaving a few milliseconds on their load time. For jQuery? One library? Is it that bad that you need to write vanilla js? So you can save a few milliseconds? Can you have a sophisticated selector for Event Delegation without using jQuery but make the code concise and easy to read? What about child selectors ("ul.thisClass > li.thatClass" > span.otherClass"). I like jQuery because the syntax makes sense, its clear and concise, you can do complex things with less code. Maybe some of the new stuff can be clean and concise and easy to read, but all of it? I have my doubts.

josephg 9y ago
> Are you absolutely certain that everything that jQuery does can now be done in a clear and concise way using plain Javascript? Can you give us some examples of things that you're worried can't be written clearly using plain JS? Obviously everything you can do with jquery you can do without jquery. Its just a library. > Can you have a sophisticated selector for Event Delegation without using jQuery but make the code concise and easy to read? What do you mean by event delegation in this context? > What about child selectors ("ul.thisClass > li.thatClass" > span.otherClass") document.querySelector / querySelectorAll supports this. Its available in all browsers on all platforms if thats how you chose to make web apps: http://caniuse.com/#feat=queryselector http://caniuse.com/#feat=queryselector
- paulddraper 9y ago
  Make an HTTP request. Parse the JSON body if a 200, otherwise log an error.