19 ms·

State of JavaScript 2021

297 points by kumartarun 5y ago

thomgo 5y ago
Does anyone know why data later was dropped from the survey? It was so included in the previous versions https://2020.stateofjs.com/en-US/technologies/datalayer/ https://2020.stateofjs.com/en-US/technologies/datalayer/ I'm curious if GraphQL is still growing in adoption.
sgdesign 5y ago
Survey maintainer here, thanks for posting this!
- EvaK_de 5y ago
  "Shadow DOM" has the wrong description, I think: "Web Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from the rest of your code — and utilize them in your web apps."
nindalf 5y ago
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. That’s the fate of any tool that becomes popular enough.
- searchableguy 5y ago
  People inheriting old react codebases now have to deal with way more complexity. 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.
  - aniforprez 5y ago
    There's also a lot of great improvements in tooling that just completely outclass what CRA does. Webpack is a dinosaur that is slow and painful to use compared to new stuff like vite that is blazing fast and isn't written in JavaScript. Nextjs comes with a lot of routing decisions already made so it becomes much easier to quickly build apps on top of it
    - dmitriid 5y ago
      That stuff is only blazing fast because it only targets greenfield projects and has no upgrade path for older projects with complex configurations (scratch "complex", any configurations). We've yet to see how it will fate in 3-5 years.
    - thrower123 5y ago
      I am always amazed at how slow any build process that involves webpack always becomes. Webpack runtime is well over 50% of the total time on our CI server builds, and that includes an installshield installer build and thousands of dotnet unit tests that are more complex than they ought to be in that pipeline.
  - tmstieff 5y ago
    I'm working on a codebase that evolved at the same pace as React, but without any thought for idiomatic principals. As a result, you have class-based components, purely functional components, hook based components, HOCs, Redux state passed in through the older functional way, Redux state passed in through an HOC, styled components, traditional CSS styled components, and anything else you can think of that was in vogue at some point. It's a mediocre code base that generally works as advertised, but the performance is trash due to misuse of styled components, and the state management is a nightmare to traverse. I think this is the reality of a lot of 3 - 5 year old React frontends, and it has definitely soured my opinion on React / Redux a bit. I'm not sure if this effects other frontend frameworks as much, but it does seem like React was always pushing for a "new way to do things" every year.
    - 5y ago
- agumonkey 5y ago
  Interesting pov. If people had a say in choosing something 90% like react, would they work happier ? Just like clients needing 4 times the same design just so they can pick their preferences?
  - rk06 5y ago
    react also happens to be The js framework used by meta. and the most popular js framework. how do you get something like 90% of that?
    - agumonkey 5y ago
      My comment wasn't clear but I had this idea that if someone made a clone of react called flowy with only marginal changes, people might be happy to use that because it's just "not react" anymore. I was questioning the emotional aspect of group work.
      - rk06 5y ago
        Take a look at preact. It is 90% like react in technical sense, and provides missing 10% in compat package
        aarpmcgee 5y ago
        It’s not perfect though. The only reason I’m not using preact is that my front-end library of choice, react-aria, does not work 100% with preact, though it sounds like it might now be close (unsure). https://react-spectrum.adobe.com/react-aria/index.html https://react-spectrum.adobe.com/react-aria/index.html https://github.com/adobe/react-spectrum/issues/781 https://github.com/adobe/react-spectrum/issues/781
jve 5y ago
Gulp build tool not receiving much love lately with a very strong "Would not use again". Why so? https://2021.stateofjs.com/en-US/libraries/build-tools/#build_tools_experience_marimekko https://2021.stateofjs.com/en-US/libraries/build-tools/#buil...
- joshghent 5y ago
  From my personal experience, it's slow, a pain to use outside of a few "happy paths" and there are better options out there
  - deleted 5y ago
    [deleted]
- conradfr 5y ago
  I would guess it's because it's old (in Javascript years).
- yakshaving_jgt 5y ago
  Perhaps it's because Grunt, Gulp, and similar JavaScript build tools never managed to improve upon a simple Makefile, which is decades-old tech.
- elevader 5y ago
  I might be getting that question totally wrong, but faced with the question of "would you use gulp for a new project" my answer would also be "no", altough I think that gulp is a nice and totally workable tool. 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.
  - bryanrasmussen 5y ago
    >If you need lots of complex build logic webpack is the way to go. 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?
throwaway4good 5y ago
Beginning of the end for Angular? Noticeable drop in relative satisfication but high usage numbers shows how hard it is to get rid of.
- trzmiel4 5y ago
  Satisfaction at 45% is the highest it's been since 2017. It's only lower on the chart because of all the new and shiny (and unused!) frameworks created later.
- rk06 5y ago
  It is literally the second most used js framework in the survey. 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.
- samwillis 5y ago
  Angular is like Java, it will always exist in enterprise. There will aways be jobs, it's just not "sexy".
