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 (68)
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 😄
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 :)
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!”
“Compass, not GPS” is exactly right. These surveys capture curiosity and sentiment, not hiring reality or long-lived systems. I’ve found the real signal is in movement over time, not who tops the chart in a single year. Great reminder to read trends calmly, not chase them.
Glad that resonated 🙂 And I fully agree — the movement over time is where the real signal is. One-year winners can change quickly, but trends across several years tell a much more reliable story. Calm reading beats trend-chasing every time 🙂
For me, surveys are just a general, bird's-eye view of the software engineering market, that's it. They give you a general sense of direction, but they've never provided real, actionable value.
We should always take them with a grain of salt, not because they're false. They're usually accurate within their own dataset. But that doesn't mean they're universally true in every context, region, company size or career stage.
"Think of it as a compass, not a GPS."
I like your analogy but I wouldn't even go as far as calling it a compass.
I'd say it's more like Google maps fully zoomed out.
I really like that “Google Maps fully zoomed out” analogy 😄 Someone in the comments even compared surveys to horoscopes for developers.
And yes - you’re absolutely right. I kind of wish I’d had that perspective at the beginning of my career. Not just me, actually - my whole local dev circle used to be super excited about these surveys and we treated them almost like gospel 😄
Spot on regarding the respondent profiles. There's a huge " survivorship bias " here : we only survey those passionate enough to fill out a 20-minute questionnaire. This inevitably skews the perception of what's " standard " in the industry. Thanks for reminding us that not following every trend doesn't mean you're falling behind.
Exactly 😄
I can totally imagine an average developer opening that survey, reading a few questions, thinking “what are they even talking about?” and closing it halfway through 😄 That alone already filters who ends up in the results.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.