Angular without SSR is faster than Next.js with SSR
alexkrupp.typepad.com
alexkrupp.typepad.com
I wonder how reliable this is for SSR as well (and sites that opt into SSR might actually have more complicated sites, so skewing the numbers): https://gist.github.com/Alex3917/fec45e5c2114c2c13b41b30e198...
On the sites I've been working pages that have been server rendered work mostly perfectly with javascript disabled.
1) The server generates html (a string).
2) Browser receives html and builds DOM just like in any static website
3) Javascript downloads and react sees the DOM already exists and does nothing
Edit: the biggest issue is that the article is vunerable from severe confirmation bias from the authors admitted sunken costs
I actually think this is a strength of the methodology. Every site is supposed to hit the same set of benchmarks regardless of how simple or complex it is -- less than 1.8 seconds FCP, and <= 3.8 seconds TTI. In this particular run, 1% of Next.js sites met this goal, as compared with 8% of Angular sites.
I'm definitely interested (and I say as much) in how this would change when you define the baskets in different ways, which is why I included the code, to make it easy for others to improve upon. But I don't really care about synthetic tests or micro benchmarks.
Ultimately my main interest was to figure out whether it might make sense to rewrite our site. But if our site is already faster than every site I can find that uses Next.js, which was legitimately very surprising, then frankly it doesn't even make sense to consider further. Especially since I already have three or four different things I can do to significantly improve our FCP without rewriting the site, where by far the most expensive of these options is maybe 10% the time and cost of a rewrite.
Your headline is comparing frameworks, while your basket is arbitrarily chosen based on a Next.js's showcase page.
I'm singling out Next but it's not limited to that framework. I like Next. I use it. I spent weeks working out if it could do what I need before I started. The problem isn't Next, it's applying Next where it doesn't fit. This is true for everything that has paid promoters. You have to do your homework. You can't blindly trust what the internet says.
When the dev industry stops conflating the opinion of someone paid to promote a product with stop cold facts that apply to everything then things will improve.
Some days it feels the everybody software industry puts their trust in a handful of famous ex-<insert FANGG> here or famous youtubers / bloggers and takes what they say as undeniable truth (Though this is true for nearly everything nowadays, everything trite, washed down, and summarized with no heart or nuance)
There's a great saying in German: "Die kochen auch nur mit Wasser" - They also cook only with water. Sure, some of these youtubers and bloggers are super smart and helpful, and there are brilliant people who have worked at Silicon Valley companies. But there are smart, helpful, and brilliant people at nearly every company around the world. It just so happens that not all of them blog, have a twitter, or have youtube channels.
Sorry for the oldmanish grumbling but the more I learn about this industry is that everything is about picking the right tool for the job, documenting the arcane decisions made, and managing all of those decisions. When you really start getting into the weeds, the (IMHO) junior level ideals of 'perfectly clean code' and '100% code coverage' rapidly go out the window. We're _maintainers_ of complex systems, not wizards with panaceas. 100% of the time it is picking the tool for the job, and know what you are doing with that tool.
Experimenting? Great. Learning something new? Great. Just don't lumber into your organization one day saying "we should do X or Y because its the hype, or Z said so". Many painful stories can be shared on this type of mentality.
The “if you have a hammer everything looks like a nail” adage makes fun of that, but in practice most people would hate maintaining their main project in Next, a tooling project in Vue, and some other stuff on the side in Knockout and a legacy project in Angular.
So for anything that is vaguely in reach of Next/react, keep using it makes more sense than switch to a slightly more adapted framework just for that single thing.
> It's very clear from this data that choice of framework is not the primary driver of site performance; just manually looking at the source code for some of these sites, it's clear that it's things like unnecessary dependencies, outdated dependencies, sites running development mode in production, etc.
Personally, I use React, not because it's faster than Angular, but because it's much more pleasant to work with.
I think the same idea applies in this context.
If you’re having trouble painting because your paintbrush isn’t made of squirrel hair, then you just need to learn to fucking paint.
I'm doing gesture drawings daily now on a Supernote. The ability to use the entire 'page', then hit next page and start a new one, lets me crank them out in a way pen and paper doesn't.
Pen and paper -absolutely- is better for trying to capture a likeness, and the actual "quality" of the job at the end is about the same (if it isn't it's probably better), but the sheer ease of use means I do the thing more, which means I'm practicing more, which means I am, indeed, becoming a better artist.
The tools have to be suitable to the task (and I don't think anyone is saying the various frontend frameworks are -unsuitable-), but after that ease of use still matters.
Angular in 2022 is simpler than react. It’s what react was in 2015 when Angular 1.x was a complicated and annoying beast.
Now, Angular is simple and pleasant; while my scaled, hooks infested, react apps make me feel like I’m handicapping myself.
If Angular is indeed simple and pleasant, perhaps there's a space for a clone and a new name, like NodeJS versus Rails.
Surely you must be joking. You have to learn all of these things to make the tiniest CRUDdy app:
- angular modules
- angular template syntax
- angular decorators
- angular dependency injection
- rxjs
I can’t speak about next.js, it doesn’t fit my use case. But claiming that “Angular is simpler than React” is ludicrous.
With decorators and dependency injection at least you're learning a concept which has been quite widely used across some popular languages/frameworks, there's a chance you'd already have come across these ideas in learning programming.
rxjs definitely can take some learning time, though to get started with basic things like handle an api request with observable it doesn't take long. There's a whole lot you can do, and that power is quite useful for complex scenarios.
Powerful tools often put people off because they appear complex. Often that complexity is at least partly an illusion - once you've learned the abstractions, much of what seemed to be complexity can actually be very simple.
Dependency injection is the exact same thing, only with different syntax.
For me Angular 1.x was simple and pleasant, first JS framework that I really liked to use back when MEAN stack was popular. Angular 2+ is what you call "complicated and annoying beast".
> my scaled, hooks infested, react apps make me feel like I’m handicapping myself
I know what you mean, I hope Vue 3+ or Solid will slowly replace React.
nothing prevents you from just using classic classes with react. we have 0 hooks on our code and we are not missing out on any feature.
I wish some of my other projects we are as easy to maintain and extend.
react + flow + redux + sagas feel like a cheat code. it shouldn't be so easy to program javascript.
Pretty sure this competition exists. Isn't it called "JavaScript"? ;)
This is going to be heavily conflated with so much other stuff that is nothing to do with SSR, that it is useless.
It is probably more a test of the underlying server performance. And whether a CDN is used (if you use Next with Vercel you will get a CDN, but not everyone does necessarily use Vercel).
Also I am guessing PageSpeed doesn't wait for angular to do the client side render? So yes <html><script ..></html> will load pretty fast.
Also a lot of NextJS people are going to be correlated with 'build it and ship it quick' bent, and may not tune performance up. I imagine Angular people are more 'long term product' people, in general.
Also if you are doing a SPA on Next, you can set up static file generation if rendered page = f(url) not f(url, user_state). Then those can be geographically cached across a CDN. You can do that in a way that say you have product_list.csv, you can build out the static site.
I just feel Angular vs. Next = apples vs. orange trees.
As others are saying, it's silly to compare frameworks unless it's across projects loading and doing basically the same things. So many ancillary decisions impact the performance.
* Not arguing in favor of frameworks here—less javascript is always better! But this comparison method makes no sense to me.
Clearly this is doing a lot more work than serving static content, but .... dozens per second? Even per-core, that's a shockingly low number.
Don't get me wrong, it's pretty good and just the fact that you're pushing these stats reflects quite well on my (external) impression of Phoenix: most don't even bother to try and just resort to "hardware is cheap".
It's just that this should be the default. Reminds me of this tweet from @SwiftOnSecurity:
> Once you understand your computer has 16 cores running at 3GHz and yet doesn't boot up in .2 nanoseconds you understand everything they have taken from you.
Yea, it’s easy to right simple fast software when you only target English, and don’t have to care about Unicode, i18n, security, or any of a billion other things modern systems offer
Either way, I stand by my bet. They're irrelevant compared to the cost of the prevailing mentality of DX over anything else. Combined with the industry leaders having machines with 128 GB of RAM on 10 Gbps connections, this mentality guarantees software gets slower way more than hardware gets faster
Disadvantage: the individual components are not as nicely packaged up with markup/css/logic in a single file and must be hooked up to the global socket explicitly.
while this is certainly the easiest path, you don't HAVE to put all your ui states on the server. its trivially easy to plugin alpinejs for small ui state stuff that is all client side.
Another huge benefit, the js escape hatch lets you create a bidirectional bridge between your custom js and your user's liveview instance.
It's definitely doable, and I know the PETAL stack (Phoenix Elixir Tailwind Alpine) is super popular, but it's nice (and perhaps less error prone) to have all of your UI logic handled by a single framework. This consolidation of UI code under a single framework was one of the killer features of SPAs initially. Prior to that lots of sites were built with a server side templating framework with jquery sprinkled in for client side UI updates.
I think there is room for a framework similar to Phoenix LiveView but also allows compiling certain interactivity to the client. Next.js and Remix are kind-of fulfilling this but they have downsides.
In the BEAM ecosystem, I think there is room for [Gleam](https://gleam.run) to be used to compile to both Javascript and the BEAM.
There was actually a developer working on a subset of Elixir that compiles to JS called Elixirscript[1], but development seems to have stalled. Another functional statically typed compile-to-js language which targets the BEAM vm is Purescript through the Purerl project [2].
If you're going to compile to JS though, there's an argument to be made that you might not want to target the BEAM at all. You could potentially run your entire backend on something like Cloudflare Workers, which has over 200 points of presence around the world, so latency is about as low as possible. The other CDNs have their own competing worker runtimes as well (e.g. Cloudfront functions, Netlify functions, etc.). These edge worker runtimes also have the benefit of not charging for each individual region in which you operate. You can also run any language which compiles to WASM like Rust, Assemblyscript, or Grain [3] on these edge runtimes. The only missing piece for me is a distributed database, but it looks like Cloudflare at least is working on that [4].
[1] https://github.com/elixirscript/elixirscript
[2] https://github.com/purerl/purerl
* SEO capabilities * Faster response for first page load
And for both of those, a CDN is useful, if not essential - you're missing out on a lot of performance boost if you don't.
Other reasons to have SSR include things such as unfurling, where a CDN isn't essential, but still nice to have.
Also, you can achieve this behaviour on CDNs from a full SSR response with just using stale-while-revalidate in the Cache-Control header.
Then again, the data also doesn't refute this. It simply shows angular sites on average score better than nextjs; it does not give any info about the speedup (if any) of rewriting the slowest of angular sites in nextjs.
For that, you'd need data on a bunch of slow angular sites before and after their conversion to nextjs.
I never use Angular for personal projects, and I have been using TypeScript exclusively for years. I.e. other libraries work really well with TypeScript as well (sometimes actually better than Angular, in my experience)
It’s leaps and bounds ahead of what it was in terms of end user and developer experience. The tooling is dramatically improved. If you asked me 6 months ago what my position on Angular was, I probably would have said something like “I haven’t used it recently, but older version were pretty awful. Bad DX, incredibly slow builds, huge bundle size, etc”. Today I think it’s pretty compelling for the right projects.
Like anything that doesn’t just fade away, there’s a reason people still use it. There are some talented and intelligent people driving it forward. I’m not eager to use it, but I was really glad to see how much it has improved.
It seems like both a strength and a weakness of the Angular ecosystem. Maybe the testing story needs to improve? I can’t recall how exhaustive marbles are, and maybe fuzzing might help catch gotchas?
Honestly I thought RxJS would benefit a ton from a visual builder. They have this decision tree tool for helping figure out which operators you need to use, but you could go further and actually build out entire observables in a similar way, plotting out the system and behaviours visually along the way.
When you have such excellent boundaries and well defined behaviours, but observables can become complex so easily, it seems like a great opportunity to visualize and constrain things with tools which generate the code you need.
I know some might find that gets in the way of programming, but I have a feeling it would help those who struggle with RxJS produce far more stable observables.
This is actually why I began using XState for a lot of things. Although I can write out all of the logic myself easily enough, their tooling seems like it’s on a very promising path to making complex state management far more approachable to people with less experience. Having well defined state, transitions, and a great testing story is huge in avoiding the kind of buggy mess I’ve seen and you seem to be describing around Angular.
Point of fact, I just started a new job and am already being thrown into fixing their state machine code (not javascript / ts though). I can't say that what they're doing requires fewer lines, tests or has fewer bugs than if they'd just written it out without the whole state machine concept. I can say that it would certainly be a lot simpler and more flexible, though.
I've been hesitant to use state machines for anything complex... I find they work great for small-ish things like an image uploading component in the front end, where the states are very well defined, there is a sort of flow, predictable actions need to be taken, etc.
I've wondered a lot about composing machines. It seems like it could be extremely useful and powerful. The actor model is the approach the XState team is taking and it seems promising, but some things holds me back. The API is certainly one reason, but it's the mounding complexity that scares me more. Like you say, it seems like it could get really messy.
I have a feeling with a good enough API this problem could be reduced, but that's not a trivial thing to figure out at all. I'd love to see it happen, though.
While this definitely isn't because of Angular, I will note that it's currently deployed in development mode.
A low total cost of ownership compared to other frameworks because:
- The code for every Angular project is structured the same way
- The code for components (and directives, services, etc.) is generally very readable
- Everything is easy(ish) to test
- 280k Stack Overflow questions, vs 95k for Vue and 19k for Next
And ease of hiring due to 170k Angular developers in the US (per Sales Navigator), as opposed to 50k for Vue.js and 48k for Next.js
And in general Angular seems much easier to learn. If you spend 20 hours watching the Udemy course then you pretty much know it, whereas I regularly see job ads looking for folks with 6+ years of React experience. Now obviously you always hear about job ads looking for folks with 10 years of experience with some technology that's been around for two years, and yet I rarely come across Angular job ads that implicitly assume it takes multiple years to learn how to use the framework correctly.
> And ease of hiring due to 170k Angular developers in the US (per Sales Navigator), as opposed to 50k for Vue.js and 48k for Next.js
Listing large numbers without commentary is a bit of a red flag unless you can point to how you analyzed the raw data — e.g. does more questions mean more happy users or more problems which people can't figure out on their own? Does that developer figure exclude the people who said “I used Angular 1, hated it, and switched to React”? That last is related to the conspicuous absence of React, which has higher numbers in both categories.
You just described every frontend framework. None of these are unique to Angular. Any developer with an understanding of JS can learn and use any framework in the exact same way.
> 280k Stack Overflow questions, vs 95k for Vue and 19k for Next. And ease of hiring due to 170k Angular developers in the US (per Sales Navigator), as opposed to 50k for Vue.js and 48k for Next.js
These are false comparisons, and you're conveniently leaving out the largest competitor. A higher SO question count isn't necessarily a positive metric, and may even imply substantial confusion about the framework. More importantly, all of the surveys[1] show that both developer and hiring interest for Angular is waning.
> whereas I regularly see job ads looking for folks with 6+ years of React experience. Now obviously you always hear about job ads looking for folks with 10 years of experience with some technology that's been around for two years, and yet I rarely come across
You're using a popular meme about some notoriously bizarre job listings written by HR managers (or interns) to suggest that developers have a harder time learning frameworks other than Angular. There is no correlation whatsoever between these two things. When "you always hear" and "yet rarely come across," you are experiencing the effects of confirmation bias.
> Angular job ads that implicitly assume it takes multiple years to learn how to use the framework correctly.
If a job lists multiple years of experience as a requirement, why would that automagically mean the employer is "implicitly assuming" multiple years of training is required to accomplish a bare minimum? In reality, it means they're looking for someone who didn't spend last weekend watching a 20 hour Udemy course to obtain a cursory understanding.
They're requiring real-world experience in a similar work/project environment, and they are paying handsomely for that experience. If it were junior development jobs with these requirements, you'd maybe have an argument, but 100% of senior positions have minimum work history requirements, because that is the definition of senior.
[1] https://gist.github.com/tkrotoff/b1caa4c3a185629299ec234d231...
You just summed up, why he said Angular is better in this regard. Yes any developer with experience CAN lean how to write good structured React apps. In Angular it is basically enforced.
That being said, I think the ergonomics in React development (JSX) are SOO much better than Angular that I still prefer it.
Coming from the React/Next.js world, I was really puzzled with that decision as I still had in mind the trauma of the Angular.js -> Angular migration and the breath of fresh air that React had represented at the time.
As most engineers out there, I had an urge to stick to what I knew would work, but I resisted that urge and gave Angular a chance. I do not regret it; Angular and the structure the framework provides is a game changer for a large project; the conventions make the code and the architecture predictable/testable/scalable. Our time is spent on delivering value for our users. This is, in my opinion, the best quality a technology can have when working on a fairly large project.
Another set of advantages comes from how declarative Angular is. With React and JSX, everything is super imperative (setState, loops to generate dom, etc). In Angular, RxJS gives you a really powerful reactive model for your state, directives give you a much more declarative way of describing application behavior, and the limited template microsyntax encourages you to put the complexity in your typescript, not in templates.
I don't know how much people have changed, but generally people don't change very fast so this is probably still relevant: If the HTML doesn't look like HTML and the CSS doesn't look like CSS, you end up with a bunch of problems that can only be solved by the people who aren't invested in it.
Designers and UX specialists end up being hobbled if they are expected to make heads or tails of the Turing Complete parts of the code. And once they feel hobbled they tend to shut down even more, and it's just pain getting any improvements in.
Mostly HTML with a little code is already at the very edge of their comfort levels. JSX and things like JSX have been abandoned more times than I can count, and there's always some necromancer who brings it back.
I don't even know if they have the OnPush version of Angular implementation (which would be fair), but if they don't - I hope someone will build it soon.
----
And while we are here, please create a Qwik implementation!
I simply use React's build in solutions[1] and a node.js server.
I dare say it's quite fast.
I have no idea why I would dislike angular beyond some mild personal preference.
However, if it was noticeably faster than alternatives then I would just deal with those frustrations, personally. User experience (including speed) trumps developer experience.
Prove me wrong with the examples, please.
1. Slow rebuild times.
2. Takes a long while to start a single unit test suite, using the default Jasmine setup.
3. No HMR.
4. Very awkward router API.
Test and, especially, builds time issues can be greatly reduced using Nx - give it a try. In one project (~400 components/directives) we’ve reduced the CI cycle (lint, test, build, deploy) from 50-55 minutes to 2-7 minutes. I know it sounds too good to be true, but there is no magic behind it: you can read how “nx affected” and remote cache works. It's basically free to use, we are using a free tier for every project.
One more thing: with Nx, it’s much easier to generate libraries, and you don't need to rebuild them to see the changes. Because of that, most of the code natively and without friction moves to libraries with time.