wiz21c 5y ago
Depending on your age (guess what!) the age demographics is absolutely scary :-)
- anton-107 5y ago
  65 year olds don't do javascript. which is explainable since javascript itself is ~28 years old and node.js is like 15?
  - badsectoracula 5y ago
    People aren't born knowledge of the programming languages at their time of birth, 65 year olds can do JavaScript just fine, it isn't even anything weird as a language :-P. I think it is more likely that, largely, there are way more 25-34 programmers than 65+ programmers out there.
    - anton-107 5y ago
      Correct, but people are more likely to learn a new skill or a tech stack in their 20s than in their 40s. And when current 65+s were in their 20s javascript wasn't a thing yet.
      - wvh 5y ago
        Not sure people over 40 don't want to learn new things; they're likely just more interested in stable long-term technologies and investing their time wisely rather than hopping onto the newest fad all the time. With age comes understanding that the more things change, the more they stay the same. Emperor's new clothes and all that.
        pjmlp 5y ago
        Speaking a someone from that demographic, if one wants to keep being able to find a technical job, better keep updating those skills.
tomerkr 5y ago
Interested in the steady drop in satisfaction with Vue since 2018. I remember being positively impressed when I looked into it. 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?
- sgdesign 5y ago
  I think every framework sees this kind of drop once it gets widely adopted. Probably a combination of being confronted with real-world use cases, as well as the appeal of newer solutions that promise to do the same thing even better.
- killingtime74 5y ago
  It’s just the hype cycle. It’s only improved in recent years
- nawgz 5y ago
  Vue.js is heavily magic and doesn't support basic React concepts like render props. How is that possibly a popular framework? Like any "easy" library, you'll run into hard situations with no solutions.
  - searchableguy 5y ago
    What do you mean? Vue has slots which is similar to render props. https://vuejs.org/guide/components/slots.html#scoped-slots https://vuejs.org/guide/components/slots.html#scoped-slots
    - nawgz 5y ago
      After a read, I guess it does. A developer I respected claimed it was not easy to pass components down like this. Now I no longer respect him. Also, I still don't respect vue. Look at this abomination <MyComponent v-slot="{ text, count }"> {{ text }} {{ count }} </MyComponent>
eterm 5y ago
The satisfaction vs usage of angular is astonishing, but I wonder how much of that usage is legacy angular? 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.
- ttty 5y ago
  Most likely the 2nd. Everyone I know that is on angular hates it.
- throwaway4good 5y ago
  It is from Angular, not AngularJS, if that is what you are asking. The dissatisfaction is quite understable if you look at the actual framework; its broad use is because it is backed and marketed by Google.
- _the_inflator 5y ago
  I think that there is a lot of bubble bias: React is used in many 1 person projects as well as in small dev teams projects. I would not advise to use Angular in this context, if you are not fluent in Angular. 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.
  - MisterSandman 5y ago
    Did you mean C++ in your second paragraph?
- Cthulhu_ 5y ago
  I think it's both; it's a solid and stable framework, but people are bored with it because once the technical hurdles have been crossed, front-end software development is just a cycle of building and rebuilding new screens and forms ad infinitum, and a lot of developers get bored with that.
searchableguy 5y ago
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. https://vitest.dev/ https://vitest.dev/ 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.
- samuelstros 5y ago
  Vitest is on the list with highest satisfaction after the testing library :)
  - searchableguy 5y ago
    Ah, I missed it on mobile.
