9 ms·

The Shocking Immaturity of JavaScript

74 points by mjgardner 5y ago

tored 5y ago
Best career choice I did in my life was quitting frontend dev, I was in deep as frontend architect and similar senior positions. I still need to do some pure JavaScript frontend occasionally and every time it is even more mad than before. Always reminds me what hellhole I managed to escape.
sam_goody 5y ago
When a language becomes stable, it also begins to lose popularity. (This is widely discussed). Javascript is the only language that has continued to grow forever without becoming an "old" language in dev mindset. One reason is the constant churn of tooling, another is the immaturity of everything, so every generation of devs have a place to add something. Overall JS gains more than it loses. This is similar to the concept that the first buggy language to capture mindshare will eventually fix its bugs and leave the initially more perfect competitors behind.
- code_biologist 5y ago
  Worse is better, it still seems.
- laurent92 5y ago
  But all these improvements should mean productivity improvements. But my engineers still aren’t able after 18 months on a React project to churn screens like we did with Freemarker+jQuery (=with bare hands, technology-wise). Every new tool should accelerate the pace, but JS doesn’t seem to deliver.
  - roofwellhams 5y ago
    If you do it properly saves time. I'm pretty sure something you guys doing might be wrong. Or maybe previous code in jQuery was not great in terms of architecture.
- bronlund 5y ago
  The main reason JavaScript is still "popular", is that you are more or less forced to use it if you are targeting web browsers. And since web developers had to spend a lot of time learning that crap, combined with that whole DevOps culture, they ended up wanting to use JavaScript on the backend as well. Which is such a bad idea it's difficult to explain even. People are starting to realize that this whole JavaScript ecosystem was a huge mistake. The level of complexity a typical Node framework introduces, compared to the benefits you get from using it, is just silly. A typical web developer doesn't understand this fact and naturally feels stupid when trying to figure this thing out. Some are moving back to PHP or Ruby, others forward using Go or Elixir or such. Even ASP.NET is simpler to work with than Node and friends, and that is telling a lot.
- BiteCode_dev 5y ago
  Well having a monopoly on the most popular and power programming platform of the planet, the web browser, will do that. In fact, remove the browser monopoly, and give it to Visual Basic, and in 3 years, VB will be the most popular language of the world.
  - emerged 5y ago
    That’s the thing about JS. It’s popular because it was first and grew into a monopoly. The language itself is horrific. We are permanently stuck with a poorly designed language because it has momentum which can’t be overcome.
stareatgoats 5y ago
It is a lost cause to rationally try and sort out what if anything is chronically wrong with js, ruby, haskell, c (or any language of choice). They each have their pros and cons, and have evolved differently for different reasons. Since programming languages many times (seemingly) are like a dear spouse to its disciples such discussions generally devolve into endless and meaningless comparisons, if not worse. The article obviously panders to ruby sentiments, and the javascript experience can obviously be frustrating to that community, as might ruby to a mainly javascript developer. Might we just leave it at that?
- jspash 5y ago
  I think the big difference with JS is that if you're doing just about anything in Web Dev these days, you MUST use JS (with a few exceptions). Don't like PHP? Try Python. Why not Go, Scala or Rust? Don't like Ruby? Move to Elixir (no really, do it! you won't regret it) But with JS you're stuck with JS - at least Typescript makes things a bit more sane. So until the browser monopoly ends and something supplants JS as one of the only ways to make a dynamic website, it will have to take the heat. The best experience I've encountered is with LiveView in the Elixir/Phoenix world. It still needs JS for the plumbing (websockets) but I no longer have to write JS. Happy days!
mjburgess 5y ago
> From backend ORMs and headless APIs to frontend site generators, package managers, and build tools—it's a miracle any of it actually works properly in production! I think the issue is clear from this first sentence. Why are there any of these things in javascript? The marvel is that in 2021 such a sentence can be written -- that these things are immature seems both obvious and to miss the point.
- laurent92 5y ago
  So engineers only have one language to absolutely master. This really hit home: Trying to recruit a Java + SpringBoot + Angular engineer is 1 order of magnitude harder than a NodeJS + Angular engineer.
  - mjburgess 5y ago
    Why not generalise SQL with classes, loops (, etc.) and truly single-language the world? And an SQL configuration language ("UPDATE aws.ec2.config ...") ? Typescript is a testament to the extreme amount of work needed to normalize a scrappy browser-lang for robust use. The issue is precisely that a community of "SQL developers" are not going to build you robust tools, merely by having generalised SQL. And likewise, a community of browser developers aren't going to either. Single-languaging down to effectively a DSL produces a particular type of community (, language, domain of competence, ...), which is exactly what OP is complaining about.
  - tjpnz 5y ago
    Languages aren't hard to learn once you've got 1-2 under your belt. FWIW I wouldn't consider myself to have "absolute mastery" in any language, there are some I'm more comfortable with than others but even when I'm not I can still be productive.
    - heipei 5y ago
      They might not be hard to learn, but it's still a considerable mental overhead to switch between writing JS on the frontend and anything but JS on the backend. I frequently mix up the simplest things, like len(list) vs list.length, or how that you can't use obj.property on Python dicts, or list.append() vs array.push(), etc. And then you might have a great tooling library in one ecosystem (like lodash in JS) and try to replicate the things in your backend language. That sort of context-switching simply isn't worth it in my opinion.
