the way to deal with the immaturity of javascript is to build instead off mature technologies like hypermedia
Hotwire and htmx do this
The Shocking Immaturity of JavaScript
11–20 of 78 posts
Re: The Shocking Immaturity of JavaScript
#12When 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 co…
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.
Re: The Shocking Immaturity of JavaScript
#13All 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…
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?
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.
Re: The Shocking Immaturity of JavaScript
#14When 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 co…
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.
Re: The Shocking Immaturity of JavaScript
#15Complexity 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/
[1]: https://corecursive.com/045-david-heinemeier-hansson-softwar...
Re: The Shocking Immaturity of JavaScript
#16> 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.
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.
Re: The Shocking Immaturity of JavaScript
#17Re: The Shocking Immaturity of JavaScript
#18When 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 co…
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.
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.
Re: The Shocking Immaturity of JavaScript
#19The 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
[2] https://trends.builtwith.com/websitelist/Ruby
[3] https://trends.builtwith.com/javascript/traffic/Entire-Inter...
Re: The Shocking Immaturity of JavaScript
#20All 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…
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?
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