- ArcMex 5y ago
  >because jest looks unmaintained Help me understand what you meant by this? https://github.com/facebook/jest https://github.com/facebook/jest
  - searchableguy 5y ago
    Recent commits are not an indicator for a healthy package. There are many unfixed issues and PRs sitting there because there is a single maintainer handling all of it (which is very understandable and I'm grateful for all the work) https://github.com/facebook/jest/pull/11529#issuecomment-1027152470 https://github.com/facebook/jest/pull/11529#issuecomment-102...
- madeofpalk 5y ago
  > has growing pain with typescript and esm support. 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.
was_a_dev 5y ago
Not familiar with much front-end work - can anyone give insight to what's gone on with Ember?
- andreime 5y ago
  I'm using it as my framework of choice for 5 years and have helped programmers become productive with it. I have used other frameworks and keep up to date with React. I have not fulfilled the survey. 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.
- rk06 5y ago
  Ember is in “SPA” space, so it is competing against other big js frameworks like angular and Aurelia. Angular is super famous and is backed by google,so it is more used, than ember. 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.
- sensanaty 5y ago
  <bigRant> 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>
WA 5y ago
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. 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.
- manigandham 5y ago
  The site is definitely slow and bloated, which is actually quite emblematic of the state of the JS ecosystem.
davedx 5y ago
I read this report every year. This year it feels the most like it's driven by hype (and marketing, hi Vercel!). 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.
- trhoad 5y ago
  There is no "popularity" tab? There's a "satisfaction" tab which basically tells you nothing. 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.
- Cthulhu_ 5y ago
  It's based on polling, and I don't think people that are content with what they use are the demographic that fills in these things; it's the people that are interested in a broad range of things, in shiny new tech (magpie developers). e.g. Angular is a framework that a company invests in long-term, 5-10 year periods.
- sgdesign 5y ago
  Keep in mind that the whole point of this survey is to ask developers what they really think of the tools that are currently getting the most “hype”.
- 5y ago
ArcMex 5y ago
I am new to JS (solo dev). I am thinking of learning React first and once I get my feet wet, explore others like Svelte.
topicseed 5y ago
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. 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.
- slim109ya 5y ago
  I think I might try Golang, I would love to just code again. I'll look into Svelte as well.
  - topicseed 5y ago
    Golang also has a rich ecosystem of external community libraries but 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.
  - StefanWestfal 5y ago
    The truth about Svelte post of Rich Harris is very much in point about Svelte. It gets out of your way and feels like HTML/JS/CSS + a few thought out features. You can use a lot of libraries without a wrapper for svelte. https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c32185b61934 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.
- synergy20 5y ago
deleted 5y ago
[deleted]
yreg 5y ago
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.
- Vinnl 5y ago
  I mean, if you're unhappy, you can leave the industry or e.g. make a transition to back-end, and I'm sure many have.
- hajile 5y ago
  If you worked on the frontend through the framework wars from 2005-2015, you'd understand why having just 3-4 frameworks that have been around 5-7 years is an amazing state of affairs. Maybe it's not good overall, but it's the best that the frontend has ever achieved.
na_other 5y ago
Could there be a conflict of interest with the pick of the year? > 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.
- dimitrisnl 5y ago
  Not really, Vercel has employed the Svelte creator. They don't care which framework (svelteKit in this case) is popular, as long as it drives people to use their service. Also people can have opinions, outside of being company spoke persons.
tempouser 5y ago
As a react guy for 5 years solidjs was the only one which piqued my interest. I feel it has all the benefits of reactjs plus more.
- pier25 5y ago
  Why create a throwaway to write this?
  - woeriud 5y ago
    Not the OP but personally I have switched away from having a main HN account towards constantly creating new throwaways. HN does not let you delete your old comments & that's not acceptable to me for privacy reasons.
cj 5y ago
Only 22% make above $100k? [0] 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 https://2021.stateofjs.com/en-US/demographics/#yearly_salary Edit: Only 14% of respondents are in the US, which probably explains the above.
- conradfr 5y ago
  Yes, there's a "By Country" tab.
- Narann 5y ago
  There is a per country tab.
- Vinnl 5y ago
  There's also a tab that divides it up by country. In the US, 58.4% makes $100k-$200k, and 16.1% over $200k.
  - sundarurfriend 5y ago
    The contrast is really stark when you compare it to for eg. India, where 64% of the respondents earn less than $50k. And this is likely with a skewed sample too - 343 respondents, of which I'd bet most are in FAANG and FAANG-adjacent companies (eg. Flipkart). The actual percentage that earn above 2 lakhs per month (= $50k p.a.) is likely less than 20%, even allowing for a strict definition of a "Javascript developer".
    - MisterSandman 5y ago
      Those numbers for India are way, way, way off, even more than you said. The average Indian dev working in TCS, Infosys or Cognizant isn't going to care about surveys like these. (Though, I don't know if any of these companies even hire too many JS devs?)
- jillesvangurp 5y ago
  Frontend development is not a great career path; it's mostly a young people's game. I know senior react developers in their thirties that are increasingly struggling to find well paying gigs because they are competing with young people at half their rate. A lot of frontend developers transition to full stack js and from there to doing more serious things using Go, Rust, or whatever. That's where the money is. It's a natural path for them. 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.
deleted 5y ago
[deleted]
sylens 5y ago
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.
- austincheney 5y ago
  React is the hotness of the moment. If you want to maximize career mobility, salary, and immaturity all at the same time React is for you.
  - scq 5y ago
    React is eight years old. Sure is a long "moment".
- snoopen 5y ago
  I'm quite fond of Vuejs. It's easy to get started... my first experience with it was too drop in the CDN link and start with the basic example. It can easily do anything react can do.
- sgdesign 5y ago
  React by itself is quite simple, but precisely because it's so simple a lot of third-party libraries have cropped up to fill out the gaps. I'm not sure if other ecosystems are really simpler, or if the complexity is just spread out differently… At least with React you have the option of not buying into Redux/GraphQL/etc. if you don't want to.
- rk06 5y ago
  No, it is not. Unless you are planning to use your experience for getting a job, it is not worth it. I would advise you to use vue or svelte.
  - sylens 5y ago
    Would most likely not factor into the career path as I don't have the time to dedicate myself to becoming a front-end pro
rembrant 5y ago
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 const { container, heading } = divs; 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. const container = document.createElement('div'); container.className = 'container'; const heading = document.createElement('div'); heading.className = 'heading'; The other way you can create elements is just with a common: const heading = span({ title: artName, innerText: whatever }); 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. 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; 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.
- seumars 5y ago
  Your comment makes no sense without you specifying what the "divs" variable value even is.
  - bretnsug 5y ago
    > 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 A never ending well of new divs that have the class name of the variable name
  - cdrini 5y ago
    I put an example of what `divs` could be in my comment here: https://news.ycombinator.com/item?id=30357788#30361633 https://news.ycombinator.com/item?id=30357788#30361633
davidkuennen 5y ago
I love how the charts are being displayed!
samwillis 5y ago
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. 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.
- seumars 5y ago
  "a core part of their business model" means actively look for vendor lock-in. I have to say I don't get it.
  - samwillis 5y ago
    Ok, so an examples of what I mean: 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.
lucideer 5y ago
> 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. 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.
sundarurfriend 5y ago
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?)
rk06 5y ago
Full version of conclusion, by swyx : https://www.swyx.io/state-of-js-2021/ https://www.swyx.io/state-of-js-2021/
- junon 5y ago
  > JavaScript is in a tremendously better state today compared to the first survey in 2016. Back then, only 21% of you used TypeScript, compared to a nice 69% today. ... 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".
  - mwid 5y ago
    TypeScript is a "replacement" for JavaScript in that it has become the defacto standard for any serious project for at least three years now. 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.