kitd 5y ago
I did web dev for a few years using Angular + various other tools, and yes, it was nightmarish. I had to come back to it briefly recently. But using "boring" Typescript, esbuild and preact, I have to say the experience was an immeasurable improvement. Verging on pleasant even. Everything was well-documented with strong Stackoverflow coverage. So, boring > shiny
- cageface 5y ago
  Typescript, esbuild, and preact would have been described as shiny not very long ago. These things take time to mature. I agree that the current JS ecosystem is fine if you don't get too far off into the weeds with obscure dependencies.
- ramchip 5y ago
  Wasn't esbuild released literally last year?
  - Ygg2 5y ago
    In JS terms, that's like a dinosaur.
- 5e92cb50239222b 5y ago
  You probably already know this, but for anyone wanting to do this: esbuild does not do any type checking, so TypeScript with pure esbuild (without a separate tsc step) is only half useful (it gives you better autocompletion, but not much else). https://esbuild.github.io/content-types/#typescript https://esbuild.github.io/content-types/#typescript
  - BiteCode_dev 5y ago
    You IDE should check the types for you.
    - johnnypangs 5y ago
      This might worked on solo projects but if you’re working with people, I’d highly recommend enforcing type checking of some sort. People will ignore the IDE error messages.
egeozcan 5y ago
IMHO, JS is has more mature parts than any other language. It's fast, stable, portable, practical and for every problem you could imagine, there's an answer on Stack Overflow, immense community, easy to learn (while hard to master, like the English language). The problem is, the popularity also brings huge amount of immaturity. So, it also has more immature parts than every other language too! People keep adding new libraries, trying to promote them, and most of them are indeed beginners, because when most people start programming, they do learn JS mainly, or as an addition. Yeah, JS has a very small standard library which exacerbates the problem but if you look at the amount of libraries that do what they do best and are stable, I guess no ecosystem is anywhere close. Beginners should just follow the happy path, and it almost always works fine. People can use "create-react-app" or "express.js" or "lithtml"... But just learn the language too. I use next.js myself and am surprised how everything just works. I can't say the same for many C# frameworks (and from Microsoft nonetheless).
- arbol 5y ago
  ... happy path... Having come back to JS recently after years away I feel that typescript should be the recommended way of interacting with JS. It makes it much easier to write code with reduced bugs.
- 5e92cb50239222b 5y ago
  I try not to use any libraries that were introduced less than 5-6 years ago. Thanks to this I don't experience much library churn and don't have to rewrite the same thing every few months. For example, I didn't pick up React until 2020. Let the kids play with their shiny toys if that's what they want.
  - dgb23 5y ago
    I think this is a smart heuristic if you optimize for stability. Incidentally, you started to learn React when it's API's got drastically simplified over the previous class based approach. You joined at the right time so to speak. But I want to add that play isn't just for kids. For me, it is an important part of my life and work. Deliberate, free play gets you in a different mode, it's fun and worth doing without some external reward. Does it have to be new, "shiny" toys? Not at all! That's the nice thing about it.
awestroke 5y ago
All this complaining about churn is ignoring what the churn stems from. There's constant, incredible evolution in the JS ecosystem. Some examples : * New syntax that makes JS so much more expressive than before, like arrow functions, spreads and null operators * Typescript has made development so much better and reduces the need to unit test structure * React was a paradigm shift when it came. React hooks is another paradigm shift, I've written code in the last few months that would have been so much harder to write and been much more buggy without hooks I spend at most a few hours per month upgrading packages and dealing with churn. It's a small price to pay
- laurent92 5y ago
  Isn’t React slow, only able to manage tables of a few dozen rows before slowing down to hell, hence starting the trend of tables paginated by 10 rows only? Isn’t that the cost of hooks?
  - fabian2k 5y ago
    React doesn't have an inherent problem with larger tables, and there are quite a few libraries to virtualize long lists or tables if yours are very large and you need the performance. React performance can be a bit tricky to handle if you don't understand how React rendering works and when React will render. But that's not really different from most things, performance is something that you often cannot abstract away entirely.
  - awestroke 5y ago
    I've written code that would have been incredibly hard be made performant without React. With React, vittualizing rendering to only render visible elements is a breeze thanks to the inherent composability of react components, and now also hooks. React is not the performance bottleneck, the DOM is
    - dotancohen 5y ago
      > React is not the performance bottleneck, the DOM is. I think that's pushing the blame just a layer too deep. It's like saying that engines are not holding up hypersonic missile development, the thick atmosphere is.
