State of JavaScript 2021
2021.stateofjs.com
2021.stateofjs.com
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.
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.
e.g. Angular is a framework that a company invests in long-term, 5-10 year periods.
Only Vite has great satisfaction (98%) and decent usage (30%).
All the popular react libraries feel very mature, have zero vulnerabilities (at least according to npm) and are easily integrated.
It was a blast!
0. https://dev.to/sachagreif/disclosing-a-state-of-javascriptst...
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.
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.
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.
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.
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. ;)
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).
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.
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.
Even still, THIS is the state of the JavaScript. None of that has to do with the language.
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.
Guess what is my approach when having side gigs.
Webpack?
There are plenty of reasons why you may want a standalone JS interpreter.
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]).
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.
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.
That’s the fate of any tool that becomes popular enough.
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.
We've yet to see how it will fate in 3-5 years.
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.
> 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 am only half joking when I say that most developers would say yes due to Resume Driven Development
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.
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.
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.
Take a look at real code here https://lit.dev/tutorial/ and component conceptual model here https://lit.dev/docs/components/overview/
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.
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.
http://mikehadlow.blogspot.com/2014/12/the-lava-layer-anti-p...
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.
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)
Because if you dare question if TailwindCSS might not be a good idea, you'll be shouted down by an angry mob?
What are you basing this theory on, and what do you think people are moving to? In my experience it's still the go-to industry standard.
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.
Help me understand what you meant by this?
https://github.com/facebook/jest/pull/11529#issuecomment-102...
I'm curious - what do you mean by this? Been using Jest in multiple codebases with typescript and ES Modules and never ran into an issue.
edit: just found this, which seems to confirm my anecdotal xp of esm in jest being weird https://github.com/facebook/jest/pull/11529#issuecomment-102...
https://github.com/grissius/jest-is-a-rude-needy-clown-and-e...
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.
Those salary demographics makes me doubt the entire data set. Over 40% of respondents make less than $50k
[0] https://2021.stateofjs.com/en-US/demographics/#yearly_salary
Edit: Only 14% of respondents are in the US, which probably explains the above.
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.
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.
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.
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....
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.
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.
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.
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.
https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c321...
I hope it gets adoption, I would like to work with it. I like React as well and use it but Svelte straight forward in so many situations that I just enden coding instead of thinking about X different ways to solve a problem and that is where I see similarities with Go.
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.
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.
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?
Vue has slots which is similar to render props.
Also, I still don't respect vue. Look at this abomination
<MyComponent v-slot="{ text, count }">
{{ text }} {{ count }}
</MyComponent>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.
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!
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
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.
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.
Imo the best use case for Vue is as a jQuery no build replacement. Preact is also another good option for this.
1. stay with Typescript
2. embrace vite, pnpm
3. keep using eslint and prettier
4. svelte is below React but *above* vue now! what a momentum.
PS - No testing framework in your list. Any reason?
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.
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.
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.
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.
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.
If you look at Windows platform there's Win32, WFP, UWP, etc. On Linux there are Qt, Tk, GTK, and more. Some old, some buggy, some ugly. It's the same thing.
Rose tinted glasses you're wearing.
Sure you're in that Delphi niche and you feel comfortable there.
const { container, heading } = divs;
const container = document.createElement('div');
container.className = 'container';
const heading = document.createElement('div');
heading.className = 'heading';
const heading = span({ title: artName, innerText: whatever });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;
A never ending well of new divs that have the class name of the variable name
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;
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);
}
I could get rid of it, because my other approach to element creation would is:
const cool = div({ className: 'cool' });
const {
root,
headingContainer,
userContainer } = divs;
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.
That’s what I like.
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.
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?
I'd rather write makefiles or even Powershell scripts.
Maybe it's not good overall, but it's the best that the frontend has ever achieved.
Most Adopted Features: Nullish Coalescing, Optional Chaining, Private Fields
Highest Satisfaction (backend frameworks): SvelteKit, Astro, Fastify
Highest Satisfaction (frontend frameworks): Solid, Svelte, React
Highest Satisfaction (mobile & desktop apps): Tauri, Capacitor, Electron
Highest Satisfaction (build tools): Vite, esbuild, SWC
Highest Satisfaction (monorepo): pnpm, Turborepo, Mx
[0] https://dev.to/sachagreif/disclosing-a-state-of-javascriptst...
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.
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.
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>
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.
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
- Embroider is actually 1.0 now and quite usable (https://github.com/embroider-build/embroider).
- 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.
I think it is more likely that, largely, there are way more 25-34 programmers than 65+ programmers out there.
While I am no fan of angular, I think angular is on right track. Once they support non-NgModule and vite, their satisfaction will improve.
> Lee Robinson, Director of Developer Relations at Vercel
> SvelteKit is a fresh take on building for the web and has an incredibly passionate, growing community of supporters.
Also people can have opinions, outside of being company spoke persons.
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.
Devolved? I honestly thought it had always been this way, going all the way back to the jQuery / MooTools / YUI / Dojo days.
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.
... 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".
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.
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".
However, I personally find it shocking to see such a huge disparity when reviewing the gender breakdown between male, female and non-binary https://2021.stateofjs.com/en-US/demographics/#gender.
Simply put, the JavaScript community is still not doing a good job when it comes to inclusivity. That needs to change.
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.
It's a library that should get more love than it does.
That's really the biggest indicator of the state of js.
I would advise you to use vue or svelte.