junon 5y ago
> Another guaranteed scientific finding: buying our t-shirt will increase your programming skills by over 9000! 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.
- gred 5y ago
  > The JS community has devolved into bunch of people who re-invent everything in 2-3 year cycles. Devolved? I honestly thought it had always been this way, going all the way back to the jQuery / MooTools / YUI / Dojo days.
  - junon 5y ago
    People were pretty supportive of each other for a long time. The community was a somewhat tighter-knit group of people just enjoying seeing what could be done with Javascript. Nowadays everything is so enterprise and formalized (see Typescript), and if you don't do X thing exactly in Y way, you're unemployable and non-"standard" (even though the "standard" changes every 6 months). 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.
    - gred 5y ago
      Thanks for the clarification!
Glench 5y ago
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: https://sveltesaas.com https://sveltesaas.com
jerrygoyal 5y ago
Interesting tidbits: 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
- MisterSandman 5y ago
  I use optional chaining so much I forgot it was, like, a "feature" that was added semi-recently
pier25 5y ago
The performance is really bad on my cheap android phone. That's really the biggest indicator of the state of js.
nobleach 5y ago
"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. Even still, THIS is the state of the JavaScript. None of that has to do with the language.
- rob74 5y ago
  Well, if developers would approach their task with knowledge and wisdom, then the abomination that is Node.js would never have been unleashed on the developer community. But here we are: "yay, Google has written a blazingly fast JS engine, so now we can use JS in the backend!" - never once stopping to question if this is really a good idea...
  - smrtinsert 5y ago
    I almost spit out my coffee. I had completely forgotten that's how we got here. It developed like pretty much everyone thought it would.
    - MonaroVXR 5y ago
      Is it that bad? I'm kinda new to web development.
      - nobleach 5y ago
        Bad? I don't think I'd use that term. Fragmented? Full of "bike-shedding"? Fanboi-ism? Definitely those things apply. There are some tools that seem to dominate the market currently. And as often is the case, you may form a love/hate relationship with them. Web dev in 2008 was simple. You had your markup, your CSS, and your scripts that progressively enhanced that markup/styling. There are subsets of people that never wanted it to move beyond that. There's another subset that's been pushing the boundaries of what the web can do. Both are right, and both could stand to learn a few things. If you find yourself working alone/contracting, you have absolute freedom to try out anything you want. Find what works for you. Do NOT use something simply because "the cool kids on Twitter are hyping it". Find out if those tools actually make your dev experience, and your user's experience better. If you find yourself on a team at a larger org, learn to be comfortable with the tools they've chosen - until you reach a point where you get to have a say. Web development can be an awfully fun career but I'd urge you as you get a bit deeper into the programming side of it, to really learn some fundamental concepts. Maybe start with Jack Herrington videos on Youtube: https://www.youtube.com/c/JackHerrington https://www.youtube.com/c/JackHerrington I've found him to be very level-headed in his approach.
swyx 5y ago
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! https://www.swyx.io/state-of-js-2021/ https://www.swyx.io/state-of-js-2021/
sylware 5y ago
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. 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".
synergy20 5y ago
Spent one hour to wade through all these results, here are my take away: 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. I'm going to checkout svelte one more time and see where it is better than vue.
- Someone1234 5y ago
  What advantages does pnpm have over yarn? I'm all on board with npm being problematic due to the security-design, but does pnpm solve that weakness better than yarn or provide other killer features? PS - No testing framework in your list. Any reason?
  - synergy20 5y ago
    forgot testing, I use jest and am looking into vitest
  - MrJohz 5y ago
    In comparison to yarn 1, my experience of pnpm is basically that it's even quicker (because it's mainly just linking), and significantly more intuitive. My mental model of the node modules directory is that it's all of the direct dependencies of my project, with each of those dependencies having its dependencies in nested node modules directories. Practically, that's not true any more because of deduping, which does solve a lot of problems, but makes that mental model a lot more complex. 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.
mwigdahl 5y ago
Interestingly, the site itself is built with Gatsby, which scooted into their negative/unpopular quadrant this year and is ranked in their "C" tier.
stack_framer 5y ago
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. [0] https://dev.to/sachagreif/disclosing-a-state-of-javascriptstate-of-css-data-breach-2lg1 https://dev.to/sachagreif/disclosing-a-state-of-javascriptst...
TearsInTheRain 5y ago
Is there a "state of ..." survey for other fields? Would be super interested in crypto and ML surveys.
Zababa 5y ago
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.
canaus 5y ago
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. 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.
- FpUser 5y ago
  >"There seems to be a bit of animosity towards front-end development" 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.
  - canaus 5y ago
    Aren't desktop solutions typically vendor locked?
    - FpUser 5y ago
      Yes. So I paid money for tool that works nicely and saves me from the insanity web front end is (on desktop obviously). On a browser it is to the point that I prefer plain Java Script with couple of libs instead of those frameworks that supposed to make my life easy but look like abomination when I compare to something like Delphi
  - hasperdi 5y ago
    I think that's a matter of perspective. Front-end development tools are more diverse because there are more devs working in that sector and there are more diverse needs. 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.