e67f70028a46fba 5y ago
the way to deal with the immaturity of javascript is to build instead off mature technologies like hypermedia Hotwire and htmx do this
spinningslate 5y ago
Complexity and instability in the JS ecosystem is a hot button for me, so it's hard not to be drawn into vehement agreement. I've been doing a little work recently with htmx[0] and it's a breath of fresh air. But then, I'm at the point in my career where "cool new tech" is much less interesting for its own sake than it used to be when I was younger. I'm drawn far more to elegant, understandable, productive simplicity these days. I think that hints at the reason we have these endless debates - not just about JS but about $(your-favourite-tech). Software development is a socio-technical endeavour. We put all the focus on the technical part, and by comparison, rarely consider the social aspect. DHH is one of the few I've heard actually refer to this, on the corecursive podcast [1]. In discussing static typing vs dynamic, his point is the latter suits his brain. But that he understands and accepts static typing suits others, and that's fine. So I get that, for some, the JS ecosystem is dynamic and interesting; stimulating; exhilarating even. For others, it's an unstable quicksand that gets in the way of doing something useful. [0]: https://htmx.org/ https://htmx.org/ [1]: https://corecursive.com/045-david-heinemeier-hansson-software-contrarian/ https://corecursive.com/045-david-heinemeier-hansson-softwar...
based2 5y ago
https://www.javabrahman.com/java-8/java-8-multiple-inheritance-conflict-resolution-rules-and-diamond-problem/ https://www.javabrahman.com/java-8/java-8-multiple-inheritan... https://stackoverflow.com/questions/561729/can-the-diamond-problem-be-really-solved/561768#561768 https://stackoverflow.com/questions/561729/can-the-diamond-p...
onion2k 5y ago
The ecosystem of JavaScript frameworks is almost unbelievably unstable. Popularity isn't a measure of quality of course, but if you're going to make a statement like "JavaScript frameworks are almost unbelievably unstable" you probably ought to cite some sort of evidence for that because reality is very much against you. There are about 10,000,000 React websites[1] compared to 95,000 Rails[2] websites. There are 325,000,000 websites that use JS[3] I mean, JS can't be that bad in the face of those numbers, can it? JS developers aren't all getting it wrong are they? [1] https://trends.builtwith.com/websitelist/React https://trends.builtwith.com/websitelist/React [2] https://trends.builtwith.com/websitelist/Ruby https://trends.builtwith.com/websitelist/Ruby [3] https://trends.builtwith.com/javascript/traffic/Entire-Internet https://trends.builtwith.com/javascript/traffic/Entire-Inter...
- Havoc 5y ago
  That's like saying there are X million humans driving therefore humans can't be that bad at driving. There is really not much of a connection between those dots
  - onion2k 5y ago
    Humans are amazing at driving. Given how many billions of miles are driven every day, the number of accidents is mind-bogglingly tiny. You'd think there would be many, many more. That is quite a good analogy to JS actually.
- andybak 5y ago
  I don't understand how the numbers you've posted here support your argument. You said it yourself "Popularity isn't a measure of quality" and then go on to imply that it does.
  - onion2k 5y ago
    I'm not suggesting JS is particularly high quality; I'm just saying that it's not completely broken. There's a middle-ground where it can be both good enough quality to be usable, and good enough to not be considered broken. Given the fact JS is used by hundreds of thousands of developers it is obviously not totally broken, so if you're going to say it is you need some very strong evidence to back that up. Half the time when I see "JS is so broken!" posts they're by Ruby devs. I can't help wonder why they're all so keen to move away from Ruby.
