3 ms·

> It's almost like the designers for these native-API's look at what the community uses, and then decide to do something similar, but different just because. T

> It's almost like the designers for these native-API's look at what the community uses, and then decide to do something similar, but different just because. This is an understandable interpretation, but I think the real explanation is more nuanced (and more favorable). Web APIs do tend to be inspired by existing use cases like you say, and that’s a good thing. But from there they tend to be low level—in the sense that they’re designed for library authors, at least as much as they’re designed for end users—either as an explicit goal or as an implied general principle. Taking inspiration from real usage is unambiguously great. Lower level APIs might feel more painful for end users (and can lead to dependency-itis which is a constant target of scorn here and all over). But the benefit is that these less friendly APIs are also well designed to be used in a wider variety of ways, without much influence on their own higher level interfaces. More concretely, the DOM as designed allows jQuery and React to coexist and thrive for their own target audiences, in a way that would probably be much less likely if the DOM had been designed more like either one of them. This is similarly true for APIs like Intl (which I’ve used directly, and it’s fine… but it’s definitely better as a library target than for every day usage).

Alupis 4y ago
Of course there are technical reasons things are the way they are - but why does javascript have like 6 different ways to select an element? Why does everything have to start with verbose "document."? Why are the new functions so long in name and cumbersome to use? In jQuery, you can select almost anything with just the constructor. It's simple... and clearly better. > in the sense that they’re designed for library authors Libraries shouldn't be necessary to write basic DOM manipulation code. Modern ECMAScript has been promised to do away with all the "hack" libraries like jQuery... and articles like "You might not need jQuery" sprang up in popularity based on new ECMAScript features. But, modern ECMAScript is objectively harder to use, more clunky and verbose. Even the naming of functions is absurd... "querySelector()" instead of just "select()" or "get()"... The problem with the javascript community is nobody actually knows javascript. No, people know whatever framework/lib they work with, which is not the same thing. It's that way because javascript... sucks to use.
- eyelidlessness 4y ago
  > why does javascript have like 6 different ways to select an element? Because all but one of them existed already when settled on the one that everyone almost universally prefers, but the others can’t be removed. You can just use the one you like and totally ignore the others. > Why does everything have to start with verbose "document."? Because it has to be namespaced to something, and the global document object is by far the best namespace available. You can destructure it once and even assign it to a global if you don’t like that reasoning. > Why are the new functions so long in name and cumbersome to use? Partly because people don’t like how things are so they do the global assignment thing and make sure no one can have nice things; partly because long names are self documenting which is often the best documentation they can guarantee at design time; partly because they expect people will never call these APIs directly. > In jQuery, you can select almost anything with just the constructor. It's simple... and clearly better. Clearly to you? I can think of a bunch of ways I’d rather access the current state of a document, and they can vary a lot depending on my task. > Libraries shouldn't be necessary to write basic DOM manipulation code. That’s a really odd position to take given you’re advocating the choices made by one! > Modern ECMAScript has been promised to do away with all the "hack" libraries like jQuery... and articles like "You might not need jQuery" sprang up in popularity based on new ECMAScript features. Modern ECMAScript didn’t make any of these claims, and didn’t set out to do any of the things jQuery does. ECMAScript has added some language features like let/const, modules, Symbol, classes, async/await. HTML added querySelector and a bunch of other DOM conveniences, as well as fetch. Browser vendors and other organizations have added other APIs for things people want to build applications on. > The problem with the javascript community is nobody actually knows javascript. No, people know whatever framework/lib they work with, which is not the same thing. It's that way because javascript... sucks to use. No, it’s that way because everyone wants JavaScript to be the thing they already shimmed it to be. You might be surprised by what it actually is. There are many problems with it of course, but it’s incredibly capable of being nicer to use than you seem to think. As far as knowing JS, I’d highly recommend just spending some casual time reading MDN. Almost every time I do (which is fairly often) I discover something elegant that I either need immediately or could imagine being helpful soon. If nothing else, it’s always a good insight into how the tools that do 95% of what I want get their job done.

Alupis 4y ago

Of course there are technical reasons things are the way they are - but why does javascript have like 6 different ways to select an element? Why does everything have to start with verbose "document."? Why are the new functions so long in name and cumbersome to use? In jQuery, you can select almost anything with just the constructor. It's simple... and clearly better. > in the sense that they’re designed for library authors Libraries shouldn't be necessary to write basic DOM manipulation code. Modern ECMAScript has been promised to do away with all the "hack" libraries like jQuery... and articles like "You might not need jQuery" sprang up in popularity based on new ECMAScript features. But, modern ECMAScript is objectively harder to use, more clunky and verbose. Even the naming of functions is absurd... "querySelector()" instead of just "select()" or "get()"... The problem with the javascript community is nobody actually knows javascript. No, people know whatever framework/lib they work with, which is not the same thing. It's that way because javascript... sucks to use.

eyelidlessness 4y ago
> why does javascript have like 6 different ways to select an element? Because all but one of them existed already when settled on the one that everyone almost universally prefers, but the others can’t be removed. You can just use the one you like and totally ignore the others. > Why does everything have to start with verbose "document."? Because it has to be namespaced to something, and the global document object is by far the best namespace available. You can destructure it once and even assign it to a global if you don’t like that reasoning. > Why are the new functions so long in name and cumbersome to use? Partly because people don’t like how things are so they do the global assignment thing and make sure no one can have nice things; partly because long names are self documenting which is often the best documentation they can guarantee at design time; partly because they expect people will never call these APIs directly. > In jQuery, you can select almost anything with just the constructor. It's simple... and clearly better. Clearly to you? I can think of a bunch of ways I’d rather access the current state of a document, and they can vary a lot depending on my task. > Libraries shouldn't be necessary to write basic DOM manipulation code. That’s a really odd position to take given you’re advocating the choices made by one! > Modern ECMAScript has been promised to do away with all the "hack" libraries like jQuery... and articles like "You might not need jQuery" sprang up in popularity based on new ECMAScript features. Modern ECMAScript didn’t make any of these claims, and didn’t set out to do any of the things jQuery does. ECMAScript has added some language features like let/const, modules, Symbol, classes, async/await. HTML added querySelector and a bunch of other DOM conveniences, as well as fetch. Browser vendors and other organizations have added other APIs for things people want to build applications on. > The problem with the javascript community is nobody actually knows javascript. No, people know whatever framework/lib they work with, which is not the same thing. It's that way because javascript... sucks to use. No, it’s that way because everyone wants JavaScript to be the thing they already shimmed it to be. You might be surprised by what it actually is. There are many problems with it of course, but it’s incredibly capable of being nicer to use than you seem to think. As far as knowing JS, I’d highly recommend just spending some casual time reading MDN. Almost every time I do (which is fairly often) I discover something elegant that I either need immediately or could imagine being helpful soon. If nothing else, it’s always a good insight into how the tools that do 95% of what I want get their job done.