12 ms·

I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving and it has burned so many people over the

by genmud 3y ago

I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving and it has burned so many people over the years that folks just don’t want to deal with it. I’m fine learning JS, but with the ecosystem it isn’t just learning JS. It’s learning the new hotness for packaging / versioning, it’s the frameworks that are constantly in flux, it’s the inconsistent abstractions that seem to be mercurial and constantly changing. If we were to sit down and write some frontend code to say, make a simple kanban board every 9 months using “current” JS best practices or popular frameworks over the last 6 years… How many different tools might you run across? How easy would it be to take that 6 year old code and bring it up to modern standards? The reason you see people allergic to the JS ecosystem is because it is incredibly opinionated while simultaneously being a free for all.

marcus_holmes 3y ago
The "new hotness" only matters if you're going to try and get a job as a FE dev in a large team. The "old hotness" still works, and likely has the more obscure bugs worked out of it. And you can always just write the thing in JS without any hotness at all. The JS ecosystem's obsession with frameworks is a diversion. You really only need a framework if your site is super complex. And even then, if you're careful about how you write your JS, you may not need a framework (you'll end up creating your own, probably). I'm with you that the JS ecosystem is a seething mess, but I don't think that's actually a problem unless you want a job as a FE dev. You can just ignore it ;)
- Andrew_nenakhov 3y ago
  I usually oppose the use of any new "hotness" in a project until that "hotness" is ~10 years old.
- leidenfrost 3y ago
  This. 90% of the toolchain is not required at all. Just quality of life improvements. Good ES6 (and TS) idiomatic code feels actually closer to reading Scala than reading a legacy Jquery app. And the V8 engine has so much investment in optimizations today that is actually closer to Java and in some cases lighter than Go. IMHO people don't hate JS in reality. They hate the strawman made of the worst parts of Junior code ever encountered and inconsistencies that really don't happen in practice unless you actively look for them.
  - sroussey 3y ago
    Same could be said for php…
loveparade 3y ago
htmx is another tool just like that, another goalpost in the frontend webdev world. It's just happens that the most recent hype is "don't write JS", but fundamnetally it's no different. Just another framework/library that has gotten some traction. In a few years we'll be back full cycle and it will be in vogue to write JS again, probably because htmx and associated projects have grown to complex.
- mkesper 3y ago
  A key difference is the promise to be working even without JavaScript.
  - vnorilo 3y ago
    "Htmx is a dependency-free, browser-oriented javascript library." https://htmx.org/docs/#installing https://htmx.org/docs/#installing
    - kkapelon 3y ago
      The framework itself is written in Javascript The end user is NOT writing Javascript.
  - loveparade 3y ago
    It's no different from anything else. The promise if every framework is to abstract away some low-level details. Whether that means writing "higher-level JS" like jQuery did many years ago already, and hundreds of other frameworks do today, or inventing some new DSL like htmx does that translated to JS internally. No difference.
baby 3y ago
I’m pretty sure you can continue to use jquery and everything still works fine :D
- zackify 3y ago
  I’m over here continuing to use react for 9+ years but every post on here acts like it’s changing every day.
  - alex_lav 3y ago
    Classes? Components as functions? Classes again? Hooks?
    - markmark 3y ago
      Classes still work fine if you want to keep using them.
      - alex_lav 3y ago
        This doesn't appear to be what the docs recommend anymore, which is exactly what my (obviously flippant) post was meant to highlight.
        chatmasta 3y ago
        Hooks were introduced five years ago and have been stable since then. So that's half a decade with no changes to the API.
        alex_lav 3y ago
        Great! I bailed in the first four years I guess, after the fourth change in API.
  - fredrikholm 3y ago
    https://www.youtube.com/watch?v=pd8kWJVDQD4 https://www.youtube.com/watch?v=pd8kWJVDQD4
hakfoo 3y ago
What I hate is that you don't even write JavaScript anymore. You write fantasy future JavaScript. Sure, it will be available in ECMAScript 23, scheduled to drop in real browsers in 2092. But for now, here's a convoluted mess of polyfills, Babel, and WebPack, that we HOPE papers over the real behaviour of browsers, and suddenly your test-and-debug cycle has introduced a flow-shattering 15-second build cycle each time you change a file.
- The_Colonel 3y ago
  There's actually no need for that anymore. JavaScript as is supported right now in the latest Chrome, Firefox and Safari is already pretty good. You can get quite far without any backend tooling these days. The only thing which I believe is still needed is a bundler when your project grows to a certain size. Fetching a complex graph of thousands of files will likely never be fast.
  - number6 3y ago
    Do you still use gulp or is it webpack nowadays?
    - arcanemachiner 3y ago
      It's JavaScript. Everyone is moving on to Turbopack. Or Vite. Or ESBuild. Or Bun.
      - sroussey 3y ago
        I definitely like the batteries included and speed of bun.
        arcanemachiner 3y ago
        Please don't tempt me.
    - brabel 3y ago