tyronehed 5y ago
I agree with this 1000%.
BiteCode_dev 5y ago
It's was my take in 2015, when saying it then got you bashed to death. Now you can say it, since people have been burnt enough to admit it, but ironically it's actually less true. Yes, the JS language is always hackish. The stdlib sucks and the ecosystem is a Jenga tower. A lot of JS projects are still what I call "disposable code bases". But. Modern JS is tolerable. Functions are now decent, you have let/const, map/filter... There are even some nice things: • spread and destructuring, and they play well with the limited data structures. • simplest async paradigm ever: immediate schedule, and returns a Future, may attach a callback or prefix with await. • concise arrow functions. • ? and ?? operators. I actually miss them in Python. Tooling has improved tenfold: • VSCode gives you good code intelligence out of the box. • any build tool will solve imports, scoping, "this" weirdness, browser compat, etc. • new gen builders, such as ViteJS (or anything based on rollup/esbuild), are fast, reliable, and have sane default. No more webpack trouble. • new gen packagers, such as pnpm, are fast, reliable, and save a ton of disk space. No more "takes 10 minutes, download the entire internet 3 times". • with VueJS (SPA), htmx (ajaxify Django, Rails, Laravel...) and petite-vue (progressive enhancement), front end dev is almost fun. And light. • Typescript. Now, I still avoid JS if I can. I don't like having to google simple things like type coercion or how to left trim a string. As soon as I can go Python, I do so. It's hard to beat Django or FastApi for the web, Typer for scripting, pandas for data analysis, pytest and robotframework for testing, or just the stdlib/pypi.org for pretty much everything. And with shiv and nuitka, deployment is now on a different level. But when I have to use JS, I don't dread it anymore.
- samastur 5y ago
  And I think the article is largely correct even though I don't dread developing Javascript-based applications. One of our Nuxt applications with default build configuration sometimes builds successfully and sometimes fails miserably for reasons not understood. So we just run the process until it succeeds. I would never tolerate this in Python or take it as lightly as I do here, but like a frog in hot water I've been conditioned to almost expect it or at least not get too bothered by it. I think Javascript the language is fine. But the rest of ecosystem feels enormously creative, myopic and too often fragile.
- zengargoyle 5y ago
3np 5y ago
The title misses the point. You can have a perfectly stable JS experience if you let go of the need to stay on top of the latest trends. I've done node.js since it came out and I stopped feeling like the author about 5 years ago. I've continued developed in js regularly but am generally "out of the loop" with regards to web framework trends etc. Apart from deprecations of request and moment and the occasional syntactic sugar, not much has changed in years now. Just the other day I made a greenfield web project for the first time in a long time, took me about one intermittent day to get from 0 to "good enough" with a couple of views. typescript, hapi, and pug. It doesn't have to be complicated. https://codeberg.org/3np/rimgu https://codeberg.org/3np/rimgu (Not saying this is a perfect project and you may argue it falls under the "do x in 10 mins fallacy" but if you think JS projects have to be complicated and unstable - they don't have to) Also, I find it unexpected hearing that comparison with Ruby. I've spent way too much time struggling with Ruby deprecations, buid systems, linters, and broken or undocumented web frameworks (Grape) that I think Python may be the one better comparison. And really, which ecosystem with comparable legacy has a significantly better track-record of webdev stability? Java? .NET? PHP? Go? It's a mess everywhere.
jokethrowaway 5y ago
I can understand new libraries being crappy, it takes time to get good and that's why you should pick well established libraries. True, the hype machine is huge in the js world and the superstars in it are better marketers on twitter than coders. I'm not going to touch anything graphql related for at least 5 more years and hopefully I will never have to touch it. React became decent last year when next started being mature enough. What I don't like is all the transpiling and new language features getting to js. The single worst decision was to swap require for import. I don't care how much better the new model is, it broke too much stuff and I feel pain at least once a week because of that crap. Frankly, that's a nightmare and I think it will be years before it's decent to use - or maybe we'll need deno to get there. I swapped js with rust (+rocket) for all my personal projects and it's been nice - but I'm still stuck with js on a few projects where I'm collaborating with other developers who are not going to realistically learn rust.
Havoc 5y ago
Big part of the issue is that it's quite hard for newbies to tell what is JS and what is the framework and what is a web standard.
marstall 5y ago
Not saying you're wrong - but a few examples or stories would help sell this idea.
arcanon 5y ago
Does anyone else think it’s weird that trivial syntax/typesystem frameworks get very popular whereas things that actually move tech forward, like new apis/webgpu dont get much hype? Maybe it just seems this way. I mean how many ways can we come up with to watch ppl struggle to build 2D form applications?
atom_arranger 5y ago
A part of this is that the tooling mostly depends on huge trees of dependencies. If top level tools devs interacted with bundled more of their deps things might be less likely to break, at the cost of a bigger node_modules folder. Right now you occasionally run into situations where Webpack or ESLint stops working right because is-even released a bad patch update.

