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?
It's easy to poke a hole in a methodology, but this was a pragmatic short curcuit of collecting websites as they are in the wild. You could ask 10 experts to code up equivelent websites and measure performance and still someone would complain that it's a synthetic benchmark.
The nice thing about this methodology is that noone was expecting the dataset to be used for this purpose. It is an interesting set of measurements in my opinion.
Edit: the biggest issue is that the article is vunerable from severe confirmation bias from the authors admitted sunken costs
> 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 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.
Until you can determine a site like TikTok and Twitch have performance problems due to Next.js, it doesn't make sense to use them as a datapoint to say Angular without SSR is faster than Next.js with SSR.
Your headline is comparing frameworks, while your basket is arbitrarily chosen based on a Next.js's showcase page.
True but you don't know if it's been exported as static, generated as static on build, progressively generated (generated once someone hits the page then cached) or generated on every page load.
Genuine question: what if you disable JavaScript and then load the page? Would you just get the SSR portion of the page and if it wasn't SSR at all then you'd get a blank page?
Hard to say since it depends(tm) but for the most part it should look like any other html site, react then just hydrates. IMO it's the best of both worlds.
On the sites I've been working pages that have been server rendered work mostly perfectly with javascript disabled.
You’re paying the price of initializing react twice and generating the dom: once on the serve side and then again on client before page is interactive.
Not quite, the second time doesn’t “generate the dom”, it just hydrates, fills in the gaps and binds event listeners. It’s not starting from scratch and isn’t a big cost.
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.
I'm of the exact same opinion, but I've mostly given up on repeating similar notions. I think it's unlikely to change: I read something once that there are about 20 devs on all of twitter that generate 90% of all the tech chatter and hype.
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.
This effect is probably accelerated by most teams wanting a limited set of technologies and lower mental burden.
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.
A complementary (and fairly easy to demonstrate) theory is that few would be using Next if it weren't for the paid promotion. Doesn't that basically make Vercel a kind of shitcoin?
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.
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.
So as someone trying to get better at drawing, I will say that the -ease of use- matters tremendously.
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.
Having lived in big (and big-ish) cities all my life, it's always a big amusement watching at Youtube the videos of people in the suburbs trying (and failing) to out-smart these intelligent burglars :)
Erm... there is a whole bunch of brushes made with a different animal hair/fur. It matters when you know how to use it. It doesn't if your skill tops at a "line and line and a circe - I drew a person".
I know many artists who are objectively good who much prefer good tools, good paints, etc...sure...they can make do with markers and make it look way better than a non artist....but that's from practice....when they want a masterpiece it won't be from markers and scraps
@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.
looks like Standalone Components, which are in preview in the latest v14, may yet see the deprecation of angular modules, or at least give more options to devs https://angular.io/guide/standalone-components
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.
For me Angular's use of rxjs is a killer feature. Our back end code relies heavily on streaming computations, and rxjs provides a great front end complement to that.
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.
yep i really like using rxjs now. i find using "await lastValueFrom(<observable>)" keeps code nicely readable and flat. it has 38m weekly downloads on npm so should be around for a good while.
I don’t want to use decorators. They’re another band-aid to keep OOP on life support. They are disguised functions applied to mutable objects in order to enhance their capabilities (or maybe to comply with type interfaces).
Dependency injection is the exact same thing, only with different syntax.
It's simpler once you know it. I bounce between Angular and React and whilst it's true that React is easier to get started, changes in the API (hooks, class vs functional componentns) and ecosystem (eg forms, UI Kits, state management, architecture etc) mean that I find it's a constant learning curve, whereas aside from a few minor changes Angular has been the same since V2.
> Angular 1.x was a complicated and annoying beast
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.
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.
> I went to the Next.js website, looked at some of the logos of the companies using the framework, and started typing their domains into PageSpeed Insights.
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.
In production marketing sites, I've found over and over that it's usually 3rd party javascript that has the most brutal impact on performance. Or put another way: it's less the particular framework you pick and more how you choose to put it to use. (To help address this, the Builder.io team is doing some amazing and super clever work with a library called Party Town that relocates resource intensive scripts into a web worker to free up the main thread.)
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.
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.
Next.js can do ISR (incremental static regeneration), which essentially gives you the same result as a CDN in front of SSR. Having said that, in most cases you should use a CDN.
Eh, in that case you're still sending all requests to one Node server. I think it'd still be preferable to have a CDN so that it can be served from the edge.
Also, you can achieve this behaviour on CDNs from a full SSR response with just using stale-while-revalidate in the Cache-Control header.
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.
> 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.
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.
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.
I agree that there's room for a language that runs on the BEAM and also compiles to JS. Gleam looks great, and it's one of the up and coming languages that I'm rooting for. In addition to having a Javascript compile target, it's statically typed which is a prerequisite for me when it comes to productivity and correctness.
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].
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.
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.
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
You're talking about the algorithms for TLS? Or hashing as in hashing a lot of things in your application?
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
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.
> 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.
These comparisons are generally pointless for a variety of reasons. BUT, Angular's dev experience is garbage, and no amount of hot take analysis will convince me otherwise.
An honest questions: How much have you worked with Angular? I have worked with it since the first release and what I see that it is steadily (albeit sometimes slowly) going into the right direction. Today the dev UX is great and differs nothing from that of using CRA for example. (If we are talking about tooling)
i think it's when you try to build something complex with angular that you can see advantages come to fruition. the opinionated structure can be quite an advantage when you're working with bigger teams/projects, as it can keep code more consistent/familiar/predictable, so when revisiting a project a few months later, you generally know where to find things quickly
I don’t understand the point of takes like this. The sites are all on different hardware in different data centers in different locations performing different tasks. Even the frameworks compared aren’t comparable. Angular should be compared to React. Not a client+server hybrid framework that utilizes React for UI and mainly exists to simplify tooling and code-splitting. Even if this comparison were relevant, the idea that you should choose a technology based on the minor variations in perception of performance of one person in one location is absurd. This is coming from someone who has had performance issues in Next.js and Angular. Both of which had little to do with Next.js and Angular.
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
> 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.
> - 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.
> 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. [...] And in general Angular seems much easier to learn. If you spend 20 hours watching the Udemy course then you pretty much know it
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.
> 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.
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.
Doesn't learning the Angular structure require learning? If that's the metric and you have to learn good structure for both frameworks, I'm not seeing the advantage. In fact, Angular's rigidity is only an advantage if the developer finds that particular structure comfortable. And the reality is that the vast majority of developers don't find Angular comfortable to work with.
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.
My experience is very similar to yours, and I concur with your conclusion. After 5 years of React, I joined a new organisation as engineering lead, and the team had embraced Angular before I joined.
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.
I would have to agree with this sentiment. I think one of the best things about hooks in general is that it put to rest all the third party state management libraries. At least now you can just agree with most people and move forward with hook state.
That being said, I think the ergonomics in React development (JSX) are SOO much better than Angular that I still prefer it.
JSX is the best thing about React, and the Angular templating is worst thing about Angular, so I can certainly empathise with that being the tipping point.
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.
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.
Having stuff included does have advantages, but, in my opinion, some of those included things in Angular are really badly designed (I'm looking at you, Forms)
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)
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.
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.
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.
I love RxJS and the testing story is not bad, but it does manage to find ways to be buggy when I encounter it.
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.
Both RxJS and XState have some really seductive tooling and promises. It has been my personal experience (from 4+years ago for both libraries) that both will quickly swamp you in accidental complexity.
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.
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
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).
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.
Others have mentioned most of the big points, so gonna be a bit contrary and ay I like being able to actually write HTML/CSS and not JSX and whatever the current flavor of the month is for CSS in React is these days. I like marking up my HTML rather than writing JSX personally. I'm sure I'll have to embrace JSX as some point, but don't see it as the huge win that others seem to consider it when I have played with it.
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.
It also shuts down an entry into the world of web development (and development in general). Sadly, I know some see this as a feature, not a bug, but I know a number of people who are great developers who started out doing HTML/CSS and learned programming (JavaScript and much much more) along the way. Some are in very high positions now at companies most of us in this industry are aware of. I'm not saying they wouldn't have found another way into the industry, but it would have been significantly more up front learning before they could start working professionally. I know that entry-level positions of that nature (mostly just HTML/CSS) are getting more and more rare, but to me that is very sad and limits the potential for some really great people to be part of our industry.
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!
Agreed it's really fast. FWIW I think the main benefit you'd get from using NextJS (or similar) is that your header/navigation wouldn't be replaced on page navigations on your features/assets pages, so you wouldn't get the whole page flash. It'd just update the content part instead. Their docs are a good example of this: https://nextjs.org/docs/basic-features/pages - if you click links on the sidebar you'll see just the content update.
I find the dev experience of Angular very frustrating, and many things seem overly complicated or not very well designed, in my opinion. That's why I would choose something else (anything, really)
However, if it was noticeably faster than alternatives then I would just deal with those frustrations, personally. User experience (including speed) trumps developer experience.
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.
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...
It's easy to poke a hole in a methodology, but this was a pragmatic short curcuit of collecting websites as they are in the wild. You could ask 10 experts to code up equivelent websites and measure performance and still someone would complain that it's a synthetic benchmark. The nice thing about this methodology is that noone was expecting the dataset to be used for this purpose. It is an interesting set of measurements in my opinion.
Edit: the biggest issue is that the article is vunerable from severe confirmation bias from the authors admitted sunken costs
> 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 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.
Until you can determine a site like TikTok and Twitch have performance problems due to Next.js, it doesn't make sense to use them as a datapoint to say Angular without SSR is faster than Next.js with SSR.
Your headline is comparing frameworks, while your basket is arbitrarily chosen based on a Next.js's showcase page.
You can't even assume a nextjs page is SSR without being on the dev team.
You just look at the response from the server… if the site html is fully fleshed out it’s SSRed
True but you don't know if it's been exported as static, generated as static on build, progressively generated (generated once someone hits the page then cached) or generated on every page load.
Genuine question: what if you disable JavaScript and then load the page? Would you just get the SSR portion of the page and if it wasn't SSR at all then you'd get a blank page?
Hard to say since it depends(tm) but for the most part it should look like any other html site, react then just hydrates. IMO it's the best of both worlds.
On the sites I've been working pages that have been server rendered work mostly perfectly with javascript disabled.
You’re paying the price of initializing react twice and generating the dom: once on the serve side and then again on client before page is interactive.
Not quite, the second time doesn’t “generate the dom”, it just hydrates, fills in the gaps and binds event listeners. It’s not starting from scratch and isn’t a big cost.
There’s no DOM on the server and you only generate it once on the client.
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
It generates the shadow dom is what I meant.
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.
I'm of the exact same opinion, but I've mostly given up on repeating similar notions. I think it's unlikely to change: I read something once that there are about 20 devs on all of twitter that generate 90% of all the tech chatter and hype.
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.
This effect is probably accelerated by most teams wanting a limited set of technologies and lower mental burden.
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.
What use cases are not good for next? In my experience it doesn't get in your way that much so I wonder what task did you find it can't do.
A complementary (and fairly easy to demonstrate) theory is that few would be using Next if it weren't for the paid promotion. Doesn't that basically make Vercel a kind of shitcoin?
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.
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.
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.
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.
So as someone trying to get better at drawing, I will say that the -ease of use- matters tremendously.
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.
Does squirrel hair make a good paintbrush? Never knew.
My wife claims that the red squirrel hair is better than gray squirrel hair, but I think its because she hates those little red bastards
Having lived in big (and big-ish) cities all my life, it's always a big amusement watching at Youtube the videos of people in the suburbs trying (and failing) to out-smart these intelligent burglars :)
Makes me wonder if her opinion would be better if she source it herself.
Erm... there is a whole bunch of brushes made with a different animal hair/fur. It matters when you know how to use it. It doesn't if your skill tops at a "line and line and a circe - I drew a person".
That increases your finesse, but the creativity boost usually comes from being able to get bored.
I know many artists who are objectively good who much prefer good tools, good paints, etc...sure...they can make do with markers and make it look way better than a non artist....but that's from practice....when they want a masterpiece it won't be from markers and scraps
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.
@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.
> Angular in 2022 is simpler than react
Surely you must be joking. You have to learn all of these things to make the tiniest CRUDdy app:
I mean, look at the FULL table of contents for their “Get data from a server” doc! [0]I can’t speak about next.js, it doesn’t fit my use case. But claiming that “Angular is simpler than React” is ludicrous.
https://angular.io/tutorial/toh-pt6
looks like Standalone Components, which are in preview in the latest v14, may yet see the deprecation of angular modules, or at least give more options to devs https://angular.io/guide/standalone-components
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.
For me Angular's use of rxjs is a killer feature. Our back end code relies heavily on streaming computations, and rxjs provides a great front end complement to that.
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.
yep i really like using rxjs now. i find using "await lastValueFrom(<observable>)" keeps code nicely readable and flat. it has 38m weekly downloads on npm so should be around for a good while.
I don’t want to use decorators. They’re another band-aid to keep OOP on life support. They are disguised functions applied to mutable objects in order to enhance their capabilities (or maybe to comply with type interfaces).
Dependency injection is the exact same thing, only with different syntax.
It's simpler once you know it. I bounce between Angular and React and whilst it's true that React is easier to get started, changes in the API (hooks, class vs functional componentns) and ecosystem (eg forms, UI Kits, state management, architecture etc) mean that I find it's a constant learning curve, whereas aside from a few minor changes Angular has been the same since V2.
It's very very difficult to get people to adopt systems that have already been labeled as failed.
If Angular is indeed simple and pleasant, perhaps there's a space for a clone and a new name, like NodeJS versus Rails.
Vue?
> Angular 1.x was a complicated and annoying beast
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.
> while my scaled, hooks infested, react apps make me feel like I’m handicapping myself
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.
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.
The “real world” project is pretty close: https://codebase.show/projects/realworld
> 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"? ;)
> I went to the Next.js website, looked at some of the logos of the companies using the framework, and started typing their domains into PageSpeed Insights.
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.
In production marketing sites, I've found over and over that it's usually 3rd party javascript that has the most brutal impact on performance. Or put another way: it's less the particular framework you pick and more how you choose to put it to use. (To help address this, the Builder.io team is doing some amazing and super clever work with a library called Party Town that relocates resource intensive scripts into a web worker to free up the main thread.)
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.
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.
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.
Next.js can do ISR (incremental static regeneration), which essentially gives you the same result as a CDN in front of SSR. Having said that, in most cases you should use a CDN.
Eh, in that case you're still sending all requests to one Node server. I think it'd still be preferable to have a CDN so that it can be served from the edge.
Also, you can achieve this behaviour on CDNs from a full SSR response with just using stale-while-revalidate in the Cache-Control header.
What about stuff like Phoenix LiveView, which can push dozens of updates per second per client to hundreds of clients simultaneously?
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.
> 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.
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.
I agree heavily with this assessment.
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.
I agree that there's room for a language that runs on the BEAM and also compiles to JS. Gleam looks great, and it's one of the up and coming languages that I'm rooting for. In addition to having a Javascript compile target, it's statically typed which is a prerequisite for me when it comes to productivity and correctness.
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
[3] https://grain-lang.org/docs/
[4] https://blog.cloudflare.com/introducing-d1/
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.
I actually find it sad that this passes as "impressive" these days
Agree. Back in he day, people were discussing how to put 10k connections into a single core FTP server.
I mean, this is on a single core, not a cluster.
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.
I find that sort of reasoning rather hollow.
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
I don't have objective stats, but I'd bet a substantial part of my income that none of these things even come close to 1% of the resource usage.
Good hashing algorithms can be pretty cpu intensive.
You're talking about the algorithms for TLS? Or hashing as in hashing a lot of things in your application?
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
No, I'm talking about password hashing. Stuff like PBKDF2
Feels like we're grasping at straws, specially when you group that with Unicode and i18n.
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.
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.
> 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.
When different architectural patterns are being compared, saying one is "faster" is almost meaningless.
These comparisons are generally pointless for a variety of reasons. BUT, Angular's dev experience is garbage, and no amount of hot take analysis will convince me otherwise.
An honest questions: How much have you worked with Angular? I have worked with it since the first release and what I see that it is steadily (albeit sometimes slowly) going into the right direction. Today the dev UX is great and differs nothing from that of using CRA for example. (If we are talking about tooling)
i think it's when you try to build something complex with angular that you can see advantages come to fruition. the opinionated structure can be quite an advantage when you're working with bigger teams/projects, as it can keep code more consistent/familiar/predictable, so when revisiting a project a few months later, you generally know where to find things quickly
Angular is boss. I love having a powerful opinionated framework that has business logic separated from ui so well. Long live Angular.
I don’t understand the point of takes like this. The sites are all on different hardware in different data centers in different locations performing different tasks. Even the frameworks compared aren’t comparable. Angular should be compared to React. Not a client+server hybrid framework that utilizes React for UI and mainly exists to simplify tooling and code-splitting. Even if this comparison were relevant, the idea that you should choose a technology based on the minor variations in perception of performance of one person in one location is absurd. This is coming from someone who has had performance issues in Next.js and Angular. Both of which had little to do with Next.js and Angular.
One of the main benefits of next.js and similar tech is that you can run a decent sized site from a 20$ cloud account.
You can run a massive PHP application on a $5 VPS without many issues at all...
You can also run a PHP app on an old school web host. In comparison to the demands of modern sites it is not really an option.
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
> 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.
> - 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.
> 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. [...] And in general Angular seems much easier to learn. If you spend 20 hours watching the Udemy course then you pretty much know it
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 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.
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.
Doesn't learning the Angular structure require learning? If that's the metric and you have to learn good structure for both frameworks, I'm not seeing the advantage. In fact, Angular's rigidity is only an advantage if the developer finds that particular structure comfortable. And the reality is that the vast majority of developers don't find Angular comfortable to work with.
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.
My experience is very similar to yours, and I concur with your conclusion. After 5 years of React, I joined a new organisation as engineering lead, and the team had embraced Angular before I joined.
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.
This is my sentiment as well. Although trying convincing people to give it a genuine try is difficult.
I would have to agree with this sentiment. I think one of the best things about hooks in general is that it put to rest all the third party state management libraries. At least now you can just agree with most people and move forward with hook state.
That being said, I think the ergonomics in React development (JSX) are SOO much better than Angular that I still prefer it.
JSX is the best thing about React, and the Angular templating is worst thing about Angular, so I can certainly empathise with that being the tipping point.
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.
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.
Having stuff included does have advantages, but, in my opinion, some of those included things in Angular are really badly designed (I'm looking at you, Forms)
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)
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.
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.
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.
I love RxJS and the testing story is not bad, but it does manage to find ways to be buggy when I encounter it.
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.
Both RxJS and XState have some really seductive tooling and promises. It has been my personal experience (from 4+years ago for both libraries) that both will quickly swamp you in accidental complexity.
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.
That's really interesting.
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.
Yes, Angular 1 wasn't great and I haven't looked back
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
> 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.
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).
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.
Add OnPush + NgRx
Others have mentioned most of the big points, so gonna be a bit contrary and ay I like being able to actually write HTML/CSS and not JSX and whatever the current flavor of the month is for CSS in React is these days. I like marking up my HTML rather than writing JSX personally. I'm sure I'll have to embrace JSX as some point, but don't see it as the huge win that others seem to consider it when I have played with it.
> write HTML/CSS and not JSX
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.
It also shuts down an entry into the world of web development (and development in general). Sadly, I know some see this as a feature, not a bug, but I know a number of people who are great developers who started out doing HTML/CSS and learned programming (JavaScript and much much more) along the way. Some are in very high positions now at companies most of us in this industry are aware of. I'm not saying they wouldn't have found another way into the industry, but it would have been significantly more up front learning before they could start working professionally. I know that entry-level positions of that nature (mostly just HTML/CSS) are getting more and more rare, but to me that is very sad and limits the potential for some really great people to be part of our industry.
Yep, we like to pull up the ladder behind us.
I guess many people will be surprised by the results of https://github.com/krausest/js-framework-benchmark
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!
Here an example of my own website with SSR: https://stockevents.app/en
I simply use React's build in solutions[1] and a node.js server.
I dare say it's quite fast.
[1] https://reactjs.org/docs/react-dom-server.html
Agreed it's really fast. FWIW I think the main benefit you'd get from using NextJS (or similar) is that your header/navigation wouldn't be replaced on page navigations on your features/assets pages, so you wouldn't get the whole page flash. It'd just update the content part instead. Their docs are a good example of this: https://nextjs.org/docs/basic-features/pages - if you click links on the sidebar you'll see just the content update.
average time to interactive says 19.2s. that cannot be trusted at all
What you have is "statistics". mostly known for infamous quote. "There are lies, damned lies and statistics".
Angular could be the fastest framework in existence and that would still not be a good reason to use it.
This comment has the same energy as people who still use a dollar sign when spelling "Microsoft".
Except we all know Microsoft has been bad for decades and we all know Microsoft never actually got better.
I have no idea why I would dislike angular beyond some mild personal preference.
Why is speed not a good reason to use a framework?
I find the dev experience of Angular very frustrating, and many things seem overly complicated or not very well designed, in my opinion. That's why I would choose something else (anything, really)
However, if it was noticeably faster than alternatives then I would just deal with those frustrations, personally. User experience (including speed) trumps developer experience.
DX in Angular is great. With Nx is even better.
Prove me wrong with the examples, please.
I'd be more interested in why you think DX in Angular is great (especially with Nx).
If my opponent will name some struggles - I will try to help, will try to show the way how to resolve them.
As an Angular developer, I find these DX issues mildly annoying:
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.
HMR is here since v12, stable since v13.
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.