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.
I’ve got quite a lot of experience with non-IT enterprise, in Denmark, and almost nobody uses those fancy new technologies around here. Over the past few years everything has moved to typescript (typically with react, but some angular remains from older decisions), dotnet, Java, php or c++.
That’s basically it. The only job listing to even mention things like Rust in the region where I live in the past 5 years is Google, and they list it as “nice to have” on a recurrent phd position for c++ development.
Python is obviously a thing, but not so much for software development, but typically requires you to be a statistician first and then maybe capable of writing a little Python second.
So there is probably a bit of a disconnect between what is hip and what puts food on the table for a lot of us.
You’re probably on to a lot of it too. I recently got back into development, returning from a stint in management, project management and enterprise architecture and I’ve grown quite fond of typescript and the node environment.
It’s obviously a place where you can cause a lot of harm if you brute-force-program 100% or the time all of the time, but it’s also a place where you can create some great business value faster than I’ve ever experienced elsewhere. I mean, I can do things faster in Python but only until whatever I’m doing outgrows what I’m capable of keeping in my head.
That being said. Looking at the previous 20 years of getting to running office365 in your browser, sort of explains why people have been working so hard to come up with newer and smarter things, doesn’t it?
For the vast majority of us, however, the boring old languages are likely going to be around long after we retire, and as such, the “popularity” measures in these articles is probably not something to pay too much attention to.
While non-IT enterprise is a big job marked, I guess the HN crowd leans towards the startup scene. There are plenty of python/django and ruby on rails and node companies in copenhagen :-)
Oh this is very true. There are actually a few django and Ruby on Rails jobs open in my area (region midt) on a fairly regular basis. There are a lot of node jobs as well as most things have moved to have some sort of TypeScript front end.
I’m not sure those really count as “new and hipster”, however, I mean the person I was replying to was lamenting “react” being old. ;)
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.
Next.js, SvelteKit and so on are backend frameworks for sure, giving you an http server, routing, authentication, data loading. It’s just a slightly different toolkit than you’d get from traditional frameworks (an ORM, job scheduling, etc). Express indeed hardly qualifies.
As a long-time frontend developer, I find Angular pretty bad, but I understand it feels fine if you come from .NET/Java or another “enterprise-y” environment.
Initially I also had the impression that Next.JS/Remix/SvelteKit shouldn't be considered as backend frameworks but, after using it for a little while, noticed that it, indeed, replaces the use of something else even if you just want to create API routes.
Overall, I find the experience similar to something like Ruby-on-Rails/Django, which I usually also consider as "backend frameworks".
For me, these new frameworks are one of the reasons that, for me, React has never been better.
It's always driven by hype, or maybe groupthink. Every year I feel bad for the Ember contributors when this thing comes out cuz the respondents boldly claim Ember's bad while also admitting they've never used it and have no interest trying it. The clear mark of a popularity contest.
I think it makes most sense to look at the "I've used it, wouldn't use it again" rather than "I haven't used it, not interested in using it". Those breakdowns are quite revealing in fact for both React and Vue.
They provide a 2d grid for positive/negative sentiment crossed with have/not used. So there's a quadrant of negative sentiment + have not used that Ember dominates the corner of! It's a weird set of beliefs to hold - hating an unknown - and even weirder to care enough to fill out that part of the survey.
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.
I went from building dummy projects in vue2 to production ready apps in react(next actually) because of the giant community it has, in particular in the web3 world. Boring or not, if it has better support/resources it's a logical better choice
Agreed. Recently started a new project with react and it's awesome. Especially in combination with tailwindcss and vite. Very little code. Fast to production.
All the popular react libraries feel very mature, have zero vulnerabilities (at least according to npm) and are easily integrated.
Hey guys, undergraduate here. After reading this thread, I doubt myself about my current studying. I'm a CS student. Normally, I'd be graduated and will be on my way into IT industry as an intern right now. But a lot of things happened in my country, Myanmar. I'm now self studying various things like react, django. My question is am I doing right thing learning those shiney tech, or which ones am I supposed to be doing for? What skills would you expect from people like me? Graduating will not be happening so soon with the country's situation right now. Originally, I'm thinking to post on ask hn but anyway.
Django and react are not what I would call "shiny tech" these days. React is a mature and widely used technology now. You are investing in learning solid technologies there.
Once you have a solid grounding in React, I would highly recommend picking up some TypeScript and node.js. Those three go together a lot, at least where I live (Netherlands). If you know all three, there are tons of opportunities for both permanent and freelance positions.
Thanks, that helps a lot. After spending some time on hn, I find most people here hate react and spa. And I thought I got manipulated by online blogs or so. I'm planning to do as you said.
Thanks again.
> This year it feels the most like it’s driven by hype (and marketing, hi Vercel!)
A few developer YouTubers I used to enjoy watching have all jumped on board this train and are now only making videos about products built by companies that are paying them.
And they're looking at closing the bubble up more cross-referencing specifically survey takers' closed-source Twitter and GitHub accounts, leaving out the privacy-conscience and open-source fundamentalists that don't use these platforms but have a worthwhile opinion that should be represented and heard.
I could rant for a while, but a few things off the top of my head: over-architected, overly complex, sometimes bad tooling (karma, protractor), tons of old issues (though they’ve been working to clean this up lately), big time inner platform effect (the templating feels like a language to itself), slow compilation, RxJS is generally overkill, Reactive forms is untyped(!) and clunky, and the “included batteries” are sometimes later removed leaving you to figure it out yourself, such as with protractor and eslint. If I’m just gonna figure it out, why not use React anyway and get a much simpler framework?
That said, for a team or teams with lots of apps where a consistent structure provides real benefits in getting up to speed, I can appreciate that some of angular’s enforced structure could be helpful.
Angular is simpler for me than React. I don truly understand the hate. I can built applications fasters in angular than React. I still use React sometimes, but I always go back to Angular.
> […] Astro are not "back end frameworks" unless you define tech by what marketing copy people have written
I can’t speak to SvelteKit, but I don’t think Astro even markets itself as such. Last I checked it doesn’t even support SSR (though it appears to be in development).
"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.
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...
Server-side JS is an exceedingly useful tool for certain use cases. Specifically, sharing server and client logic. I know everyone here likes to hate on JS frameworks, but the productivity of being able to build one thing in one language instead of the same thing twice in two languages is hard to overstate.
Sure, that has some trade offs like page bloat. But almost all of the JS framework universe is focused now on reducing or eliminating those trade offs: partial hydration, build time code elimination, server components, etc. There’s still a long way to go before the DX and UX reach parity, but it’s inevitable, and closer than one might think (see Qwik[1]).
There's no reason to use two languages. All the major server-side frameworks still exist and many have been upgraded with the modern component style templating for the frontend too.
Nothing is new with JS frameworks. Hydration and fancy "resumable" state has been done over a decade ago with serialized viewstate and AJAX controls. The JS world is just discovering how powerful server-side stuff can be after all this time.
I don't know, maybe I'm dumber than I think I am, but I've been building software for 10+ years with a lot of different tools in a lot of different environments and I really like Node. Like with all tools, it depends on the use case and the players, but I've used it with great success for BE web services (yes, at scale), CLI tools, and automation. Some of the worst and some of the best code I've ever read has been JS. It requires discipline, but that doesn't make it inherently bad.
I think it was a brilliant idea. I don't know any ecosystem where I can be as productive as with Node.js+Typescript+React. Having everything typed from frontend to backend, even the email templates (tsx + ReactDOMServer) makes refactoring a breeze and work across the entire project.
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
I've found him to be very level-headed in his approach.
I don't blame the language for what the community does though. I mean, I've suffered through VBScript. I know how bad a utility/glue language can really be. Netscape did have it running on the server way back in the 90s too. Should we create services with it? I dunno. For some things, I really don't care. Should we be tossing it CPU intensive, multiple db query traffic? No. No it doesn't do well at all in those scenarios. I've done enough PHP (really bad PHP) to realize that any time we lower the bar of entry, we're going to get a lot of folks with no programming background. That's actually pretty cool! What's not cool is getting folks who have no background, and refuse to listen to anyone who does.
Those days are still here, and now getting better. All these server-side frameworks have figured out their own component-based UI frontends. Now you can get all the same design advantages without the JS overhead and nonsense.
Nope, my first sentence, pack the JavaScript stuff on the scripts lib and let Java/.NET build take care of the rest, as it belongs on a proper full stack SSR framework.
As a person new to web development, I feel the same as what you have described. Since I'm not that long in I.T. I would ask... What could we learn from the past?
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.
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.
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.
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.
From here, your problem sounds like a broken code review process or missing/unclear style guides in teams/company.
> 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.
In my experience, it purely depends on how you regulate the code internally. You can always find developers using something shiny every week when you already solved the problem the shiny thing solves like 100 times in your codebase. I had the same problem with some random integration of Blazor recently in a .NET codebase. Some had the same problem (apparently, I came later) integrating Primefaces to a JSF codebase.
It may be amazing tech, but do you really need it if you can KISS without it?
I believe React is inherently terrible, rather than your reason. I think all libraries that try to abstract an underlying technology into something that it is not, and then also have to provide escape clauses for the abstraction because the user actually has to know how the underlying stuff works, are inherently broken. I also think state-based reactivity is a terrible way to reason about things because sometimes you don't want a certain part of the state to participate in the reactivity, and then at another time you do, so you have to add another state variable to say when it is OK for the other state variable to start participating in the state. It just isn't a good way to create algorithms.
The whole idea of React performing a bunch of tasks in the background and updating everything when it feels like is just all a bunch of silly magic. In fact, my state of JavaScript 2021 would be pretty damning, but because of the libraries used instead of JavaScript (like React and TypeScript), not because of JavaScript.
React presents a simple view of the world, but in doing so, you now have no idea what is actually happening, and you need to know that. This isn't like an array in JavaScript that is abstraction of an array in c that needs memory allocated and new arrays created and so on. You don't need to know how that works other than that the JavaScript version is a bit slower and you accept that. You need to know how all of the stuff React hides actually works to create your program.
In terms of hooks, there are so many "rules". Instead of seeing an API, the API is moved into the documentation and not visible in the code until run-time when you get one of the many errors like not adding a dependency to a hook, using a hook outside of some specific area, etc, etc. It isn't JavaScript at all, so you no longer have the tools of the language to freely use to make your life easier.
I really disagree with this, plus I have to say, it doesn't sound like you are offering an alternative.
1. Escape hatches are good. Designing an API is hard, and supporting every use case within that API is harder. Providing a way to make sure you don't get backed into a corner means you can continue building things.
2. State updates -> View updates seems perfectly reasonable to me. I don't think I've ever wanted a view to use a stale piece of state in one section and an up-to-date piece of state in another.
3. Reconciliation is just React's way of saying "we are trying to make things fast." I generally don't have to worry about how this happens while I'm building things: I can just build things. A library that let's me focus on business logic rather than boilerplate or implementation details is one that I want to continue using.
4. "Thinking in React" I put into two buckets: The first is easier to grasp, in how to reason about state (propagating down in one direction) and how to keep things in "React" land (don't manipulate the DOM directly, React won't "know" about it). The 2nd is in the API, and I'll admit does take some time to get used to. Lifecycle methods I think can be learned faster, but knowing the lifecycles around hooks also can be learned, of course. Plus, the abstraction and co-location benefits of hooks outweigh the learning curve IMO.
5. The [rules of hooks][1] that React provides is just two items, hardly overwhelming. The actual API of hooks (e.g. the need for a dependency array, return function from useEffect to cleanup on unmount, etc.) is larger and takes longer to fully grasp, but being able to have a linter catch a large chunk of these is a good thing in my book. Plus, no library is without its footguns. In the jQuery days there were plenty of times I'd forget to remove a listener, create race conditions in ajax stuff, etc. Learning a library's API is just that, its API. You are writing in Javascript, but of course no one is saying "the idea of dependency arrays is 'Javascript,'" although that concept definitely appears in other computer science / programming fields.
> A library that let's me focus on business logic rather than boilerplate or implementation details is one that I want to continue using.
React is the exact opposite of that. Endless boilerplate, abstractions and unwritten rules. As the reality of large projects sets in, they look nothing like the starter examples.
I really enjoy the Lit model. It’s quite a bit faster than React, it is a tiny bit of syntactic sugar on top of browser APIs. It’s powering Photoshop (https://web.dev/ps-on-the-web/) and a future release of YouTube I believe.
Lit is just react with web components. It uses all the same magic, and a whole bunch of documentation is needed (is this state reflective, reactive, blah blah). It does the same "let me figure out updates in the background and you don't worry about it" as React, just without a virtual DOM.
>it doesn't sound like you are offering an alternative.
Actually, I create a library github.com/thebinarysearchtree/artwork which I use but haven't documented for public use. You can probably see some earlier versions of actual components in the history with the initial commit. I think I created a login component or something. The essential concept behind it is that html is no longer necessary in a component world, where everything is broken down into little pieces and spread out inbetween loops and so on. Removing html and having access to the live dom elements, and using modern JavaScript and dom API features is now a better alternative than all of these ridiculous libraries that are just variations of React or Vue or insane with their own compilers and virtual doms and god knows what else.
>State updates -> View updates
state updates -> query updates
state updates -> url / history updates
>A library that let's me focus on business logic rather than boilerplate or implementation details is one that I want to continue using.
From my experience, these implementation details are important. The library I use is less code than React and shows the implementation details so you know what is happening.
>The [rules of hooks][1] that React provides is just two items
That definitely isn't correct. It is missing the warnings about dependencies, where async methods can run, and a lot more. There is a list of eslint warnings somewhere. There are a lot of rules of React and hooks and the different types of hooks and they are all in the documentation and not visible in the code. The order of your setState calls is important, you can't use async in certain places, the state has to be assumed to be stale unless you do setState(a => a + 1) etc. It is quite frankly ridiculous. There is so much happening that is all hidden in magic.
Bluntly, I think it is all complete garbage that is more complex than it should be and there are now so many people writing incompatible React instead of standard JavaScript that works for everybody. I just find it hard to believe that there is anybody who has written a large project in React and has come away with any conclusion other than that React is complete and utter garbage. It is a failure and it will not stand the test of time. The only people who could think otherwise: have some kind of cocoon set up by a large tech company and they basically just write demo code all day, or they haven't worked with React long enough.
My library, which I have used to rewrite a large application with, is less code, faster, and easier to understand. I proved that React is complete garbage to myself by doing that.
You could say this of absolutely anything. Let's use assembler then so we know what we're doing. Oh no, wait, let's write the 0s and the 1s ourselves so we understand what the processor is doing. Even better, let's just put some voltage on some transistors so we understand the flow of the electricity.
At some point you need to accept the underlying stuff just works and build on top of existing layers. That's what DHH calls "conceptual compression" I think, and that's also how science works. Building everything from scratch so that you understand it doesn't work, specially in a business context and usually ends up in worse home-made frameworks.
React's blessing and curse is that it is so (relatively) simple. It holds only one opinion, that UI should be a pure function of input/state. It leaves everything else up to "you", which is where the problem sets in.
I don't think I'll be looking to work in a react codebase in the future again. I don't know what was wrong with class based components, especially the lifecycle methods, they were so easy to understand/read. But almost every react codebase is now a combination of classes/hooks or 100% hooks which imo is so messy/unreadable...
When I will be looking for a job change I'll definitively look for angular only jobs (or even better, backend only)
> I'm not sure if this effects other frontend frameworks as much
Depends. Angular is the same old solid brick you can toss towards your enemies since 2017 or so. Vue has had at least one major breaking release, but there's a migration path, so it's not impossible to transition(although I know of one instance where the team opted for not doing that because of uncertain estimates).
But none of them have this goldfish-memory-like attraction to the new and shiny.
Bad developers will write bad code no matter the pattern - styled components has never been a source of issues for us. Why would we move to a new “trend”? I think this is unique to the JS ecosystem.
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
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.
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).
The difference compared to "Java inheritance hell" is that refactoring in Java takes minutes and is safe, going back as far as they have releases for. Good luck doing that on an old node project with any library frankly.
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?
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.
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).
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.
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.
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)
I remember having trouble with this recently. No specific examples to cite because I gave up and nuked the project, but support for ESM is experimental in Jest. I literally just couldn't get it to work with ES6. I remember thinking I would have to compile to CJS so jest would work.
My experience has been that basically every time you need to change your Babel/typescript/webpack configuration you have to do it a second time, with a different set of quirks and constraints, for Jest. It's not a blocker but it's a persistent pain
I've been doing some benchmarks recently and actually it is not that fast, compared to Jest. It seems to have solved the Jest unforgivable memory leaks, but overall has much greater memory consumption.
That is due to ESM. You aren't testing the same thing in your jest and vitest test. Enable experimental support for esm in jest, change your test suite template, and run it.
I'm sure that causes the bottleneck for vitest but it's a necessary evil as ecosystem moves toward ES module and no global context across tests.
You can also speed up vitest by changing config to make it behave similar to jest, I think.
The benchmark covers several different scenarios, and memory and time efficiency leans more towards Jest (which is already pretty bad as it is), so I don't think it is fair to declare "A blazing fast". The project looks promising (appreciate ESM and TS support), don't get me wrong, but speed is not its strength.
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.
Do you have any data to back this up at all? My experience is opposite, many backend jobs have been replaced by different BaaS', while most of the programming is done on the frontend. If you hire a younger developer half your rate, you get what you pay for. Complicated frontend projects needs good seniors, and they get paid their fair share.
IME demand for experienced and talented frontend seniors have never been higher, as frontend continues to expand in complexity, and more logic is handled on the frontend-stack (routing, API-routes with eg. Nextjs, SSG/SSR and so on.
> Complicated frontend projects needs good seniors, and they get paid their fair share.
My experience has largely been the same. I would say the biggest mistake some companies make is thinking that the frontend will be "trivial" and hire a bunch of cheap and inexperienced devs.
On the one hand yes, if your bar for the UI is just making it look like the mockups then go right ahead and hire the cheap inexperienced folks. But without proper oversight and experienced developers there, the app almost always devolves into a nighmare.
All of the frontend stuff I've been involved with (mostly as a backend developer) has long been retired. There's not a single thing I can point at that lived for more than 2-3 years before getting shelved or replaced.
The stuff you mention I would classify as shiny new stuff. Easy to hire for now and in fact I know a few guys looking to hire exactly that kind of skills. It's going to be different in a few years because by then it will be unfashionably old stuff.
Angular, backbone, jquery were the fashionable stuff ten years go. Who even uses backbone at this point? Their last release was 3 years ago. That's the kind of now unfashionable thing that has probably been largely replaced or shelved by now. They had a pretty big community of users back in the day. Interesting data point if you are looking for one to figure out what happened to all those projects. There are still about 620K downloads per week so there clearly are some projects still pulling that in. But apparently they've not needed a new version since February 2019, which was when the last release was tagged. Good luck if you are hiring for such projects.
I don't think it's so much about fashion/trends as it is about ever increasing user expectations, and frankly JS/HTML/Web is the best of the worst solutions. It's not ideal but its the fastest and most accessible.
Everything started going to shit in front-end after the iPhone was released. You had the emergence of web apps, web as a platform, pervasive social media, so many horrible things....
> Complicated frontend projects needs good seniors, and they get paid their fair share.
Yes, but "needs" is different from "gets". I'm sure there are many places that hire experienced frontend developers, but the rule is that it's more a market of lemons than developers in general, so people jump out with time.
This hasn't been my experience at all. People are building increasingly complicated apps like Figma in the browser and are happy to hire senior developers and pay them well. If anything I see the number of back end roles diminishing as people increasingly delegate that stuff to various cloud services.
Figma has been great new thing that simply did not exist ten year ago. I know a co-founder of a competitor to Figma called fluid UI. That was working on that around that time. Shiny new stuff in other words.
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".
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?)
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.
> 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.
At least for me it was never a decision once I found TS, TS always got chosen. My spicy opinion in the JS space is that Typescript is better in every single way over Javascript, it is a superior language. Typescript IMO should be merged into Javascript, how anyone develops with just JS anymore (especially larger projects) baffles me.
I think we need something quite a bit more radical than Typescript.
We have "use strict" and I think we need to add "use types" too.
In that mode, we need to disallow the more dynamic parts of JS. They add TONS of typing headaches resulting in poorly-typed projects and they hurt performance too.
This could allow for a much more simple type system and allow a path forward where things like type coercion aren't a thing.
Ignoring virtual dom, the number one thing that kept me in react was normalized event handling across every conceivable type of browser that the web could throw at you. Is that no longer a thing in 2021 or do all libraries handle it?
This is one of many things that were true when React was first created and is now no longer needed. I feel like half of React’s codebase is just reimplementing features that are now browser native.
It seems like they have painted themselves into a weird spot by drifting so far from web standards because the path back doesn’t seem that obvious from the outside at least.
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.
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.
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.
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?
Unpopular opinion here: the more I use Vue, the more I realize that it started off doing things differently because it thought it was smarter than more established frameworks. Over time, you're seeing it copy a lot ideas from other systems because they're actually hard earned lessons. Vue is the manifestation of the frontend hype cycle. There's no reason to use it over something like React which is much better supported
Agree, used it for about half a year at a previous job. It tries to copy everything from everywhere and creates too many ways to do the same thing. The ecosystem is a lot smaller and many times I ended up on issue comments or readmes in chinese, which din't make it any easier. Also I got pretty pissed off with the 2 -> 3 transition, not as easy as they claim on big projects with real business pressure like to stop development for weeks during migration. Also Next.js is incredibly better (and better managed) than Nuxt. I'm never using it again.
Most likely due to vue 2 to 3 transition. Vue 3 introduced many improvements and breaking changes. This also made many libraries lose compatibility with Vue 3. Not a good thing.
While vue 3 was soft launched a year ago. The transition is still happening. With Vue 3 becoming default last week(feb 7). And major vue frameworks (vuetify and nuxt) just still working to support vue 3.
I expect satisfaction to increase next year, when ecosystem catches up. And dissatisfied folks switch to other options.
One thing to note is v2.7 is still shrouded darkness. Now, that major vue 3 work is done, Clarity and good support on v2.7 will also improve satisfaction.
Vue 3 is Vues "Python 3" moment, give it a couple of years and it will be mostly forgotten.
Just as Python changed its string type to Unicode breaking compatibility, Vue changed the reactivity system. The other changes in Vue3 wouldn't fundamentally break compatibility on their own but made sense to fold into a big overhaul, just as Python did with various other changes in v3.
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.
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.
You can respect that developers you respect are humans who make mistakes and misunderstand things. As you've done, you've made an inaccurate claim and learned from it. Hopefully you still respect yourself.
Also (and I'm not familiar with Vue to know if this is the case), the state of software is such that you can make a claim and have it invalidated a few days later after an update comes out.
> You can respect that developers you respect are humans who make mistakes and misunderstand things
No I can't.
Seriously, it was a joke, he's my best friend, but I guess I misunderstood his claim or he misunderstood render props!
From what I can see reviewing Vue's 2.x docs, they seem to have had this "slots" idea for a while. I get a little bit ill from looking at that syntax though so I think I'll refrain from arguing about the library again!
I understand all this traction with Composition API, and don't liked it at all first time.
Whenever I need to go and fix some bugs in old Vue 2 app without CompositionAPI and setup syntax - I feel very bad. Guess that Vue team a bit failed to properly describe why to use composition api, but now I think that it seems to be useful a lot
I still don’t understand what’s so interesting about it… why you wouldn’t just write js that you already know? Instead choosing to use strings to code… ugh
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?
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.
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.
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.
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.
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.
We use angular and are ok with it. There are tons of pros & cons for and against using angular. The biggest pro it being a very nice fully typesafe template engine.
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.
>"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.
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.
I am not in the niche. I do all kind of development with multiple languages and tools. But I am trying to choose tools that work for me, not the other way around. For Windows desktop Delphi is unmatched in my opinion.
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
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/
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.
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.
Oh cool, that's very clever! Probably a little too clever for me, though :P I think the code is misleading, and you can't handle classes with hyphens in it (and if you do, that's even more misleading!). But it's a neat application of proxies!
For folks wondering, here's how it would work:
const htmlClasses = new Proxy({}, {
get: (target, prop, receiver) => document.querySelector('.' + prop)
});
// Get element with class pagetop
htmlClasses.pagetop;
const htmlNodes = new Proxy({}, {
get: (target, prop, receiver) => document.querySelectorAll(prop)
});
// Get all h3s
htmlNodes.h3;
Yes you can definitely argue that it is misleading, but given the alternative I was faced with (React) whose entire world is misleading and unknown, I decided I liked this option better. I write less code, I understand my code more, and it is native hand-written performance. You can also argue that these are all features of JavaScript, and so if you think that is misleading, getters are also misleading because the getter could be doing all kinds of things even though it looks like a standard property access. So it has to be put into perspective with Vue/React/etc, where your code doesn't even correspond to anything and the React engine underneath recreates the dom, diffs it, updates when it wants, etc, and the setState stuff relies on declaration order and all kinds of ridiculous garbage.
Anyway, I just think it is cool kind of for the same reason it is misleading :)
You can do a loop like:
for (let i = 0; i < 100; i++) {
const { cool } = divs;
cool.innerText = new Date();
document.body.append(cool);
}
and cool is actually a new div each time, even though you would think it was the same cool from divs (divs.cool). It also caches the div, so it is faster than even if you wrote the manual version with createElement.
I could get rid of it, because my other approach to element creation would is:
const cool = div({ className: 'cool' });
which isn't too bad, but when I have a lot of divs, it is just nicer to do:
> 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
They don't at all, at least in my implementation. I read that they affected performance greatly, but all of my real world and bench mark testing says they don't at all, and in fact allow me to cache partially created elements to improve performance.
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.
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.
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.
>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?
Should have specified that more, sorry for that. Webpack, for better or worse, has most of the current dev mindshare and tons of plugins, stackoverflow questions & random blog posts. If you need some integration for <fancy thing>, your chance of finding something working for webpack is far higher.
You can build/support everything with gulp just fine if you don't want to use webpack, the question is: Why exactly would you specifically choose gulp and not, for example, esbuild?
Webpack and friends do a lot of what people used to do with Gulp, I guess. I still use Gulp as a task runner to kick off my various dev servers (including webpack).
I wrote my own build tool many years ago and rarely extend it with new build tasks. The core tool hasn’t changed much in the 5+ years I have been using it, so why bother with something like gulp?
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.
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.
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.
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.
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>
Handlebars extends on Mustache which considers itself "logic-less" templating language. I think `{{#if (and foo bar)` goes against that principle, so introducing ie `shouldShowX` property on component which then depends on foo && bar and just using `{{#if shouldShowX` really helps.
I do understand that reasoning, but that comes back to my annoyance with having to deal with a million files to do anything simple. I then need to create a backing controller if it wasn't there before, and if it is there, I need to add on an extra computed on top of the mess of other computeds already present. Why so complicated? JSX and Vue's flavor of templating is infinitely better, since it's basically just regular javascript in the template.
I've read your comments and it looks like a mess of a codebase, more than a "framework mess". It seems like a bad experience and I would not want to deal with deep inheritance and over-reliance on old/deprecated functionality (computed properties), so... hug.
Controllers are not required for anything except query params mapping.
It's perfectly fine, and I think very common, to load data in components. A rule of thumb is to load in the route only the minimum amount of data for your layout to work.
As for the million of files ... React co-locates template and logic code while ember-cli generates a js/ts file, a hbs file and a test file. It's either 2 to 3 (if you count a test file for the React component) or 1 to 2 (discard test files).
Finding the sweetspot between large components and multiple components is not easy.
For example, it was considered a best practice to apply the presentation-container pattern in React, which means 2 components.
I'm not going to say anything about your claim that JSX is regular javascript in the template.
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.
As someone else said, Ember was never that popular, and the community doesn't really strive to be popular. This is, however, a dilemma, because you need some popularity for your framework to have people interested in working on it.
Ember was cool initially because, if you knew Rails, then you could get what Ember was about even if it was confusing at times.
There were some choices made early on that even the Ember core team implicitly admits weren't so good, and they spent a lot of time moving away from those choices. As time went on, more developers became interested in other libraries like React because it's simpler and obscures much less of what it's doing under the hood. Ember decided to sit on the sidelines and take the time to figure out what to do next. This was both a good and a bad thing for Ember in the long run.
The long road to "modern" Ember got us the Glimmer component system, which is much nicer than the classic reactivity system, and it also gave us an improved templating system to classic Handlebars. Usability in the space of the runtime code was much improved, but this seemed to be at the cost of the build step being up to snuff with every other emerging JavaScript toolchain. Broccoli does some interesting things, but literally no one outside of Ember uses it because not only is it poorly documented but it's inferior to Webpack in a lot of ways. If an add-on that integrates Ember builds with Webpack wasn't made, Ember would be totally dead by now. Because Broccoli is niche and kind of hard to understand, even the developers who managed to figure out how to create add-ons for Ember didn't seem to understand the potential performance penalties of making a library into an Ember add-on as opposed to finding some other way to include code. Somehow a lot of Ember apps become really slow to build in Ember CLI, and that's partly because so many apps import a bunch of Ember-specific add-ons that are all doing something with the Broccoli tree.
Now there's Embroider, but we've been hearing about Embroider forever now, and it's neither reached v1.0 or the compatibility level it's advertised (in my experience). Not only is it too little way too late but it's still too complicated a way to simply bundle and share code between Ember projects. Trying to be compatible with Broccoli was a complete mistake and it should have been an opportunity to completely leave behind the cruft of v1 add-ons.
There's also some failed promises along the way. This thing called "module unification" which was going to greatly change but also improve the directory structure of Ember apps was sold as being something to look forward to in "Ember Octane", only to be dropped long into the process because for some reason it became infeasible. What does that tell you about Ember when the developers of Ember can't even change their own directory structure? Eventually they introduced template co-location, which was a good enough improvement over having a separate directory for templates, but that's another example of too-little-too-late. How is anyone supposed to be excited for template co-location when we were promised something better and every other framework is already more flexible to start with?
No matter how hard it tries, Ember is stuck in the past. Everyone has seen better at this point.
Yes, you can build ambitious web applications with Ember, but at least in other frameworks you can more easily figure out how to do something without getting stuck somewhere deep in the endless stack of framework code and being baffled. Yeah, Ember Data will "just work" for you until you want to do something like also fetch nested resources (example: /users/123/posts/456), which I'm pretty sure is still hard to do without some workarounds. Yes, the router is pretty great until you realize you need a wildcard segment in your URL.
But why would you do that when you could have used that time to just write your own solutions or swap out different libraries if you were using most other frameworks?
In Ember, you hardly get that choice because you have to use Ember CLI, you have to use Broccoli, you have to use the Ember router, you have to use the Ember/Glimmer reactivity model, and so on, and so on. With Ember, you're either all in or you're all out, more or less. Yes, technically you can write your way out of these things, but like I said, at that point you might as well just write your own framework using any number of other tools out there.
All in all, Ember isn't bad. It's just another tool like anything else. I've worked with it on apps with millions of users worldwide. There are still things I like about it. That said, I don't find it surprising that Ember is declining in relevance. With React and Svelte on two ends of the frontend continuum and Vue somewhere in the middle, there just isn't a big demand for what Ember provides. In order to do that, it would need to accept that it's lost and do things to entice new users, which would mean completely abandoning
- Agree with Ember Data and nested resources, that's still needlessly complicated. Same with lack of wildcard in the router/URL.
There are still things Ember needs to fix, for example removing controllers and improve Ember Data. But overall I think there is a good future ahead for Ember.
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.
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?)
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.
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.
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.
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.
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.
> 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.
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.
> 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".
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.
Deno missed the library list (it includes an extensive standard library) and I'm glad to see it in included in the runtimes and mention of new things. I just finished moving an app from Nodejs+npm to it and am finding work is quite a bit easier. Initially I'd thought it was completely missing.
Yooo lets go Svelte! I really love using it and I’m glad other people are discovering it. I’m even releasing my own SaaS boilerplate made around SvelteKit: https://sveltesaas.com
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".
> 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.
"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."
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.
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.
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.
I think with React the core functionality / idea is much more simple than you'd imagine. The complexity evolves out of the add-ons and library situation, some do simplify the situation though, I find Next.js React apps incredibly powerful and easy to build on top of.
If career ambitions aren't a factor, I'd definitely second Svelte. I used to do frontend dev and switched into a more backend role, but every time I do a hobby project with frontend work, I always pick Svelte. I briefly peek into the others, but Svelte is the simplest by far.
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.