74 points by mjgardner 5y ago

Best career choice I did in my life was quitting frontend dev, I was in deep as frontend architect and similar senior positions. I still need to do some pure JavaScript frontend occasionally and every time it is even more mad than before. Always reminds me what hellhole I managed to escape.

sam_goody 5y ago

When a language becomes stable, it also begins to lose popularity. (This is widely discussed). Javascript is the only language that has continued to grow forever without becoming an "old" language in dev mindset. One reason is the constant churn of tooling, another is the immaturity of everything, so every generation of devs have a place to add something. Overall JS gains more than it loses. This is similar to the concept that the first buggy language to capture mindshare will eventually fix its bugs and leave the initially more perfect competitors behind.

code_biologist 5y ago
Worse is better, it still seems.
laurent92 5y ago
But all these improvements should mean productivity improvements. But my engineers still aren’t able after 18 months on a React project to churn screens like we did with Freemarker+jQuery (=with bare hands, technology-wise). Every new tool should accelerate the pace, but JS doesn’t seem to deliver.
- roofwellhams 5y ago
  If you do it properly saves time. I'm pretty sure something you guys doing might be wrong. Or maybe previous code in jQuery was not great in terms of architecture.
bronlund 5y ago
The main reason JavaScript is still "popular", is that you are more or less forced to use it if you are targeting web browsers. And since web developers had to spend a lot of time learning that crap, combined with that whole DevOps culture, they ended up wanting to use JavaScript on the backend as well. Which is such a bad idea it's difficult to explain even. People are starting to realize that this whole JavaScript ecosystem was a huge mistake. The level of complexity a typical Node framework introduces, compared to the benefits you get from using it, is just silly. A typical web developer doesn't understand this fact and naturally feels stupid when trying to figure this thing out. Some are moving back to PHP or Ruby, others forward using Go or Elixir or such. Even ASP.NET is simpler to work with than Node and friends, and that is telling a lot.
BiteCode_dev 5y ago
Well having a monopoly on the most popular and power programming platform of the planet, the web browser, will do that. In fact, remove the browser monopoly, and give it to Visual Basic, and in 3 years, VB will be the most popular language of the world.
- emerged 5y ago
  That’s the thing about JS. It’s popular because it was first and grew into a monopoly. The language itself is horrific. We are permanently stuck with a poorly designed language because it has momentum which can’t be overcome.

stareatgoats 5y ago

It is a lost cause to rationally try and sort out what if anything is chronically wrong with js, ruby, haskell, c (or any language of choice). They each have their pros and cons, and have evolved differently for different reasons. Since programming languages many times (seemingly) are like a dear spouse to its disciples such discussions generally devolve into endless and meaningless comparisons, if not worse. The article obviously panders to ruby sentiments, and the javascript experience can obviously be frustrating to that community, as might ruby to a mainly javascript developer. Might we just leave it at that?

jspash 5y ago
I think the big difference with JS is that if you're doing just about anything in Web Dev these days, you MUST use JS (with a few exceptions). Don't like PHP? Try Python. Why not Go, Scala or Rust? Don't like Ruby? Move to Elixir (no really, do it! you won't regret it) But with JS you're stuck with JS - at least Typescript makes things a bit more sane. So until the browser monopoly ends and something supplants JS as one of the only ways to make a dynamic website, it will have to take the heat. The best experience I've encountered is with LiveView in the Elixir/Phoenix world. It still needs JS for the plumbing (websockets) but I no longer have to write JS. Happy days!

mjburgess 5y ago

> From backend ORMs and headless APIs to frontend site generators, package managers, and build tools—it's a miracle any of it actually works properly in production! I think the issue is clear from this first sentence. Why are there any of these things in javascript? The marvel is that in 2021 such a sentence can be written -- that these things are immature seems both obvious and to miss the point.

laurent92 5y ago
So engineers only have one language to absolutely master. This really hit home: Trying to recruit a Java + SpringBoot + Angular engineer is 1 order of magnitude harder than a NodeJS + Angular engineer.
- mjburgess 5y ago
  Why not generalise SQL with classes, loops (, etc.) and truly single-language the world? And an SQL configuration language ("UPDATE aws.ec2.config ...") ? Typescript is a testament to the extreme amount of work needed to normalize a scrappy browser-lang for robust use. The issue is precisely that a community of "SQL developers" are not going to build you robust tools, merely by having generalised SQL. And likewise, a community of browser developers aren't going to either. Single-languaging down to effectively a DSL produces a particular type of community (, language, domain of competence, ...), which is exactly what OP is complaining about.
