6 ms·

As someone who doesn't use JS frequently but still has to build some things ocasionally with it, it's funny how "Simple Modern Javascript" is a completely diffe

As someone who doesn't use JS frequently but still has to build some things ocasionally with it, it's funny how "Simple Modern Javascript" is a completely different beast each year. Libraries, UI frameworks, build systems, preprocessing tools, the JS community seems to have a knack for rebuilding everything from the ground up with almost zero backward compatibility with a frequency I haven't seen anywhere. For example, in this post already I see quite a lot of things that completely break how things were done in other projects or other frameworks. All for what? I don't see any improvements that would make such a break worthy. Another example, I recently had to upgrade a Vue 2 application to Vue 3, because Vue 2 is going EOL this year. Well, apparently that means I also had to change the build system from Webpack to Vite, the test library also was a "recommended change", the state store library was different and wasn't backwards compatible, and half the vue plugins required an update or a replacement for a Vue 3 compatible alternative. I have not seen this pace in other languages/environments. For example, in Python, there are different "build" systems (old setuptools, pip, poetry...) and yet they are all compatible. In C/C++ I still haven't heard of a framework that forces you to upgrade your build system when they push a new version.

Offler 4y ago
A React project wouldn't have the same issues.
flippinburgers 4y ago
I agree with you but it might be due to my own ignorance. I've done react, vue, and old school jquery and miss the days when javascript was just something you had a script tag for in your website. "Building" js projects and all of the other weird ... garbage ... that gets thrown in is just totally frustrating. The best I have been able to manage is to use esbuild + react + typescript in a very conservative fashion to keep things manageable for someone like my self: has a life and doesn't want that life to be consumed by yet-another-new-node-js-build-this-perpetually-differently-and-forever-and-with-much-pain system.
- madeofpalk 4y ago
  > miss the days when javascript was just something you had a script tag for in your website. What's to stop you from doing this now? In fact, in between all the fluff in the article, mentions of browser support for ES Modules makes this pretty straight forward. I used it recently for a small repro and i was surprised at how well it worked https://idb-perf-repro.netlify.app https://idb-perf-repro.netlify.app
selfmodruntime 4y ago
> Libraries, UI frameworks, build systems, preprocessing tools, the JS community seems to have a knack for rebuilding everything from the ground up with almost zero backward compatibility with a frequency I haven't seen anywhere The modern web industry isn't that old yet. Give it time. We've been writing C++ since 1985. React is 10 years old. Vue is 9 years old. Angular is 11 years old. The only "real" new kid on the block is Svelte, which is 7 years old now. The web constantly strives towards simplicity. React was developed because AngularJS was this huge enterprise framework of global state. React includes immutability to make things simpler. Vue was developed because its developers saw React (then with classes) as too complicated. It's loved to this day even by the HN crowd for its simplicity. Svelte again was developed because their developers saw the possibility to make updating the DOM simpler. Again, the HN crowd and its users love it, because Svelte really is dead simple. It's been my drug of choice for 2 years now and I'm seeing unbelievable productivity among friends and colleagues which choose to use it. The amount of libraries you see can be explained because of JS huge open source crowd, perhaps the largest among any language. There is no controlling entity, so people are free to write their own open source abstractions. We as an industry should see this as a good thing, because there are mountains of code now available for everyone, free of charge with MIT licensing. Startups can write applications that reach millions and generate billions, without worrying about QT licensing costs or paying for a Delphi compiler toolset. They need one codebase for an application that runs virtually the same on every device, mobile, tablet or desktop alike. > Another example, I recently had to upgrade a Vue 2 application to Vue 3, because Vue 2 is going EOL this year. Well, apparently that means I also had to change the build system from Webpack to Vite Again, Vite strives for simplicity. Vite is so simple that it took the industry by storm. Gone are the days of webpack 4 era configuration files that made you want to rip your hair out. Vite was written by Evan You, the man behind Vue, which could give you an indicator of the quality of the tool. I hate working on our C++ / QT enterprise product, because each change takes ages for me to see and verify. If that product was a web app (which we are currently looking into), I could see changes instantly, with application state persisting through recompilations. Grizzled seasoned developers have longed for a native application toolset that runs on every device for decades. Some just miss that web browsers do exactly that, with the added benefit of being a near perfect sandbox. Of course it's not perfect (yet?), but perfect is the enemy of good.
duxup 4y ago
I love the variety. But I understand how it can be head spinning. IMO the important thing is to find what works for you. I’d be wary of every other article out there that offers their ideas of the best way of doing anything web. Personally I wouldn’t consider the article’s solution “simple”.
- j45 4y ago
  It’s less about it being head spinning vs the need for it to be. Creating beginners is important. Having more attention to spend on the user than maintaining the brittleness that can be present is a real tax.
