On the other side, I wish the babel tower of javascript stacks collapses under its own weight so we can stop normalizing 50mb of download and 2gbs of ram used for a front end.
It probably won't happen but what I'd really like to see is for browsers to be a bit more "batteries included" when it comes to UI so devs feel it less necessary to build leaning towers of JS. In fact I think it should be a bigger priority than a lot of the things that've been focal points in the web standards space recently… it feels silly that one needs to pull in a third party lib or roll your own for something as basic as a sortable table.
It’s often not worth baking it into the browser; you’ll have to rewrite it anyways to implement the latest design trend or interaction pattern. I think having a “standard library” in userspace, preferably catchable, kinda like we used to have with jquery is as good as it’s going to get, but even then it’s inviting version hell on the “standard library”
High degrees of stylability is a must for these UI components, so design trends should be moot, unless we're talking about technical design trends in which case I don't think web front end is going to see such crazy churn forever. It's already slowed down somewhat from what it was and I believe it's eventually going to hit something of a steady state.
Plus even if there's some degree of persistent trendchasing in the web front end space, there's also those who always go for the old "boring" options when making choices of this nature, and better baked-in components would serve these devs well.
When I work in teams, the FE folks handle whatever they feel like and I just integrate their stuff, when I do my own little side projects, I do vanillajs and keep being an happy fellow.
So now you'll download megabytes of wasm. Because the browser has very little of what you need, and you need to bring all your world with you, all the time: https://news.ycombinator.com/item?id=34218520
Lead survey maintainer here; we are aware of the problem and are working on a new data visualization that will use historical data to highlight how bad the graphs are getting year over year, so we can really narrow down the issue.
My point is "I know it's bad but not this bad". Like, I thought it would be more like 10% or something.
And I was not asking for any "magical answer", just wanted to know if this survey is representative enough (others have already answered it, so all good now.)
Sometimes it matters a lot. I'm a Pythonista who had to work with Rails just today (because I had to mend some Rails-based API project I had to interop with) and cussed a lot.
Rails remind me of Perl's metaprogramming beauty (code is almost literature or even art) but also its worst sides (unique situational DSLs for everything and then some more, with TIMTOWTDI). It takes a lot of research to figure out where things are coming from because everyone seem to really love metaprogramming the whole kitchen sink, magically converting :symbols to ClassNames to autogenerated helped methods to generated attributes. And nothing is ever implicitly imported in the file you're looking at. Surely, it's all pretty simple after you learn how the particularly selected gem is used, but almost incomprehensible before you do. E.g. I just struggled for good 15 minutes before I learned that expose(:foo) is from a `decent_exposure` gem (and read that gem's source to understand how and why it does all its magics) - and there seem to be hundreds if not thousands of such gems in any sufficiently large and old Rails project.
Oh, TIL that Rails doesn't implement If-Match at all (only If-None-Match for GET and HEAD through some Rack middleware). Every other toolkit I've used had something for that.
I think a lot of people are now used to seamless interaction and realtime data updates. Also, pricing models on cloud service providers increasingly discourage serving from rails or nodejs, and encourage static files that offload as much as possible to the end user's device.
You make sure you're only trying to do frameworkless development on pages where "data consistency" means "the text box displays the text that's in the text box." :-)
In my understanding template would be the entire page. So while an an individual div re-rendering is also technically a template, it's not really the same thing. It's a tiny re-render compared to a page refresh.
Again, this is a different spin on doing things. Rails preaches abandoning the over-complexity of the client-side in the browser and pushing work to the server.
I personally love it. I'm sure someone who is as fast in React as I am in Rails is laughing reading this.
You're going back in forth about whether the html re-render that's sent back over the wire is always the entire page or only the specific element needed.
So you're adding Bootstrap and jQuery and Popper onto Rails, just to get a modal. What happens when that modal performs an action? If it mutates data, does it require a full page refresh to do so, causing the user to lose their context? Or does it do so without a refresh, but does that mean you've now got multiple frontend and backend ways of saving and loading data in the app? How do you maintain data consistency on the rest of the page after the mutation?
You can post data to API endpoints with vanilla JS fairly easily now. There are a lot of simplifying cases where there's no complexity to state management - like when the data flow is one-way.
If your input is just a text box, you can post it whenever it is submitted and put up some kind of status gleaned from the server's response body. In another comment, I point out how easy it is for requirements to end up forcing you out of the stateless happy path of frameworkless frontend, but that doesn't mean there aren't a lot of cases where you can stay in it.
What headaches? You mark a query as stale and it fetches new data from the backend and rerenders elements as needed automatically.
What reason is there to learn Ruby and Rails and Hotwire and streams and turbo frames and whatever the next churn is just to avoid rendering some html with javascript?
You know you're not required to understand and use every piece of tech ever made, right? Who cares if someone published a hobby project?
No one is suggesting the industry immediately adopt some random new library, except for Rails fans who constantly demand everyone abandon a de facto standard like React and use their new toy.
For many cases I think you can refresh the page. The context (the same page) is mostly still there. I think it really depends on what the user is expecting to do next. For example if the modal was “are you sure you want to delete this record” a full refresh and the record appearing deleted might be a fine experience.
It's not a fine experience if the user had scrolled down the page, or had filtered down the table listing, or had set up the UI by opening a panel or whatnot.
Yes if the user must retain their state after the modal closes a full page refresh would not be the right thing. I probably wouldn’t build Figma in Rails, but I probably would build a CRM in Rails.
Unless you mean you still need JS to build the modal, which is true but I doubt GP was implying that you shouldn't use JS whatsoever. You don't need a SPA to build a modal.
SPA-like complexity sneaks up on you. You start with clear stages to user interaction that might as well be separate URLs, then you need to add more connections, then you have to add pop-out panels and things that can be open or closed in various combinations, and by the end you have manually re-implemented what most frameworks do.
If you know in advance that you will never have complicated combinations of states, then sure, go ahead and use alpine (vanilla DOM element creation makes very unreadable code) or if you won't even need to create elements don't use anything... but the situations where you really know your application won't evolve that way are very rare next to the situations where you merely don't yet know that it will.
The way I see it, rewrites are inevitable so it's best to start with what's most comfortable right now and then deal with complexity creep when the time comes. Unless the app in question is being written for BigCorp there's a decent chance that it'll never hit that level of complexity during its lifetime anyway. Starting out with an SPA feels a bit like killing a fly with a sledgehammer.
This is a weird mindset. If I wanted to “just ship” something, why would I try to relearn technologies I haven’t used in almost ten years over ones I know well today?
If you combine together all the static web 1.0 sites in the world with all the backend-as-a-service companies (Commercelayer, Stripe not exactly, the weather ones), and mix in the mostly-just-plumbing backends you can come up with by stitching together AWS offerings, and top it off with all the things you can do by writing less than 100 lines to run a Lambda function, you have covered a huge number of use cases without ever needing to learn Rails.
You can do a lot of things, depends on your goals I suppose. You seem to be really sold on the concept of not learning Rails, so I won’t argue with you further. I personally found Rails much easier to learn and use than React or pretty much anything I use in the JS world.
Rails is built with developer happiness in mind. JS though became the answer to all questions for reasons that are beyond me. You can’t escape it entire so I try to limit how much I have to use it.
You can, sort of, if you write it using next.js. Also presumably if you know react you know node, so you could write an express server or something. I'm assuming this is what OP meant.
Using Next.js for writing your backend is pure masochism. You'll only understand why I say this if you've ever used a real batteries included backend web framework.
Such as I guess you mean like Django or Rails? I have used Django but because I'm more comfortable building pure client software (games and stuff included, where all logic is happening on the client CPU and RAM), I found it a bit uncomfortable. To be fair I also find next.js somewhat comfortable: I prefer a clean delineation between the client and server, and often find myself fighting next.js when I'm thinking "no, i DEFINITELY want this run ONLY on the server, TRUST me!" But I could just be out of date, I hear "running on the edge" is the hot new thing and I probably just don't know yet how to dev that way.
What I mean is that if you enjoy using React, Next.js is your best option in my opinion and from my experience with similar tools (heavy SPA meta-frameworks...). But that's it, it's there for the *frontend* of your application. And the more your application looks like a landing page with a form than a real full stack application, the better it fits.
A lot of problems arise when you want to use it to build a "full stack" application with just Next.js and no "real" backend framework. Many people will tell you Next.js is "full stack" because it can execute JavaScript in the server. For me that's not "full stack"... Maybe when I say "full stack" I'm actually meaning "batteries included" because that's what I need when I'm building a "full stack" application.
For any non trivial application, you'll need things such as authentication, authorization, migrations, orm, background jobs, translations, logging, error reporting, rate limiting, security guards (cors, brute force attacks, etc, etc, etc). Most, if not all of these things come out of the box in real "full stack" frameworks such as Laravel, Django, Rails or Adonis.
A few months ago I had to deal on a Next.js application which needed server side rendering, internationalization and data validation. Making the error messages from the server show correctly and making the i18n library work together with the authentication, the SSR, the half-assed orm/wrappers around prisma, etc.... it... worked... but you end up looking at the code and asking yourself "Why am I doing this?... Adonis.js or Laravel would do it for me already".
Of course some people here will say "but there's a library for each one of those things in the Next.js ecosystem"... yes, but picking the right ones, integrating them so they work in a seamless, secure and battle proven way, keeping it up to date, maintainers abandoning them, trends making them out of fashion, etc, etc it becomes a TON of (business wise) useless work.
So Next.js for the frontend? Great. Next.js for a non-trivial full stack application or for your backend? Sure, but you're not using the right tool, it's like trying to put a screw with a hammer. Might work. Just far from ideal.
Well, no. But you can write your backend in JS/TS. I find backend code needs much less of a "framework" anyway (depending on use case, I'm thinking of CRUDdy-ish stuff). You just need to nail the API between frontend and backend, and using the same language means you don't have to do anything fancy with your domain model.
This is the way. Rails and Hotwire especially really worth a look. Hope it can gain some traction, so tired of the constant “innovation” of JS frameworks
I'm the lead survey maintainer; I agree that the survey is very front-end oriented, but that's because it was hard to properly cover everything, and we're instead hoping to do a separate "State of Node" (well, or a similar name that also includes Deno, Bun, etc.) survey at some point.
SvelteKit isn't there yet, but once it is fully fleshed out (yes, I know it hit 1.0, but it still doesn't support the big three cloud providers out of the box) I think it's going to change the standard for frontend architecture. There is no way to get React to render itself on edge servers.
It's a little funny that Javascript haters and Javascript influencers meet in their desire to highlight the new and shiny toys of the front-end ecosystem, but if you actually look at the survey results (or work on the front-end) then you know that in the real world, where people are shipping to prod, the story is the stability of favored tools.
These things won: React, Webpack, Jest. They've been the dominant tools for years. (Typescript is getting there.) The ecosystem around them is enormous; a million edge cases have already been handled; they're not going anywhere for a long time.
It's not really a surprise that as browsers become more like operating systems, people will experiment and find new ways to leverage the available capabilities, but you don't have to play with the new toys, and you definitely don't have to use them for paying work. Just say "risk" ten times if anyone suggests them, and your PM will end up agreeing with you.
>The ecosystem around them is enormous; a million edge cases have already been handled; they're not going anywhere for a long time.
Sounds like everything that came before them, but they got a foothold somehow.
>Just say "risk" ten times if anyone suggests them, and your PM will end up agreeing with you.
Please don't overuse this, if you get in your groove then ten years down the line you'll end up being a naysayer to something the company actually should adopt.
Yeah, like one of the companies I briefly worked for. An outdated hell of WordPress, with no package.json, no linters, no formatters, copy & pasted / vendored dependencies, lot of NIH home built libraries, no tests, no framework other than jQuery, no automation (we built scss from the CLI because "we don't need to complicate it with scripts", and absolute negationism about any "shiny new tool" if it was less than 20 years old. The only people that stayed there were the ones happy to work in those conditions, or that haven't seen anything better.
That's the reality of it. You don't need shiny frameworks or any of those tools to make money.
Are developers happy with it? Maybe! Nothing wrong with spicing up a site with a little jQuery. Heck, I used Alpine.js on a brand new site and it's great. No build step, just works!
Here's my feelings like someone who's not strictly frontend developer but has to deal with it from time to time.
Frontend seems to be React, rest is dead, everyone's on React.
Build system seems to work. Last time I used vite and didn't tinker with it at all. It just works. That's good. It was a royal pain for in in the past. All those grunts, webpacks, gulps and whatnot. But it doesn't seem like dust is settled yet. I guess more build systems will appear and disappear in the future.
State storage: I don't know. Redux was hot in the past. Nowadays it seems to be react-query which is supposed to be wrapper around fetch but apparently its caching is good enough to replace the whole state storage framework. Sounds weird, but here we are.
Routing is weird. I don't understand what's with it. There's react-router but there are some fuss with latest version, with react-query compatibility.
Code quality tools are not complete. There's prettier which is nice but does not work for everything as they have some weird artificial constraints, like they don't want to insert curly braces automatically, so you need to use eslint. Configuring this stuff still is pain. Deno is awesome in that aspect.
What I miss in JS ecosystem is something single which solves all my problems. Like npm which can also build website, which can hot reload it for dev mode, which can autoformat my code with single blessed unconfigurable code style, which can lint it, which can run unit tests and so on. I don't want to spend a single second setting up my environment.
>What I miss in JS ecosystem is something single which solves all my problems. Like npm which can also build website, which can hot reload it for dev mode, which can autoformat my code with single blessed unconfigurable code style, which can lint it, which can run unit tests and so on. I don't want to spend a single second setting up my environment.
I'm EXTREMELY confused about what's going on with react router, the documentation seems mismatched from versions, and any tips I find online seem to be for some now defunct version.
I remember a few months back I was working on a react app with react router and trying to figure out how to hook into all route changes for some reason, and all the documentation centered around "picking a router," of which there was `createBrowserRouter`, `createHashRouter`, etc, all which had different considerations. But I couldn't find an invocation for any of those! Just a single `useRoutes` and that was it lol. And the argument for it was just objects and arrays, with element properties set to JSX. From my understanding, we shouldn't have had history working at all without explicitly setting it to do so, but it all was working, so... who knows?
>What I miss in JS ecosystem is something single which solves all my problems. Like npm which can also build website, which can hot reload it for dev mode, which can autoformat my code with single blessed unconfigurable code style, which can lint it, which can run unit tests and so on. I don't want to spend a single second setting up my environment.
For this, you have Next.js/SvelteKit/Nuxt.js/whatever framework you prefer. For React in particular, Next.js with the default setup has all of these features but unit testing (there's a template for that, but it isn't as commonplace in frontend as it should be), and more such as server-side rendering, routing, data fetching, etc.
I get that. Testing components in particular is something I've rarely found to be worth it as well.
But often I find myself writing logic in the frontend, say for processing data from the API. That's where I want to create a file and write a unit test because it would actually be easier. Sadly for a small project the effort of configuring and maintaining updates of an external test framework on-top of Next makes no sense.
I've use React Router 6 in combination with @tanstack/react-query 4 in a ±2 month old project without issue. I did notice that React Router 6 annoyingly by default returned to an object notation for its routes instead of elements, but with `createRoutesFromElements` the option is still there. I find the object notation less readable and it doesn't follow the React paradigm.
One thing that I imagine would cause issues (or make react-query at least partially redundant) is the `loader` prop that React Router now has that allows is to do data fetching and posting in the router. I didn't try that due to time constraints.
The biggest pain for me in Javascript is tool configuration, it's something that I'm just not good at and configuring Prettier, eslint, testing library (with mocks), tsc, … and all the rules that inevitably start crashing with each other is hell. That's why for the longest time I kept using CRA which had all these things preconfigured with sane defaults. But CRA development is moving at a crawl and with the lack of SSR NextJS makes much more sense so I'm focussing on that now.
So it's not looking good. After all these years, people stuck with a bloat/slow React (but with all benefits come with being popular alone). State / routing / form, nothing has a decent de facto.
But to your point, I get the impression every project is adopting TS in some form. It's now pretty rare for me to find an NPM library that doesn't have typings, and anecdotally I'd say at least half are provided by the project. And I've seen a lot of "migrated to TS" in project changelogs.
To misquote the author of Solid.js as I remember it:
--- start misquote ---
There's no wonder react has been popular for all this time. We needed a time of relative stability and gradual evolution. We don't need revolutions every year.
It gave time to think about hard problems, and come up with new solutions. There's intensive work being done right now on things like proper partial hydration, SSR, granular reactivity etc.
--- end misquote ---
This is partly reflected in the graphs as well: react dominates, but "new kids on the block" like Svelte and Solid have insane rates of interest and retention.
To keep beating the same tired old drum: despite literally hundreds of millions of dollars poured into development and promotion of Web Components... the results are at best meh. The two leading frameworks, Lit and Stencil, see very little interest, so-so retention, and barely any usage.
None of the major frameworks and barely any of the newcomers use them... well, for anything.
115 comments
[ 4.2 ms ] story [ 198 ms ] threadLet the newest, slickest, shiniest batch of Javascript web frameworks commence! Oh boy.
Maybe something that compiles to wasm? Idk
Plus even if there's some degree of persistent trendchasing in the web front end space, there's also those who always go for the old "boring" options when making choices of this nature, and better baked-in components would serve these devs well.
This has been happening gradually for the past decade and now jquery is no longer necessary.
Even so, I’d like to see it improve further and at a faster pace.
Edit: fix the number to use "% of question respondents".
I don't think it's as extreme as ~5%, though.
https://insights.stackoverflow.com/survey/2021#demographics-...
Means that this survey may not be as representative. But with the info you gave, it might be.
> only 5.2% women?
You answered your own question though.
There is no magical answer.
What is curious though is why you think any of that matters.
Its like saying: I know zebras have stripes but do zebras have stripes only?
And I was not asking for any "magical answer", just wanted to know if this survey is representative enough (others have already answered it, so all good now.)
And htmx is worth exploring. As is HTML over the wire tools across various languages.
Rails remind me of Perl's metaprogramming beauty (code is almost literature or even art) but also its worst sides (unique situational DSLs for everything and then some more, with TIMTOWTDI). It takes a lot of research to figure out where things are coming from because everyone seem to really love metaprogramming the whole kitchen sink, magically converting :symbols to ClassNames to autogenerated helped methods to generated attributes. And nothing is ever implicitly imported in the file you're looking at. Surely, it's all pretty simple after you learn how the particularly selected gem is used, but almost incomprehensible before you do. E.g. I just struggled for good 15 minutes before I learned that expose(:foo) is from a `decent_exposure` gem (and read that gem's source to understand how and why it does all its magics) - and there seem to be hundreds if not thousands of such gems in any sufficiently large and old Rails project.
Oh, TIL that Rails doesn't implement If-Match at all (only If-None-Match for GET and HEAD through some Rack middleware). Every other toolkit I've used had something for that.
Again, this is a different spin on doing things. Rails preaches abandoning the over-complexity of the client-side in the browser and pushing work to the server.
I personally love it. I'm sure someone who is as fast in React as I am in Rails is laughing reading this.
https://dzone.com/articles/rails-creating-modals
The problem is what happens next. Do you reload the entire page each time the user makes any kind of change?
I suppose what you have to learn and add is relative to what you already know and have, isn’t it?
What reason is there to learn Ruby and Rails and Hotwire and streams and turbo frames and whatever the next churn is just to avoid rendering some html with javascript?
No one is suggesting the industry immediately adopt some random new library, except for Rails fans who constantly demand everyone abandon a de facto standard like React and use their new toy.
I must've dreamed up the dozens of times I did.
Unless you mean you still need JS to build the modal, which is true but I doubt GP was implying that you shouldn't use JS whatsoever. You don't need a SPA to build a modal.
If you know in advance that you will never have complicated combinations of states, then sure, go ahead and use alpine (vanilla DOM element creation makes very unreadable code) or if you won't even need to create elements don't use anything... but the situations where you really know your application won't evolve that way are very rare next to the situations where you merely don't yet know that it will.
Rails is built with developer happiness in mind. JS though became the answer to all questions for reasons that are beyond me. You can’t escape it entire so I try to limit how much I have to use it.
Although it's more the "Laravel of js" than the "Rails of js".
P.S: Yes, I know Nest.js and I don't like it and don't think it's better or even closer to the developer experience you get with Adonis.
Could you expand what you mean?
A lot of problems arise when you want to use it to build a "full stack" application with just Next.js and no "real" backend framework. Many people will tell you Next.js is "full stack" because it can execute JavaScript in the server. For me that's not "full stack"... Maybe when I say "full stack" I'm actually meaning "batteries included" because that's what I need when I'm building a "full stack" application.
For any non trivial application, you'll need things such as authentication, authorization, migrations, orm, background jobs, translations, logging, error reporting, rate limiting, security guards (cors, brute force attacks, etc, etc, etc). Most, if not all of these things come out of the box in real "full stack" frameworks such as Laravel, Django, Rails or Adonis.
A few months ago I had to deal on a Next.js application which needed server side rendering, internationalization and data validation. Making the error messages from the server show correctly and making the i18n library work together with the authentication, the SSR, the half-assed orm/wrappers around prisma, etc.... it... worked... but you end up looking at the code and asking yourself "Why am I doing this?... Adonis.js or Laravel would do it for me already".
Of course some people here will say "but there's a library for each one of those things in the Next.js ecosystem"... yes, but picking the right ones, integrating them so they work in a seamless, secure and battle proven way, keeping it up to date, maintainers abandoning them, trends making them out of fashion, etc, etc it becomes a TON of (business wise) useless work.
So Next.js for the frontend? Great. Next.js for a non-trivial full stack application or for your backend? Sure, but you're not using the right tool, it's like trying to put a screw with a hammer. Might work. Just far from ideal.
I'm interested in a whole breakdown of Javascript in the backend.
It's missing alot.
https://2022.stateofjs.com/en-US/libraries/front-end-framewo...
These things won: React, Webpack, Jest. They've been the dominant tools for years. (Typescript is getting there.) The ecosystem around them is enormous; a million edge cases have already been handled; they're not going anywhere for a long time.
It's not really a surprise that as browsers become more like operating systems, people will experiment and find new ways to leverage the available capabilities, but you don't have to play with the new toys, and you definitely don't have to use them for paying work. Just say "risk" ten times if anyone suggests them, and your PM will end up agreeing with you.
Sounds like everything that came before them, but they got a foothold somehow.
>Just say "risk" ten times if anyone suggests them, and your PM will end up agreeing with you.
Please don't overuse this, if you get in your groove then ten years down the line you'll end up being a naysayer to something the company actually should adopt.
Those places still exist, sadly.
That's the reality of it. You don't need shiny frameworks or any of those tools to make money.
Are developers happy with it? Maybe! Nothing wrong with spicing up a site with a little jQuery. Heck, I used Alpine.js on a brand new site and it's great. No build step, just works!
Frontend seems to be React, rest is dead, everyone's on React.
Build system seems to work. Last time I used vite and didn't tinker with it at all. It just works. That's good. It was a royal pain for in in the past. All those grunts, webpacks, gulps and whatnot. But it doesn't seem like dust is settled yet. I guess more build systems will appear and disappear in the future.
State storage: I don't know. Redux was hot in the past. Nowadays it seems to be react-query which is supposed to be wrapper around fetch but apparently its caching is good enough to replace the whole state storage framework. Sounds weird, but here we are.
Routing is weird. I don't understand what's with it. There's react-router but there are some fuss with latest version, with react-query compatibility.
Code quality tools are not complete. There's prettier which is nice but does not work for everything as they have some weird artificial constraints, like they don't want to insert curly braces automatically, so you need to use eslint. Configuring this stuff still is pain. Deno is awesome in that aspect.
What I miss in JS ecosystem is something single which solves all my problems. Like npm which can also build website, which can hot reload it for dev mode, which can autoformat my code with single blessed unconfigurable code style, which can lint it, which can run unit tests and so on. I don't want to spend a single second setting up my environment.
SvelteKit can do that.
I remember a few months back I was working on a react app with react router and trying to figure out how to hook into all route changes for some reason, and all the documentation centered around "picking a router," of which there was `createBrowserRouter`, `createHashRouter`, etc, all which had different considerations. But I couldn't find an invocation for any of those! Just a single `useRoutes` and that was it lol. And the argument for it was just objects and arrays, with element properties set to JSX. From my understanding, we shouldn't have had history working at all without explicitly setting it to do so, but it all was working, so... who knows?
For this, you have Next.js/SvelteKit/Nuxt.js/whatever framework you prefer. For React in particular, Next.js with the default setup has all of these features but unit testing (there's a template for that, but it isn't as commonplace in frontend as it should be), and more such as server-side rendering, routing, data fetching, etc.
But often I find myself writing logic in the frontend, say for processing data from the API. That's where I want to create a file and write a unit test because it would actually be easier. Sadly for a small project the effort of configuring and maintaining updates of an external test framework on-top of Next makes no sense.
One thing that I imagine would cause issues (or make react-query at least partially redundant) is the `loader` prop that React Router now has that allows is to do data fetching and posting in the router. I didn't try that due to time constraints.
The biggest pain for me in Javascript is tool configuration, it's something that I'm just not good at and configuring Prettier, eslint, testing library (with mocks), tsc, … and all the rules that inevitably start crashing with each other is hell. That's why for the longest time I kept using CRA which had all these things preconfigured with sane defaults. But CRA development is moving at a crawl and with the lack of SSR NextJS makes much more sense so I'm focussing on that now.
Looking at the "retention, interest, usage, and awareness ratio over time" - Percentages: almost perfectly flat. Rankings: all slowly going down.
Relative feelings are in near perfect lock-step. The only thing to note is people, as always, have ennui and are looking for something new.
There is nothing to support your statement, at all. You are basically lying.
So that graphic excludes JavaScript itself.
But to your point, I get the impression every project is adopting TS in some form. It's now pretty rare for me to find an NPM library that doesn't have typings, and anecdotally I'd say at least half are provided by the project. And I've seen a lot of "migrated to TS" in project changelogs.
I think they should have had it in the main selection as - at least to me - sounds improbable that really so few use vanilla JS these days.
--- start misquote ---
There's no wonder react has been popular for all this time. We needed a time of relative stability and gradual evolution. We don't need revolutions every year.
It gave time to think about hard problems, and come up with new solutions. There's intensive work being done right now on things like proper partial hydration, SSR, granular reactivity etc.
--- end misquote ---
This is partly reflected in the graphs as well: react dominates, but "new kids on the block" like Svelte and Solid have insane rates of interest and retention.
None of the major frameworks and barely any of the newcomers use them... well, for anything.
(Of course the person responsible for them tries to downplay it because biased etc. https://toot.cafe/@slightlyoff/109669688324474159 )