In my professional and personal experience, react has never been better to use (in terms of features, DX, maturity, community, productivity), yet if you look at the "popularity" (oh dear) graph, it's basically just describing how older tech slides down while newer shiny tech comes in and is instantly the most "popular".
The "Back end frameworks" section is particularly bad. Sveltekit and Astro are not "back end frameworks" unless you define tech by what marketing copy people have written. Even express (which I still use daily for most of my back end projects) barely qualifies as a "framework" in my opinion. Again I have the feeling that choosing which techs go into this section is driven by something like "github star delta" rather than an evaluation of what the tech actually does.
Finally, jeez, angular isn't that bad. Plenty of enterprises use it successfully, and for companies with .NET or Java stacks, it's a great fit. I think almost certainly the devs at those kinds of companies are probably busy just doing their day job and not responding to "state of hype mixed in with some subtle marketing by commercial companies" surveys like this one has become.
That’s basically it. The only job listing to even mention things like Rust in the region where I live in the past 5 years is Google, and they list it as “nice to have” on a recurrent phd position for c++ development.
Python is obviously a thing, but not so much for software development, but typically requires you to be a statistician first and then maybe capable of writing a little Python second.
So there is probably a bit of a disconnect between what is hip and what puts food on the table for a lot of us.
You’re probably on to a lot of it too. I recently got back into development, returning from a stint in management, project management and enterprise architecture and I’ve grown quite fond of typescript and the node environment.
It’s obviously a place where you can cause a lot of harm if you brute-force-program 100% or the time all of the time, but it’s also a place where you can create some great business value faster than I’ve ever experienced elsewhere. I mean, I can do things faster in Python but only until whatever I’m doing outgrows what I’m capable of keeping in my head.
That being said. Looking at the previous 20 years of getting to running office365 in your browser, sort of explains why people have been working so hard to come up with newer and smarter things, doesn’t it?
For the vast majority of us, however, the boring old languages are likely going to be around long after we retire, and as such, the “popularity” measures in these articles is probably not something to pay too much attention to.
The "usage" tab tells us what really matters - that in the last 3 years essentially nothing has changed despite the hype. Angular/Vue/React/Express dominate.
As a long-time frontend developer, I find Angular pretty bad, but I understand it feels fine if you come from .NET/Java or another “enterprise-y” environment.
0. https://dev.to/sachagreif/disclosing-a-state-of-javascriptst...
Overall, I find the experience similar to something like Ruby-on-Rails/Django, which I usually also consider as "backend frameworks".
For me, these new frameworks are one of the reasons that, for me, React has never been better.
e.g. Angular is a framework that a company invests in long-term, 5-10 year periods.
Only Vite has great satisfaction (98%) and decent usage (30%).
All the popular react libraries feel very mature, have zero vulnerabilities (at least according to npm) and are easily integrated.
It was a blast!
Once you have a solid grounding in React, I would highly recommend picking up some TypeScript and node.js. Those three go together a lot, at least where I live (Netherlands). If you know all three, there are tons of opportunities for both permanent and freelance positions.
A few developer YouTubers I used to enjoy watching have all jumped on board this train and are now only making videos about products built by companies that are paying them.
I can’t speak to SvelteKit, but I don’t think Astro even markets itself as such. Last I checked it doesn’t even support SSR (though it appears to be in development).
Even still, THIS is the state of the JavaScript. None of that has to do with the language.
Sure, that has some trade offs like page bloat. But almost all of the JS framework universe is focused now on reducing or eliminating those trade offs: partial hydration, build time code elimination, server components, etc. There’s still a long way to go before the DX and UX reach parity, but it’s inevitable, and closer than one might think (see Qwik[1]).
Guess what is my approach when having side gigs.
There are plenty of reasons why you may want a standalone JS interpreter.
Futhermore, the "Satisfaction" chart is heavily skewed towards new stuff. I probably wouldn't make this the default view of the charts.
And on a more personal note: Take the results with a grain of salt. For example, I've been using Ionic since 2017 and the survey shows that interest is severely declining. From my perspective, Ionic just got more stable, more polished and becomes an even more viable option to do mobile apps these days.
Edit: Oh man, the chart kinda fooled me. Ionic is extremely stable over the years at ~52%, but how it is displayed makes it look like the numbers go down.
That’s the fate of any tool that becomes popular enough.
For example, everyone was using styled components 2-3 years ago and now they are moving away. The complexity styled components introduced has to be managed alongside the current trend (tailwind?). Old styled components codebase looks horrible. They end up with Java inheritance hell. You create a button, then create another button inheriting that button but with slightly different behavior. Now that one button is extended by God knows how many and any change is going to break all of it.
There have been many patterns which got popular but then we found problems and stopped using them.
There is also hooks vs classes.
There is an exponential complexity in a legacy react codebase if it is not maintained well because react itself is not opinionated.
What are you basing this theory on, and what do you think people are moving to? In my experience it's still the go-to industry standard.
It's a drop in replacement for jest. The only change you will need to make in most cases is adding an explicit import for expect, describe, and it. It works without any config with esm and typescript.
It's also 5x faster in development.
It integrates well with vite which is the bundler I use.
Help me understand what you meant by this?
https://github.com/facebook/jest/pull/11529#issuecomment-102...
I'm curious - what do you mean by this? Been using Jest in multiple codebases with typescript and ES Modules and never ran into an issue.
edit: just found this, which seems to confirm my anecdotal xp of esm in jest being weird https://github.com/facebook/jest/pull/11529#issuecomment-102...
https://github.com/grissius/jest-is-a-rude-needy-clown-and-e...
I'm sure that causes the bottleneck for vitest but it's a necessary evil as ecosystem moves toward ES module and no global context across tests.
You can also speed up vitest by changing config to make it behave similar to jest, I think.
Those salary demographics makes me doubt the entire data set. Over 40% of respondents make less than $50k
[0] https://2021.stateofjs.com/en-US/demographics/#yearly_salary
Edit: Only 14% of respondents are in the US, which probably explains the above.
Frontend projects have a few issues:
- They are mostly greenfield projects with relatively new and immature technology.
- They mostly have short shelf lives since UIs get replaced after a few years.
- A lot of the new and shiny stuff ends up moving the problem rather than solving it. So, there's a lot of change happening more or less continuously but a lot of the problems stay the same.
- And of course there is the notion that developer demographics dictate that there are about 4x more developers available who never worked with what was fashionable 10 years ago. The amount of developers keeps on doubling every five years, so most of the talent on the market will never have heard of or worked with stuff fashionable ten years ago.
So, hiring frontend developers to work on some old legacy code base built with whatever was fashionable 5-10 years ago is hard and expensive. First of all it's rare for projects to survive that long and usually they are not in a great shape if they do. So, you basically need people with lots of experience in completely outdated tech stacks that are willing to do that instead of using the new and shiny stuff that everybody else is doing. All of those people are now at an age where they would be charging senior rates with no guarantee that they are any good. It's a tough one. Paying more is a good strategy but you'd still need to find somebody willing to do it.
Of course, all the good developers will prefer greenfield projects because if they are that good, they will have the choice and they'll mostly choose for investing in learning new stuff rather than working on somebody else's shitty code base. That actually drives a lot of frontend projects to an early death. They'd be salvageable in principle except there's nobody around still willing to do it. It's literally cheaper to start from scratch than it is to hire to keep an old project going. You actually risk losing good frontend developers if you fail to do that. Because they'll have options elsewhere.
IME demand for experienced and talented frontend seniors have never been higher, as frontend continues to expand in complexity, and more logic is handled on the frontend-stack (routing, API-routes with eg. Nextjs, SSG/SSR and so on.
In the backend, I went all in with Golang and oh my... Now I just code.
In the frontend, Svelte is a godsend. No longer need to find "React-friendly" libraries. Simple JS works for the most part. Not ideal but great versus React for the types of admin panels I build.
At least for me it was never a decision once I found TS, TS always got chosen. My spicy opinion in the JS space is that Typescript is better in every single way over Javascript, it is a superior language. Typescript IMO should be merged into Javascript, how anyone develops with just JS anymore (especially larger projects) baffles me.
I think we need something quite a bit more radical than Typescript.
We have "use strict" and I think we need to add "use types" too.
In that mode, we need to disallow the more dynamic parts of JS. They add TONS of typing headaches resulting in poorly-typed projects and they hurt performance too.
This could allow for a much more simple type system and allow a path forward where things like type coercion aren't a thing.
It seems like they have painted themselves into a weird spot by drifting so far from web standards because the path back doesn’t seem that obvious from the outside at least.
1) the standard library is often enough to get work done (http server, sql, etc)
2) external libraries often would simply sit atop the standard library which is easier to standardise and swap things around
3) the language is quite bare and simple, I was weirded out by the "for" in Go but I now like it. Need to map, filter, or increment counters? Use "for".
4) No need to hesitate between 5 linters or testing libraries, "go" does it so again it's standardised.
As for Svelte, I'm not loving it as much as Go but for frontend, it's just the most "JS/TS" of all without added layer of magic. There is still some, but it's graspable.
https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c321...
I hope it gets adoption, I would like to work with it. I like React as well and use it but Svelte straight forward in so many situations that I just enden coding instead of thinking about X different ways to solve a problem and that is where I see similarities with Go.
Is it simply due to more usage in actual systems causing people to dislike tools they really work with, or is the framework developing in a direction people are unhappy with?
Imo the best use case for Vue is as a jQuery no build replacement. Preact is also another good option for this.
While vue 3 was soft launched a year ago. The transition is still happening. With Vue 3 becoming default last week(feb 7). And major vue frameworks (vuetify and nuxt) just still working to support vue 3.
I expect satisfaction to increase next year, when ecosystem catches up. And dissatisfied folks switch to other options.
One thing to note is v2.7 is still shrouded darkness. Now, that major vue 3 work is done, Clarity and good support on v2.7 will also improve satisfaction.
Just as Python changed its string type to Unicode breaking compatibility, Vue changed the reactivity system. The other changes in Vue3 wouldn't fundamentally break compatibility on their own but made sense to fold into a big overhaul, just as Python did with various other changes in v3.
Vue has slots which is similar to render props.
Whenever I need to go and fix some bugs in old Vue 2 app without CompositionAPI and setup syntax - I feel very bad. Guess that Vue team a bit failed to properly describe why to use composition api, but now I think that it seems to be useful a lot
1. stay with Typescript
2. embrace vite, pnpm
3. keep using eslint and prettier
4. svelte is below React but *above* vue now! what a momentum.
PS - No testing framework in your list. Any reason?
In pnpm, though, it just works like that, but without most of the problems because, rather than a deep nested directory structure, it's just your direct dependencies symlinked from a truly flat store into the right places, with their dependencies symlinked again from the same shared store.
I haven't tried yarn 2 as much yet, which I think is a similar attempt to solve the problems inherent to node modules, just in a more complex way. My intuition and initial experiences are that it feels more brittle than pnpm, which already has some problems if a dependency relies too much on the deduped structure that npm provides.
One way to read the graph would be that there's a lot of angular just quietly getting on with the job and it's a solid choice, but another would be that there's a large amount of legacy angular out there that people aren't very happy with.
However Angular in my opinion totally outshines React in setups with many teams. It is comparable to C (React) vs. Java/Swift (Angular). Angular enforces a certain programming style, while React gives you a lot of "include this lib" freedom.
I attended many Angular meetings, and large enterprises use it.
It is similar to .NET and C-Sharp. Great stuff in a certain environment.
But, there haven't been calls for solutions.
There's points to backend technologies not changing much. My thoughts are because the backend just doesn't matter as much. Backends are mostly I/O streams placed and interacted with on mega-monolithic-hardware.
Front-end is different in every aspect. User interaction, engine/language constraints, client differences, and more. They all come into play. The applications you can run on the front-end currently would be alien to those writing them in the 90's, 00's and early 10's.
Front-end has to deal with immensely more complexity than the backend, and therefore new solutions and technologies need to be made.
On desktop we have nice mature solutions that are powerful and easy to use. Comparatively browser based front ends are a never ending mess in a state of constant swings.
If you look at Windows platform there's Win32, WFP, UWP, etc. On Linux there are Qt, Tk, GTK, and more. Some old, some buggy, some ugly. It's the same thing.
Rose tinted glasses you're wearing.
const { container, heading } = divs;
const container = document.createElement('div');
container.className = 'container';
const heading = document.createElement('div');
heading.className = 'heading';
const heading = span({ title: artName, innerText: whatever });For the second way of creating elements (the span example), instead of creating a function for every html or svg tag, I use another proxy so you can do:
const { span, h3 } = html;
For folks wondering, here's how it would work:
const htmlClasses = new Proxy({}, {
get: (target, prop, receiver) => document.querySelector('.' + prop)
});
// Get element with class pagetop
htmlClasses.pagetop;
const htmlNodes = new Proxy({}, {
get: (target, prop, receiver) => document.querySelectorAll(prop)
});
// Get all h3s
htmlNodes.h3;
Anyway, I just think it is cool kind of for the same reason it is misleading :)
You can do a loop like:
for (let i = 0; i < 100; i++) {
const { cool } = divs;
cool.innerText = new Date();
document.body.append(cool);
}
I could get rid of it, because my other approach to element creation would is:
const cool = div({ className: 'cool' });
const {
root,
headingContainer,
userContainer } = divs;
A never ending well of new divs that have the class name of the variable name
The other one with an even more explicit in its commercial support for the framework is Ionic, you know the firework will always be supported as they use it themselves for their own consulting business. I see that as a massive plus.
Ionic (the company) have the Ionic Framework and Capacitor for mobile development. They also provided consulting services, paid plugins, and build automation for it, all very much optional. It’s open source and they give every impression of maintaining it for the long haul without going closed sauce.
I means they are actively invested in it for the continuity of their business but also committed to it being an open source platform that doesn’t require the use of their paid services. But they are there is you want them.
That’s what I like.
The thing is that gulp doesn't really have all that much to offer these days. If you need lots of complex build logic webpack is the way to go. If simple & fast is the desired goal then something like esbuild or swc do a much better job, especially in the "fast" section.
And if none of these tools are what you want you could always use make (and bazel would also be possible I think, not sure though). Or maybe just plain tsc is enough.
I mean that is a weird thing to say it seems to me because whenever I have any sort of complex build logic that is when webpack becomes completely impenetrable or just does not support what I need - what do you mean by a complex logic that webpack supports that gulp doesn't?
I'd rather write makefiles or even Powershell scripts.
Maybe it's not good overall, but it's the best that the frontend has ever achieved.
Most Adopted Features: Nullish Coalescing, Optional Chaining, Private Fields
Highest Satisfaction (backend frameworks): SvelteKit, Astro, Fastify
Highest Satisfaction (frontend frameworks): Solid, Svelte, React
Highest Satisfaction (mobile & desktop apps): Tauri, Capacitor, Electron
Highest Satisfaction (build tools): Vite, esbuild, SWC
Highest Satisfaction (monorepo): pnpm, Turborepo, Mx
[0] https://dev.to/sachagreif/disclosing-a-state-of-javascriptst...
Ember was never very popular. It is sort of similar with how Rails is seen. I've found it very productive and great. I've had issues hiring people because they've heard of Ember, have not used it and don't want to move away from React because (my opinion) it's very popular on LinkedIn and the likes.
The chart mixes frameworks and it makes little sense. Ember and Angular are big frameworks with a sort of standard response for everything. React and Vue are view layers, you eventually build your own framework. I think Svelte also fits here. Stimulus updates the browser with html from a Rails server. Not sure where to put Alpine. They describe it as an updated jQuery-like development thing.
I just got a new job, mostly backend but with a bit of Ember thrown in, and I despise the framework. It's slow to work with, massive, and incredibly over-engineered and makes it so that creating the simplest of features is an absolute mess. Maintaining a sizeable Ember project is pure hell of traversing through 800 folders and files to find the one place the thing you're looking for is, since you can have a controller inherit from another, which inherits from another, which inherits from another ad infinitum, so good luck guessing where exactly that one attribute is coming from, or even what the hell it even is. The base controller might have a variable called `foo`, but then somewhere down along the chain that variable has been aliased/transformed into a completely different variable name with 0 bearing on what it originally maps to.
Handlebars templating is also *awful*, I cannot describe with words how much I despise Handlebars and everything surrounding it. To create a simple `if (foo && bar)` in a template, you have to do `{{#if (and foo bar)`. Okay, the `and` DSL is a bit weird, but not that bad. But then `if (foo && !bar)` becomes `{{#if (and foo (not bar))}}`. God forbid you want to do any kind of comparison though, because `if (foo < 0 || bar > 1)` becomes `{{#if (or (gt foo 0) (lt bar 1))}}`. You get the point, it quickly dissolves into an unreadable soup of brackets and DSL for very simple logical operands.
I could go on for a while about why I hate Ember, but I'll leave it at that. </bigRant>
On the other hand, react & vue are in “view layer” with ability to move to full SPA space with additional libraries. Hence, they have wider scope, and therefore are more used than large frameworks like angular.
This won’t change in future either. Large js framework will require more learning effort. So, newer devs would prefer smaller frameworks.
As someone else said, Ember was never that popular, and the community doesn't really strive to be popular. This is, however, a dilemma, because you need some popularity for your framework to have people interested in working on it.
Ember was cool initially because, if you knew Rails, then you could get what Ember was about even if it was confusing at times.
There were some choices made early on that even the Ember core team implicitly admits weren't so good, and they spent a lot of time moving away from those choices. As time went on, more developers became interested in other libraries like React because it's simpler and obscures much less of what it's doing under the hood. Ember decided to sit on the sidelines and take the time to figure out what to do next. This was both a good and a bad thing for Ember in the long run.
The long road to "modern" Ember got us the Glimmer component system, which is much nicer than the classic reactivity system, and it also gave us an improved templating system to classic Handlebars. Usability in the space of the runtime code was much improved, but this seemed to be at the cost of the build step being up to snuff with every other emerging JavaScript toolchain. Broccoli does some interesting things, but literally no one outside of Ember uses it because not only is it poorly documented but it's inferior to Webpack in a lot of ways. If an add-on that integrates Ember builds with Webpack wasn't made, Ember would be totally dead by now. Because Broccoli is niche and kind of hard to understand, even the developers who managed to figure out how to create add-ons for Ember didn't seem to understand the potential performance penalties of making a library into an Ember add-on as opposed to finding some other way to include code. Somehow a lot of Ember apps become really slow to build in Ember CLI, and that's partly because so many apps import a bunch of Ember-specific add-ons that are all doing something with the Broccoli tree.
Now there's Embroider, but we've been hearing about Embroider forever now, and it's neither reached v1.0 or the compatibility level it's advertised (in my experience). Not only is it too little way too late but it's still too complicated a way to simply bundle and share code between Ember projects. Trying to be compatible with Broccoli was a complete mistake and it should have been an opportunity to completely leave behind the cruft of v1 add-ons.
There's also some failed promises along the way. This thing called "module unification" which was going to greatly change but also improve the directory structure of Ember apps was sold as being something to look forward to in "Ember Octane", only to be dropped long into the process because for some reason it became infeasible. What does that tell you about Ember when the developers of Ember can't even change their own directory structure? Eventually they introduced template co-location, which was a good enough improvement over having a separate directory for templates, but that's another example of too-little-too-late. How is anyone supposed to be excited for template co-location when we were promised something better and every other framework is already more flexible to start with?
No matter how hard it tries, Ember is stuck in the past. Everyone has seen better at this point.
Yes, you can build ambitious web applications with Ember, but at least in other frameworks you can more easily figure out how to do something without getting stuck somewhere deep in the endless stack of framework code and being baffled. Yeah, Ember Data will "just work" for you until you want to do something like also fetch nested resources (example: /users/123/posts/456), which I'm pretty sure is still hard to do without some workarounds. Yes, the router is pretty great until you realize you need a wildcard segment in your URL.
But why would you do that when you could have used that time to just write your own solutions or swap out different libraries if you were using most other frameworks?
In Ember, you hardly get that choice because you have to use Ember CLI, you have to use Broccoli, you have to use the Ember router, you have to use the Ember/Glimmer reactivity model, and so on, and so on. With Ember, you're either all in or you're all out, more or less. Yes, technically you can write your way out of these things, but like I said, at that point you might as well just write your own framework using any number of other tools out there.
All in all, Ember isn't bad. It's just another tool like anything else. I've worked with it on apps with millions of users worldwide. There are still things I like about it. That said, I don't find it surprising that Ember is declining in relevance. With React and Svelte on two ends of the frontend continuum and Vue somewhere in the middle, there just isn't a big demand for what Ember provides. In order to do that, it would need to accept that it's lost and do things to entice new users, which would mean completely abandoning
- Embroider is actually 1.0 now and quite usable (https://github.com/embroider-build/embroider).
- Agree with Ember Data and nested resources, that's still needlessly complicated. Same with lack of wildcard in the router/URL.
There are still things Ember needs to fix, for example removing controllers and improve Ember Data. But overall I think there is a good future ahead for Ember.
I think it is more likely that, largely, there are way more 25-34 programmers than 65+ programmers out there.
While I am no fan of angular, I think angular is on right track. Once they support non-NgModule and vite, their satisfaction will improve.
> Lee Robinson, Director of Developer Relations at Vercel
> SvelteKit is a fresh take on building for the web and has an incredibly passionate, growing community of supporters.
Also people can have opinions, outside of being company spoke persons.
Okay, fellow kids.
This report doesn't surprise me. The JS community has devolved into bunch of people who re-invent everything in 2-3 year cycles. It's Silicon Valley in online clique form - and that's coming from being both deeply intertwined in it for the better part of a decade, and working in SF big tech.
It's pretty much all hype now, and the 'vibes' have gotten so toxic and corporate that it's hard to really enjoy doing FOSS for Javascript nowadays.
Devolved? I honestly thought it had always been this way, going all the way back to the jQuery / MooTools / YUI / Dojo days.
On jQuery, it hasn't really been re-invented by much these days, except for a lot of it being moved into the browser APIs directly (e.g. querySelectorAll()) which I would argue is not "re-inventing" things. Just replaced.
Anyway, maintaining Javascript projects is a chore now. People are rude, demanding, spammy, whiney, persistent, etc. It didn't use to be like this, and you don't see the same thing in other language spheres quite like you do with Javascript.
... what? Typescript isn't Javascript, just like C++ isn't C. They're two completely separate languages controlled by two completely separate entities.
Typescript is cool but it's not a replacement to Javascript. I don't see the point of implying that not using Typescript is "not nice".
They are not two separate languages at all, TS is a superset of JS and exists within the JS ecosystem and is designed so that JS projects can be incrementally migrated to TS, it's one of the first things in the documentation.
I wonder if there is a "standard", simple enough (reasonable implementation cost for very few devs) and stable in time way to call C functions of a shared library (aka "libdl-ing" from javascript), and use their memory objects and primitive types. We can even think of extensions for direct syscalls of various kernels.
How to make this "generic" enough? If I recall properly, python has "ctype".
However, I personally find it shocking to see such a huge disparity when reviewing the gender breakdown between male, female and non-binary https://2021.stateofjs.com/en-US/demographics/#gender.
Simply put, the JavaScript community is still not doing a good job when it comes to inclusivity. That needs to change.
What are the survey makers doing to improve these efforts?
Don't get me wrong, the stats are representative of a problem much broader than the remit of a small survey-maker, but still, without any follow-up referencing explicit efforts the wording seems off here.
It's a library that should get more love than it does.
That's really the biggest indicator of the state of js.
I would advise you to use vue or svelte.