deleted 4y ago
[deleted]
jalapenos 4y ago
Frontend JS frameworks have been a meme for a while now. I think it's a combination of the front-end needing more boilerplate than back-end, and developers struggling with accounting. Maybe your cool new framework will save you 10% dev time, but you'll lose that 10% ten times over with the learning and error-bashing you and your teammates and future team members will have to go through. My policy is that you can use pure JS where a framework is overkill (I'll also accept jQuery), and React otherwise. React has emerged as the winner, and trying other things isn't worth the cost if you're paying (which employee developers are not). I recently built a small app using pure JS, just to remind myself how it used to be. It's definitely too verbose to avoid frustration. But HotNewFrameworkX vs React is never going to be big enough a benefit to be justified.
- alpinelogic 4y ago
  I'll just leave this here for the ones who have convinced themselves that react is the winner (whatever that means): https://andy-bell.co.uk/the-extremely-loud-minority/ https://andy-bell.co.uk/the-extremely-loud-minority/
  - psygn89 4y ago
    I feel like comparing Wordpress to React/Vue is strange. Do people build web apps using Wordpress these days? I know you can make Wordpress do more via extensions (site builder, e-commerce), but it seems weird creating something original with Wordpress to me, but I genuinely don't know what Wordpress is capable of these days. In the sense of what Wordpress was made for and the extensions available for it, it checks out to me that it would dominate the web landscape. As far as not blindly following the advice of web advocates, I agree - they live on the bleeding edge. Unfortunately these are the people the new and impressionable devs come across on social media and hold their words like gospel because look how many followers they have and look at who they worked for, they must be right! Web tech moves fast, especially the shiny frontend stuff, and that generates discussion and leads people to believe that everything else is obsolete when in reality it's not.
  - jalapenos 4y ago
    The winner means I can easily hire people who can develop on it from the get go, I can sell it without resistance, it's effective enough, and the business is aligned with productive output rather than technical oneupmanship.
deleted 4y ago
[deleted]
j45 4y ago
So much of the effort of extending JavaScript via many frameworks and the constant updating feels brittle. It makes having a relationship with a stable piece of code challenging to move on to the next big function. Over time, maintaining anything too old or too new can drag momentum and progress. Still it’s one of the most universal technologies. Some of the more recent simple frameworks like alpine.js, or lit as I rediscovered today on HN may have more merit than initially realized.
323 4y ago
> I have not seen this pace in other languages/environments. For example, in Python It happens in Python too. For example in ML, in 2015 everybody was using torch, then Keras, then TensorFlow, then PyTorch. Pandas now being replaced by Polars. If you look at MLOps, every 3 months there is a new hot library. In other words, it happens in the active parts of the ecosystem (data-science), not in the old stable ones (standard library, reading files, ...)
- gjulianm 4y ago
  It’s one thing that the “standard library for X” changes every few years. The problem is when upgrades within the same library are backward incompatible, or require changes in unrelated things (such as the build system), or when the library gets dropped completely from support.
- brahbrah 4y ago
  Just want to point out that polars is not a complete replacement for pandas and they will likely live side by side in the data ecosystem. One of the main and original intentions of pandas is replacing highly dynamic and changing excel models for financial, econometric and physical systems. The rigid structure of polars syntax while great for stability and optimization is not practical for research/development iteration of these kinds of models.
- andybak 4y ago
  > It happens in Python too. Python ML maybe. That's a different community to Python in general. The only place where there's been churn in general Python is probably package management.
  - 323 4y ago
    10 years ago there was a new Python web framework every month. Now that space is pretty much stable (dead). The fact that JavaScript front-end is going through so much churn just shows that it's not obvious yet what the proper design looks like. Rust is going through the same thing now with GUI frameworks, every couple months a new approach appears. Because it's not obvious yet what's the proper design for a Rust GUI API.
remorses 4y ago
Probably because all tooling comes from open source developers that are simply not happy with the status quo and are trying to improve things doing what they can, see Webpack, Babel, Vite, pnpm What we really need is an end to end echo-system with funding, adoption and vision. Deno and Bun are both getting in this direction
TheRealDunkirk 4y ago
I must point out for the record that this problem isn't novel. Apologies for bringing up his name here, but JWZ labeled this phenomenon "CADT," the "cascade of attention-defecit teenagers" model of development, all the way back in 2003.
mwexler 4y ago
To paraphrase a trite and old SNL line: "Simple Modern JS from last year is neither simple nor modern. Discuss amongst yourselves" Ala https://en.m.wikipedia.org/wiki/Coffee_Talk_(Saturday_Night_Live)#Discussion_topics https://en.m.wikipedia.org/wiki/Coffee_Talk_(Saturday_Night_...
dawnerd 4y ago
JS backends do the same thing too. Hapijs had a habit for a long time of making breaking changes often. Most recently for me was Strapi which took everything and threw it out the window with really no way to upgrade that didn't also involve re-writing a ton of code. It's exhausting. This is what makes me want to just stick with the old tried and true tools (like WordPress).
rk06 4y ago
It sucks. But part of the reason is ecosystem shift. commonjs to esm is a massive shift. esbuild in place of babel is a ground breaking achievement. Vite, which leverages ESM and esbuild, is very different, and better than webpack. The ecosystems which haven't changed, I. E. react and angular, are either in middle of transition or suffering from not doing it.
gemstones 4y ago
I love JS, but I agree with all of this. I will say that vite/parcel/etc. are genuinely simpler and worth the migration headaches. (They are also built in Go/Rust, which should probably cause some self-reflection in the Javascript community.)
eckza 4y ago
Give Elm a shot. We haven't had a breaking change to the current version since August 2018: https://github.com/elm/compiler/tags https://github.com/elm/compiler/tags In fact, the single most frequent criticism of our community is, "Is Elm dead? It hasn't been updated in years". The truth of the matter is that it's not dead; it's just really stable. Everything still works. You can use a bundler, like Vite or Parcel, but you don't really have to. You can use whatever Javascript library you like, through ports or web components, but again: you don't really have to, unless you need to do interop with another service (i.e., Google reCAPTCHA or Stripe) - and in that case, you're at their mercy regardless of whether you're building your application in Elm, or in something else. Compared to the rest of the JS ecosystem, we have virtually zero dependencies on outside tools or infra, other than Github; but if Github "goes away", I'd be willing to bet that the rest of the Javascript ecosystem would be in a lot of trouble, too. We are a small but passionate developer community. Enough of us - myself included - do this full time for it to feel like it's a safe bet and that it's not going anywhere anytime soon. Join us. https://elmlang.slack.com/ https://elmlang.slack.com/
- jcparkyn 4y ago
  > it's not dead; it's just really stable. Am I the only one who thinks this idea is somewhat contradicted by the TODOs that are still in the official docs, and seem to have been for years?
- philote 4y ago
  Elm looks quite interesting, I may have to try it out. But I feel that for many JS/TS devs, it may be too much of a jump to move to a functional language.
adhoc_slime 4y ago
I did the vue2 - vue3 upgrade, while I see what you're saying and actually agree, I have no idea why you had change your build tool from webpack to Vite. I'm still on webpack, for better or worse.
- gjulianm 4y ago
  Webpack wasn’t on the list of supported build systems when I made the upgrade, don’t know if it still isn’t there. I preferred to waste time making a supported build system work than wasting it making an unsupported one work.

Offler 4y ago

A React project wouldn't have the same issues.

flippinburgers 4y ago

I agree with you but it might be due to my own ignorance. I've done react, vue, and old school jquery and miss the days when javascript was just something you had a script tag for in your website. "Building" js projects and all of the other weird ... garbage ... that gets thrown in is just totally frustrating. The best I have been able to manage is to use esbuild + react + typescript in a very conservative fashion to keep things manageable for someone like my self: has a life and doesn't want that life to be consumed by yet-another-new-node-js-build-this-perpetually-differently-and-forever-and-with-much-pain system.

madeofpalk 4y ago
> miss the days when javascript was just something you had a script tag for in your website. What's to stop you from doing this now? In fact, in between all the fluff in the article, mentions of browser support for ES Modules makes this pretty straight forward. I used it recently for a small repro and i was surprised at how well it worked https://idb-perf-repro.netlify.app https://idb-perf-repro.netlify.app

selfmodruntime 4y ago

> Libraries, UI frameworks, build systems, preprocessing tools, the JS community seems to have a knack for rebuilding everything from the ground up with almost zero backward compatibility with a frequency I haven't seen anywhere The modern web industry isn't that old yet. Give it time. We've been writing C++ since 1985. React is 10 years old. Vue is 9 years old. Angular is 11 years old. The only "real" new kid on the block is Svelte, which is 7 years old now. The web constantly strives towards simplicity. React was developed because AngularJS was this huge enterprise framework of global state. React includes immutability to make things simpler. Vue was developed because its developers saw React (then with classes) as too complicated. It's loved to this day even by the HN crowd for its simplicity. Svelte again was developed because their developers saw the possibility to make updating the DOM simpler. Again, the HN crowd and its users love it, because Svelte really is dead simple. It's been my drug of choice for 2 years now and I'm seeing unbelievable productivity among friends and colleagues which choose to use it. The amount of libraries you see can be explained because of JS huge open source crowd, perhaps the largest among any language. There is no controlling entity, so people are free to write their own open source abstractions. We as an industry should see this as a good thing, because there are mountains of code now available for everyone, free of charge with MIT licensing. Startups can write applications that reach millions and generate billions, without worrying about QT licensing costs or paying for a Delphi compiler toolset. They need one codebase for an application that runs virtually the same on every device, mobile, tablet or desktop alike. > Another example, I recently had to upgrade a Vue 2 application to Vue 3, because Vue 2 is going EOL this year. Well, apparently that means I also had to change the build system from Webpack to Vite Again, Vite strives for simplicity. Vite is so simple that it took the industry by storm. Gone are the days of webpack 4 era configuration files that made you want to rip your hair out. Vite was written by Evan You, the man behind Vue, which could give you an indicator of the quality of the tool. I hate working on our C++ / QT enterprise product, because each change takes ages for me to see and verify. If that product was a web app (which we are currently looking into), I could see changes instantly, with application state persisting through recompilations. Grizzled seasoned developers have longed for a native application toolset that runs on every device for decades. Some just miss that web browsers do exactly that, with the added benefit of being a near perfect sandbox. Of course it's not perfect (yet?), but perfect is the enemy of good.

duxup 4y ago

I love the variety. But I understand how it can be head spinning. IMO the important thing is to find what works for you. I’d be wary of every other article out there that offers their ideas of the best way of doing anything web. Personally I wouldn’t consider the article’s solution “simple”.

j45 4y ago
It’s less about it being head spinning vs the need for it to be. Creating beginners is important. Having more attention to spend on the user than maintaining the brittleness that can be present is a real tax.

deleted 4y ago

[deleted]

jalapenos 4y ago

Frontend JS frameworks have been a meme for a while now. I think it's a combination of the front-end needing more boilerplate than back-end, and developers struggling with accounting. Maybe your cool new framework will save you 10% dev time, but you'll lose that 10% ten times over with the learning and error-bashing you and your teammates and future team members will have to go through. My policy is that you can use pure JS where a framework is overkill (I'll also accept jQuery), and React otherwise. React has emerged as the winner, and trying other things isn't worth the cost if you're paying (which employee developers are not). I recently built a small app using pure JS, just to remind myself how it used to be. It's definitely too verbose to avoid frustration. But HotNewFrameworkX vs React is never going to be big enough a benefit to be justified.

alpinelogic 4y ago
I'll just leave this here for the ones who have convinced themselves that react is the winner (whatever that means): https://andy-bell.co.uk/the-extremely-loud-minority/ https://andy-bell.co.uk/the-extremely-loud-minority/
- psygn89 4y ago
  I feel like comparing Wordpress to React/Vue is strange. Do people build web apps using Wordpress these days? I know you can make Wordpress do more via extensions (site builder, e-commerce), but it seems weird creating something original with Wordpress to me, but I genuinely don't know what Wordpress is capable of these days. In the sense of what Wordpress was made for and the extensions available for it, it checks out to me that it would dominate the web landscape. As far as not blindly following the advice of web advocates, I agree - they live on the bleeding edge. Unfortunately these are the people the new and impressionable devs come across on social media and hold their words like gospel because look how many followers they have and look at who they worked for, they must be right! Web tech moves fast, especially the shiny frontend stuff, and that generates discussion and leads people to believe that everything else is obsolete when in reality it's not.
- jalapenos 4y ago
  The winner means I can easily hire people who can develop on it from the get go, I can sell it without resistance, it's effective enough, and the business is aligned with productive output rather than technical oneupmanship.

deleted 4y ago

[deleted]

j45 4y ago

So much of the effort of extending JavaScript via many frameworks and the constant updating feels brittle. It makes having a relationship with a stable piece of code challenging to move on to the next big function. Over time, maintaining anything too old or too new can drag momentum and progress. Still it’s one of the most universal technologies. Some of the more recent simple frameworks like alpine.js, or lit as I rediscovered today on HN may have more merit than initially realized.

323 4y ago

> I have not seen this pace in other languages/environments. For example, in Python It happens in Python too. For example in ML, in 2015 everybody was using torch, then Keras, then TensorFlow, then PyTorch. Pandas now being replaced by Polars. If you look at MLOps, every 3 months there is a new hot library. In other words, it happens in the active parts of the ecosystem (data-science), not in the old stable ones (standard library, reading files, ...)

gjulianm 4y ago
It’s one thing that the “standard library for X” changes every few years. The problem is when upgrades within the same library are backward incompatible, or require changes in unrelated things (such as the build system), or when the library gets dropped completely from support.
brahbrah 4y ago
Just want to point out that polars is not a complete replacement for pandas and they will likely live side by side in the data ecosystem. One of the main and original intentions of pandas is replacing highly dynamic and changing excel models for financial, econometric and physical systems. The rigid structure of polars syntax while great for stability and optimization is not practical for research/development iteration of these kinds of models.
andybak 4y ago
> It happens in Python too. Python ML maybe. That's a different community to Python in general. The only place where there's been churn in general Python is probably package management.
- 323 4y ago
  10 years ago there was a new Python web framework every month. Now that space is pretty much stable (dead). The fact that JavaScript front-end is going through so much churn just shows that it's not obvious yet what the proper design looks like. Rust is going through the same thing now with GUI frameworks, every couple months a new approach appears. Because it's not obvious yet what's the proper design for a Rust GUI API.

remorses 4y ago

Probably because all tooling comes from open source developers that are simply not happy with the status quo and are trying to improve things doing what they can, see Webpack, Babel, Vite, pnpm What we really need is an end to end echo-system with funding, adoption and vision. Deno and Bun are both getting in this direction

TheRealDunkirk 4y ago

I must point out for the record that this problem isn't novel. Apologies for bringing up his name here, but JWZ labeled this phenomenon "CADT," the "cascade of attention-defecit teenagers" model of development, all the way back in 2003.

mwexler 4y ago

To paraphrase a trite and old SNL line: "Simple Modern JS from last year is neither simple nor modern. Discuss amongst yourselves" Ala https://en.m.wikipedia.org/wiki/Coffee_Talk_(Saturday_Night_Live)#Discussion_topics https://en.m.wikipedia.org/wiki/Coffee_Talk_(Saturday_Night_...

dawnerd 4y ago

JS backends do the same thing too. Hapijs had a habit for a long time of making breaking changes often. Most recently for me was Strapi which took everything and threw it out the window with really no way to upgrade that didn't also involve re-writing a ton of code. It's exhausting. This is what makes me want to just stick with the old tried and true tools (like WordPress).

rk06 4y ago

It sucks. But part of the reason is ecosystem shift. commonjs to esm is a massive shift. esbuild in place of babel is a ground breaking achievement. Vite, which leverages ESM and esbuild, is very different, and better than webpack. The ecosystems which haven't changed, I. E. react and angular, are either in middle of transition or suffering from not doing it.

gemstones 4y ago

I love JS, but I agree with all of this. I will say that vite/parcel/etc. are genuinely simpler and worth the migration headaches. (They are also built in Go/Rust, which should probably cause some self-reflection in the Javascript community.)

eckza 4y ago

Give Elm a shot. We haven't had a breaking change to the current version since August 2018: https://github.com/elm/compiler/tags https://github.com/elm/compiler/tags In fact, the single most frequent criticism of our community is, "Is Elm dead? It hasn't been updated in years". The truth of the matter is that it's not dead; it's just really stable. Everything still works. You can use a bundler, like Vite or Parcel, but you don't really have to. You can use whatever Javascript library you like, through ports or web components, but again: you don't really have to, unless you need to do interop with another service (i.e., Google reCAPTCHA or Stripe) - and in that case, you're at their mercy regardless of whether you're building your application in Elm, or in something else. Compared to the rest of the JS ecosystem, we have virtually zero dependencies on outside tools or infra, other than Github; but if Github "goes away", I'd be willing to bet that the rest of the Javascript ecosystem would be in a lot of trouble, too. We are a small but passionate developer community. Enough of us - myself included - do this full time for it to feel like it's a safe bet and that it's not going anywhere anytime soon. Join us. https://elmlang.slack.com/ https://elmlang.slack.com/

jcparkyn 4y ago
> it's not dead; it's just really stable. Am I the only one who thinks this idea is somewhat contradicted by the TODOs that are still in the official docs, and seem to have been for years?
philote 4y ago
Elm looks quite interesting, I may have to try it out. But I feel that for many JS/TS devs, it may be too much of a jump to move to a functional language.

adhoc_slime 4y ago

I did the vue2 - vue3 upgrade, while I see what you're saying and actually agree, I have no idea why you had change your build tool from webpack to Vite. I'm still on webpack, for better or worse.

gjulianm 4y ago
Webpack wasn’t on the list of supported build systems when I made the upgrade, don’t know if it still isn’t there. I preferred to waste time making a supported build system work than wasting it making an unsupported one work.