To say that there are quite a few JS frameworks to choose from would properly be the understatement of the year.
It seems like every few months a ...
For further actions, you may consider blocking this person and/or reporting abuse
Nice breakdown of frameworks!
I've always thrown out the performance metric for UI frameworks. What's important to me is how easy it is to build? Are the dependencies stable? Do I need extra build tools? Can I write TypeScript? Can I read my code months later? Oddly enough most frameworks aren't considered because their routing system.
As a beginner in the area, I am very curious on if you know anything about EmberJS with respect to routing. I've read that they have a mature routing system which is one of their main strength.
They also seem mature and chilled kind of framework and slow moving than others (since they are mature) since front-end scene is overwhelming. Convention over configuration rings nice. Their RFC (Request for comments) is really cool compared to others I have been reading up on. Maybe I am wrong here but been taking my free time to understand EmberJS better. Am tied between Svelte and EmberJS. If am to take something new and trending, Svelte seems like the right pick. Especially now that SvelteKit is stable. Would love to pick your brain on this.
Typescript gets officially supported ; their routing conventions inspired; it provides SSR; all in one etc... EmberJS is the very first JS frontend framework introducing CLIs an first SPA framework. Funny fact, their CLI got literally copied by Angular's team.
Used by a bunch of companies among Netflix and Apple.
IMO EmberJS is the way to go to for any beginner. And, keep an eyes on other frameworks to sharpen you skills.
For getting a job out there -- and if you don't care about the quality of the habits you acquire during the first stages of your learning process, pickup Vue or React instead ;)
Yeah, makes sense to focus on developer experience. I'm curious on when in the proces you shift your focus to performance?
Optimization is the lest step for me. When an issue comes up or I notice a performance bug by accident then I'll fix it. Otherwise, I'm more concerned about getting features out the door.
Love it! Seems pretty thorough and generally following the recommended practices for each framework. I especially love how close the results were in the end.
I do want to point out that the rendered pages are entirely static, so Astro really shines here. If you remove the
<Scripts />element from Remix I imagine the lighthouse score would improve a lot, too (although not the SSR points like TTFB). I don't know if the other frameworks support the same thing. Alternatively, it would be cool to measure the speed of transitions between pages, since that's where frameworks with full hydration can improve the UX (perceived performance). Another alternative would be to include interactive elements on the page and see where Astro ends up compared to others with hydration.NodeJS based; but what about Deno; and Web container ?
Nice article, thanks for sharing !
These kind of articles really motivates me to do some more personal projects and enjoy the coding as it used to be before having a job.
Your work is really inspiring! Thanks for the great article! 🚀
Could you add Qwik to your comparison as well?
It's maybe the hottest modern contender.
I completely agree on what have you written and how you have bifurcated every framework.
But just want to ask, have you heard about TezJS? Did you even try it?
If no, then, I would recommend you go for it. I am sure, it tops the list and gives the best performance on Google Lighthouse.
Try TezJS (GitHub - github.com/tezjs/tezjs) and then let the world know about it through this article.
Happy Coding! :))
Ouch, TTI (Time To Interactive) between Astro and Next.js, more than a second slower, that hurts ... TTI is arguably one of the most important indices. And, not quite coincidentally (?) - Next.js is the oldest framework of the bunch :)
However, isn't it a bit misleading to say you measured the SSR performance of the frameworks? I'd say you measured the total web performance, and the SSR process is an important part of that (but I think it's not the only part).
In the test, I chose to only focus on SSR and not use SSG or CSR for any of the sites. Therefore all the sites are rendered using SSR. Had I chosen SSG the results may had be different. I don't see it as misleading, but appologize if it comes across as this.
I agree that "misleading" is putting it a bit harsh - my bad! :)
However to me, "measuring SSR", when taken literally, would mean profiling or measuring the server side rendering process (i.e. the execution of the React rendering process on the server, rather than on the client), which is a very specific process, that's pretty heavy on the server - so assessing the performance or efficiency of "SSR" as such ...
However your results - the differences between the frameworks - are probably due to much more than to the differences in efficiency of "SSR" per se, in each framework.
Yeah, nitpicking, I know ... :)
All of which is not to take away anything from what you've done, which is great!
"End-to-end performance with SSR" vs. "isolated SSR performance" could be a way to delineate it.
Nice article! If you consider adding other frameworks to this comparison could you add Quasar as well? Vue framework with 21k github stars, would love to see where that would stand in the rankings.