hajile 5y ago
Preact was interesting to see. Loads of "not interested" comments, but very well liked from people who tried it. It's a library that should get more love than it does.
jimmont 5y ago
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.
canyonero 5y ago
Much of this discussion is about frameworks, technology and trends in JavaScript as a language. 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 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.

297 points by kumartarun 5y ago

Does anyone know why data later was dropped from the survey? It was so included in the previous versions https://2020.stateofjs.com/en-US/technologies/datalayer/ https://2020.stateofjs.com/en-US/technologies/datalayer/ I'm curious if GraphQL is still growing in adoption.

sgdesign 5y ago

Survey maintainer here, thanks for posting this!

EvaK_de 5y ago
"Shadow DOM" has the wrong description, I think: "Web Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from the rest of your code — and utilize them in your web apps."

nindalf 5y ago

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. That’s the fate of any tool that becomes popular enough.

searchableguy 5y ago
People inheriting old react codebases now have to deal with way more complexity. 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.
- aniforprez 5y ago
  There's also a lot of great improvements in tooling that just completely outclass what CRA does. Webpack is a dinosaur that is slow and painful to use compared to new stuff like vite that is blazing fast and isn't written in JavaScript. Nextjs comes with a lot of routing decisions already made so it becomes much easier to quickly build apps on top of it
  - dmitriid 5y ago
    That stuff is only blazing fast because it only targets greenfield projects and has no upgrade path for older projects with complex configurations (scratch "complex", any configurations). We've yet to see how it will fate in 3-5 years.
  - thrower123 5y ago
    I am always amazed at how slow any build process that involves webpack always becomes. Webpack runtime is well over 50% of the total time on our CI server builds, and that includes an installshield installer build and thousands of dotnet unit tests that are more complex than they ought to be in that pipeline.
- tmstieff 5y ago
  I'm working on a codebase that evolved at the same pace as React, but without any thought for idiomatic principals. As a result, you have class-based components, purely functional components, hook based components, HOCs, Redux state passed in through the older functional way, Redux state passed in through an HOC, styled components, traditional CSS styled components, and anything else you can think of that was in vogue at some point. It's a mediocre code base that generally works as advertised, but the performance is trash due to misuse of styled components, and the state management is a nightmare to traverse. I think this is the reality of a lot of 3 - 5 year old React frontends, and it has definitely soured my opinion on React / Redux a bit. I'm not sure if this effects other frontend frameworks as much, but it does seem like React was always pushing for a "new way to do things" every year.
  - 5y ago
agumonkey 5y ago
Interesting pov. If people had a say in choosing something 90% like react, would they work happier ? Just like clients needing 4 times the same design just so they can pick their preferences?
- rk06 5y ago
  react also happens to be The js framework used by meta. and the most popular js framework. how do you get something like 90% of that?
  - agumonkey 5y ago
    My comment wasn't clear but I had this idea that if someone made a clone of react called flowy with only marginal changes, people might be happy to use that because it's just "not react" anymore. I was questioning the emotional aspect of group work.
    - rk06 5y ago
      Take a look at preact. It is 90% like react in technical sense, and provides missing 10% in compat package
      - aarpmcgee 5y ago
        It’s not perfect though. The only reason I’m not using preact is that my front-end library of choice, react-aria, does not work 100% with preact, though it sounds like it might now be close (unsure). https://react-spectrum.adobe.com/react-aria/index.html https://react-spectrum.adobe.com/react-aria/index.html https://github.com/adobe/react-spectrum/issues/781 https://github.com/adobe/react-spectrum/issues/781

jve 5y ago

Gulp build tool not receiving much love lately with a very strong "Would not use again". Why so? https://2021.stateofjs.com/en-US/libraries/build-tools/#build_tools_experience_marimekko https://2021.stateofjs.com/en-US/libraries/build-tools/#buil...

joshghent 5y ago
From my personal experience, it's slow, a pain to use outside of a few "happy paths" and there are better options out there
- deleted 5y ago
  [deleted]
conradfr 5y ago
I would guess it's because it's old (in Javascript years).
yakshaving_jgt 5y ago
Perhaps it's because Grunt, Gulp, and similar JavaScript build tools never managed to improve upon a simple Makefile, which is decades-old tech.
elevader 5y ago
I might be getting that question totally wrong, but faced with the question of "would you use gulp for a new project" my answer would also be "no", altough I think that gulp is a nice and totally workable tool. 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.
- bryanrasmussen 5y ago
  >If you need lots of complex build logic webpack is the way to go. 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?

throwaway4good 5y ago

Beginning of the end for Angular? Noticeable drop in relative satisfication but high usage numbers shows how hard it is to get rid of.

trzmiel4 5y ago
Satisfaction at 45% is the highest it's been since 2017. It's only lower on the chart because of all the new and shiny (and unused!) frameworks created later.
rk06 5y ago
It is literally the second most used js framework in the survey. 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.
samwillis 5y ago
Angular is like Java, it will always exist in enterprise. There will aways be jobs, it's just not "sexy".

wiz21c 5y ago

Depending on your age (guess what!) the age demographics is absolutely scary :-)