- tjpnz 5y ago
  Languages aren't hard to learn once you've got 1-2 under your belt. FWIW I wouldn't consider myself to have "absolute mastery" in any language, there are some I'm more comfortable with than others but even when I'm not I can still be productive.
  - heipei 5y ago
    They might not be hard to learn, but it's still a considerable mental overhead to switch between writing JS on the frontend and anything but JS on the backend. I frequently mix up the simplest things, like len(list) vs list.length, or how that you can't use obj.property on Python dicts, or list.append() vs array.push(), etc. And then you might have a great tooling library in one ecosystem (like lodash in JS) and try to replicate the things in your backend language. That sort of context-switching simply isn't worth it in my opinion.

kitd 5y ago

I did web dev for a few years using Angular + various other tools, and yes, it was nightmarish. I had to come back to it briefly recently. But using "boring" Typescript, esbuild and preact, I have to say the experience was an immeasurable improvement. Verging on pleasant even. Everything was well-documented with strong Stackoverflow coverage. So, boring > shiny

cageface 5y ago
Typescript, esbuild, and preact would have been described as shiny not very long ago. These things take time to mature. I agree that the current JS ecosystem is fine if you don't get too far off into the weeds with obscure dependencies.
ramchip 5y ago
Wasn't esbuild released literally last year?
- Ygg2 5y ago
  In JS terms, that's like a dinosaur.
5e92cb50239222b 5y ago
You probably already know this, but for anyone wanting to do this: esbuild does not do any type checking, so TypeScript with pure esbuild (without a separate tsc step) is only half useful (it gives you better autocompletion, but not much else). https://esbuild.github.io/content-types/#typescript https://esbuild.github.io/content-types/#typescript
- BiteCode_dev 5y ago
  You IDE should check the types for you.
  - johnnypangs 5y ago
    This might worked on solo projects but if you’re working with people, I’d highly recommend enforcing type checking of some sort. People will ignore the IDE error messages.

egeozcan 5y ago

IMHO, JS is has more mature parts than any other language. It's fast, stable, portable, practical and for every problem you could imagine, there's an answer on Stack Overflow, immense community, easy to learn (while hard to master, like the English language). The problem is, the popularity also brings huge amount of immaturity. So, it also has more immature parts than every other language too! People keep adding new libraries, trying to promote them, and most of them are indeed beginners, because when most people start programming, they do learn JS mainly, or as an addition. Yeah, JS has a very small standard library which exacerbates the problem but if you look at the amount of libraries that do what they do best and are stable, I guess no ecosystem is anywhere close. Beginners should just follow the happy path, and it almost always works fine. People can use "create-react-app" or "express.js" or "lithtml"... But just learn the language too. I use next.js myself and am surprised how everything just works. I can't say the same for many C# frameworks (and from Microsoft nonetheless).

arbol 5y ago
... happy path... Having come back to JS recently after years away I feel that typescript should be the recommended way of interacting with JS. It makes it much easier to write code with reduced bugs.
5e92cb50239222b 5y ago
I try not to use any libraries that were introduced less than 5-6 years ago. Thanks to this I don't experience much library churn and don't have to rewrite the same thing every few months. For example, I didn't pick up React until 2020. Let the kids play with their shiny toys if that's what they want.
- dgb23 5y ago
  I think this is a smart heuristic if you optimize for stability. Incidentally, you started to learn React when it's API's got drastically simplified over the previous class based approach. You joined at the right time so to speak. But I want to add that play isn't just for kids. For me, it is an important part of my life and work. Deliberate, free play gets you in a different mode, it's fun and worth doing without some external reward. Does it have to be new, "shiny" toys? Not at all! That's the nice thing about it.

awestroke 5y ago

All this complaining about churn is ignoring what the churn stems from. There's constant, incredible evolution in the JS ecosystem. Some examples : * New syntax that makes JS so much more expressive than before, like arrow functions, spreads and null operators * Typescript has made development so much better and reduces the need to unit test structure * React was a paradigm shift when it came. React hooks is another paradigm shift, I've written code in the last few months that would have been so much harder to write and been much more buggy without hooks I spend at most a few hours per month upgrading packages and dealing with churn. It's a small price to pay

laurent92 5y ago
Isn’t React slow, only able to manage tables of a few dozen rows before slowing down to hell, hence starting the trend of tables paginated by 10 rows only? Isn’t that the cost of hooks?
- fabian2k 5y ago
  React doesn't have an inherent problem with larger tables, and there are quite a few libraries to virtualize long lists or tables if yours are very large and you need the performance. React performance can be a bit tricky to handle if you don't understand how React rendering works and when React will render. But that's not really different from most things, performance is something that you often cannot abstract away entirely.
