Angular 13
blog.angular.io
blog.angular.io
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'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.
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.
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.
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.
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.
For this reason I prefer Svelte these days. https://kit.svelte.dev/
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.
- 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.
It also tells you how you should write your components, which is another sign that it's a framework and not just a library.
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."
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 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.
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.
[1] E.g.: https://www.youtube.com/watch?v=qeQljCLpR04, https://www.upgradingangularjs.com/
By any metric, React is by far the most popular framework in 2021. It has even surpassed jQuery. [1][2]
[1] https://insights.stackoverflow.com/survey/2021#section-most-...
[2] https://trends.google.com/trends/explore?date=all&q=react,an...
https://www.npmtrends.com/@angular/core-vs-next
But yeah, I wasn't trying to reply that React isn't still popular.
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.
React always felt appalling and alien do me -and I wrote a whole react native app.
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).
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
- Good compatibility with third party JS
Currently in an Angular project and I would say "somewhat". Our production bundle is still >1MB if you include all the polyfills etc.
As an alternative I recommend Svelte Kit:
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.
you can integrate it to a server with ssr: https://github.com/frandiox/vite-ssr
These days, I can't imagine using anything but Svelte/SvelteKit for anything JS.
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.
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.
I'm far from that, but "5MB is very large" to me is ludicrous. Press "play" on a Netflix movie and you're over that benchmark straight away.
I grew up in the era of sub-56k modems.
Just searching Google for "56k modems" returns 5.1 MB of data with an ad-blocker on.
Let's be realistic.
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)
I'm well aware of profiling as I am lead on this project.
No issues.
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?
Clearly this is on the developer.
https://developers.google.com/web/fundamentals/performance/o...
I'm two decades into this. As the lead on my current project, on both sides (Angular and C#), I know all about this.
We have performance benchmarks and to this point, we've had no issues.
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.
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.
> it's pretty amazing. It's a lot less boilerplate than React, and god that feels good.
I could have said this for Elm! :)
i.e. if your product is relying on some organic search traffic to grow, would bundle size be a concern?
Svelte if I don’t.
React via CRA if I do.
I’m hopeful that Svelte will continue to pick up steam, but React serves my needs well as-is.
The complaint about the high initial complexity of Angular certainly resonated with 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.
But Angular? I just .. can't.
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
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.
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.
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.
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)
document.addEventListener("something", event => { /* blah */ });
Nor are Java streams or .NET linq.
Ignoring the maintenance issues, reactive applications do not yield better performance on realistic I/O-bound workloads: https://julien.ponge.org/blog/publication-performance-and-co...
So all you end up with is less maintainable code and more developer headache.
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 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.
Ok, fair enough - JavaScript + DOM is a "framework" for creating webapps.
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.
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.
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.
Don’t underestimate the corporate landscape. It’s super conservative.
And then, Angular isn’t really something to get passionate about, in my opinion.
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.
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 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.
And why did you switch (if it was be choice not merely a change of jobs)?
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.
> everything is straight forward to write the elm way.
Same could be said for React and Angular I guess; but mainstream drama is easily forgotten. :)
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.
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.
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).
If so then they have bigger problems.
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.
In less dysfunctional organizations you go with whatever the technical lead specified.
It's typical because it's life and it happens often.
> In less dysfunctional organizations
Dysfunction is the norm.
I am arguing for opinionated tools in general, I'm not saying you can't make it without them.
Similarly I advise against lottery while not doubting you won at it.
I imagine it's settled by now?
"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.
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).
Ah, damn, so it hasn't progressed much, if I'm not mistaken. They should really invest in that. I wonder how Google uses it internally, in this case.
Angular - https://github.com/angular/angular/releases/tag/13.0.0
CLI - https://github.com/angular/angular-cli/releases/tag/13.0.0
Components - https://github.com/angular/components/releases/tag/13.0.0
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.
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.
export const singleton = new Singleton()
and import it like any other symbol, e.g:
import { singleton } from './providers'
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.
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.
This was my point exactly.
and to repay the unwanted commentary you have a bloated, overly abstracted tech-debt ridden liability that’s perfectly suited for Angular, congratz.
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.
Anyway the faster we can get rid of Angular the better :)
React was just a better fit for this particular project. I feel Angular is too much overhead when you don't use the more advanced features.
Great work.
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.
Agreed about rxjs though. Very underutilized outside of Angular unfortunately.
Which tutorial is that? I searched on YouTube and found a lot of introductory stuff but nothing that appeared that comprehensive.
https://www.udemy.com/course/the-complete-guide-to-angular-2...
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.
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.
We are [fixing this](https://github.com/angular/angular/pull/43834), hopefully in 14!
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).
However! I do advocate the use of Angular for larger teams, since that structure can help a lot when you have many hands.
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.
Shit in, shit out.
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
Your application is likely smaller or a simpler use-case
Embrace simplicity: https://github.com/cheatcode/joystick#joystickjsui.