There was a time when I treated State of JS results almost like prophecy.
A new edition dropped and I’d read it with excitement, looking for the future of JavaScript hidden somewhere in those charts.
Today I still read it.
But with much less awe and much more distance.
If you haven’t seen the 2025 results yet, you can explore them here:
https://2025.stateofjs.com/en-US/
It’s honestly a fantastic piece of work. Beautifully built, interactive, full of data. Huge respect to the creators — it’s not a small project.
But the real question is:
How seriously should we treat it?
A Very Short Recap of 2025 📊
I won’t do a full summary. Plenty of people already did, and you can just look at the charts.
In short:
- TypeScript is firmly mainstream
- Big frameworks mostly hold their positions
- Tooling keeps evolving
Surveys like this are great for sensing the ecosystem.
What’s popular. What’s growing. What annoys developers.
Sometimes tools highly praised in surveys reach real production adoption years later. Vite is a good example.
So yes — these surveys are useful.
But they come with a lot of nuance.
My Younger-Developer Phase 😄
I remember being a junior and wanting to immediately try (or even introduce to production) everything that ranked high in satisfaction.
Luckily, nobody asked for my opinion back then 😉
I also used to feel genuinely sad seeing Angular score poorly in satisfaction.
Because… I liked working with it. My teams liked it. Our projects worked.
Was Angular dying?
Spoiler: many years later, it’s still doing just fine.
And it made me wonder:
If some tools are so loved in surveys, why don’t they dominate job listings?
Why is there constant demand for React and Angular devs, but much less for Vue or Svelte (at least where I live)?
A Little Story About Surveys 🧠
Fun fact: when I was very young, I had a part-time job in a company that conducted surveys.
That’s where I learned how serious research is actually done.
A reliable study needs:
carefully selected demographics, well-phrased neutral questions, controlled variables, clear definitions, sometimes even different question orders to avoid bias.
As you can guess — State of JS (and most dev surveys) don’t meet those strict scientific standards.
And that’s okay. They’re not academic research.
But it’s worth remembering.
Who Actually Answers? 🔥
Most likely:
people who care about tech, follow trends, hang out on DEV, Reddit, Twitter, and enjoy exploring tools.
Also people willing to spend time filling out a long survey.
Who probably doesn’t?
Developers who treat programming as a normal job and close their laptop at 5 PM.
That group might be huge. Possibly the majority.
So we’re mostly hearing from the curious and passionate slice of the community.
Which is interesting — but not the whole picture.
Regional Reality 🌍
Participation is open, which is great, but it also means representation isn’t proportional.
The US is strongly represented.
India has one of the biggest developer populations in the world, yet doesn’t always show up proportionally.
And regions differ.
Vue is strong in parts of Asia.
In Poland and much of Europe, React and Angular still dominate job markets.
So survey trends don’t always match local reality.
What Does “Usage” Even Mean? 🤨
This one always makes me think.
If I heard about a tool once by an accident in an office kitchen, do I have awareness?
If I did a tutorial, does that count as usage?
Or should usage mean delivering a real project?
When someone says they like a tool, is it after comparing many options, or just because it feels nice? Or maybe it's the only tool he/she knows? 🤔
And even in anonymous surveys, some people may hesitate to admit they don’t know something.
Human psychology never disappears from data.
Surveys vs Real Careers 💼
Can surveys help choose what to learn?
Sometimes.
Can they guide tech decisions?
Maybe.
But surveys and job markets are two different worlds.
You can learn the “best” framework and still land in a 10-year-old legacy codebase.
You can study modern React and get class components on day one 😉
Real careers are messy and non-linear.
How to Read Surveys 🧭
What works for me:
Look at trends year to year.
Compare satisfaction and usage.
Watch movement, not winners.
Remember that popular tools get more criticism simply because people use them daily.
And most importantly:
treat surveys as insight, not truth.
Yesterday’s winner can be tomorrow’s loser.
So… Should We Care? 🙂
Yes. But calmly.
State of JS doesn’t tell you what to use.
It shows what developers are curious about right now.
Think of it as a compass, not a GPS.
Direction, not destination.
It reflects the mood of the community more than the future of the industry.
Still useful. Just not absolute.
What do you think?
Do surveys influence your decisions, or do you mostly treat them as interesting reading?
Top comments (69)
I think these surveys show what new "developer-led" projects may use as core technology. Most people building systems have long standing products, or at least libraries, that you can't keep re-inventing. I love Svelte. I still use React for new work projects because I can hire a team; we all know it, and it is good enough!
Exactly, that’s a great example 🙂
I once even had a quick demo built in Angular, which might sound illogical on paper, but I had a developer who was very fluent in it and that was simply the fastest path.
“Good enough” is really the key phrase here.
I don't know why not use jsDoc more frequently? Because that is capable to solve static typing without modify the JS language itself.
My second favorite is: pipeline operator. I hope sooner or later it is will be part of JS.
Interesting point 🙂 JSDoc can definitely help with types in smaller projects. In larger codebases though, many teams still prefer full TypeScript for stronger guarantees and tooling.
And yes, pipeline operator would be fun to see standardized someday!
Personally, I prefer JSDoc if you are doing anything highly polymorphic or using inversion of control because it works well and doesn't force you into corners. My codebase is not small; it has a TIOBE score of 85 and a maintainability score of 87+. I'm very happy with JSDoc as a tool for typing; the AI understands and writes it as well as my dev team.
I know my opinion is unpopular, but I find TS constantly trying to stop me from doing things that its target language allows, and I consider those things to be useful flexibility. Yes, I know I can just ignore TS whenever I like, but why bother with a build step?
That’s a really valuable practitioner’s perspective - and I appreciate that it comes without fanboyism 🙂
I personally use TypeScript because the type system is still more powerful for my needs (advanced generics alone can be a big win). I’m also not fully convinced by the “build step” argument, since most projects already have bundling, tree-shaking, etc., so the extra cost is usually small.
But you’ve definitely made me curious - I might try JSDoc in one of my own projects and see how it feels in practice 😄
which advanced generic functionality are you missing from jsDoc?
I know jsDoc documentation is so terrible compare the TS documentation.
Only the real test can show which syntax is working in jsDoc.
We have two different jsDoc syntax have, the newer is near equal the TS one.
Maybe I phrased it imprecisely earlier - I was thinking more about conditional types, which I do use sometimes. I’m not aware of JSDoc supporting those (at least not in the same way as TS). If it actually does now, I’d be genuinely impressed 🙂
Either way, this is a really interesting area - could be a fun topic for a deep-dive article 😄
I should say that our IDEs do use TypeScript to help with intellisense, so TS is running in the background, interpreting the JS and the JSDoc (which we mostly use TypeScript style definitions for - it's just super lightweight and only where needed). I should probably try a whole project in TS, but each side project I've done I end up trying to follow the rails and I'm back in that corner. Probably my issues lol.
Just out of curiosity 🙂 how do you feel about strongly typed languages like Java, C#, or Rust then? Does the strict typing there bother you as well, or does it feel different than in TS?
I am fine with a strongly typed languages also. But I cannot play how to solve a deeply structured quite dynamic types with rust for example, where user type passed to a generic.
But without strong typing I am also fine just need to remember the type structure
Like Peter, I'm totally 100 with strongly typed languages. It makes sense there. I write C# frequently, and I do fight my way through tough cases where I need the flexibility, but mostly, that's not what I'm doing there. I guess it makes sense in those languages because it directly affects lookup tables and pointer systems (I'm a C++/C programmer too) - so I know why I'm making the trade-offs. JavaScript lets me think in a dynamic fashion, and I can then decide if my choices are messing up V8 optimisation in a case that matters and fix that - they almost never do.
If you were to look at this JS project, you'd see things constantly decorating other objects and then consuming their decorations, etc. Because of inversion of control, I don't necessarily know these things, and I certainly don't want the core code to know anything about the extensions, because then I'd have to keep touching those files. Don't get me wrong, you can do this in TS, but you end up with some wacky types, and you are spending a long time worrying about defining types and telling the compiler what you've already done, which already works.
Ahh, now I get it! 🙂 In that sense TS really might not fit that kind of architecture and style.
That would actually make a great article though - if you ever write it, I already have a title for you: “Why some senior engineers intentionally avoid TypeScript” 😄
Technically jsDoc is equal and interchangable of TS. This is proof my jsdoc-duck npm module, which is implementing a quite challenging Type, because that type is depend on user type of state. This module can used on js, js-jsDoc, TS codebase near same way. The only source is a single js/jsDoc file. Much better if not installed as npm package instead copy that single file.
So that why I think jsDoc = TS just do not need compile the code.
That looks really interesting, thanks for sharing 🙂 I’ll definitely take a closer look at your tool - always curious to see approaches around typing in JS.
I feel your cooling ambition towards those surveys. They got me excited and StackOverflow's yearly report felt like a holy testament of the truth. Maybe the State of ... team did a good job disclosing their own demographical and methodical issues and consequently we're seeing all of those surveys more critical, or it's just like you said the more experienced you get and see trends come and go, the less exciting it feels.
Surveys with free text options can catch ideas and feedback for standards committees and framework developers like why was Svelte/Astro/Bun/Deno/yarn trending and what could it mean for their priorities? One reason why npm and React are still there might be the adoption of features that made contenders popular. While TypeScript and missing type security in native JavaScript has been a thing in survey results for years, and JS gets new syntactical sugar features every year, but types are still missing. Meanwhile CSS has evolved a lot, :has parent selectors and container queries became possible and maybe even native masonry layout.
Exactly 🙂 I’ve lost count how many times I’ve read about the “death” of some technology in survey summaries - and then it keeps doing perfectly fine for years. PHP is a classic example 😄
I also agree about the value of open-text responses. They can surface real signals and ideas. Sometimes in funny ways too - I remember one State of JS edition where NestJS ranked at or near the top among backend frameworks even though it wasn’t on the predefined list. People kept writing it in the “other” field so often that it showed up strongly in the results 😄
So yes, those qualitative bits can be surprisingly insightful. They don’t make surveys definitive, but they do make them interesting to watch 🙂
Exactly - that’s a great example 🙂
And you’re absolutely right. Even in professionally designed, statistically controlled surveys there’s always a significant margin of error. Human perception, personal experience, recent events, and individual bias all influence answers more than we sometimes realize.
So if that margin exists in rigorous research, it’s naturally even bigger in open community surveys like ours, where participation is voluntary and driven by interest.
I took a look at the results, and you’re right — they’re very well presented. But how much confidence can we really place in surveys like this? Without a representative panel across user profiles, countries, and industries, some level of bias is inevitable. At best, they give us a direction, a trend.
As you pointed out, many senior developers won’t even bother responding. Those who do are often the ones already engaged enough to share their views — which can skew the picture if taken as the majority.
On a side note, JavaScript and I have a… distant relationship. On my latest project, PHP took the top spot with 97.5%, CSS followed with 1.3%, and JavaScript still managed to secure third place at 1.2% 😁
Exactly - the most we can realistically take from them is a sense of direction or trend 🙂
I wrote about it precisely because for many of us this feels obvious, but it’s not always obvious for beginners. A few years ago I was that person too, reading results a bit too literally 😄
And honestly, respect for that 1.3% CSS - these days people try to move even CSS into JS, so it’s holding strong there 😄
What I use to check from time to time is the Tech Radar published by ThoughtWorks. It is not based on surveys but in people that has investigated each technology. It can be a bit subjective but at least has a rationale behind.
It is not saying which technology is widely adopted but which you could adopt. For me is interesting to see the trends and investigate tools that can be useful.
But the problem remains the same, a company may want to adopt something but if no one has experience or knows it...
Not an easy topic!
Exactly, it’s a really hard topic 🙂
A team might be very experienced in a solid technology already. Switching stacks means training time, a learning curve, and sometimes resistance in the team. That’s a real cost.
So do you still push for the new and “better” option, or stick with what works?
It depends on the project, time-to-market pressure, and long-term plans. A “better” tech on paper isn’t always better for a given team at a given moment.
So yes - not an easy topic at all 🙂
Fully agree with this, at the end is a trade-off between different variables.
Totally 🙂 And whether a decision was “good” often only becomes clear with time - sometimes months, sometimes years later. That’s the tricky part with tech choices.
This is such a refreshing perspective, As a student I definitely went through that "Younger-Developer Phase" early on, where every new survey felt like a mandatory checklist of things I had to learn to stay relevant. The "wall of logos" in these surveys can be so overwhelming when you're just starting out. Great post!
Thanks a lot 🙂
And honestly, sometimes I don’t even feel like checking every new technology unless it genuinely interests me or reaches a certain level of adoption. Things change so fast that it’s hard to keep up with everything anyway.
Plus, we forget quickly - especially with frameworks. If you don’t use them in real projects, the knowledge fades just as fast as it came 😄
It makes a lot of sense to be picky about what you learn. The tech world moves so fast that trying to catch every single shiny new tool usually leads to burnout. Since knowledge fades quickly without practice, that's why I only check new technology if it is related to my interests and career goal 😅. Because there is always something new out there these days. Great read Sylwia :)
I treat surveys as both. There both interesting to my decision making as well as interesting to see why the surveys show the way it is.
Because of this, I had to make sure how the survey is conducted such as:
I think those are important to consider and also helpful to see more than one survey, so it would "balance" out.
Great post once again!
Thanks a lot 🙂
And yes - it’s definitely worth looking at them critically, especially the methodology. Let’s be honest, most of these are not scientific studies, just open surveys that anyone interested can fill in. If someone really wanted to (and tried hard enough), they could probably even submit more than once.
That doesn’t make them useless, but it does mean we should read them with a bit of healthy skepticism 🙂
I treat these surveys as an opportunity to check for what's new. It's a way to expand my horizons and try out new libraries/tools I discover are rising in popularity.
I believe in T-shaped development: focus on a couple of core competences and domains of expertise but also leave some time to branch off and try out new things. Surveys are a way for me to discover what new things exist out there and to assess whether my core competences are still in trend.
Also the graphics and data are pleasing to read through :)
That’s a great way to use them 🙂 Not as hype or a checklist, but as a way to spot trends and broaden your perspective.
And yes - fully agree, their visuals and data presentation are genuinely beautiful. They make exploring the results a pleasure 🙂
Interesting insights! Always good to see trends, but I think we should take these surveys with a pinch of salt—sample bias and self-selection can skew the results.
Exactly - that’s a perfect summary 🙂 Trends, yes; oracle, no 😄
“Glad we’re on the same page 😄 Trends can guide, but they’re definitely not an oracle!”
Some comments may only be visible to logged-in visitors. Sign in to view all comments.