julianeon 3y ago
I think this comment is a bit out of date, especially if you’ve been watching JS from a distance for the past couple decades. This would’ve been true circa 2014. In 2023 it’s obsolete. There’s one framework that won, that’s all you have to learn, as far as the industry goes (as opposed to hobbyists) it’s been decided. React won. React is the framework you learn. “Popular frameworks for the past 6 years” - React has been dominant over that entire time period, from beginning to end. React is what you would’ve reached for 6 years ago (it was already mature then, in 2017) and it’s what you’d turn to now. This is what I mean. You could update your React code to use hooks instead of classes - or you could not, it will continue to work if you don’t. The “JS changes all the time” take is frankly out of date in 2023. “Which framework do I learn…” you learn React, the framework that won. It’s pretty much that simple.
- SanderNL 3y ago
  That’s a bubble. You are in a bubble. React is dominant, sure, like the US is dominant, but it’s not The World.
  - Hermitian909 3y ago
    The important part is that it's a bubble you can choose to live in. Companies everywhere use React and almost no one need ever choose to learn something else. As long as you know it you will be employable for another 20 years, just like with Java.
    - genmud 3y ago
      But people in that bubble keep shaming people who aren’t… and react keeps changing, so it’s not like you learn it once, it requires careful study and understanding of all the different permutations that are used in different environments. You generally can’t go from company A to company B who both use react and have the same calling convention, code structure or tool chains even though they are both using react.
    - SanderNL 3y ago
      Ouch, 20 years? I sincerely hope so for their sake, but I wouldn’t bet 10 dollars on it.
throwaway2037 3y ago
This is a great post. I'm not a web dev myself, but I have a couple on my team. I criminally underrated the challenge of maintaining a complex web app. It is madness: endless incompatible, forced upgrades. Real Question: Why does this ecosystem have this issue, but others have it less? For example: Why doesn't Python or Java have the same madness? Please don't read the question as criticizing web dev / JavaScript / etc. My curiosity is genuine. To be fair, it does feel like C++ is more maddening than Python or Java, but part of can be explained by (1) native code generation (build is way harder than languages that run in a VM) and (2) the insane complexity of the language which _traditionally_ made IDEs much weaker than other languages. MSFT Visual Studio and JetBrains CLion have come a long way. (I can already feel the HN pitchforks poking at me for these C++ comments!)
- oaiey 3y ago
  Because the originals parts where broken. I am speaking of 90s JavaScript, the DOM/Browser API and the not so much "batteries included". They could neither get fixed without a standard by committee approach of the browser vendors. So we started to compensate: end state: Typescript to fix JS, React/Angular/Svelte to fix DOM API and a npm package hell to have batteries included. And all of that bundles, compressed, etc to have a good download time.
  - owenpalmer 3y ago
    Yes. When JavaScript is your only option, the only solution to JavaScript is... more JavaScript :(
    - serallak 3y ago
      Seems like the old joke about XML: "XML is like violence: if it doesn't solve your problem, you're not using enough of it."
sroussey 3y ago
> I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving Welcome to real life. Beware the ecosystem that does not change (COBOL).

by genmud 3y ago

marcus_holmes 3y ago

The "new hotness" only matters if you're going to try and get a job as a FE dev in a large team. The "old hotness" still works, and likely has the more obscure bugs worked out of it. And you can always just write the thing in JS without any hotness at all. The JS ecosystem's obsession with frameworks is a diversion. You really only need a framework if your site is super complex. And even then, if you're careful about how you write your JS, you may not need a framework (you'll end up creating your own, probably). I'm with you that the JS ecosystem is a seething mess, but I don't think that's actually a problem unless you want a job as a FE dev. You can just ignore it ;)

Andrew_nenakhov 3y ago
I usually oppose the use of any new "hotness" in a project until that "hotness" is ~10 years old.
leidenfrost 3y ago
This. 90% of the toolchain is not required at all. Just quality of life improvements. Good ES6 (and TS) idiomatic code feels actually closer to reading Scala than reading a legacy Jquery app. And the V8 engine has so much investment in optimizations today that is actually closer to Java and in some cases lighter than Go. IMHO people don't hate JS in reality. They hate the strawman made of the worst parts of Junior code ever encountered and inconsistencies that really don't happen in practice unless you actively look for them.
- sroussey 3y ago
  Same could be said for php…

loveparade 3y ago

htmx is another tool just like that, another goalpost in the frontend webdev world. It's just happens that the most recent hype is "don't write JS", but fundamnetally it's no different. Just another framework/library that has gotten some traction. In a few years we'll be back full cycle and it will be in vogue to write JS again, probably because htmx and associated projects have grown to complex.

mkesper 3y ago
A key difference is the promise to be working even without JavaScript.
- vnorilo 3y ago
  "Htmx is a dependency-free, browser-oriented javascript library." https://htmx.org/docs/#installing https://htmx.org/docs/#installing
  - kkapelon 3y ago
    The framework itself is written in Javascript The end user is NOT writing Javascript.
- loveparade 3y ago
  It's no different from anything else. The promise if every framework is to abstract away some low-level details. Whether that means writing "higher-level JS" like jQuery did many years ago already, and hundreds of other frameworks do today, or inventing some new DSL like htmx does that translated to JS internally. No difference.