- awestroke 5y ago
  I've written code that would have been incredibly hard be made performant without React. With React, vittualizing rendering to only render visible elements is a breeze thanks to the inherent composability of react components, and now also hooks. React is not the performance bottleneck, the DOM is
  - dotancohen 5y ago
    > React is not the performance bottleneck, the DOM is. I think that's pushing the blame just a layer too deep. It's like saying that engines are not holding up hypersonic missile development, the thick atmosphere is.

e67f70028a46fba 5y ago

the way to deal with the immaturity of javascript is to build instead off mature technologies like hypermedia Hotwire and htmx do this

spinningslate 5y ago

Complexity and instability in the JS ecosystem is a hot button for me, so it's hard not to be drawn into vehement agreement. I've been doing a little work recently with htmx[0] and it's a breath of fresh air. But then, I'm at the point in my career where "cool new tech" is much less interesting for its own sake than it used to be when I was younger. I'm drawn far more to elegant, understandable, productive simplicity these days. I think that hints at the reason we have these endless debates - not just about JS but about $(your-favourite-tech). Software development is a socio-technical endeavour. We put all the focus on the technical part, and by comparison, rarely consider the social aspect. DHH is one of the few I've heard actually refer to this, on the corecursive podcast [1]. In discussing static typing vs dynamic, his point is the latter suits his brain. But that he understands and accepts static typing suits others, and that's fine. So I get that, for some, the JS ecosystem is dynamic and interesting; stimulating; exhilarating even. For others, it's an unstable quicksand that gets in the way of doing something useful. [0]: https://htmx.org/ https://htmx.org/ [1]: https://corecursive.com/045-david-heinemeier-hansson-software-contrarian/ https://corecursive.com/045-david-heinemeier-hansson-softwar...

based2 5y ago

https://www.javabrahman.com/java-8/java-8-multiple-inheritance-conflict-resolution-rules-and-diamond-problem/ https://www.javabrahman.com/java-8/java-8-multiple-inheritan... https://stackoverflow.com/questions/561729/can-the-diamond-problem-be-really-solved/561768#561768 https://stackoverflow.com/questions/561729/can-the-diamond-p...

onion2k 5y ago

The ecosystem of JavaScript frameworks is almost unbelievably unstable. Popularity isn't a measure of quality of course, but if you're going to make a statement like "JavaScript frameworks are almost unbelievably unstable" you probably ought to cite some sort of evidence for that because reality is very much against you. There are about 10,000,000 React websites[1] compared to 95,000 Rails[2] websites. There are 325,000,000 websites that use JS[3] I mean, JS can't be that bad in the face of those numbers, can it? JS developers aren't all getting it wrong are they? [1] https://trends.builtwith.com/websitelist/React https://trends.builtwith.com/websitelist/React [2] https://trends.builtwith.com/websitelist/Ruby https://trends.builtwith.com/websitelist/Ruby [3] https://trends.builtwith.com/javascript/traffic/Entire-Internet https://trends.builtwith.com/javascript/traffic/Entire-Inter...

Havoc 5y ago
That's like saying there are X million humans driving therefore humans can't be that bad at driving. There is really not much of a connection between those dots
- onion2k 5y ago
  Humans are amazing at driving. Given how many billions of miles are driven every day, the number of accidents is mind-bogglingly tiny. You'd think there would be many, many more. That is quite a good analogy to JS actually.
andybak 5y ago
I don't understand how the numbers you've posted here support your argument. You said it yourself "Popularity isn't a measure of quality" and then go on to imply that it does.
- onion2k 5y ago
  I'm not suggesting JS is particularly high quality; I'm just saying that it's not completely broken. There's a middle-ground where it can be both good enough quality to be usable, and good enough to not be considered broken. Given the fact JS is used by hundreds of thousands of developers it is obviously not totally broken, so if you're going to say it is you need some very strong evidence to back that up. Half the time when I see "JS is so broken!" posts they're by Ruby devs. I can't help wonder why they're all so keen to move away from Ruby.

tyronehed 5y ago

I agree with this 1000%.

BiteCode_dev 5y ago

