[HN Gopher] Angular without SSR is faster than Next.js with SSR
___________________________________________________________________
Angular without SSR is faster than Next.js with SSR
Author : Alex3917
Score : 56 points
Date : 2022-06-27 15:18 UTC (7 hours ago)
(HTM) web link (alexkrupp.typepad.com)
(TXT) w3m dump (alexkrupp.typepad.com)
| nicoburns wrote:
| Article can be summarised by this quote (which I very much agree
| with):
|
| > 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.
| andai wrote:
| For many years I believed that better gear would make me a
| better artist. I learned the hard way that this just ain't so.
|
| I think the same idea applies in this context.
| tshaddox wrote:
| Sounds like very different ideas. I'm pretty sure having a
| work environment and tools that are more pleasant to work
| with will indeed make you a better artist.
| jacksnipe wrote:
| If you're having trouble learning to paint, but you're
| trying to learn with a fork, then you should start by
| replacing the fork.
|
| If you're having trouble painting because your paintbrush
| isn't made of squirrel hair, then you just need to learn to
| fucking paint.
| cphoover wrote:
| Does squirrel hair make a good paintbrush? Never knew.
| bonestamp2 wrote:
| I prefer to use Angular for the same reason you prefer to use
| React. It really is personal opinion, both are good and mature
| frameworks/libraries.
| FinalBriefing wrote:
| I've found that SSR is generally quite slow. If you're using it,
| you'd want a CDN or some other caching layer in front of your
| server so you don't need to render each page server-side.
| jsguy wrote:
| The main reasons (IMHO) to have SSR are:
|
| * 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.
| TylerE wrote:
| What about stuff like Phoenix LiveView, which can push dozens
| of updates per second per client to hundreds of clients
| simultaneously?
| doliveira wrote:
| I actually find it sad that this passes as "impressive" these
| days
| fxtentacle wrote:
| Agree. Back in he day, people were discussing how to put
| 10k connections into a single core FTP server.
| TylerE wrote:
| I mean, this is on a single core, not a cluster.
| switchbak wrote:
| According to Wikipedia: "The term C10k was coined in
| 1999", and we've been discussing the C10M problems for
| years now.
|
| 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.
| TylerE wrote:
| Did you miss the hundreds of clients bit? So we're
| talking several thousand responses per second per core. I
| think that's fairly impressive, and VERY different from
| an FTP server connection that isn't really doing much
| most of the time.
| doliveira wrote:
| Even then, the heavy lifting of pushing the dozens of
| updates is mostly in the kernel, isn't it?
|
| 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.
| anonyfox wrote:
| Well it's a completely different technology compared to JS'
| spa/ssr approach, but in most cases (latency is not too bad)
| vastly superior: perceived and real performance is
| ,,instant", the code amount is smaller, less and more robust
| libraries involved.
|
| 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.
| ksbrooksjr wrote:
| The obvious downside to Liveview is that all of the UI state
| resides on the server. Every UI update therefore requires a
| full roundtrip request to the server, and so reducing latency
| is of paramount importance. That's why fly.io is so heavily
| invested in the Phoneix ecosystem, because their service is
| predicated on the idea of distributing your app globally to
| reduce latency. A React/Angular/Vue spa on the other hand can
| make decisions about how to update the UI without contacting
| the server. In fact, many PWAs these days are actually
| designed to work completely offline.
| cultofmetatron wrote:
| > Every UI update therefore requires a full roundtrip
| request to the server,
|
| 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.
| ksbrooksjr wrote:
| Yeah you can definitely pull in Alpine for UI updates
| that don't require any server side interaction, but then
| your app's logic is fragmented between different
| frameworks (Alpine and LiveView).
|
| 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.
| friedman23 wrote:
| Angular could be the fastest framework in existence and that
| would still not be a good reason to use it.
| bgun wrote:
| This comment has the same energy as people who still use a
| dollar sign when spelling "Microsoft".
| tracerbulletx wrote:
| I think it would be entertaining to have a recurring competition
| where teams sign up to compete on a few metrics like performance,
| number of total features completed, and maybe some kind of code
| review. Everyone would be given the same project spec and list of
| features, and have the choice of one of a few different
| frameworks per contest. So you'd end up with like 10 teams of
| various quality using react, and 10 using angular, and 10 using
| Vue or whatever the contest definition is.
| solardev wrote:
| > I think it would be entertaining to have a recurring
| competition where teams sign up to compete on a few metrics
| [...]
|
| Pretty sure this competition exists. Isn't it called
| "JavaScript"? ;)
| onion2k wrote:
| I have a theory that pretty much every developer saying "X is
| best for Y" is simply believing what a developer relations
| engineer or evangelist has said to them at a conference (or they
| read on a blog post, or heard 5th hand from a dev they know).
| What they fail to realise is that people who work in dev rel jobs
| _are paid to promote a product._ Next.js is wildly popular
| because the dev rel team are excellent devs who produce fantastic
| content, but they 're paid to promote Vercel and Next, and they
| do it well, but they don't mention where it _isn 't_ a good fit.
| Consequently every frontend dev claims Next is the answer to
| everything, and then builds a site that doesn't work very well
| because it doesn't fit Next's model.
|
| 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.
| Beldin wrote:
| > _people have been promoting the idea that the way to fix slow
| Angular sites is to rewrite them in Next.js, and the data very
| clearly does not support this._
|
| 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.
| pictur wrote:
| what are the advantages of using angular right now? in terms of
| documentation, it doesn't look like an atomic reactor compared to
| the past. more like simplified
| InsaneOstrich wrote:
| It's very opinionated compared to the alternatives and it has a
| "batteries included" kind of approach. There's a "right" way to
| do things and you don't need to pull in a lot of third party
| libraries for basic functionality. The native typescript
| support is really nice too.
| jeremycarter wrote:
| I've worked on react apps where some features use different
| routers, state stores and component syntax. Angular gives you
| 2 ways to solve problems and keeps things consistent and on
| the rails.
| trhoad wrote:
| I worked with React almost exclusively for ~5 years. I got so
| fed up with everyone reinventing the wheel on every project,
| coming to Angular (late) was a massive breath of fresh air. I
| now spend more time building valuable features rather than
| discussing changing state management libraries and people
| banging on about hooks all day long. YMMV, and I'm certainly in
| the minority, but I'd probably choose Angular over React for
| any new projects now, personal or professional. The only thing
| I really miss is that JSX is much more ergonomic and the
| devtools for React are a bit better.
| aluminum96 wrote:
| In my opinion, the biggest advantage of Angular is how
| batteries-included it is. Everything just works out of the box,
| and project configuration is very standardized. The framework
| owns everything from common UI components (Angular Material) to
| your build process (Angular CLI) to non-core packages (router,
| forms) to state management (RxJS).
| jeremycarter wrote:
| Angular has great support. It is the front end to some
| absolutely huge apps like Google AdWords, Google Cloud Platform
| etc. Angular shines when you have 10+ devs working on the
| project. It's not slow, flexible and the boilerplate module
| code will be removed in the next version. Basically you just
| have to give it a go, so many people trash technology without
| giving it a unbiased go.
| steve_adams_86 wrote:
| Having used Angular 1 then migrating to 2, and then trying it
| again very recently I wonder if a lot of people were burned
| by early Angular and unwilling to try it again.
|
| 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.
| wdb wrote:
| Yes, Angular 1 wasn't great and I haven't looked back
| zdragnar wrote:
| The code quality of angular 4/5/6 and the add-on packages
| was so bad, I wouldn't want to lock myself into that
| ecosystem ever again. I don't remember exact numbers, but
| I'm pretty sure that about half the bugs that project had
| were due to angular, poorly designed Rxjs interactions, or
| angular flex-layout.
| wdb wrote:
| Google Cloud Platform Console is really slow for me. Always
| painful experience to use especially switching products.
| Wouldn't say that's a good advertisement for Angular
| Alex3917 wrote:
| > Google Cloud Platform Console is really slow for me.
|
| While this definitely isn't because of Angular, I will note
| that it's currently deployed in development mode.
| aluminum96 wrote:
| I'm going to reply twice, because I'm a true believer (TM).
|
| 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.
| Alex3917 wrote:
| > What are the advantages of using angular right now?
|
| 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.
| acdha wrote:
| > - 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
|
| 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.
| ramoz wrote:
| @alex3917 summarizes in comments below, and what are also similar
| reasons why I believe modern angular will "overtake" modern
| react/frameworks like next.
|
| 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.
| ec109685 wrote:
| This is such a misleading headline. It compares the speed of a
| basket of sites that happen to use Angular in some capacity with
| a separate list of sites that happen to use Next.js and makes a
| broad sweeping conclusion about framework speed?
|
| 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...
| dawnerd wrote:
| You can't even assume a nextjs page is SSR without being on the
| dev team.
___________________________________________________________________
(page generated 2022-06-27 23:00 UTC)