baby 3y ago

I’m pretty sure you can continue to use jquery and everything still works fine :D

zackify 3y ago
I’m over here continuing to use react for 9+ years but every post on here acts like it’s changing every day.
- alex_lav 3y ago
  Classes? Components as functions? Classes again? Hooks?
  - markmark 3y ago
    Classes still work fine if you want to keep using them.
    - alex_lav 3y ago
      This doesn't appear to be what the docs recommend anymore, which is exactly what my (obviously flippant) post was meant to highlight.
      - chatmasta 3y ago
        Hooks were introduced five years ago and have been stable since then. So that's half a decade with no changes to the API.
        alex_lav 3y ago
        Great! I bailed in the first four years I guess, after the fourth change in API.
- fredrikholm 3y ago
  https://www.youtube.com/watch?v=pd8kWJVDQD4 https://www.youtube.com/watch?v=pd8kWJVDQD4

hakfoo 3y ago

What I hate is that you don't even write JavaScript anymore. You write fantasy future JavaScript. Sure, it will be available in ECMAScript 23, scheduled to drop in real browsers in 2092. But for now, here's a convoluted mess of polyfills, Babel, and WebPack, that we HOPE papers over the real behaviour of browsers, and suddenly your test-and-debug cycle has introduced a flow-shattering 15-second build cycle each time you change a file.

The_Colonel 3y ago
There's actually no need for that anymore. JavaScript as is supported right now in the latest Chrome, Firefox and Safari is already pretty good. You can get quite far without any backend tooling these days. The only thing which I believe is still needed is a bundler when your project grows to a certain size. Fetching a complex graph of thousands of files will likely never be fast.
- number6 3y ago
  Do you still use gulp or is it webpack nowadays?
  - arcanemachiner 3y ago
    It's JavaScript. Everyone is moving on to Turbopack. Or Vite. Or ESBuild. Or Bun.
    - sroussey 3y ago
      I definitely like the batteries included and speed of bun.
      - arcanemachiner 3y ago
        Please don't tempt me.
  - brabel 3y ago

julianeon 3y ago

I think this comment is a bit out of date, especially if you’ve been watching JS from a distance for the past couple decades. This would’ve been true circa 2014. In 2023 it’s obsolete. There’s one framework that won, that’s all you have to learn, as far as the industry goes (as opposed to hobbyists) it’s been decided. React won. React is the framework you learn. “Popular frameworks for the past 6 years” - React has been dominant over that entire time period, from beginning to end. React is what you would’ve reached for 6 years ago (it was already mature then, in 2017) and it’s what you’d turn to now. This is what I mean. You could update your React code to use hooks instead of classes - or you could not, it will continue to work if you don’t. The “JS changes all the time” take is frankly out of date in 2023. “Which framework do I learn…” you learn React, the framework that won. It’s pretty much that simple.

SanderNL 3y ago
That’s a bubble. You are in a bubble. React is dominant, sure, like the US is dominant, but it’s not The World.
- Hermitian909 3y ago
  The important part is that it's a bubble you can choose to live in. Companies everywhere use React and almost no one need ever choose to learn something else. As long as you know it you will be employable for another 20 years, just like with Java.
  - genmud 3y ago
    But people in that bubble keep shaming people who aren’t… and react keeps changing, so it’s not like you learn it once, it requires careful study and understanding of all the different permutations that are used in different environments. You generally can’t go from company A to company B who both use react and have the same calling convention, code structure or tool chains even though they are both using react.
  - SanderNL 3y ago
    Ouch, 20 years? I sincerely hope so for their sake, but I wouldn’t bet 10 dollars on it.

throwaway2037 3y ago

This is a great post. I'm not a web dev myself, but I have a couple on my team. I criminally underrated the challenge of maintaining a complex web app. It is madness: endless incompatible, forced upgrades. Real Question: Why does this ecosystem have this issue, but others have it less? For example: Why doesn't Python or Java have the same madness? Please don't read the question as criticizing web dev / JavaScript / etc. My curiosity is genuine. To be fair, it does feel like C++ is more maddening than Python or Java, but part of can be explained by (1) native code generation (build is way harder than languages that run in a VM) and (2) the insane complexity of the language which _traditionally_ made IDEs much weaker than other languages. MSFT Visual Studio and JetBrains CLion have come a long way. (I can already feel the HN pitchforks poking at me for these C++ comments!)

oaiey 3y ago
Because the originals parts where broken. I am speaking of 90s JavaScript, the DOM/Browser API and the not so much "batteries included". They could neither get fixed without a standard by committee approach of the browser vendors. So we started to compensate: end state: Typescript to fix JS, React/Angular/Svelte to fix DOM API and a npm package hell to have batteries included. And all of that bundles, compressed, etc to have a good download time.
- owenpalmer 3y ago
  Yes. When JavaScript is your only option, the only solution to JavaScript is... more JavaScript :(
  - serallak 3y ago
    Seems like the old joke about XML: "XML is like violence: if it doesn't solve your problem, you're not using enough of it."

sroussey 3y ago

> I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving Welcome to real life. Beware the ecosystem that does not change (COBOL).