anton-107 5y ago
65 year olds don't do javascript. which is explainable since javascript itself is ~28 years old and node.js is like 15?
- badsectoracula 5y ago
  People aren't born knowledge of the programming languages at their time of birth, 65 year olds can do JavaScript just fine, it isn't even anything weird as a language :-P. I think it is more likely that, largely, there are way more 25-34 programmers than 65+ programmers out there.
  - anton-107 5y ago
    Correct, but people are more likely to learn a new skill or a tech stack in their 20s than in their 40s. And when current 65+s were in their 20s javascript wasn't a thing yet.
    - wvh 5y ago
      Not sure people over 40 don't want to learn new things; they're likely just more interested in stable long-term technologies and investing their time wisely rather than hopping onto the newest fad all the time. With age comes understanding that the more things change, the more they stay the same. Emperor's new clothes and all that.
      - pjmlp 5y ago
        Speaking a someone from that demographic, if one wants to keep being able to find a technical job, better keep updating those skills.

tomerkr 5y ago

Interested in the steady drop in satisfaction with Vue since 2018. I remember being positively impressed when I looked into it. 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?

sgdesign 5y ago
I think every framework sees this kind of drop once it gets widely adopted. Probably a combination of being confronted with real-world use cases, as well as the appeal of newer solutions that promise to do the same thing even better.
killingtime74 5y ago
It’s just the hype cycle. It’s only improved in recent years
nawgz 5y ago
Vue.js is heavily magic and doesn't support basic React concepts like render props. How is that possibly a popular framework? Like any "easy" library, you'll run into hard situations with no solutions.
- searchableguy 5y ago
  What do you mean? Vue has slots which is similar to render props. https://vuejs.org/guide/components/slots.html#scoped-slots https://vuejs.org/guide/components/slots.html#scoped-slots
  - nawgz 5y ago
    After a read, I guess it does. A developer I respected claimed it was not easy to pass components down like this. Now I no longer respect him. Also, I still don't respect vue. Look at this abomination <MyComponent v-slot="{ text, count }"> {{ text }} {{ count }} </MyComponent>

eterm 5y ago

The satisfaction vs usage of angular is astonishing, but I wonder how much of that usage is legacy angular? 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.

ttty 5y ago
Most likely the 2nd. Everyone I know that is on angular hates it.
throwaway4good 5y ago
It is from Angular, not AngularJS, if that is what you are asking. The dissatisfaction is quite understable if you look at the actual framework; its broad use is because it is backed and marketed by Google.
_the_inflator 5y ago
I think that there is a lot of bubble bias: React is used in many 1 person projects as well as in small dev teams projects. I would not advise to use Angular in this context, if you are not fluent in Angular. 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.
- MisterSandman 5y ago
  Did you mean C++ in your second paragraph?
Cthulhu_ 5y ago
I think it's both; it's a solid and stable framework, but people are bored with it because once the technical hurdles have been crossed, front-end software development is just a cycle of building and rebuilding new screens and forms ad infinitum, and a lot of developers get bored with that.

searchableguy 5y ago

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. https://vitest.dev/ https://vitest.dev/ 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.

samuelstros 5y ago
Vitest is on the list with highest satisfaction after the testing library :)
- searchableguy 5y ago
  Ah, I missed it on mobile.
