I read this report every year. This year it feels the most like it's driven by hype (and marketing, hi Vercel!).<p>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".<p>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.<p>Finally, jeez, angular isn't <i>that</i> 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.
"Popularity contest" describes the front-end community in a nutshell. I've been in software development since before the web was a big deal. Never have I seen any language have more "high school popularity" style personalities hawking whatever the "best" library is... without any knowledge or wisdom. Any attempt to point out why some of these technologies or approaches are a "bad idea" leads to massive downvote trains. The saddest part is, I could be accused of "gatekeeping" when I say, "maybe we can learn from the past?". Nope. Yet somehow, folks with absolutely no pedigree are out there deciding what a "best practice" is... and immediately the "community" hops on board. It's almost cultish in that way. Don't you dare ask "who decided this was best?". What qualifications does that person have to decide a "best practice". You'll be met with the name of the company where that person works... as if that means something.<p>Even still, THIS is the state of the JavaScript. None of that has to do with the language.
How did the participation in the survey itself develop over the years? Do people get tired to take part? I participated in the survey for several years in a row now, but this time, it was slow as heck and buggy and I almost didn't participate because of this.<p>Futhermore, the "Satisfaction" chart is heavily skewed towards new stuff. I probably wouldn't make this the default view of the charts.<p>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.<p>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.
Not surprised to see satisfaction drop with increase in usage for React. People feeling like they’re forced to use something because of external constraints (coworkers choices etc) are rarely satisfied with that choice.<p>That’s the fate of any tool that becomes popular enough.
For testing, I've been exploring vitest which is missing from this list because jest looks unmaintained and has growing pain with typescript and esm support.<p><a href="https://vitest.dev/" rel="nofollow">https://vitest.dev/</a><p>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.<p>It's also 5x faster in development.<p>It integrates well with vite which is the bundler I use.
Only 22% make above $100k? [0]<p>Those salary demographics makes me doubt the entire data set. Over 40% of respondents make less than $50k<p>[0] <a href="https://2021.stateofjs.com/en-US/demographics/#yearly_salary" rel="nofollow">https://2021.stateofjs.com/en-US/demographics/#yearly_salary</a><p>Edit: Only 14% of respondents are in the US, which probably explains the above.
JS and TS brought so much happiness to me for years. But I found it extremely difficult to constantly have to "decide" between X and Y.<p>In the backend, I went all in with Golang and oh my... Now I just code.<p>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.
Interested in the steady drop in satisfaction with Vue since 2018. I remember being positively impressed when I looked into it.<p>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?
Spent one hour to wade through all these results, here are my take away:<p><pre><code> 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.
</code></pre>
I'm going to checkout svelte one more time and see where it is better than vue.
The satisfaction vs usage of angular is astonishing, but I wonder how much of that usage is legacy angular?<p>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.
There seems to be a bit of animosity towards front-end development based on the comments. Particularly due to the constant change of the environment and what's perceived as the best option.<p>But, there haven't been calls for solutions.<p>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.<p>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.<p>Front-end has to deal with immensely more complexity than the backend, and therefore new solutions and technologies need to be made.
I wrote the conclusion, and it had to be cut quite a bit for translation purposes, so here is the full text for anyone interested in high level takeaways! <a href="https://www.swyx.io/state-of-js-2021/" rel="nofollow">https://www.swyx.io/state-of-js-2021/</a>
Proxies are cool. I use them in github.com/thebinarysearchtree/artwork which I haven't released. That libraries tag line is "you wanted less javascript and more html, so we delivered - artwork, the 100% javascript and css front-end framework". Anyway, I use proxies when I want a bunch of divs with classnames. You just do<p><pre><code> const { container, heading } = divs;
</code></pre>
and then container is assigned to an HTMLDivElement <div class="container"></div> and the same type of thing for heading because divs is a proxy for an object with getters that can figure out the name of the variable you are destructing into and create a new element with that class name. It saves a lot of code.<p><pre><code> const container = document.createElement('div');
container.className = 'container';
const heading = document.createElement('div');
heading.className = 'heading';
</code></pre>
The other way you can create elements is just with a common:<p><pre><code> const heading = span({ title: artName, innerText: whatever });</code></pre>
etc so my web components have less code than react components, and run at native hand-written speed. Proxies aren't actually slow despite what I had read via google. In fact, the proxy is a bit faster than the naive implementation because it caches the divs and cloneNodes them.<p>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:<p><pre><code> const { span, h3 } = html;
</code></pre>
and it creates the span and h3 function dynamically. This saves me writing all the code for each tag and allows new tags to be used without me having to add them to the library.
When choosing a framework to build with now, I always look at how the project is funded and increasingly want to see a business backing it where it's a core part of their business model. That's what's so appealing about Svelte, now its effectively funded by Vercel, they need it to thrive as they want people to host their Svelte app on their platform.<p>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.
Does anyone know why data later was dropped from the survey? It was so included in the previous versions <a href="https://2020.stateofjs.com/en-US/technologies/datalayer/" rel="nofollow">https://2020.stateofjs.com/en-US/technologies/datalayer/</a> I'm curious if GraphQL is still growing in adoption.
Gulp build tool not receiving much love lately with a very strong "Would not use again". Why so? <a href="https://2021.stateofjs.com/en-US/libraries/build-tools/#build_tools_experience_marimekko" rel="nofollow">https://2021.stateofjs.com/en-US/libraries/build-tools/#buil...</a>
Only 4.5% of respondents said that they are unhappy with the state of front end frameworks. That satisfaction level is "official approval of a president in a dictatorship" high.
Sadly, I won't be responding to this survey anymore due to its data breach [0]. I appreciate the transparency of the disclosure, but you only get one chance with my data.<p>[0] <a href="https://dev.to/sachagreif/disclosing-a-state-of-javascriptstate-of-css-data-breach-2lg1" rel="nofollow">https://dev.to/sachagreif/disclosing-a-state-of-javascriptst...</a>
Even a slight zoom-in (110%) makes the labels on the axes overlap and become hard to read. I'm usually at 120%, and most of the text is practically unreadable at that point. Plotting is hard, let's go shopping! (Or maybe not, in a major survey like this that happens about the language the plots are implemented in?)
Could there be a conflict of interest with the pick of the year?<p>> Lee Robinson, Director of Developer Relations at Vercel<p>> SvelteKit is a fresh take on building for the web and has an incredibly passionate, growing community of supporters.
> Another guaranteed scientific finding: buying our t-shirt will increase your programming skills by over 9000!<p>Okay, fellow kids.<p>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.<p>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.
Full version of conclusion, by swyx : <a href="https://www.swyx.io/state-of-js-2021/" rel="nofollow">https://www.swyx.io/state-of-js-2021/</a>
Deno missed the library list (it includes an extensive standard library) and I'm glad to see it in included in the runtimes and mention of new things. I just finished moving an app from Nodejs+npm to it and am finding work is quite a bit easier. Initially I'd thought it was completely missing.
Yooo lets go Svelte! I really love using it and I’m glad other people are discovering it. I’m even releasing my own SaaS boilerplate made around SvelteKit: <a href="https://sveltesaas.com" rel="nofollow">https://sveltesaas.com</a>
The problem with javascript is not javascript, it is the system interface of the software where the javacript engine is: massive and beyond sanity heavy web renderers (blink|webkit/geeko) or very custom stuff like node-js.<p>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.<p>How to make this "generic" enough? If I recall properly, python has "ctype".
Much of this discussion is about frameworks, technology and trends in JavaScript as a language.<p>However, I personally find it shocking to see such a huge disparity when reviewing the gender breakdown between male, female and non-binary <a href="https://2021.stateofjs.com/en-US/demographics/#gender" rel="nofollow">https://2021.stateofjs.com/en-US/demographics/#gender</a>.<p>Simply put, the JavaScript community is still not doing a good job when it comes to inclusivity. That needs to change.
> <i>While we know collecting and publishing diversity data can be a sensitive issue, we do think it's important to obtain this data to help measure and improve the survey's efforts in terms of inclusivity and representativeness.</i><p>What are the survey makers doing to improve these efforts?<p>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.
Preact was interesting to see. Loads of "not interested" comments, but very well liked from people who tried it.<p>It's a library that should get more love than it does.
As someone new to front-end and who will probably only be building small hobbyist stuff by myself, is the mountain climb that is mastering React worth it? From my initial look into it, it seems incredibly complex.
Interestingly, the site itself is built with Gatsby, which scooted into their negative/unpopular quadrant this year and is ranked in their "C" tier.
16,085 respondents? That is not a lot. I don't know how many people use JavaScript in general, but that's probably at least 1 000 times that.