4 ms·

This really isn’t worth reading. The author is trying to stir up controversy without making substantive points. For example, the ES6 the author wrote is a scape

This really isn’t worth reading. The author is trying to stir up controversy without making substantive points. For example, the ES6 the author wrote is a scapegoat file with pretty bloated design that wouldn’t pass a code review. Additionally, the author isn’t comparing bundle size, but rather LOC without dependency size which is baffling. If you read the replies you can find people who trivially write better versions using ES6.

jaapz 2y ago
It still amazes me how much we argue in this field about which tools should or should not be used, there is so much tribalism. jQuery is fine to use if it solves your problem and you like working with it. Going vanilla JS is fine too (nowadays). Use something like SolidJS if it solves your problems, or Angular if you like their approach more. Go with a server-side only solution if that floats your boat! Everyone has a different way of thinking, a different way to mentally model a problem and therefore different tools that work better or worse for them. Stop arguing about which is better, start building with the tools that work for you.
- KronisLV 2y ago
  I enjoyed slightly more fine grained comparisons, like: https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/ (this hasn't been updated in a little bit, it seems) Either way, I think you're right, just use whatever works for you. I'd admittedly love to see a larger scale comparison of going vanilla JS vs recreating the same functionality in jQuery/Vue/Angular/React, for a real world apps and what the takeaways are from that, say, 50'000 SLoC instead of 100, that'd probably be more useful, but also is way more unlikely. Nobody will put in that much effort just for the sake of a comparison and so a lot will be up to opinion and comparing vaguely similar projects. Closest I've seen was https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 https://medium.com/dailyjs/a-realworld-comparison-of-front-e... but still a fairly simplistic example, given the large amount of options that were compared. Still very cool, less about opinions and more about giving you metrics that you can weigh in yourself! Here's the repo: https://github.com/gothinkster/realworld https://github.com/gothinkster/realworld
- ryandv 2y ago
  It can be argued that some languages or technologies are superior to others in expressive power [0]. Some languages or technologies are easier to learn, but the solutions they produce are more complex, less simple, and/or less elegant; thus, one should strive to use the most expressive or "powerful" technologies available. Granted, the shadow aspect of this line of thinking is the constant treadmill of fashionable JS frameworks and the tribalism you allude to. That being said, Moxie was recently featured on HN frontpage [1] regarding black boxes of abstraction and a lack of understanding of what goes on underneath. Much of development these days (think npm left-pad) is unnecessary abstraction and obscurantism of how the machine actually operates. Few people understand the underlying concepts and technologies, and many are trained only to operate trendy frameworks, languages, and technologies. Once the abstractions leak, and they always will [2], they are often lost as they don't understand how to step down a layer of abstraction to something more primitive. To this extent the point can be made that it may sometimes be worthwhile to not overcomplicate your solution stack with too many layers of indirection [3]. Not only does this simplify debugging, but you can more clearly see how your system actually operates and enrich your understanding of the software. To this extent it can be argued that one ought to pursue simpler, more "standard" (ES6, even jQuery) solution stacks in the JS space instead of the combinatorial explosion of dependencies and multilayer cake of abstractions that seems to be par for the course today. It should be noted that level of abstraction and expressive power, while not quite orthogonal, are not quite collinear either [0]. [0] https://paulgraham.com/avg.html https://paulgraham.com/avg.html [1] https://news.ycombinator.com/item?id=41208627 https://news.ycombinator.com/item?id=41208627 [2] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... [3] https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...
- drewcoo 2y ago
  > It still amazes me how much we argue in this field about which tools should or should not be used Like any craft. Is it really a bad thing that people think about how to solve their problems better and want to share with others? Anyone who doesn't want to listen to that will ignore it and just pursue their own work.

jaapz 2y ago

It still amazes me how much we argue in this field about which tools should or should not be used, there is so much tribalism. jQuery is fine to use if it solves your problem and you like working with it. Going vanilla JS is fine too (nowadays). Use something like SolidJS if it solves your problems, or Angular if you like their approach more. Go with a server-side only solution if that floats your boat! Everyone has a different way of thinking, a different way to mentally model a problem and therefore different tools that work better or worse for them. Stop arguing about which is better, start building with the tools that work for you.

KronisLV 2y ago
I enjoyed slightly more fine grained comparisons, like: https://youmightnotneedjquery.com/ https://youmightnotneedjquery.com/ (this hasn't been updated in a little bit, it seems) Either way, I think you're right, just use whatever works for you. I'd admittedly love to see a larger scale comparison of going vanilla JS vs recreating the same functionality in jQuery/Vue/Angular/React, for a real world apps and what the takeaways are from that, say, 50'000 SLoC instead of 100, that'd probably be more useful, but also is way more unlikely. Nobody will put in that much effort just for the sake of a comparison and so a lot will be up to opinion and comparing vaguely similar projects. Closest I've seen was https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 https://medium.com/dailyjs/a-realworld-comparison-of-front-e... but still a fairly simplistic example, given the large amount of options that were compared. Still very cool, less about opinions and more about giving you metrics that you can weigh in yourself! Here's the repo: https://github.com/gothinkster/realworld https://github.com/gothinkster/realworld
ryandv 2y ago
It can be argued that some languages or technologies are superior to others in expressive power [0]. Some languages or technologies are easier to learn, but the solutions they produce are more complex, less simple, and/or less elegant; thus, one should strive to use the most expressive or "powerful" technologies available. Granted, the shadow aspect of this line of thinking is the constant treadmill of fashionable JS frameworks and the tribalism you allude to. That being said, Moxie was recently featured on HN frontpage [1] regarding black boxes of abstraction and a lack of understanding of what goes on underneath. Much of development these days (think npm left-pad) is unnecessary abstraction and obscurantism of how the machine actually operates. Few people understand the underlying concepts and technologies, and many are trained only to operate trendy frameworks, languages, and technologies. Once the abstractions leak, and they always will [2], they are often lost as they don't understand how to step down a layer of abstraction to something more primitive. To this extent the point can be made that it may sometimes be worthwhile to not overcomplicate your solution stack with too many layers of indirection [3]. Not only does this simplify debugging, but you can more clearly see how your system actually operates and enrich your understanding of the software. To this extent it can be argued that one ought to pursue simpler, more "standard" (ES6, even jQuery) solution stacks in the JS space instead of the combinatorial explosion of dependencies and multilayer cake of abstractions that seems to be par for the course today. It should be noted that level of abstraction and expressive power, while not quite orthogonal, are not quite collinear either [0]. [0] https://paulgraham.com/avg.html https://paulgraham.com/avg.html [1] https://news.ycombinator.com/item?id=41208627 https://news.ycombinator.com/item?id=41208627 [2] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... [3] https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...
drewcoo 2y ago
> It still amazes me how much we argue in this field about which tools should or should not be used Like any craft. Is it really a bad thing that people think about how to solve their problems better and want to share with others? Anyone who doesn't want to listen to that will ignore it and just pursue their own work.