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 f...
For further actions, you may consider blocking this person and/or reporting abuse
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!”
“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 🙂
The sampling bias is the biggest issue imo. Twitter-active devs and conference speakers are way overrepresented. Still useful as a rough signal for what's gaining traction though.
Exactly 🙂 And many 9–5 developers in large corporations don’t answer these surveys either - and that’s where stacks like Angular often dominate. So it’s only part of the picture.
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.
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 😄
I think surveys like State of JS are worth taking seriously but with context.
They are great for spotting broad trends, what tools are gaining or losing interest, and how developers feel about ecosystems year-over-year. Because they poll a large number of real practitioners, you can often validate whether something you’re hearing anecdotally is actually widespread.
At the same time, they’re not crystal balls. Results can be biased by who chooses to respond, regional differences, and hype cycles around frameworks or tools. I’d avoid treating them as definitive roadmaps for the next 5–10 years, but they’re very useful for short-term decision making (e.g., hiring priorities, learning focus, tooling choices).
Exactly - I treat them very similarly 🙂
They’re great to see what’s getting more popular and where it’s worth paying attention, especially when something grows year over year.
But I’d still be cautious even with short-term planning based purely on surveys. As I joked in the post, according to surveys Angular should have been dead a long time ago - and yet it’s doing just fine 😄
The survey is only as good as the people answering it. That is why I always try to get everyone I know to answer these surveys. With the State of surveys, you can see who is answering so you can asses based on that. You also get notable people to comment on it and discussion gets created that highlights shortcomings of the survey and discusses the trends.
For me, these surveys have primarily become a test of knowledge and point me to things that I miss in the daily grind (new standards, interesting frameworks, etc.). That is why I find them indispensable.
That’s a very fair point - they can be a nice reference point 🙂
I just don’t jump on every technology I see there anymore (unless it genuinely interests me), because I’ve seen too many things appear and disappear quickly. If something trends consistently for a few years, then it’s usually worth a more serious look 😄
I think it's a component of our ecosystem to see how every developer think about x technology, how the market will go, and give us some personal questions about what we need to learn, build or something else. I see more as a "human" and technical metric
Exactly - that’s a healthy way to look at it 🙂 Seeing them as a mix of human and technical signals makes a lot of sense.
This is such a grounding perspective. It’s easy to treat State of JS like a 'To-Do List' for our careers, but you’re right—it’s actually a Vibe Check.
The most important takeaway here is the 'Compass vs. GPS' analogy. A GPS tells you exactly where to turn (Usage), but a Compass just shows you where the wind is blowing (Satisfaction). If we only followed the GPS, we'd all be working in Svelte 5 by Tuesday, even though the job market is still 70% React and Angular.
I also love your point about the 'Laptop-Closed-at-5' crowd. There is a massive, silent majority of developers shipping critical infrastructure who don't care about the 'Meta-framework of the week.' They are the ones actually keeping the world running while the rest of us argue about signals vs. hooks.
I really love this comment 🙂 Especially the part about the “laptop-closed-at-5” crowd.
Even though I touched on it in the article, your wording made me realize how strong and interesting that group actually is. It’s a huge part of our industry that we rarely hear from.
I might genuinely write a piece about that - comments like yours are such a goldmine for ideas 😄
Spot on, Sylwia! I love the phrase 'the future of legacy is machine-generated and painfully well-indented.' It’s a great reminder that while AI makes code look clean, it doesn't necessarily make it right. Clean code is ultimately an act of empathy for the next person (or our future selves) who has to touch the file at 3 AM. If it’s readable and doesn't break everything else, we've done our job. Great read!
Yeah it probably reflects more what people WISH they could use, than what they HAVE to use (or what they actually ARE using) - I think you're right, and that you need to take it with a big grain of salt - it's not meaningless, but its "meaning" is probably something else than what we think it is ;-)
P.S. I never paid much attention to these surveys TBH ...
I like that “wish” framing a lot 😄 It actually fits surprisingly well.
And honestly, in the last few years on paid projects I only really got to choose the stack once. I remember the CTO wanted to go a bit wild with newer tech, and I was the one slowing things down and picking something older and more boring instead 😄 Sometimes boring is exactly what the project needs.
This is such a grounding perspective. It’s easy to treat State of JS like a 'To-Do List' for our careers, but you’re right—it’s actually a Vibe Check.
The most important takeaway here is the 'Compass vs. GPS' analogy. A GPS te..
I really like that “vibe check” framing 🙂 It captures the idea perfectly.
Surveys paint a fascinating picture of trends but can sometimes miss local realities and nuances. It's almost like a mood ring for the dev community! How do you balance trends with practical needs when choosing tools? 🤔
That’s a great question 🙂
Most of the time it really comes down to common sense: a solid, proven technology that your team knows and enjoys working with, and one you can realistically hire for. Trends are interesting, but delivery and maintainability usually matter more.
Great take. I was not aware of that survey site. Thanks for sharing 😉
Haha, another unexpected benefit of the post then - spreading the fame of the State of JS survey 😄 Glad it was useful!
Great take! Love the "compass, not GPS" framing—perfect way to think about surveys. Super insightful breakdown! 🚀
Thanks a lot! 💖
Surveys now = horoscopes for developers. Fun to read, instantly forgotten when I open my terminal and see the same old JavaScript errors staring back at me.
I absolutely love the horoscope comparison 😄
Great perspective! I think the biggest issue with developer surveys is selection bias — the people who take time to fill out State of JS are already a specific subset of developers (usually more experienced, English-speaking, Twitter/dev.to active).
In my experience building SaaS products with Go + React, I've noticed that the "boring" tech choices (the ones that never trend in surveys) are often the most productive. Surveys create FOMO around the newest framework, but real-world teams just need something stable that ships.
That said, I do find them useful as a conversation starter rather than a decision-making tool. They show sentiment, not necessarily adoption.