It's was my take in 2015, when saying it then got you bashed to death. Now you can say it, since people have been burnt enough to admit it, but ironically it's actually less true. Yes, the JS language is always hackish. The stdlib sucks and the ecosystem is a Jenga tower. A lot of JS projects are still what I call "disposable code bases". But. Modern JS is tolerable. Functions are now decent, you have let/const, map/filter... There are even some nice things: • spread and destructuring, and they play well with the limited data structures. • simplest async paradigm ever: immediate schedule, and returns a Future, may attach a callback or prefix with await. • concise arrow functions. • ? and ?? operators. I actually miss them in Python. Tooling has improved tenfold: • VSCode gives you good code intelligence out of the box. • any build tool will solve imports, scoping, "this" weirdness, browser compat, etc. • new gen builders, such as ViteJS (or anything based on rollup/esbuild), are fast, reliable, and have sane default. No more webpack trouble. • new gen packagers, such as pnpm, are fast, reliable, and save a ton of disk space. No more "takes 10 minutes, download the entire internet 3 times". • with VueJS (SPA), htmx (ajaxify Django, Rails, Laravel...) and petite-vue (progressive enhancement), front end dev is almost fun. And light. • Typescript. Now, I still avoid JS if I can. I don't like having to google simple things like type coercion or how to left trim a string. As soon as I can go Python, I do so. It's hard to beat Django or FastApi for the web, Typer for scripting, pandas for data analysis, pytest and robotframework for testing, or just the stdlib/pypi.org for pretty much everything. And with shiv and nuitka, deployment is now on a different level. But when I have to use JS, I don't dread it anymore.

samastur 5y ago
And I think the article is largely correct even though I don't dread developing Javascript-based applications. One of our Nuxt applications with default build configuration sometimes builds successfully and sometimes fails miserably for reasons not understood. So we just run the process until it succeeds. I would never tolerate this in Python or take it as lightly as I do here, but like a frog in hot water I've been conditioned to almost expect it or at least not get too bothered by it. I think Javascript the language is fine. But the rest of ecosystem feels enormously creative, myopic and too often fragile.
zengargoyle 5y ago

3np 5y ago

The title misses the point. You can have a perfectly stable JS experience if you let go of the need to stay on top of the latest trends. I've done node.js since it came out and I stopped feeling like the author about 5 years ago. I've continued developed in js regularly but am generally "out of the loop" with regards to web framework trends etc. Apart from deprecations of request and moment and the occasional syntactic sugar, not much has changed in years now. Just the other day I made a greenfield web project for the first time in a long time, took me about one intermittent day to get from 0 to "good enough" with a couple of views. typescript, hapi, and pug. It doesn't have to be complicated. https://codeberg.org/3np/rimgu https://codeberg.org/3np/rimgu (Not saying this is a perfect project and you may argue it falls under the "do x in 10 mins fallacy" but if you think JS projects have to be complicated and unstable - they don't have to) Also, I find it unexpected hearing that comparison with Ruby. I've spent way too much time struggling with Ruby deprecations, buid systems, linters, and broken or undocumented web frameworks (Grape) that I think Python may be the one better comparison. And really, which ecosystem with comparable legacy has a significantly better track-record of webdev stability? Java? .NET? PHP? Go? It's a mess everywhere.

jokethrowaway 5y ago

I can understand new libraries being crappy, it takes time to get good and that's why you should pick well established libraries. True, the hype machine is huge in the js world and the superstars in it are better marketers on twitter than coders. I'm not going to touch anything graphql related for at least 5 more years and hopefully I will never have to touch it. React became decent last year when next started being mature enough. What I don't like is all the transpiling and new language features getting to js. The single worst decision was to swap require for import. I don't care how much better the new model is, it broke too much stuff and I feel pain at least once a week because of that crap. Frankly, that's a nightmare and I think it will be years before it's decent to use - or maybe we'll need deno to get there. I swapped js with rust (+rocket) for all my personal projects and it's been nice - but I'm still stuck with js on a few projects where I'm collaborating with other developers who are not going to realistically learn rust.

Havoc 5y ago

Big part of the issue is that it's quite hard for newbies to tell what is JS and what is the framework and what is a web standard.

marstall 5y ago

Not saying you're wrong - but a few examples or stories would help sell this idea.

arcanon 5y ago

Does anyone else think it’s weird that trivial syntax/typesystem frameworks get very popular whereas things that actually move tech forward, like new apis/webgpu dont get much hype? Maybe it just seems this way. I mean how many ways can we come up with to watch ppl struggle to build 2D form applications?

atom_arranger 5y ago

A part of this is that the tooling mostly depends on huge trees of dependencies. If top level tools devs interacted with bundled more of their deps things might be less likely to break, at the cost of a bigger node_modules folder. Right now you occasionally run into situations where Webpack or ESLint stops working right because is-even released a bad patch update.