ArcMex 5y ago
>because jest looks unmaintained Help me understand what you meant by this? https://github.com/facebook/jest https://github.com/facebook/jest
- searchableguy 5y ago
  Recent commits are not an indicator for a healthy package. There are many unfixed issues and PRs sitting there because there is a single maintainer handling all of it (which is very understandable and I'm grateful for all the work) https://github.com/facebook/jest/pull/11529#issuecomment-1027152470 https://github.com/facebook/jest/pull/11529#issuecomment-102...
madeofpalk 5y ago
> has growing pain with typescript and esm support. 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.

was_a_dev 5y ago

Not familiar with much front-end work - can anyone give insight to what's gone on with Ember?

andreime 5y ago
I'm using it as my framework of choice for 5 years and have helped programmers become productive with it. I have used other frameworks and keep up to date with React. I have not fulfilled the survey. 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.
rk06 5y ago
Ember is in “SPA” space, so it is competing against other big js frameworks like angular and Aurelia. Angular is super famous and is backed by google,so it is more used, than ember. 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.
sensanaty 5y ago
<bigRant> 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>

WA 5y ago

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. 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.

manigandham 5y ago
The site is definitely slow and bloated, which is actually quite emblematic of the state of the JS ecosystem.

davedx 5y ago

I read this report every year. This year it feels the most like it's driven by hype (and marketing, hi Vercel!). 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.

trhoad 5y ago
There is no "popularity" tab? There's a "satisfaction" tab which basically tells you nothing. 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.
Cthulhu_ 5y ago
It's based on polling, and I don't think people that are content with what they use are the demographic that fills in these things; it's the people that are interested in a broad range of things, in shiny new tech (magpie developers). e.g. Angular is a framework that a company invests in long-term, 5-10 year periods.
sgdesign 5y ago
Keep in mind that the whole point of this survey is to ask developers what they really think of the tools that are currently getting the most “hype”.
5y ago

ArcMex 5y ago

I am new to JS (solo dev). I am thinking of learning React first and once I get my feet wet, explore others like Svelte.

topicseed 5y ago

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. 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.

slim109ya 5y ago
I think I might try Golang, I would love to just code again. I'll look into Svelte as well.
- topicseed 5y ago
  Golang also has a rich ecosystem of external community libraries but 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.
- StefanWestfal 5y ago
  The truth about Svelte post of Rich Harris is very much in point about Svelte. It gets out of your way and feels like HTML/JS/CSS + a few thought out features. You can use a lot of libraries without a wrapper for svelte. https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c32185b61934 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.
synergy20 5y ago

deleted 5y ago

[deleted]

yreg 5y ago

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.

Vinnl 5y ago
I mean, if you're unhappy, you can leave the industry or e.g. make a transition to back-end, and I'm sure many have.
hajile 5y ago
If you worked on the frontend through the framework wars from 2005-2015, you'd understand why having just 3-4 frameworks that have been around 5-7 years is an amazing state of affairs. Maybe it's not good overall, but it's the best that the frontend has ever achieved.

na_other 5y ago

Could there be a conflict of interest with the pick of the year? > 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.

dimitrisnl 5y ago
Not really, Vercel has employed the Svelte creator. They don't care which framework (svelteKit in this case) is popular, as long as it drives people to use their service. Also people can have opinions, outside of being company spoke persons.

tempouser 5y ago

As a react guy for 5 years solidjs was the only one which piqued my interest. I feel it has all the benefits of reactjs plus more.

pier25 5y ago
Why create a throwaway to write this?
- woeriud 5y ago
  Not the OP but personally I have switched away from having a main HN account towards constantly creating new throwaways. HN does not let you delete your old comments & that's not acceptable to me for privacy reasons.

cj 5y ago

Only 22% make above $100k? [0] 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 https://2021.stateofjs.com/en-US/demographics/#yearly_salary Edit: Only 14% of respondents are in the US, which probably explains the above.

conradfr 5y ago
Yes, there's a "By Country" tab.
Narann 5y ago
There is a per country tab.
Vinnl 5y ago
There's also a tab that divides it up by country. In the US, 58.4% makes $100k-$200k, and 16.1% over $200k.
- sundarurfriend 5y ago
  The contrast is really stark when you compare it to for eg. India, where 64% of the respondents earn less than $50k. And this is likely with a skewed sample too - 343 respondents, of which I'd bet most are in FAANG and FAANG-adjacent companies (eg. Flipkart). The actual percentage that earn above 2 lakhs per month (= $50k p.a.) is likely less than 20%, even allowing for a strict definition of a "Javascript developer".
  - MisterSandman 5y ago
    Those numbers for India are way, way, way off, even more than you said. The average Indian dev working in TCS, Infosys or Cognizant isn't going to care about surveys like these. (Though, I don't know if any of these companies even hire too many JS devs?)
jillesvangurp 5y ago
Frontend development is not a great career path; it's mostly a young people's game. I know senior react developers in their thirties that are increasingly struggling to find well paying gigs because they are competing with young people at half their rate. A lot of frontend developers transition to full stack js and from there to doing more serious things using Go, Rust, or whatever. That's where the money is. It's a natural path for them. 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.

deleted 5y ago

[deleted]

sylens 5y ago

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.

austincheney 5y ago
React is the hotness of the moment. If you want to maximize career mobility, salary, and immaturity all at the same time React is for you.
- scq 5y ago
  React is eight years old. Sure is a long "moment".
snoopen 5y ago
I'm quite fond of Vuejs. It's easy to get started... my first experience with it was too drop in the CDN link and start with the basic example. It can easily do anything react can do.
sgdesign 5y ago
React by itself is quite simple, but precisely because it's so simple a lot of third-party libraries have cropped up to fill out the gaps. I'm not sure if other ecosystems are really simpler, or if the complexity is just spread out differently… At least with React you have the option of not buying into Redux/GraphQL/etc. if you don't want to.
rk06 5y ago
No, it is not. Unless you are planning to use your experience for getting a job, it is not worth it. I would advise you to use vue or svelte.
- sylens 5y ago
  Would most likely not factor into the career path as I don't have the time to dedicate myself to becoming a front-end pro

rembrant 5y ago

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 const { container, heading } = divs; 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. const container = document.createElement('div'); container.className = 'container'; const heading = document.createElement('div'); heading.className = 'heading'; The other way you can create elements is just with a common: const heading = span({ title: artName, innerText: whatever }); 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. 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; 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.

seumars 5y ago
Your comment makes no sense without you specifying what the "divs" variable value even is.
- bretnsug 5y ago
  > 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 A never ending well of new divs that have the class name of the variable name
- cdrini 5y ago
  I put an example of what `divs` could be in my comment here: https://news.ycombinator.com/item?id=30357788#30361633 https://news.ycombinator.com/item?id=30357788#30361633

davidkuennen 5y ago

I love how the charts are being displayed!

samwillis 5y ago

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. 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.

seumars 5y ago
"a core part of their business model" means actively look for vendor lock-in. I have to say I don't get it.
- samwillis 5y ago
  Ok, so an examples of what I mean: 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.

lucideer 5y ago

> 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. 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.

sundarurfriend 5y ago

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?)

rk06 5y ago

Full version of conclusion, by swyx : https://www.swyx.io/state-of-js-2021/ https://www.swyx.io/state-of-js-2021/

junon 5y ago
> JavaScript is in a tremendously better state today compared to the first survey in 2016. Back then, only 21% of you used TypeScript, compared to a nice 69% today. ... 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".
- mwid 5y ago
  TypeScript is a "replacement" for JavaScript in that it has become the defacto standard for any serious project for at least three years now. 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.

junon 5y ago

