I am a big fan of Angular (2+). While I can't exactly say I now enjoy front-end development 20 years into it, I can say it is a much more enjoyable experience than it used to be.
I'm coming at it from a strong OOP background, and while people call it "opinionated" I have no problem with that. My current project is Angular v12 and C# .Net 5 for APIs and it all just works, C# developers who don't have experience with SPAs can read the code and see at a glance what is going on. "We can inject the UserService in the constructor here and get the current ID", etc.
I have worked with React but it seems to come from the other direction, JS-first, and is constantly changing how you should approach things, from hooks to routing.
I've worked on more React projects than Angular, and am very competent in both.
I'll take an "opinionated" framework any day of the week over what I see in the React ecosystem. Every React project that I've walked into has looked completely different from each other.
One common complaint about Angular is that it is "bloated." Yet every React project I've seen pulls in a million 3rd party libraries to solve the most trivial problems, and I've seen very few React apps that implement code splitting of features. So you have massive bundles being pulled into the client and the majority of code contained in those bundles are not going to be needed for a given user session because no user is going to use all features when they login.
Also, JSX reminds me of PHP code in the 90s. While you can separate your markup from your view logic and styles with discipline, most React devs don't. Most components I've seen are a large hodgepodge of markup, styles and logic.
Give me Angular any day of the week.
- Give me view encapsulation so I can write straight-up SASS and have it scoped to a component.
- Give me a template language to keep my view logic separate from my markup.
- Give me dependency injection.
- Give me code splitting / bundles right out of the box. Let me configure my routing without having to use components.
- Give me a sane, reactive forms module out of the box. Form controls are the standard way of interacting with the end-user and so the typical front-end application will work heavily with forms in some shape or form (no pun intended). I have yet to find a decent forms solution for React.
- Components should just be views. I like a framework that encourages developers to separate their concerns and get integration code, routing config, state management and the like into a separate layer of the app (and no, react hooks are not a good solution for this. They introduce tight coupling between the view and other app layers - I use them a lot, but they're no substitute for dependency injection).
- Give me pipes. Formatting and manipulating string data is a very typical problem that views need to solve. In React apps you'll typically see low-level JavaScript code doing this type of stuff inside of markup.
> Every React project that I've walked into has looked completely different from each other.
Which, on its own, doesn't necessarily bug me as much as the attitude I've run in to. I've come in to a handful of React projects in the past 3 years, and each team says that "their" way is the "correct" way, and whatever I was doing elsewhere is just dumb/wrong/outdated/slow/bad/untestable, etc.
"Oh, we don't do class-based here - that's so outdated!".
"But... you have 85 class-based components already, and 4 functional ones..."
"We're converting everything - class-based components are so hard to test"
"How do you know? You don't have any tests around them at all"
"Because it's so hard to test"
"But you have no tests around the 4 functional ones -"
"It's going to be easier once we convert all the legacy class -based components".
I've done some Angular (versions 1-5) but mostly Vue these days. Angular was getting overbearing for me (especially on projects where I'm the only/primary js person), but I understand the appeal. A couple of colleagues have done Angular at big companies, and the structure (and extra layers) mapped very well to their existing way of thinking. I've shown one of those colleagues some standard Vue stuff - he 'gets' it, but thinks it's way too loose.
> Also, JSX reminds me of PHP code in the 90s. While you can separate your markup from your view logic and styles with discipline, most React devs don't. Most components I've seen are a large hodgepodge of markup, styles and logic.
This is no doubt the biggest problem of React that no one talks about; “where do I put my business logic?”
The most common solution to this is to sprinkle it all over some sort of pseudo-controller components. Even worse when it’s all hook-spaghetti.
At least Angular recognises that not everything is components.
Uh, the hooks in the new versions literally solved this problem. And is backward compatible although it's somewhat painful if you work with both the class based and hook based base code base at the same time.
But if you use an current opinionated package. Next.js + pure hooks based+ typescript, beats everything on the market by miles. It's not even close.
What is your definition of business logic? Business logic as I know it doesn't belong in the front-end at all. Your business logic should be taken care of on the back-end and your front-end application responsible for displaying the end-result.
Yes the answer to the complaints above is Next.js + hooks + Typescript. Absolutely fine if that isn't your cup of tea, but let's not kid ourselves that a solution isn't already available.
But the hooks literally solved the logic problem. I know what the complain means as I have worked on old code base. But I don't see anything better than handling cross cutting logic better than hooks. A pure hook based code base is not just the best in browser, but also better any other UI technologies in other platforms I have ever seen. This is my personal opinion. Could you show me a better way?
Problem is that you end up spending so much time working against the framework when the framework is too opinionated.
I prefer a framework that tries to get out of the way. It just gives you what is needed to structure your code, so that everybody can find their way around the codebase, and then lets you get on about the actual concrete implementation that you need. Angular instead has sooo many opinions about how you should do everything. So much boilerplate, so much runtime, and so much accidental complexity everywhere.
It doesn't have opinions about things it doesn't have to. It's fast and minimal and lends itself to a clear common code structure. This is what a framework should do.
There seems to be a lot of confusion about what a framework is.
- React is not a framework /Angular is a framework
- JQuery is not a framework / Ruby on Rails is a framework
The fundamental difference between a framework and a library is that a library is passive. It provides reusable code that sits there waiting for the consuming application to call into it.
A framework takes the opposite approach. Frameworks apply the "Hollywood Principle" (don't call us, we'll call you). A framework is a skeleton application already developed for you, having made fundamental design and architectural decisions. It does not exist to get out of the way but to take control and do the driving for you. The idea is that you provide the unique, domain-specific behaviours that are specific to your application and delegate as much as possible of everything else to the framework.
This is a feature, not a bug. Frameworks exist to give you as much scaffolding, bootstrapping, internal APIs and up-front design decisions as possible.
That appeals to developers because it speeds up development time. But it trips a lot of developers up when they don't understand the internals and design decisions of the framework they are using. If you approach a framework with design paradigms in mind that do not align with the framework's underlying decisions and architecture, then you will feel like the framework is getting in your way.
The relationship between a framework and an application built with a framework is very much a marriage. The choice of which framework to use, and whether to use a framework in the first place, is a crucial architectural design decision that must be made carefully. If you make the wrong decision then you would be right to rip out your domain specific code and start over.
My point is there is no such thing as a framework that "stays out of the way." That would be a library.
There is nothing wrong with not using a framework and using libraries instead. My main problem with React and the React ecosystem is that this fundamental distinction between libraries and frameworks is not recongized by React developers and the community. They treat React like a framework when it isn't, complain about Angular being "too opinionated" not recognizing what those opinions have to offer, and then proceed to pull in a million different libraries thinking they're working within a framework while doing the exact opposite and putting next no thought into fundamental front-end application architecture.
I come from the era of Java OOP frameworks like Spring MVC and front-end frameworks like Ruby on Rails. That's why Angular appeals to me - because I understand what a framework is, what to expect from a framework, how I would go about designing my own and what to look for when choosing one.
If you don't then any framework will feel oppressive. The best thing you can do at that experience level is to learn as much about system design as possible, read a book like Building Application Frameworks (Fayad, Schmidt & Johnson), and think about how your ideal React framework (if one existed) would look. Then you will understand the different opinions of different frameworks and will have well informed and defined opinions of your own.
When you write a React component, there are all kinds of ways where React calls you, e.g. the hook mechanisms. And that can be considered a framework in my opinion.
It also tells you how you should write your components, which is another sign that it's a framework and not just a library.
I may not have been clear enough in my opening sentence discussing the differences though I did go into great detail following it and so I don't think my comment was unclear.
By the logic you just demonstrated, if you call a function that accepts a call-back as a parameter, when it evaluates your callback you are consuming a framework. Or any React component that receives a callback as a prop would suddenly be a framework. Promise libraries would be "frameworks."
Just because a framework executes your code primarily via the application of the Hollywood Principle, and operates primarily through the application of the HP, doesn't mean that any application of the hollywood principle automatically indicates that you are working with a framework.
When getting into discussion about definitions, there is a lot of room for nuance, opinion and degrees. The key part of my definition that you glossed over was [paraphrasing myself]: "skeleton application that provides as much scaffolding, bootstrapping, internal APIs and design decisions as possible leaving you free to focus only on the pieces of your application that are specific to your domain problem."
Yes, you are right it's very nuanced and also a bit subjective. So it doesn't actually make much sense to argue about it, much less here. Anyway, thanks for your comments, they are insightful.
The problem with DSLs -- compared to just writing JavaScript/TypeScript -- is the IDE experience is incredible. It takes a formidable team to create both the software for parsing the DSL, and the language service to provide intellisense and ordinary language-feature goodies. At that point, why not just use a conventional programming language? Formatting a string is an extremely normative thing to do; it doesn't seem to necessitate the DSL plus all the tooling that elevates the developer experience of using the DSL.
> I'm coming at it from a strong OOP background, and while people call it "opinionated" I have no problem with that.
I love opinionated frameworks, if those opinions make sense. This is the same reason I prefer maven to gradle; I like knowing how a project is set up sight-unseen. It makes onboarding so much easier.
Too much of the UI world is a random hodgepodge of cobbled-together libraries, utilities, and frameworks. There's no "right" way to do anything. There's rarely even a "right" way to do something in a given framework.
I work in technical due diligence, mostly of mid stage companies getting bought by private equity, so typically revenue of a $5-100 million. (Which, by the way, is the most common exit for tech companies now by far.) Perhaps surprisingly to some, I see much more Angular than React, 3 to 4 times as much. I've been doing this job for 3 years now, and it has been very interesting to see the gap between what you read in the tech online blogosphere, etc, and what most companies that are quietly making lots of money do. Devs at small startups and big tech giants both write and talk about what they are doing, folks in the middle not so much. From what I see, it seems most mid-stage companies doing unglamorous enterprise software in Java or C# with regular dev teams of 5-20 people prefer NG. Obviously a biased sample, but perhaps interesting to some folks.
This could also be a selection bias based on age of company. A company in that revenue range is probably 3-5+ years old. Angular was much more popular back then, and even though it changed drastically with 2.0 there was a much clearer upgrade path than a full rewrite in something like React.
> even though it changed drastically with 2.0 there was a much clearer upgrade path than a full rewrite in something like React.
Even though Angular2 was released in 2016, there wasn't really an easy-to-follow upgrade path until mid 2018. (ngMigration-Assistant wasn't even released until summer 2018, and people didn't really start releasing in-depth tutorials until around this time.[1])
Since React was released in 2013, it was already pretty popular by 2015 when Angular2 was announced. So a ton of startups migrated from Angular to React in between 2016 and 2019, when it wasn't clear there would ever be a good upgrade path, or that Angular2 would actually develop into a good product.
Now obviously in retrospect there is now a very good upgrade path, and Angular has actually become quite good, but it wasn't at all clear that either of these things would happen for several years. But yeah, I'm sure there is a time effect here, but I think there might also be something more nuanced going on. Like no doubt most of these startups that are selling are 5+ years old, but that still puts us well into the time when React was popular.
That sounds reasonable, but the comparison becomes an issue if there are vastly more people using React for small hobby projects that aren't meant to be businesses, or for things that aren't even web apps.
We are getting into nerdy arguments. React is by far a framework, as every library that you use will be highly influenced by its constructs and rendering engine, be it React Router, Redux, or others from the Hooks ecosystem. Many say it is just a library, but in practice, when trying to bring JS vanilla libraries, there's always that edge case where it conflicts with the virtual DOM.
It's definitely selection bias, influenced by stage, size, and age. My point though is that so is the wider perception that everyone uses React - that's a selection a bias for those who make a lot of noise online, and as I've learnt doing this work, that is actually a much smaller section of the industry than one might think. There are tons and tons of very profitable mid-stage business-to-business software companies out there building stuff in C# and Java, and most of them need some kind of SPA now.
I guess my main point is that I've learnt that there are a lot more companies who find NG a good fit than folks think, but the same factors that make them prefer NG also mean they don't make a lot of noise online. These are firms of principally senior devs in their 30's to 50's, just building shit and taking care of business. I'm not saying they are better, or that NG is better, just that they are out there.
For me as a Java backend dev, Angular feels extremely welcoming. I can immediately turn my fantasies into reality with it. Kind of feels like the angular developers were all spring devs once.
React always felt appalling and alien do me -and I wrote a whole react native app.
Same here c# and angular i get the same feeling its very well documented and i always find a way, i never could get along with vue/react it just seems foreign to me no offense :)
FWIW AngularJS written in post-1.5 style (with components instead of controllers) is basically the same as Angular2, and the port from AngularJS straight to Angular13 is pretty straightforward and rote.
The choice between OOP React and Angular boils down to this, as you said, people prefer the OOP nature as they come from Java, C#, some prefer even more the templating system of Angular as that reminds them of JSP, Thymeleaf and other systems that were used in enterprise systems in the past.
Though, the concept of React Hooks changes everything. Functional components coupled with JSX and styledcomponents give you superior composability and encapsulation, imho. When I'm programming in Angular, I notice the familiary, it's like I'm using Spring but on the frontend, while in principle I like the rule of least power, I can say that the declarative nature of React is game changing. Look at the ecosystems that are being developed now with Hooks, like Tanstack, react-hook-form, etc. People are literally creating their own SwiftUIs and Jetcomposers in JavaScript (TypeScript).
I abandoned angular (around version 5) because even a simple application was unusually large in size, and I did not want to have to deal with the disproportionate time investment of trying to squeeze out performance / optimization / reduce bundle sizes.
Have these kinds of issues been improved since? At the time it, at best, seemed like a decent fit to build things like backoffice / admin related tools.
On a related note, if you were building a web project in 2021, given the multitude of JS framework options available, which ecosystem would be your go-to pick in most cases that gives you:
- Performance
- Tree-shaking/AOT compilation/chunking/minification/cache-busting other optimization magic out-of-the-box.
- Good debugging tools
- A seamless way to drop-in to an existing server-side web framework without wanting to take over routing and other such things
But it's best to wait until it's out of beta. The value proposition here is that it's performant, bundles are exceptionally small since it's more a compiler than a framework and you need less code than in say, React, to achieve the same result.
Now that it has TypeScript support the developer experience is decent as well.
> I abandoned angular (around version 5) because even a simple application was unusually large in size, and I did not want to have to deal with the disproportionate time investment of trying to squeeze out performance / optimization / reduce bundle sizes.
What do you consider "unusually large in size?".
I am lead on a "large" Angular code-base, which compiles to less than 5 MB in production mode using lazy-loaded modules.
5 MB is often smaller than a picture of a cat people post online, and can be cached.
I think front-end developers often overthink "performance" and "bandwidth". Sure, it's great to keep things as small and concise as possible, but at the end of the day it gets a lot more nuanced.
I'm much more concerned about the C# code and the SQL than I am about anything Angular is doing in JS land.
Default angular builds are large compared to other frameworks even when you consider all the extra stuff that gets bundled with angular.
5MB is large for a single bundle, I'd say if you are using lazy loaded modules 2MB for a single module is large.
Front-end performance varies in importance based on your context. In e-commerce performance is tied to conversion so it's very important. If you're a government contractor building CRUD apps, it's not as important.
people seem to always talk about this as if it's about the time to download.
Open the profiler and see how long it takes for your computer to parse and execute those 5 megs of JS. especially if its not crafted in the right way for V8 or whatever to ignore the contents.
Also all the garbage your code might run on first run to get started. "Garbage" here being used as neutrally as possible (I like Python and it has a similar "pay init costs up the wazoo for anything" feelings)
Oh just parse that 5MB of JS to 20MB of used memory for the code (after spiking even higher), then actually run it and oh my it allocates another 20MB for god knows what, and we're gonna need like 5 representations or outright copies of every "component" on the page sitting around in memory somewhere, you know, in the name of being "performant" and having good "Developer Experience" so now it's nearing 150MB of memory total. Oh and we need instant updates from the server (narrator: no, they didn't) so let's have some web sockets eat a bit more memory and a few processor cycles (so, battery) here and there even when the user's not on the page. Oh and everything needs to be immutable because it's impossible to write good code otherwise, so of course we imported libraries for that (how do you think we got to 5MB, if not importing shitloads of libraries of dubious value? LOL it's not like our "app" actually does very much) and since Javascript's not designed for it we're gonna really give that garbage collector a workout for no good reason.
Great, now that that's sorted out: let's download a few MB of JSON, then parse that into Javascript data structure (more memory spikes), copy and slightly modify that about three times in different places, then use it to create a few representations of a "component" one of which will be a set of actual entries in the DOM. And we'll keep most of that around after we're done.
A reasonable rule of thumb is that on a low-end Android phone 100KB of JS takes about 1 second to download and parse. A 5MB bundle would take 50s or so to run. You probably don’t notice this if you’re only testing on fast PCs/macs, or modern iOS devices.
I deal with very large-scale Angular systems that handle this sort of stuff day in, day out ... can you give me an example of a 5 MB Angular payload that takes 50 seconds to execute?
That JS and image are different things entirely. It costs the browser more to parse JS than the image. These are not 1:1 comparisons, as you can see in this post
> A seamless way to drop-in to an existing server-side web framework without wanting to take over routing and other such things
These days, I would first check whether I can get away with just using web components, typically with lit for convenience. The reason being that web components are a browser standard, which means that if you do it right, you get an opportunity to escape the hamster wheel of keeping up with new frameworks.
That web components are often adequate to do the job is evidenced by Adobe releasing their web version of Photoshop based on web components and lit.
For internal tools and small apps, I stopped using React and went with Svelte. Not as mature, but what a breath of fresh air.
Otherwise, React for larger projects though I'm trying SvelteKit for a larger project right now, and it's pretty amazing. It's a lot less boilerplate than React, and god that feels good.
If your target userbase has a stable, reasonably good internet connection, bundle size doesn't matter. Perhaps it's a dirty secret of front end development these days, but in many use cases, it's a micro-optimization. Now if you're selling goods on Amazon, and billions of page hits and 50ms slower page load time means X% fewer goods sold, you've made a case: one developer spending time on performance optimization is saving your business millions. Most engineers aren't working at that scale.
React via NextJS is becoming a popular option. It ticks all of your boxes. NextJS has an opinioned way of approaching the backend but also supports just rolling your own and exporting the frontend as a fully static site if wanted.
I have been a developer for 20 (e: I've just realised it's actually just over 25 years..) or so years now. I've attempted to "learn" Angular multiple times. I just can't do it. I get mental fatigue within an hour of picking up Angular CLI, or even just watching/reading tutorials. It speaks a foreign language to me.
And I've got years of React, Vue, vanilla-JS as well as Java, Kotlin, Scala, PHP, Smalltalk, Go, Rust, .NET (and the various flavours that comes in) under my belt. If I put some effort into it I could probably regurgiate some Cobol, RTF, and other now-forgotten stuff, too.
Are you really talking about angular or is it more about rxjs/observables ?
Because the former is really hard to imagine with what you claim to be proficient in.
The reactive stuff from rxjs is another story though, few people I know really worked with any of the reactive libraries before and mostly everyone I know struggled with the concepts at first, no matter which language they were using them in
I'm absolutely fine with rx* and observables. I was an early (but very minimal) contributor to many of the rx* family of libraries, even. I basically adore the pattern.
But I didn't even get that far with it. I don't think I could even accurately describe what an angular component is.
Angular CLI is definitely the biggest cause of my confusions.
This really isn't a fair statement to make because Angular without RxJS and Observables is nothing. The core http library is based on observables. If you forego observables, you're using very little of what makes Angular useful.
IMO using Observables instead of Promises for most API-type HTTP calls causes more harm than good. i.e. if you pipe the observable into an async pipe in more than one place, it does more than one HTTP call. I find in Angular code having my services that do HTTP calls return Promises via .toPromise() is much cleaner, and enables async/await and try/catch. Also with Observables, you have to remember to unsubscribe if you manually subscribe to the call, implement OnDestroy, etc. No need to worry about that with Promises.
Observables are great for other things though, like debouncing input, timers, @Outputs, etc. where there might be more than one result produced. They're awkward compared to Promises for single-result futures.
Yeah, Angular uses RX Observables so terribly and its HTTP module in particular for using Observables as "heavy weight Promises" does so much injustice for the entire ecosystem. People using Angular treat Observable subscribe() like it is just a bad non-conforming Promise then() in nearly every project including examples baked into Angular's own awful documentation and many "Production" libraries out there. Those bad habits are just so entirely persistent across the ecosystem that you just about have to assume every dependency is a memory leak (including Angular team's own CDK and Material libraries!).
I've made PRs to things to push them to use .toPromise() at least when they want Promises.
I was angry for days when I finally discovered where they buried AsyncPipe in the documentation (letting the template language automatically manage subscribe/unsubscribe rather than all bad habits of every component for themself and all the boiler plate for OnDestroy). Something like that should have been the default in the template binding language, not hidden away in a closet in the basement of the documentation. But they buried it because they never really committed to RxJS in the first place (such a huge dependency to half ass) and would have to teach things like shareReplay and hot versus cold Observables if they were to recommend AsyncPipe more strongly and/or make it the default it deserves to be (if they were actually committed to RxJS/Observables).
(React's been on a multi-year journey to towards Suspense/Concurrency and waiting for some updates together before scheduling them/Scheduling some DOM updates on requestAnimationFrame versus others more immediately that Angular could have done it so easily with a couple RxJS operators at template binding time if it had been intelligently designed with good defaults! It's amazing how hard they have instead worked to sabotage everything about the RxJS ecosystem in Angular.)
There's too many leaky boat escape hatches from RxJS and the few core libraries that make use of RxJS make use of it so poorly as either heavy-weight Promises or heavy-weight Node Classic Event Emitters (and bleeding Subjects/BehaviorSubjects everywhere across API boundaries which are their own violations of RxJS best practices). As an RxJS fan going into Angular it just makes me weep.
Thats true to a degree, but the distinction makes sense to me because angular is not the only project using reactive concepts.
RxJS is just one of the implementations [1] and people that haven't grokked it would struggle with other project utilizing it as well - even if its a React frontend, Go backend etc.
(and as others have pointed out: angular should not be considered a poster-child of reactive programming. they made it work somehow, but its really easy to get memory leaks even if you're just copy-pasting code from the official angular docs)
One of my projects for work is RxJava and I’ll never touch anything Rx again. I don’t see any benefit it brings outside of making your project and control flow convoluted.
That's unfortunate because reactive programming shines when you have continuous data flows and want to run pipelines against them; whether that's clicks, websocket events, queue items, etc.
Java streams don’t infest your project. They also don’t throw away the error system of the language. They are also leagues more maintainable than a reactive project.
I feel the same way. I just get stuck on trying to understand what actual problem Angular is trying to solve. Like, ok, it's a framework but... a framework for what? Webapps? Javascript is a "framework" for webapps, too.
When I first saw jQuery, I could understand the appeal, but Angular just seems like a lot of extra code for the sake of having extra code. (Like Spring...)
Angular is a framework for single-page applications, based on components with templates. If a property of a component changes, the rendering is automatically updated by the framework. This is supposed to free you from direct DOM manipulation and let you focus on the business logic.
Angular is somewhat similar to React and other SPA-frameworks, but Angular takes more of a kitchen-sink approach and provide its own dependency injection framework, URL routing, HTTP client abstractions and so on.
In comparison jQuery is just a library, it doesn't really care how you structure your application. jQuery makes it a lot easier to manipulate the DOM, but something like Angular is supposed to free you from having to manually touch the DOM in the first place.
And JavaScript is a programming language, but you probably already know that.
Yeah you can say that - the browser environment with DOM and other Wep API's is a framework for client-side apps. Single-page application frameworks like Angular, React etc. are frameworks on top of this, which provide higer-level abstractions and tools. Whether you need these higher level abstractions depend on your use case.
If you have lots of in-page DOM mutation in response to user interaction or data from the server, a SPA framework might simplify things. For a site like HN with very little in-page DOM mutation it probably isn't worth the complexity.
So you could certainly write your own component framework, state propagator, router, module framework, build engine, and more. But you'll probably find that, at the end of it all, you have a SPA framework you can share with us. If you're just doing simple web pages maybe you don't need all that, but some types of applications do.
Not OP but feel the same way as OP... I can use Angular just fine, it just feels like I'm working around the Angular part trying to get down to the actual stuff I'm trying to program. Whenever I do use it, I spend most of the time thinking, "I could do this a lot faster in Javascript without Angular adding extra steps along the way..."
Honestly I'm not sure if there even is a big reason.
The terminology doesn't feel right - I feel like I need to constantly remind myself what some of the terms mean compared to what I am used to, which I find occupies a tremendous amount of my cognitive capacity.
"The tutorials are shit" doesn't help. They really suffer from the problem of the author expects the reader(s) to know what it is they are being taught ahead of time. "Tutorial 1: how to make a component. Step 1: Run `ng component <name>`. Now you have a component." type deal. Now I'm left to my own devices to find out what a component really is, etc.
Another part is that it just isn't very exciting. I was/am more excited when using react or vue.
I've been maintaining angular apps (albeit lightly) for nearly 2 years at my current role, but even here react is being introduced to replace it.
I tried to pick it up 5 years ago or so and my main barrier was that any tutorial, even the official Google ones, was long obsolete and their examples would fail out the gate ... but I guess that's to be expected of frameworks in tech.
...wait! are you guys still using this in 2021 (almost 2022)? :) Jokes aside, I hear less and less people (friends from the dev scene) using Angular these days. Wonder if it's just what happens to stuff (especially, software-related) after it matures... it gets out of sight, does the job, but nobody talks about it anymore.
I think that's a pretty good point about maturity. If it's just working people use it without talking much. Similar to Ruby on Rails (RoR) for example, although Angular still changes a lot more than Rails these days.
Another point going into the same direction especially for Angular: It's a very important framework for big enterprises in industries like banking & insurance and probably more I'm not aware of. There are large networks of developers organized in isolated or self-hosted GitHub Enterprise or GitLab instances of enterprises working with Angular, but most of them are not able to talk publicly about it.
I'm sure there are hidden projects based on React, Vue or Svelte too, but I have the feeling the biggest enterprises rely a lot on Angular but don't talk about it, which skews the way people perceive the overall framework landscape.
As always, the standard info: $big_corp is absolutely still using Angular for everything, even for greenfield development. However, their developers often aren’t as outspoken and the software is often for internal use only.
Don’t underestimate the corporate landscape. It’s super conservative.
And then, Angular isn’t really something to get passionate about, in my opinion.
:) who said anything about react? react has been aggressively advertised for so long that it's the "default" in devs' minds when talking about JS framweorks/libs. There's lots of other frameworks and tools these days to choose from (if not dictated by corporate policies), the World is a very big place. Anyway, though, I quit developing angular since v6, good to see solid progress.
I feel like Angular is the "dark matter" developers choice. It gets picked to do shit now, not tomorrow. Therefore every comment on these updates for Angular are a repetition of "Isn't Angular dead yet?", the hype for a new Angular release is not the same as for a React one, because the developers using it use it to do boring but helpful CRUD applications.
I used Angular1 for years. Then Angular2 for a while before being assigned to a React project. Then elm for 3 years, and now back to React. So really now idea how ng looks today.
But one thing I really liked about ng was directives. It allowed you to compose and reuse stuff, and attach multiple behaviors to the same node that could cooperate. Of course it could end up being hard to grok sometimes. But for instance having various input components, and then being able to attach various validation directives to those seamlessly in the html was very nice. Almost like an entity-component-system in game programming.
React does something similar now with hooks (didn't exist when I used react the first time). Allowing you to compose stuff more easily compared to when class-based. But still have to write the glue code between all hooks in a component, though that makes it more visible what's going on.
I personally hate angular1 architecture(I did not tried the rest), some of my reasons are
1 instead of pure code you use markup like ng-repeat , ng-if , this causes weird bugs and weird errors and not clear scoping issue. I prefer the old react architecture(not sure if modern react is still sane) where instead of ng-repat item in items you could have pure JS code like items.foreach(renderItem(,,,)).
It is a personal opinion but I prefer to see my code to run when I debug rather that my markup getting "compiled" under the hood and not seeing the actual code.
2 I dislike the error mesages, the stack traces are useless
3 the performance is terrible, it is super easy as a SPA grows to get too much updates triggering , this might have been solved with new versions and maybe a more component oriented architecture but still the way data binding and update cycles works is pure performance insanity.
4 sometimes shit does not work, maybe you have a typo and you get no warning, maybe there is some scope conflict, maybe you forgot to add some attribute, maybe the data-binding fails and you need to always apply "that workaround" but I wasted a lot of time on problems like "why is this element not updating", at least the devs could add some extra checks and warn when something is not right, I manage to write some code and add this extra checks but is not that well tested.
This is personal opinion, angularjs is not targeted for developers like me, I worked with Qt, GTK, Windows Forms and WPF, I think i done a bit of MFC, Flex4, React , Swing and angular is the worst one for my personal taste. I thin Flex4, Qt and WPF are better architected and more powerfull, you can do simple and modareate things fast but you still have flexibility to do everything. With angular you can do Hello World fast, after that it is a pain, and a giant pain when you need to maintain a fea years old code base made by a newb angular dev team.
It was also their meanest trick. We used angular 1.x and when that was sunsetted, it took so much effort to get everyone to understand that v2 was a completely different framework, and that it might not even be able to do what we needed it to do.
It couldn’t, and we went with React instead. We were able to replace the whole UI layer, and aside from some 3rd-party components we had to swap out (like data grids), no one could tell the difference.
If the architects of Anuglar >=2 are the same people then i do not have high hopes, they probably fixed some of the issues but for me personally the architecture is broken.
Let me know if they brought some competent(for this task) developer for angular2 and I might have a bit of hope but I would never chose angular if I ever had a chance to start something new.
Sounds like you might like Vue. It has directives for HTML which I like better than using JSX and it has a composition style now that I like better than React's hooks.
I'd use elm again if given the opportunity, certainly. Enjoyed it very much. But I wouldn't evangelize my current company to switch, exactly. While it's not hard to learn elm, everyone here already knows react. And while elm leads to very robust code with little bugs and no runtime errors, it's at a cost of implementation speed, not everything is straight forward to write the elm way.
Yes, but in React for instance, you could always do something "dirty" if you want. Like adding a class to some random parent element when a modal is showing from within deep down in the component tree, and remove on unmount, and also trigger a google analytics event.
In elm, the GA event is a side effect, so it has to come from your update function, using a port out to JS. So it has to be triggered by the same conditions showing your modal. Sometimes that leads to that logic being duplicated.
And the modal either the same to trigger some js code to set the class, or set a value on your main model somewhere and edit the render function of that specific element to take the new classname into account (so have to modify some other part of the code).
Of course, it leads to maintainable code with little surprises. But at a cost of a stricter way to do it.
It's like either use Angular or end up building an Angular when you choose a smaller/lightweight framework. At least so many times it's true in my case.
Angular gives so much out of the box without making your double think it, well it's an opinionated toolset for sure.
However, any other frontend framework I've used and know, makes you to build all those stuff form scratch or get them by adding more and more dependencies to your project.
Great release and can't wait to try the performance optimization and build enhancements.
Looking forward to see esbuild gets more and more involved in their toolchain.
This is exactly my experience. I also recently heard a story (from a close friend) of a rewrite to React where a good few months were spent on questions like which routing (or whatever) library to use, all things provided by Angular out of the box.
JSX mixing presentation and business logic also looks weird for someone who lived at a time when not doing MVC in PHP was a blasphemy and would not get you a respectable job.
Admittedly AngularJS was horrible but nowadays Angular offers me everything I need while I watch other people moving to Nextjs or whatever latest buzz frameworks for features Angular provides (like server side rendering).
It's life. It's one thing to call people amateurs from a sofa and an other to find yourself in 20 person team arguing about things.
The easy solution to arguments is having less things to argue about, similarly how Go solved formatting wars by an official format, Angular solves those fights by providing a default implementation.
It's not life, it's your typical bike-shedding. React is being used on much larger teams all the time without spending months on arguing whether react-router is the right choice. I don't think I have ever spent more than ten minutes on choosing which library concoction works best for a given project.
In less dysfunctional organizations you go with whatever the technical lead specified.
How is the angular internationalization and automated testing story? Last time I looked at it (v3 or v4, I think), it was still half baked, especially in comparison with AngularJS.
The i18n has apparently progressed (can't speak to it, though; we're still using ngx-translate, without which Angular life would have gone to Hard Mode) but the testing (and also debugging runtime errors) story is still the utter trash fire that it's always been.
"Unit" or "component" testing works, but there is tons of boilerplate required in real-world situations, which will often only become obvious after you try to run your tests, so it is tedious to write.
Protractor (the previous Angular-sanctioned E2E test framework) really died with AngularJS, so it's been a pretty unworkable and high-maintenance mess this whole time, and they only just now finally came to terms with this and killed it. (Also didn't replace it.)
P.S.:
From grievous and traumatic personal experience: Don't use Cypress. Use Playwright[1]. Cypress was great in 2017 of you were coming from Selenium/Protractor. But Playwright in 2021 is to Cypress what Cypress was to
Selenium in 2017.
The provided i18n library is really good, but it lacks tooling around it (like proper extraction of keys, meanings, descriptions, etc..).
Unit testing works flawlessly out of the box with Karma and live reloading, E2E needs a bit of setup, especially if you want to go with Cypress instead of Protractor.
For most use cases its ready to use and for everything else there will almost always be some articles on how to achieve it (i.e. E2E with Cypress).
It's pretty close to the way you'd work with C#/Java. If you were coming from that type of background, it's an easier transition.
A plus, and also a minus, of Angular is that it's pretty "self-contained". There's first party tools built-in, that are maintained by Angular. You also don't have to endlessly tweak Webpack which is also a plus.
That self-containment has also led to a less vibrant ecosystem in my opinion. There's more React "stuff" out there than for Angular.
Also, if you're the "mythz" I think you are, just want to say I'm a big fan of ServiceStack and you do great work on it.
Just wish I could work somewhere that uses it instead of primarily working with it on my personal projects. Given how the .NET community "works" though, I fear that might not happen. Conversation for another thread though. Kudos again.
> Angular is the EE of JS FX’s (inelegant and bloated), always surprised when some devs choose it over Vue, React or Svelte.
Cargo culting. There is absolutely no need for a IoC container with Javascript or any other dynamic language for the matter. It only ever made sense for compiled language in order to allow reconfiguration without recompilation.
I say that as someone who heavily used AngularJS in the past. Angular X always seemed to me like a project looking for a problem and not the other way around, trying to justify its existence with complexity and bloat.
We use Angular for our large realtime process control application in place of a lower-level UI (like Qt). Having all of the tools you mentioned above has given us an organized codebase with components that we've been able to successfully reuse across the application itself and across different products. Having to work around "the Angular way" can be annoying sometimes, but to be honest at the same time it's nice to not have to make decisions that Angular has already made for you (routing, modules, etc)
What happens when that singleton has dependencies? And they have dependencies? Not unrealistic once you have a config block that sets stuff like language direction ltr/rtl or API endpoint at runtime based on test/prod env.
Not saying that these are impossible, but at some point you either end up reinventing dependency injection, or you end up with all the problems that cause people to invent dependency injection.
> What happens when that singleton has dependencies? And they have dependencies?
Everyone exports/imports their deps the same way as everything else.
> Not unrealistic once you have a config block that sets stuff like language direction ltr/rtl or API endpoint at runtime based on test/prod env.
Having different environment config is standard feature in most JS FX Apps, if it changes at runtime it's maintained as App state with any changes typically propagated reactively.
I've yet to run into any issue that I needed an IOC for in a client JS App (despite always using them for backend C# Servers) but they're unnecessary in JS, our Angular templates are the only ones that use them, all other premier JS FX's happily get by without them.
I’m happy to see improvements in Angular (since I’m forced to work with it).
I still don’t like it though. Too much frameworky stuff. Too much magic. Too much stuff which is impossible to debug when things go wrong.
Fucking zones and overarchitecting everything with rxjs where it’s not needed and just adding complexity and errors not catchable by the Typescript type system, giving runtime-errors for what is compilation-errors in any other TS front-end framework.
Compile-time mangling your standard ES-promises and shoving them into ZoneAwarePromises which are not handled by the normal JS runtime’s event-loop, but instead tossed into Angulars own micro queue system, all written in incomprehensible, minified JS.
Oh and the terrible stack-traces and impossibility to debug anything once the framework decides to do things you never asked it (and it will!)
Man I really don’t like angular, but at least now it seems I can build it faster.
Sad to say, but for all the work put into this, I’d rather see this project die.
Is it just me or does Angular-CLI seem incredibly bloated and slow (including building)? Usually CLIs are lightning fast. I can't help but think if Angular-CLI were written in a compiled language it too would be lightning fast. I don't see any reason "building" JS files should take more than a few hundred milliseconds.
It's JIT compiled, which means that you have a startup cost. Java doesn't make for great CLIs, while Go does, and both have a reasonably close performance.
As far as I know it is JIT compiled to native code. But it is a rather complex process, where the execution is profiled which informs the JIT'er to re-optimize. This obviously have some overhead compared to executing AOT compiled code, but the overhead is independent from how long the code takes to execute. So if something is noticeably slow, it is not because of the JIT compilation overhead.
The persistent build cache is the feature that jumped out at me. It was also the only feature that had its performance impact quantified ("up to 68% improvement in build speed"). All the other improvements notably lacked any quantification, making me think they aren't worth much beyond improved architecture and hopefully greater improvements in the future
I've been doing Angular front end development exclusively since 1.1 days (now on 12) and last couple of years I get the feeling this might negatively affect my future job prospects. The framework does the job just fine, of course it has certain long standing issues (boilerplate, mandatory host component, non-strict forms, hierarchical injectors), but you eventually learn how to live with these or work around. All the jobs seem to default to React nowadays and require prior experience, limiting the employer choice. Now, if an experienced developer wanted to join the team I'm at, I'd vouch for them even if they never touched Angular, but am not sure if other companies share my sentiment.
It's funny how everyone says they like React because "it's easier to learn", but employers only want to hire people with multiple years of React experience. Whereas with Angular, you just watch the 20-hour video tutorial and then at the end of the week you know it. As someone who mostly uses Angular on the front end, it feels like I'm trapped in the movie Idiocracy.
I'm someone who was pretty embedded in the AngularJS/Angular ecosystem for 5 years before (I was a major contributor to the open source ecosystem & was an early pioneer/advocate of some of the views that became common), and the past 4 years I've almost exclusively been working on React apps. There are a lot of things that I see in the React ecosystem that have been huge mistakes - prevalence of react-router, the worst router I've ever worked with minus Ember's, form story being generally awful/full of awkward APIs in libraries, react-query & overuse of hooks/context over something sane like rxjs to encapsulate async logic, hooks themselves being full of magic and needing your code to be written in certain ways sometimes terribly to satisfy opaque flow instead of something more explicit, and the testing story being filled with too much mantra about being integration test heavy instead of breaking up code to be lighter on integration tests, resulting in too many component tests being too integrated and breaking all the time/flaky as a consequence of the lack of focus. I miss Angular when it comes to a lot of these aspects some days, but I hated the DX story in Angular (it definitely got worse from AngularJS to Angular).
I feel like the frontend world could do better than both React and Angular, but I don't feel like the other options available solves the union of problems, and I don't feel React is positioned to solve its problems, and Angular's problems seem limited by the personnel/leadership involved as well.
You really think Ember has the worst router? I'm the exact opposite. But maybe we used different versions of it I suppose, since it was overhauled a couple of times I think.
Agreed about rxjs though. Very underutilized outside of Angular unfortunately.
There are 34 hours of video. But if you skip the exercises, which imho are unnecessary, it's about 28 hours. And if you watch the remaining videos at 1.5x speed, that's like 17.5 hours. Even less if you skip some of the optional sections. So realistically probably a little over 20 hours if you're constantly pausing to take notes, but still not bad at all. And certainly not something that should take multiple years to learn, given that you should be more-or-less up to full speed within a few weeks of starting to actually build stuff after watching the course.
It doesn’t matter if the interviewers are sensible.
We don’t use Angular but we interview Ng devs anyway. If you’re smart enough to write maintainable apps in it you can learn e.g React or Vue quite quickly.
I've worked with angular 1.x never made it to the upgrade of v2 and moved to React. I couldn't grok the two way data binding which seems odd let alone all the decorators / services / controllers patterns. In the end I had no clue what I was doing.
I do like to read up on these kind of things, but why should I be excited about Angular 13? Except from yay faster because of esbuild (like any other frontend framework).
I come from a .NET background and I don't really like applying the same concepts I use in the backend to the frontend. I don't enjoy writing TS and would rather have much less boilerplate for doing simple stuff. Working with Angular has not been a satisfactory experience for me.
However! I do advocate the use of Angular for larger teams, since that structure can help a lot when you have many hands.
Angular kind of lost me in the rxjs move. I had been using it since v1 and used 2-7 but fell off the wagon around that point when I switched jobs and fell in love with Vue 2. I had used Vue 1 and enjoyed it but I only used it on a side project so I never fully learned it. For me, Vue felt much lighter than Angular and I could move faster. I really prefer the 1 .vue file for a page/component's HTML/(S)CSS/Typescript (though I know some people hate that).
I still have yet to move anything to Vue 3 since it's TS support is different than Vue 2 (I currently prefer class-based components and it doesn't appear like Vue 3 plays nice with that, or at least last I checked none of the libraries I use have been updated). Eventually I'll bite the bullet on Vue 3 but for now I'm extremely happy on 2.
Word of advice. Don't use Angular. Use React. I'm working on maintaining a large Angular app right now and you don't ever want your app to become this monstrosity that consumes my sanity.
I think OP is correct for reasonably large projects
I've worked on large multi-team Angular/React monorepos. The tooling was lacking for both but Angular feels like it actively gets in your way. React has a lot of churn and keeping your dependencies up to date but React itself is incredibly stable and gets out of your way
My educated guess is that this is clear because Facebook actively uses React, where most Google web properties don't use Angular. There's projects where Angular allows a team to define a SPA UI relatively quickly and pain free. But for large projects, I would continue to choose React. Also, CSS encapsulation with Angular is great until it isn't: it can be overridden only with ng-deep which is deprecated with no alternative
This is untrue. Angular has major version changes twice a year, migration is a time sink for our team to handle breaking changes in our growing codebase. Compare to React with far fewer major version updates, and fewer breaking changes (likely from their deprecation usage)
Your application is likely smaller or a simpler use-case
Congrats to the Angular team and its community. I think Angular is closer to Next.js than it is to React.js. I am excited to see all this progress on this front. What a time to be alive!
if u want me to elaborate on this I could say:
- boilerplate
- unsafe two way data binding
- not functional in any way
- the hell of the DI with services
- laggy and heavy
I'm coming at it from a strong OOP background, and while people call it "opinionated" I have no problem with that. My current project is Angular v12 and C# .Net 5 for APIs and it all just works, C# developers who don't have experience with SPAs can read the code and see at a glance what is going on. "We can inject the UserService in the constructor here and get the current ID", etc.
I have worked with React but it seems to come from the other direction, JS-first, and is constantly changing how you should approach things, from hooks to routing.