> Another guaranteed scientific finding: buying our t-shirt will increase your programming skills by over 9000! 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.

gred 5y ago
> The JS community has devolved into bunch of people who re-invent everything in 2-3 year cycles. Devolved? I honestly thought it had always been this way, going all the way back to the jQuery / MooTools / YUI / Dojo days.
- junon 5y ago
  People were pretty supportive of each other for a long time. The community was a somewhat tighter-knit group of people just enjoying seeing what could be done with Javascript. Nowadays everything is so enterprise and formalized (see Typescript), and if you don't do X thing exactly in Y way, you're unemployable and non-"standard" (even though the "standard" changes every 6 months). 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.
  - gred 5y ago
    Thanks for the clarification!

Glench 5y ago

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: https://sveltesaas.com https://sveltesaas.com

jerrygoyal 5y ago

Interesting tidbits: 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

MisterSandman 5y ago
I use optional chaining so much I forgot it was, like, a "feature" that was added semi-recently

pier25 5y ago

The performance is really bad on my cheap android phone. That's really the biggest indicator of the state of js.

nobleach 5y ago

"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. Even still, THIS is the state of the JavaScript. None of that has to do with the language.

rob74 5y ago
Well, if developers would approach their task with knowledge and wisdom, then the abomination that is Node.js would never have been unleashed on the developer community. But here we are: "yay, Google has written a blazingly fast JS engine, so now we can use JS in the backend!" - never once stopping to question if this is really a good idea...
- smrtinsert 5y ago
  I almost spit out my coffee. I had completely forgotten that's how we got here. It developed like pretty much everyone thought it would.
  - MonaroVXR 5y ago
    Is it that bad? I'm kinda new to web development.
    - nobleach 5y ago
      Bad? I don't think I'd use that term. Fragmented? Full of "bike-shedding"? Fanboi-ism? Definitely those things apply. There are some tools that seem to dominate the market currently. And as often is the case, you may form a love/hate relationship with them. Web dev in 2008 was simple. You had your markup, your CSS, and your scripts that progressively enhanced that markup/styling. There are subsets of people that never wanted it to move beyond that. There's another subset that's been pushing the boundaries of what the web can do. Both are right, and both could stand to learn a few things. If you find yourself working alone/contracting, you have absolute freedom to try out anything you want. Find what works for you. Do NOT use something simply because "the cool kids on Twitter are hyping it". Find out if those tools actually make your dev experience, and your user's experience better. If you find yourself on a team at a larger org, learn to be comfortable with the tools they've chosen - until you reach a point where you get to have a say. Web development can be an awfully fun career but I'd urge you as you get a bit deeper into the programming side of it, to really learn some fundamental concepts. Maybe start with Jack Herrington videos on Youtube: https://www.youtube.com/c/JackHerrington https://www.youtube.com/c/JackHerrington I've found him to be very level-headed in his approach.

swyx 5y ago

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! https://www.swyx.io/state-of-js-2021/ https://www.swyx.io/state-of-js-2021/

sylware 5y ago

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. 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".

synergy20 5y ago

Spent one hour to wade through all these results, here are my take away: 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. I'm going to checkout svelte one more time and see where it is better than vue.

Someone1234 5y ago
What advantages does pnpm have over yarn? I'm all on board with npm being problematic due to the security-design, but does pnpm solve that weakness better than yarn or provide other killer features? PS - No testing framework in your list. Any reason?
- synergy20 5y ago
  forgot testing, I use jest and am looking into vitest
- MrJohz 5y ago
  In comparison to yarn 1, my experience of pnpm is basically that it's even quicker (because it's mainly just linking), and significantly more intuitive. My mental model of the node modules directory is that it's all of the direct dependencies of my project, with each of those dependencies having its dependencies in nested node modules directories. Practically, that's not true any more because of deduping, which does solve a lot of problems, but makes that mental model a lot more complex. 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.

mwigdahl 5y ago

Interestingly, the site itself is built with Gatsby, which scooted into their negative/unpopular quadrant this year and is ranked in their "C" tier.

stack_framer 5y ago

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. [0] https://dev.to/sachagreif/disclosing-a-state-of-javascriptstate-of-css-data-breach-2lg1 https://dev.to/sachagreif/disclosing-a-state-of-javascriptst...

TearsInTheRain 5y ago

Is there a "state of ..." survey for other fields? Would be super interested in crypto and ML surveys.

Zababa 5y ago

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.

canaus 5y ago

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. 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.

FpUser 5y ago
>"There seems to be a bit of animosity towards front-end development" 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.
- canaus 5y ago
  Aren't desktop solutions typically vendor locked?
  - FpUser 5y ago
    Yes. So I paid money for tool that works nicely and saves me from the insanity web front end is (on desktop obviously). On a browser it is to the point that I prefer plain Java Script with couple of libs instead of those frameworks that supposed to make my life easy but look like abomination when I compare to something like Delphi
- hasperdi 5y ago
  I think that's a matter of perspective. Front-end development tools are more diverse because there are more devs working in that sector and there are more diverse needs. 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.

hajile 5y ago

Preact was interesting to see. Loads of "not interested" comments, but very well liked from people who tried it. It's a library that should get more love than it does.

jimmont 5y ago

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.

canyonero 5y ago

Much of this discussion is about frameworks, technology and trends in JavaScript as a language. 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 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.