This was a fast release cycle. It was back in November 2019 we were talking about 3.7, and now it's in.
I'm not even thinking about Ivy. But it's nice to have all the nice comforts of typescript ready and working out of the box. (I mainly work in React, but dabble with angular/vue to stay up to date)
And what a smooth update process (abbreviated):
ng update @angular/cli @angular/core
** Executing migrations of package '@angular/cli' **
** Executing migrations of package '@angular/core' **
Your project has been updated to Angular version 9!
For more info, please see: https://v9.angular.io/guide/updating-to-version-9
It may seem "smooth" but I've been developing some hobby apps from time to time and it was never smooth. From Angular 2.0 release to 8 I've always had to spend 1-2 days to fix some random bugs from undocumented contract changes every time I came back to my projects. I'm speaking just from my amateur experience with 50 file projects.
After 2 years of Angular madness I will send my resignation and I hope I will never work with it again.
My app is a big stack of workaround stuff that might break anytime. Because that is how angular work. Some stuff work in a context and doesn't in an other. Nobody's know why !
They have so much issue on Github that they need a bot to close them after a while. They hope the bug disappear by himself ?
Almost every problem I've seen with Angular involve people not knowing how to implement features correctly or using it for what it wasn't meant to be used for. You know, the same problems people have with all frameworks.
The problem is there's so much you need to know. Angular invented a custom feature with plenty of boilerplate for every task -- and if you want to do something that Angular doesn't explicitly support you'll end up fighting the framework very quickly.
I work with GCC since 1996 and I never encountered a compiler bug. Whatever I wrote, the program always ran as it was supposed to run (even if it, more frequently than I'd like to admit, it didn't do what I wanted it to).
Angular has a lot of unique concepts that people find difficult to wrap their heads around. The Observable pattern, decorators, typescript, etc. When you throw things like NGRX and effective management of state / side-effects in the mix; things get exponentially more complex and difficult to scale.
I have personally witnessed companies take guys who have been slapping together "apps" in jQuery / .NET for the past 10 years and tell them "it's time to make the stack modern" and "we're going with Angular because we're a Microsoft house".
Things go very bad very quickly.
If you don't take the time to understand the Architecture behind scalable modern web applications you're going to have a bad time.
Anyone can slap together a quick and dirty app with Angular or React - not everyone can scale one correctly with thought given to the architecture behind these applications.
Agreed. "Unscalable" code is completely possible to write in Angular or React. Simply put, it's bad code that doesn't follow the paradigms of the framework it lives in, with all of the usual suspects (spaghetti code) sprinkled in.
I haven't done much with Angular 2+ (I use Vue now), but in my Angular 1 days, I've definitely seen a lot of Angular apps that were basically put together like a jQuery app. Massive controllers, lots of dom manipulation and logic in the controllers. My approach at the time was that controllers should be as small and simple as possible, with most business logic, data models, communication, etc extracted to services. The controller should just connect the various parts, nothing more. But when you're used to unstructured jQuery, the controller is an obvious place to just put everything.
The architecture concepts behind Angular are very .net-esque in a lot of ways. It's often an easier transition for folks used to MVC style projects with a heavy reliance on dependency injection to wrap their head around Angular than some other SPA options out there so the two get related in this way a lot.
Microsoft also supported Angular early on as it was one of the largest early adopters driving folks to Typescript.
Angular is the framework of choice for most Java/.NET shops, because it is basically JEE/Spring/WebForms/MVC, but in JavaScript, besides being written in TypeScript which is quite appealing.
Before Angular, those developers would probably have chosen Knockout.js instead.
Would you recommend any resources to learn how to effectively build a scalable modern web app? I haven't worked with Angular for about a year now, but I didn't use NGRX or similar alternative and I distinctly remember that managing state for the app got progressively harder as the app got more complex.
yeah I think what people are getting at here is that there's often a large investment to figure out how to use Angular2+ correctly (and even a lot of the concepts from Angular2 have been improved upon with new features in versions 6-8). A lot of times it's not "bugs" but if you're not in a place where you can spend 8 hours a day learning the framework in addition to building your app, you're going to have to choose one or the other -- and that's where frustrations set in. I'm gonna choose "build my app" every time.
I don't think Angular is a bad choice across the board, but you need to weigh this heavily when deciding to use it.
They are not Angular-specific, but they are required to know. That undeniably increases the learning curve. And the Observable pattern is decoupled from Angular change detection, so spaghetti coders can find themselves in especially confusing situations. I say this as someone who loves RxJS and typescript.
I m pretty sur the 2500+ issues on github are not all people using Angular wrong.
Yet I agree, a lot of things in my project is wrong and maybe blaming the framework for the mess is too easy. But I really do not enjoy working with Angular. Also, learning to use RxJS was a painful experience full of frustration.
I agree with you 100% here. I have been working in Angular for a long time and feel like I have a pretty strong understanding on how it works. Like you, I will not build another app with Angular (or any framework for that matter). I don't think I encountered as many bugs as you have, but I have spent too much time trying to figure out how to do it the Angular way or the RxJS way. With modules, web components, promises, and async/await, I feel like you can now write very clean code with just JS. So, that is what I am going to do going forward.
If you can write the app you need with "modules, web components, promises, and async/await" then you never needed Angular to begin with.
And that's a good thing, frameworks/libraries are never the answer to everything and are a decision to be weighed carefully.
Agreed. I think the increased support for modules and web components across major browsers in the past year has really given me the confidence that I can go without Angular/React/Vue and still have a well organized project. I still really miss the binding and routing of Angular. But, that is a small compromise.
I had many, but here is the first I can remember correctly :
I have a backendService that use the httpClient; it's a wrapper that automate stuff to make API request. I guess it's pretty common.
I have a provider for APP_INITIALIZER. It can use the HttpClient but not the backendService.
The backendService work everywhere else of course.
On HN in general there is a disdain for anything other than react, probably more people of Facebook generation and admiration of it's technology like open graph, react and few other products.
Based on personal usage of React, it's no easier than angular or any JS based framework like Vue (which in my view more sensible than react). You add state management, templates, router and 1000's of npm packages to do anything simple and react soon becomes an unmaintainable nightmare with emany vulnerabilities if you do not upgrade. An app is not just simple react but many of the npm packages (although it's true in general for JavaScript eco-system which is by default is insecure and maintenance nightmare unless there is an extra amount of work done to secure it).
Angular at least provide a decent complete single framework to work with and a unified documentation, there are issues with it, but react is same when you need any reasonable size app from it.
React gives you an easy start with false sense that it's easy, than becomes just too convoluted and complicated with the addition of different components as soon as app starts growing. Maintaining and upgrading apps based on react is very difficult as one version to another it introduces breaking changes. Angular had similar thing from angularjs to angular 2, but slowly they made it much better but letting compiler do more work.
Ivy tree shaking compiler will give a fight to upcoming compiler framework like svelte and keep the size smaller and may be in some cases much smaller than react app bundles, will wait for the benchmarks and size comparisons.
I am still waiting for a simpler way of developing web apps, elm looked very nice, but it is still far from ready for use in the same way as Angular or react yet.
Maybe the disdain comes from the fact that people don’t like getting a whole house (like angular) built on shaky grounds, but prefer a clean basic foundation (like react) where they can lay whatever bricks they like on top (routing, data management).
Your argument is flawed with a very opinionative starting point, which is that Angular wouldn't provide a solid foundation.
This is, at the very best, very debatable.
In my experience, it's the very opposite. Angular gives you very solid foundations as it's a proper framework that ships everything you need to build scalable apps. So you start from something small, and as you grow you know you can do so without rethinking the foundations of the app, as they are provided by the framework, which is Google guys, which means most likely people with a lot more experience than the average front end dev.
On the contrary, react leaves basic choices (the bricks you mentioned) to the user. While freedom can be good, it also implies that errors will be made, so you are a lot more likely to build on shaky foundations.
They are not people with more experience you are appealing to authority. The cold hard truth is that Angular got it so wrong the first go around that they had to completely rewrite the framework. The very reason was that a lot of the early guys where just out of school and built a framework on theory. If you contrast this with React, guys in the trenched trying to build applications at scale for FB, they where built with totally different mindsets. The FB guys understood the render loops that has been a pattern in UI since the desktop days and has stuck around because it works. To this day two way data binding and template based logic are both a dumpster fire, that cause unmaintainable code and side effects that cause debugging to be more difficult.
This is the most comprehensive document I can find on debugging in 9 and I still do not see a way to set a breakpoint in say a loop declared in a template. I may be missing something as I have not worked on an Angular project in probably 6 months. But I don't see template debugging I see being able to get reference to a component and then manipulate said component via dev tools.
The real difference between the two frameworks boils down to developer happiness. In Angular, all of the choices are made for you. For some, the lack of autonomy and agency when writing Angular applications makes those developers sad. It's hard to take pride and ownership in your work when 90% of everything has been decided for you, and if you try to eject from the "Angular" way of doing this, you end up just writing bad Angular code.
Choice to pick the best of breed solution to each smaller problem within the context of building an enterprise grade web application is at the heart of React. I get to look at all published routers and choose the one with the most intuitive API to me: I get to look at bundle sizes, and consider trade-offs.
This is the biggest “meme” about angular and it’s so unbelievable wrong. It shows that you haven’t used the framework if you think all the choices are made for you.
Instead of spending all my time analyzing different open source packages for every single thing you do, you just have access to a first class supported solution.
IMO, lots of the react ecosystem is built on engineers trying to show off. They get fancy coming up with a solution, writing a unique library, and there’s no reason for this. Everyone likes to think their code is unique and special and great, but it’s not. We don’t need to reinvent the wheel all the time. So many of these apps are going to need to be rewritten in a couple years because of how poorly architected they are. That’s not a problem of react, but it’s a problem of react devs who take a small view library then build a framework on top of it.
Unlike most people, I've written both Angular and React extensively: I've shipped both Angular and React web applications in enterprise settings.
I wouldn't characterize my time in React spent "all day comparing open source packages" -- if that's what you think web application development on React looks like on a day-to-day basis, you haven't done much on it.
To be clear, I do not intend to speak negatively about Angular. Some people love the provided structure. It's also not for some other people. This is okay. Different things make different developers happy. I wasn't generally describing all people's sentiment: that would be insane, both frameworks have huge backing. If you'd like to understand more about how some people view the framework as inflexible, and you're open to that perspective, I'm glad to shine some light on it.
I was mostly responding to this line “ It's hard to take pride and ownership in your work when 90% of everything has been decided for you,” Which in my kind is just a weird thing to say and seemed to imply a general statement.
A lot of comments state angular is inflexible and opinionated, but come from people who haven’t used the framework. They think your forced to do a lot of things where angular gives you choice.
I haven’t done much react development, but my significant other has and multiple members of my team have as well, and I’ve heard them discuss how when you need to find a package to pull in it’s a decision that involves searching and weighing the pros and cons much more then for angular.
I don’t hate react at all and totally understand its pros and how I think it’s a net positive on the web development landscape. It’s more that this site is extremely react focused and biased, and the US dev community is also that way. So angular gets called out as being something stupid to use that’s cumbersome, slow and big, but that’s just simply not the case. Example of angular app being smaller and faster then comparable react: https://www.freecodecamp.org/news/a-real-world-comparison-of.... I know these comparisons are silly so I’m not putting much thought into it, just one anecdote.
Both are great libraries/frameworks with great ecosystem of developers, we all need to stop flaming each other and see the progress each community is making. It’s not a winner take all type deal, there’s plenty of room for both.
> it’s a problem of react devs who take a small view library then build a framework on top of it
This has been solved by create-react-app. I'm working on a 10K+ LOC app now, and the only significant dependencies that aren't part of create-react-app or its docs are d3 and date-fns, which don't belong in a framework anyway.
"Built on shaky grounds" needs a citation and additional explanation.
I mean I hear what you're saying, but Angular is an opinionated framework whereas React is not, and many people end up reinventing the wheel (or an application framework) in the process. There is value in being opinionated.
The churn between angular versions, stemming from the limitations and inconsistencies of two way data bindings and others, are what I mean by «shaky grounds».
Yes there is value in being opinionated, but it is less risky to decorrelate the opinion from the foundation. There are opinionated frameworks built on top of react and it is very nice like this. But react itself should not be opinionated.
There is so little churn between angular versions. Angular 1-2 was a big change and they should have renamed the framework. But you have to understand how angular 1 came into existence. It wasn’t planned to be used by everyone, it was just solving some problems experienced by a couple devs and it spread like wild fire.
The team that eventually took it over and grew around it recognized it had some problems scaling and being used for large applications. They knew they couldn’t just change angular 1 to be what it needs to be, so they made a big switch. They put in patterns that benefit large apps, typescript, observables, the choice of two way binding or one way binding, better DI system.
Everyone says react isn’t opinionated, and for developing an enterprise app that just sounds like a nightmare.
I'm not sure what churn you are talking about, unless you mean the Angular 1 - Angular 2+ split?
ng update is ridiculously easy, and the automatic code rewriting is generally sensible and easy to follow. When there are breaking changes, Angular takes care of the modifications for you. Generally I've felt like those changes resulted in a better expressed codebase (eg RxJS syntax improved massively from 5 to 6, lazy loaded routes are expressed with arrow functions now, etc).
I assumed the React community was also migrating versions with codemods, but maybe React does not introduce any breaking changes?
> You add state management, templates, router and 1000's of npm packages to do anything simple...
You don't actually have to do that. React just turns your data into DOM elements, most of the time it's a simple transformation.
Otherwise, how you architect your application is up to you. You don't need to overcomplicate things by following the latest trends, you don't need a ton of dependencies to do simple things. You don't need templates at all.
Angular is complicated by default. It makes design decisions for you that you probably wouldn't have made, and then sometimes it reverts those decisions, making you clean up the mess. React code very rarely breaks.
> Ivy tree shaking compiler will give a fight to upcoming compiler framework like svelte and keep the size smaller and may be in some cases much smaller than react app bundles, will wait for the benchmarks and size comparisons.
Angular bundles are huge by default, it has a long way to go. Tree shaking already works with React, you just need to set your build up that way. Also, don't assume that a compiler will make your build smaller, it may well inline a lot of stuff and end up larger.
Although Ivy will bring nice improvements all around, you won't see the 12kb bundle sizes you are talking about in this initial release of Ivy. `renderComponent` is the key that will enable that down the road in some fashion (you can play with it now), but I appreciate the teams approach to easing the framework into major changes like that.
I joined a company that had two fairly simple internal web apps, one in Angular and the other one in React. Both had been written and maintained by a number of devs, each on the task for a few weeks or months. Both had several issues and blunders that needed to be fixed. However, while the Angular app had a very obvious, predictable structure, with issues confined inside single components or services, the react app was a totally obscure jam of javascript and html with more javascript and more html interspersed within, tons of redux boilerplate and properties passed down three or four levels of nested components. The stuff was such a wild spaghetti mess that editing a form in a foreground modal made the text in a background static page jump around when the number of characters in the form was even.
Anecdotal evidence. This is just the result of bad practices. React is less opinionated than Angular I'll give you that, so I guess that subpar angular might be preferable to subpar react.
Well-managed react is incomparable in power. Try to make a library like react-three-fiber using Angular, in less than 500lines of code.
lol it would work fine. I've had a joke app running Angular 2.0 in production for years. The code doesn't just expire and break. If you upgrade to Angular 8 in your package.json without running the upgrade schematics, yes it will break...because there were breaking changes.
In 2016 React was on version 14. Are you telling me that from version 14 to 16.12 React has had ZERO breaking changes? Because they definitely haven't. That ecosystem has also changed recommended patterns countless times. They just choose to leave a lot of the old implementation options around if they can while Angular as a frameworks tends to be more opinionated.
Same goes for any library or framework across major versions...
> Because they definitely haven't. That ecosystem has also changed recommended patterns countless times.
You can just ignore the "ecosystem". You don't need it. React pretty much only does one thing. It doesn't impose an architecture on you. If you want to go all-in on the ecosystem, maybe it's as bad or worse than Angular. That's besides my point.
> Same goes for any library or framework across major versions...
No it doesn't. Some or even most people working with Javascript are completely out of touch with software engineering practices outside of the web bubble. Breaking changes are supposed to be avoided at great cost. Of course there's no real incentive for that if you're a random person pushing something to npm, or if you're Google and your business model is selling users instead of software.
I wouldn't expect anything else to be honest; as long as the underlying JS / HTML does not change, anything written 10, 20 years ago should still work now. Browsers (= your application runtime) are pretty good with backwards compatibility, and not touching your application should not break things.
Unless it's doing unsafe or nonstandard stuff in the first place, like idk, cross-domain requests or weird stuff with iframes or whatever it was Google tried to do when it added an extension that tried to do preloading and stuff like that.
One day, all Meteor.js apps went blank in production (you'd just get a blank screen) due to a change in Chrome, that required everyone to upgrade (albeit, a non-breaking change, so it was easy to accept). I had been building an enterprise application on top of Meteor. The outage caused a huge lack of confidence among my customers.
The Angular1 apps I wrote around that time are still running as well. The question is about maintaining them.
Did you try to actually upgrade the react version? Lots and lots of breaking changes in that time, some really major ones along the way. Especially when upgrading react also forced one to change router etc.
I find it deeply ironic that, judging by the stories regularly posted and upvoted, Hacker News readers supposedly value science, rationalism, evidence-based thinking, etc. Yet the same people reliably upvote these kinds of toxic, detail-free, ungrammatical, emotional rants.
By all means, upvote criticism that is properly argued and backed up with evidence. But upvoting these kinds of comments is the equivalent of posting anti-vaccination memes on Facebook.
The only thing I like about Angular is the dependency injection of services. Having "services" managed for you and just picking and choosing what you want is pretty nice.
What I don't like is the verbosity and boilerplate... here's 2 examples:
- Routing boilerplate is convoluted and time consuming. I think Nuxt.js has a much nicer implementation of SPA routing, where the filesystem is used to map the routes.
- Angular modules are verbose, redundant and don't even truely encapsulate dependencies anyway. You can easily create implicit dependencies by relying on services instantiated in higher level modules.... which is bad
Another benefit in my mind is that Angular is "batteries included" - you get everything you need in a single library, e.g. routing is a big one.
From what I understand of React, you need to pick and chose the libraries (and versions of those libraries!) to use for your app, and then keep the versions of all the different libraries up-to-date and in sync with each other. Sounds like a maintenance nightmare.
It has probably been improved since I last tried it but this is one of the reasons I picked Angular over React. Having a router, HTTP client, forms, i18n, etc. out of the box compared to having to find/evaluate/integrate/maintain the various libraries that build on React to get the same functionality was a great benefit.
The other reason is the first class TypeScript and RxJS support.
I've seen people tout this as a benefit for certain ecosystems for years and years and years, and I think it's a big bag of crap. Maybe if you are ultra talented and ultra disciplined, it's possible to stay on the ball and make things work when you are gluing together disparate pieces and shaving an untold herd of yaks.
But for mere mortals, having sensible defaults and pieces that were designed and built together is wildly more productive.
I was more amenable to the libraries-not-frameworks argument a decade or two ago, when release cycles were once or twice a year, libraries were mostly independent, and granularity was much coarser. Now it's just too goddamn much work to keep things sane. I do not have time to dedicate a day a week to troubleshooting why updating package X has pulled a new dependency on library Y, which is incompatible with library Z.
Then again, that is what might lead to the boilerplate. I've been out of Angular for a while, but was kind of following along around the release of v2, where they went through about four routers, I think. GP mentions mapping routes to the file system, but then how are you going to accommodate a route pointing to a modal inside another route, identified by its hash? By having one blessed implementation, they also feel forced to support every potential use case.
I just updated my mid-size app from v8.2 to v9 with Ivy, and the total es2015 bundle size decreased from 973 KB to 669 KB. An over 31% improvement with no effort on my part!
Thats exceptional, I wonder if it was a really clever optimization they found or if it was a really lazy bloat they let into an earlier build.
It reminds me of a great hack where game developers used to hide a large memory allocation early in the game development process and when they ran into memory constraints towards launch they'd just comment out the line and instantly save the day. Artificially constraining the memory caused intermediate development to be more frugal and ultimately allowed them to get where they needed to be by the end of it.
Sounds like you've never actually worked in a large application to me. Not to gatekeep or anything but large web applications will be in the order of millions if not tens of millions of LOC.
React was a mistake of the last decade. React itself is a great academic idea (i.e. pure functions, composability), but the whole React-Redux boilerplate mess (I dare not call it an "ecosystem" because that word implies harmony of some sort) is the the result of an entire generation of code monkeys and job seekers who didn't design their technology stack with any real engineering consideration, but rather on the basis of tool popularity, feeding a vicious cycle of "lean startup" companies spending a glut of VC money looking for the fastest way to hire more React code monkeys because they think "that is how you do engineering".
I have the exact opposite opinion. React is the only sane way to do web development. All other approaches are deeply flawed by either relying on imperative mutations of the DOM instead of clean declarative code, or by relying on ugly templating syntax and data attributes instead of just using JS basic constructs like react. The power of react is just at its beginning, as we can see with things like react-three-fiber that was coded in a weekend initially and which is unthinkable in any other framework.
I'm not a React hater (in fact, I like it a lot when it fits) but I think when people criticize React, they're actually after the one-size-fits-all attitude displayed in comments such as yours. No, React is clearly not "the only sane way of doing web development" considering the web hosts many types of markup applications, the most successful ones predating React by decades.
Don't interpret too much into it :) When I signed up to HN and had to choose a nick, I sat in my living room looking at a Tanne (a fir in German) outside, and chose Tannhäuser (literally, a man who lives in the woods) in a hurry. If anything, it's a (quite arrogant towards the HN crowd) reference to Richard Wagner's opera/character rather than Blade Runner.
Tannhäuser Gate is only the most enigmatic reference of the best scene of the best movie in the universe, and I never heard of any mind altering substance called Tannhae that you were admitting to use (are you a Can-D user or a Chew-Z user? [1]), so I assumed it must be a Blade Runner reference! But now I understand it's a direct reference to what Roy Batty may have been indirectly and allegorically referencing, which is quite un-disappointing. ;)
I personally think React scales well both up and down but you can avoid Redux for small things. Use Mobx or some easier state management lib and you are all set.
Of course, those are lightweight / 'native' (to react) alternatives to redux / state management; last time I used it there were some really neat (theoretical) advantages, such as a browser addon where you could do time traveling debugging (replay individual events) or push the state and all state changes into a support ticket for reproducibility. Purely theoretical though, and at the time using Redux added a lot of mental and labor overhead, especially when using it to manage forms. (personally, I think form data should never be part of a global state; it should be limited to a component that manages the data itself and does not leak it elsewhere. But, it depends on the situation, as always)
I think a blend of both is the best approach for most apps. Redux for global state, api interactions, etc. so that you get the power of middleware like thunk and saga and get great debugging support for overall app state, then anything local to a page or component (like you said, for form data) you use a react context and useContext it in child components to hook up events and manage page level state using useReducer or useState within your page component. This model has been very successful for us and helps partition state in an easy to understand way.
Only sane way, you missed a word. Of course there are other ways, but they clearly flawed in my opinion. I used to hate web development before 2014 and now I love it. Php is an awful language, jquery was a nightmare. Angular makes no sense hence why it keeps reinventing itself, Vue forces you to have some logic expressed using an ad hoc language in templates like it’s 2010 instead of just using JS constructs etc...
I stand by my point, I am yet to find a use case where some form of react is not the best solution. Whether it is server side rendered, a single page app, or statically rendered.
The only criticism I hear about react boil down to people complaining about bad practices that are not linked to react, but merely conflated with it, like not caring about bundle size, messing architecture or other aspects that are orthogonal.
> Whether it is server side rendered, a single page app, or statically rendered.
Nail meet hammer. Seriously though, what why you need a JS framework for static pages? What if your backend is in Go? What if you're doing heavy duty numerical analysis? What if your users want a Wordpress-like site? What if your team uses Rails or Drupal to quickly build sites?
You are right indeed, but from a developer point of view at that point you could be using a react based framework and your experience would be the similar to vue with JSX.
Render functions returning JSX is the key brilliant idea invented by react and the fact that vue adopted it just proves the point even more:
React or the ideas at the core of react are not the mistake of the last decade but the blessing of the last decade for web development (and more).
> from a developer point of view at that point you could be using a react based framework and your experience would be the similar to vue with JSX
It will not, because Vue has a better integration with the data source (Vuex) and a better integration with the routing (Vue Router)
I mean, I agree that React is an awesome framework implemented upon great design ideas (pure functions and plain JS templates), but it has its shortcomings, that frankly make me still prefer Vue to React (mainly Redux and the router)
For routing react-router is just perfect. And for data source/state management there is plenty of choice, I use Apollo for global state/data source and useState for small state full interactions, I can’t see how it could get simpler.
But whatever floats you boat really, the point is that the nice part of vue are inspired by react anyway. I wish the two community merged, to be honest, I see no point in dividing for such small differences.
You specifically argued against that, your arguments seem to be highly religious in nature.
I don't know how many years you've worked in the industry but if you think React will be the dominant way of building apps for the next ten years, I have some Adobe Flash developers who I'm sure would like to say a few words.
haha! Former hotshot Flash ActionScript 3 Ninja Developer reporting for duty as requested.
Seriously though, JSX and TypeScript are nothing new. Both were part of ActionScript 3, a big language backed by a powerful company (Adobe). 15 years later, nobody even remembers it existed. How am I still making a comfortable living coding today? By not getting too attached to any language or framework... they are all just tools in the end.
So let the young ones be, time will eventually teach them those lessons, sooner than they think.
The ideas behind react will still be big in ten years yes.
My arguments are not religious but based on facts, I can share my PhD thesis from 2016 about user interface specification languages, that includes a comparison of more than 20 different approaches including react.
Flash was always a proprietary platform and only fools would have bet their whole career on it back then. The situation of the ideas behind react, and browsers as a platform are very different.
I’m not betting my career on it though (I’m a CTO in a company which Is not centered around web stuff) but I do believe that these ideas will leave an impact in the industry, and this belief is backed by specifically studying this topic for 4years, plus my 15years in the industry.
I'm a UI architect of a major SaaS company who maintains our 4-5 products between 8-10 feature teams. I've worked in the web industry for 11 years.
My job is to enforce some semblance of sanity between very smart and clever engineers without heavily impacting their ability to deliver. My job entails much cat-herding, setting norms, and maintaining expectations.
Every day I thank the gods we went with Angular. It has saved us countless times, every refactor is a joy, every upgrade is painless, every component is easily shared.
I don't have to constantly worry about XSS, I don't have to explain how I want things structured (because the build fails if they don't structure it right), and I don't have to worry that if someone leaves, no one will know how to pick up and modify their project.
Do developers hate it? Absolutely! They want to get work done fast and pump out cool, clever, smart work! They see Angular as a hinderance to the objective of "doing" because now they need to know about all these damn opinions that aren't their own. Angular isn't for them, it's for everyone else.
By contrast, React enables selfish coding, which while totally okay when you have a few people and clear lines of ownership, does not scale well without strictly defined responsibilities and amazing cultural levels of synchronous decision-making.
I don't want a "you could..." in my framework... I want a "this is the way" in my framework. Thus me the dev before me... the dev after me can get on with things. It will not be the perfect solution but it will be a consistent solution... This is of course true for any framework.
I agree. I have to develop for both Angular and React for work, and I find my experience with React so much more relaxing. The logic between the what I see and what I think is straight forward. What I see is what I get. JSX is great.
Meanwhile, for Angular, I keep constantly going back to the documentation, trying to remember all the small details about templating, binding, decorators, modules, dependency injection, etc...
The alternative to React is not Angular or another JS framework. That was not just my anti-React rant, it was an anti-SPA rant in general. I still fail to see why people need to build an entire application twice, once on the server, and again on the client, except perhaps when you have very frontend-heavy interactivity requirements (like photoshop-in-the-browser or games). SPA's attempted to rebuild the entire HTML web-browser model, and they did it poorly. I yearn for the days of Rails/PHP/Django where the server "is" your application, and we use the web browser's native functionality as designed, with a much simpler application model, and, in most cases, a better end-user experience. That's enough for 80% of apps. A little bit of DOM manipulation is acceptable (i.e. jQuery / Vue.js) and easy to keep track of in your head since every page is a new context/state, instead of ever-increasing layers of abstraction for "state management" and "components". If you write clean HTML, the DOM is much easier to deal with than some state management library. If you could truly abstract away the DOM without ever thinking about it, I would agree with you, but you can't. You can't escape thinking about the DOM if you care at all about performance and debugging, and now you have to worry about the DOM AND your state abstractions. I'm not saying we have to go back to writing assembly code, but I'm saying JS frameworks are the leakiest abstraction ever designed.
That react-three-fiber project is cool, but engineering is not about you can do, it's about finding the best solution for a given set of requirements, and 95% of web apps don't need that kind of functionality - it's just unnecessary over-engineering at a huge overhead cost.
React devs love to talk about one-way-data flow and Flux state management. They forget state doesn't come from the client, it comes from the server. Why not carry this one-way-data-flow model all the way back to the database, which is where your state actually originates?
>> I still fail to see why people need to build an entire application twice, once on the server, and again on the client
I fully agree, and this is why I can’t understand why in 2020, some people still don’t understand that react/SPA and node backend for server side rendering are the best solution.
With react and server-side rendering you code your front end only once, of course. And the same codebase can be rendered on the server or on the client transparently. Same JS libraries can be used in the server, in the browser, in mobile apps with react native.
There is just the API on one side, and the frontend on the other side. Where the frontend is rendered does not matter.
Not to interrupt a good rant against tech (in this era... very brave, btw) but you should look at react with the context api. I think everyone who’s used it is glad it removed redux’s boilerplate insanity. There’s even some other frameworks (the name escapes me now) that are like boilerplateless redux if ppl like that style of event driven state updates.
Please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once:
Also, note that we have a new "Style Guide" docs page which specifically recommends patterns that we feel will lead to simpler code, like the "ducks" structure for single-file Redux logic:
Finally, we're currently working on a major rewrite of the Redux core docs, with the goals of updating them for today's target audience and teaching easier-to-use patterns:
(and by "we" I basically mean "me", since I'm not getting a lot of help with this effort so far.)
I'll also point out that while Context is a great tool for making data available to a nested subtree of components, it has major limitations in terms of processing frequent updates. We tried to use it internally in React-Redux v6, and it just wasn't sufficiently fast enough, which is why we had to rewrite the internals again in v7 to use direct subscriptions instead. So, very useful, but not a replacement for Redux.
Thank you for your work on Redux - I think it's fantastic!
Lots of hate in this thread, but React/Redux are great, even if that somehow makes me an imposter or a hipster or whatever the tools I use somehow say about me.
I obviously didn't _create_ Redux, but I'll take a decent amount of credit for helping keep it relevant over the last few years (docs work, blog posts, answering questions, React-Redux updates, Redux Toolkit).
I'll say up front that it's definitely not as "necessary" as it was early on and that there's lots of other great alternatives out there, but yeah, I don't get the recurring waves of "I hate Redux" that seem to pop up on Twitter every few months.
FWIW, I talked about some Redux usage stats and where it fits in compared to other options in my "State of Redux" talk at Reactathon last year:
Wow! such a strong opinion warrants some more justification.
Having used both Angular (since 1.0) and React (only recently), it's obvious why React is more popular. Any decent engineer can be productive in React within a day since the concepts are so intuitive and simple. With Angular, if you don't really know how things work, you are going to struggle a lot for a while.
While i can't speak for the rendering performance, the design itself is definitely elegant and not built for "code monkeys" but real engineering productivity
I use React and I find it fine.
I don't use Redux though, so it may be the reason why we had different experiences.
I think that just by using Hooks and Contexts you can get a lot done in a predictable way without adding too much complexity. With typescript and a proper IDE you get also wonderful type-checking and refactoring capabilities.
I used AngularJs (1.x) a lot before and in comparison it was both more complex and full of unexpected behaviors.
I have less experience with Angular (2+), but I found it much more complex and in some parts over engineered.
A lot of enterprises hiring juniors on the cheap actually thought of it in the opposite way. They saw Angular's rigidity as some sort of safety rails to help guide developers in the rightish direction. They thought React was the Wild Wild West of JS land ;D No manager got fired for choosing Angular. If only
I'm kind of surprised this is downvoted. There are definitely companies out there that chose Angular because it enforces writing code within the framework's style. It feels like bowling with the guard rails on, and if your team leans junior, it seems sensible to opt for that choice.
I'm not saying I personally agree with the decision, but I could see how management might conclude to chose Angular with that rationale.
I wouldn’t say the same no matter the domain - junior devs can and will surprise you, and because React gives you less guardrails for app architecture, it likely has the potential to go far worse.
Except wire up routing in a strange way, or pick a library for form validation or form framework, or come up with odd ways of structuring tests, picking a strange approach for animations, etc.
This is the cost when app architecture gets delegated to your developers over a high quality central solution, the quality is as good as your developers.
Those are the parts where you put a senior in charge. Hell I can't even do that in React, and have in the past literally hired a contractor to set that up for me.
> If you stick to prop drilling and functional code
Juniors new to React are unlikely to do so, IME (as a semi-new-to-React not-junior working on a team with new-to-React junior-ish devs -- by experience; there isn't a formal junior/not-junior distinction on our team.)
OTOH, if you do things you really shouldn't do in React, while they won't all be flagged, there's a very high probability it will result in at least related warnings pointing to it in the devtools console, so that's something.
> the whole React-Redux boilerplate mess... is the the result of an entire generation of code monkeys and job seekers who didn't design their technology stack with any real engineering consideration
What do you even mean?
Redux was a simple and elegant implementation of the unidirectional data flow (aka the Flux pattern). It came out during the time when the state of the art was Angular 1.x (aka AngularJS)'s two-way data binding, requiring a lot of dirty checking. Redux might or might not (the story is moot) have been influenced by Elm, which has exactly the same concept of actions, state modifications in response to actions, and re-renders in response to state modifications; all as pure functions; and Elm developers are finding this approach enjoyable and predictable. But even Elm aside, the pattern that redux is using, i.e. communicating via messages (actions) and subscribing to state changes in connected components, is a variation on the age-old, battle-tested event sourcing and pub/sub. What's so bad about that?
React != redux. I really like react, I really hate redux, so I use react without redux and it works just fine (we actually use tracker+minimongo from meteor for our app state and really like it)
I second this. In my last largish application, state was getting really messy and I needed a place to keep it all organized. I really tried hard to get Redux to work as at the time it was the tool that everyone was talking about. I struggled and couldn't make sense of it. Eventually I stumbled upon MobX and it just clicked. So easy to work with and checks all of my boxes. Productivity and happiness soared :)
Oh man, don't say it. I've just started to learn React to improve my chances of landing into my first job, since all Java positions are either full-time or requires >4 years of previous relevant experience.
I wouldn’t worry about that. React won the framework war in most industries. The only places who really utilise Angular in my area are the same companies who build the JAVA backends you can’t get hired for, and even some of them are switching to react.
All in all you shouldn’t worry too much about employability if you pick and stick with something popular. Check your local job-market and stop worrying about what’s hipster cool on HN. There hasn’t been a single Rust or Go job listing in my entire region of Denmark for an entire year, mean while there are currently around 150 PHP positions open right now.
If for you extrapolating types trying to fit a square into a circle every variable declaration and having 10 lines of decorators per file means less boiler-plate then yes angular is the better framework.
You don't have to create actions or constants anymore, you just create your reducer functions and selectors, then use hooks to select and dispatch in your components.
Never got why people took up a completely different paradigm just because they couldn't figure out how to reduce their boilerplate...
Or use XState as Redux is only a half implementation of a state machine. It get's the job done but a state machine gives you far more structure and comprehensibility around state management.
Didn't know that. What I thought I knew is based on years of breathless claims about React's great performance. This is eye opening. Even Angular 8 does better in these benchmarks.
I think the breathless claims of performance are because for what React is doing -- storing the entire application tree using virtual DOM and seamlessly rendering updates -- it is really impressive. The fact that it is has similar performance as some much more naive frameworks is pretty amazing. In practice all of these frameworks are fast enough that you wouldn't notice unless you were doing something really crazy.
Yes, it's an admirable design. I've used it. I know. And no, nothing I've done with it has been intolerably slow. Although now I'm starting to wonder about some responsiveness issues I've experienced...
I also wonder if batteries care about elegance. Not really they don't. If one makes the highly likely assumption that these micro benchmarks are a measure of efficiency then it's actually difficult to do worse than React regarding battery life, heat, etc.
Bundle size and start time are much more important metrics IMO unless you have a high perf use case. Like you said, most of these are fast enough for the majority of uses cases.
Poor design and architecture. Doing too much and blocking the event loop, memory leaks, using too much frontend code to poorly mimic native browser features like new tabs and back buttons, uncaught exceptions that stop the javascript thread and leave the page stuck, etc.
React ecosystem is centered heavily on "components". This sounds nice, but IMO it breaks down quickly on the "whole program" level. What you end up with is crazy re-renders because it doesn't make sense to "componentize" the state.
Facebook absolutely is, it's a beast. I find it can frequently freeze up my old laptop, which is admittedly getting past it but I have little trouble with most any other site.
because React's stance is that it's a rare enough case in their experience, so they don't spend time optimizing for it.
that metric is slower in general because libs with simple reconciliation strategies will tend to do work for every row between the two swapped ones (2,998).
By choosing React I'm optimizing for my time. I'll always add a framework that adds a tiny performance overhead if it means I can develop and maintain features easier.
That said -- performance characteristics like this are rarely interesting to me. The vast majority of "performance issues" I've encountered have to do with high-level architecture and/or network issues. I've never given up on a framework because it couldn't swap two DOM nodes fast enough.
having never seen that benchmark, I’m surprised at how close wasm-bindgen and webstd are to vanilla. It’s not zero overhead yet (for some obvious data conversion issues I’m guessing), but it’s way better than react for example.
Huge thanks Angular team. A few years ago, my team desperately needed to pick and run with a frontend framework. After a couple months to learn the Angular fundamentals, we haven't looked back. We find the framework to be extremely intuitive and flexible enough to handle any scenario we've encountered. The productivity wins have been enormous. We have about a dozen apps and anyone on our small team can jump into any project and contribute. I can't imagine how fractured our knowledge would be if we had to stitch together multiple libraries and come up with our own constructs.
Huge release with a lot of time and effort put into it. Congrats to the angular team. Couldn’t imagine another framework putting in the amount of work they did in order to insure Ivy goes well.
Just want to say that all the Angular React comparisons are dumb. It is comparing apples to oranges.
Angular is a bigger framework for developing more complex stuff. Therefore of course there is a steeper learning curve. Here are comments like "react is so much more easier because it is just functions". Why not just using vanilla js because you have nothing to learn then? Or just use binary code? It is just 0 and 1.
I wholeheartedly agree, this is a false equivalency.
Angular was built specifically around avoiding an entirely different problem that the heavily debated issue here of overengineering: Multiple teams that build out complicated and feature laden systems in parallel need to make concessions to allow interoperability.
If your organization is culturally flat, Angular prevents the core of your application from diverging in unmaintainable ways.
The comparisons are valid because for 99% of the web apps out there, the makers could have gone with either angular or react.
Regardless of the underlying philosophies, the choice between React, Vue and Angular is a very real one businesses have to make everyday, so it makes sense to compare them.
I think the problem then is people not respecting YAGNI. The vast majority of web apps should be built using React ant only the true monoliths should be built using Angular.
Also it's worth nothing that React and Vue scale. They work as well for small, scrappy projects as they do for large enterprise ones. I wouldn't say the same for Angular.
AFAICT the upgrade path is still the same (0) and...it looked pretty painful when I first looked at moving from 1.x to 2.
I maintain a sizable 1.x codebase and am deciding what to move to, since 1.x is dead next year. I just don’t see a good reason to go to 2+. It’s a different framework. All of the UI libraries we built upon (ng-grid, angular-ui) are either gone or different enough that we will have to redo all of our code no matter what. If I have to switch frameworks anyway, I want to go with something simpler (no custom module nonsense, no annotations, no hierarchical dependency injectors, hell, no classes!) with a healthy ecosystem.
React with hooks, bootstrapped with CRA, is the clear winner for me. It’s just so much more straightforward to reason about, and way faster to build things with too. I made a toy app in Angular a year ago to check it out, and had a hell of a time even getting the simple data model working right. With React, day two had me already wiring up a dashboard with charted details that responded to a calendar widget I had customized to show QoS at a glance. I was looking at Vue too before I read up on react hooks, but once I saw functional components everywhere I was...erm...hooked. Sorry.
Now if only I can convince them to let me use ClojureScript...
Having ported some Angular SPAs from 1.x to 2++ I have to say: Looked more painful at the onset, was actually quite easy in the end.
Having used React for some years now, I have to say: I wouldn't compare the two. React's atomic ecosystem is perfect if your stack of tools you embed doesn't grow too large.
However as soon as you want the feature set Angular provides out of the box IMHO you're screwed.
Objects and messages good, classes and inheritance mostly bad.
Except maybe for modelling/simulating concrete classes of objects (ie, as in Simula, the language).
Proper multiple dispatch (a la common lisp CLOS) seems rare - I'm guessing java/c++ seemed like a sane trade-off for some type safety - but they probably should've stuck to self/smalltalk (for Java) or looked to standard ml/common lisp (c++).
I still don't understand why Javascript got classes, rather than some paint on the prototype system.
Google declaring end of support is enough to make us have to move. Banks are kinda picky about security updates.
We’ve had a bunch of long-standing state management bugs and performance issues too ($watches, $watches everywhere, nor any prop’s in sync) that we built a lot of cruft around trying to fix, mostly due to two-way binding and our weird use case. Some were unfixable due to the framework and others due to bad early decisions. But This Time!!
It will definitely be fun to rewrite. The app is so much like a web-based dumb terminal that a view-layer library like React was probably always a better fit for us, had we known about it when we started the project. Plus the JS ecosystem is a lot nicer now: arg destructuring and VS Code’s intellisense thanks to es6 imports are both big productivity wins. Also, not having to maintain a gulpfile is its own blessing.
They are wholly incompatible. The choice of the Angular name for this new framework was just marketing, beyond some similar design choices.
Probably there are better ways now but here’s how I did it:
* Determine exactly how moving to a new framework will benefit your users. If it doesn’t, why are you doing it? It is going to be a lot of hard work and your users will not care you’re on a new framework.
* evaluate if Angular really is the right choice to upgrade to
* if it is, do not mix the code in one repo. Use two repos.
* Migrate route by route, starting with lowest impact pages first. When user clicks on the route served by the new angular page it will point to the new app
* to support this, you’ll need to build out foundational modules critical for the switching to happen, e.g. auth, common header, footer, menus etc
* how the switch happens between routes is up to how your app is served. You will need to configure the domain to stay the same between serving the different apps.
* update your deployment and testing strategies to account for two apps going out instead of one.
* we took a bell curve approach, lowest impact routes first, then peaked with critical routes, then back to less and less important pages. This allowed a gradual ramp up to work out the kinks but at some point you will need to get your most important stuff moved over so you’re not building two systems.
* get buy-in from stakeholders that this migration is going to add value for users. Get them excited so you are working together to get it all moved over.
* allocate x% of Dev time to the transition.
* agree on a date for each route and for the full transition so work can be prioritized.
I’m sure there’s loads of blogs with more specifics. Just wanted to share my experience at a high level.
No there is no way to go from a donkey-cart to the Star ship USS Enterprise in a incremental way while still travelling forward. I've also had to do it. Just start from scratch. I'm a lot more productive with A6+ than I was with AJS
I think they had an official migration utility to help with going from 1.x to 2.0, since it was basically a total rewrite. I think the major versions after that have been more incremental, though eight at once might still be rough.
The path provided is being able to load Angular 9 components into AngularJS components relatively seamlessly. This is helpful, but it's almost certainly a big leap to get your codebase compiling under angular-cli. If you manage it though, you can, in theory, do a bottom-up replacement of all your AngularJS components.
Another thing to think about though is how you're currently doing state management. Angular 9 is all about RxJS, and if you're currently managing state without it, your migration will be that much harder.
I have spent a lot of time in Angular 2 and later in Angular 6. I had later switched to plain java script and used requireJS to modularize. I have my own orchestrator to route events like a pub-sub. HTML5 + CSS + plain JS is good enough for most simple UI.
"I have my own orchestrator to..."
Herein lies the problem.. does your own orchestrator have good examples, documentations or examples on StackOverFlow ? Not trying to be di*k !
While I want to agree, at the same time I'm afraid of people creating their own frameworks, re-inventing the wheel, etc. Mind you, Angular feels like a very heavyweight framework, so that would be the other side of the coin.
Personally I wouldn't go for a vanilla JS application, not unless the script / application part of it are minimal.
I should have been more clear - my point is not so much that people should use vanilla JS rather than a framework, it’s more that the majority of SPAs I’m forced to interact with could have been implemented just as well with HTML, CSS, and a relatively small amount of JavaScript - small enough to not beg for any kind of framework at all. If the nature of the app really truly demands a full-blown SPA, then by all means go all in on something like React.
How often do they release major versions? It seems every few months there's a new major version update. Having been burned once with angular, combined with this aggressive release schedule, by themselves are enough to make me not even consider angular. It could be the greatest framework in the world and I still wouldn't consider it. Not everyone is building throwaway prototypes and garbage startup code. Many people need stable libraries and frameworks that last many years and don't need time consuming updates and migrations constantly. Angular is clearly not this.
I am in no way the whole crowd, but having used both legacy AngularJS, React, and Angular 4+ in production for medium-sized apps, this is my main takeaway:
The mental model for React is much simpler than Angular's.
In React, There are two concepts one needs to understand: Components, and Hooks. JSX too, but as a web dev the HTML-like syntax was already familiar.
In Angular, you need to understand: the binding syntax; Components; Templates; Factories; Modules and Services. And learning bindings also means learning RxJS (which I love as a standalone lib, but is a big cognitive load when coupled with the rest of ng).
Even just comparing the "Fundamentals" page of Angular versus the "Main Concepts" of React (which, isn't exactly the best measure of complexity, of course, but it's A measure), you can see Angular spends 8 of its 10 sub-sections explaining essentially-required concepts, while in React it uses 6 out of 12 sub-sections.
React is much more concise in terms of concepts, and instead just has a bunch of common patterns that are sufficiently approachable and memorable, but most importantly can be "rediscovered"/"derived" on your own, rather than relying on framework-provided "black box" concepts.
I think that's pretty well correct, but my preference has been the opposite in terms of more concepts vs cognitive complexity. I find that to do the same stuff with react and redux and so on, you end up decoupling and abstracting in such a way that the 5 or concepts in something like Angular or Vue end up being a more manageable mental model. In the sense that the main purpose of React is lost in the weeds of trying to managing the modularity of your app.
I have found good success with React + RxJS, in fact. They have some overlap, but with the benefit of interop outside React, and Rx is excellent at both message-passing-style events, as well as general-purpose "data binding".
And the total load is still in my perspective smaller than Angular. I have never even casually used Vue (I've since switched to gamedev as a profession), so I cannot comment on it, but from a cursory on its docs, it seems like a leaner Angular, which is good.
That's a curious suggestion. I've never taken a serious look at RxJs, but I've used obsevables in android so might do that. Vue is like React but just enough separation to get all the benefits that I find in composition as well as the templating and stuff from Angular. How did you make the switch to game dev?
I've always had gamedev as a goal, and since 2012 participated in "game jams", which are basically make-a-game hackathons; as well as making free web games/prototypes. The industry is very portfolio-focused.
Mostly did webdev as a way of supporting myself until I got a gamedev job (but I like doing webdev too). I currently work at a company that makes corporate/educational games, but am collecting more experience to be more competitive on the actual entertainment industry. Which is a bit more challenging given I'm based in Brazil.
That being said, it's much easier to "switch careers" when you're 22 and it barely started!
My favorite things about Angular were it's choice to use TypeScript, RxJS for state, CSS-in-JS-like, and Dependency Injection. I'm glad I learned Angular to be exposed to all those choices.
My favorite things about React were JSX and FP.
Seems like you've found a good way to have it all.
This is true for Angular as well. To use the framework you don't need to understand everything it provides. In https://angular.io/start we're aiming to reduce the initial conceptual overhead.
We understand that we can work on simplifying the mental model of Angular. This is something we're working towards. We're careful with in process though because we want to provide a consistent, backwards compatible development experience.
If your definition of usage excludes the hordes of feature-rich production React codebases with no hooks (hooks being a relatively recent React addition), I'd call that definition...counter intuitive.
I've used both for non-trivial apps. I find angular heavily over-engineered. The problem is not just the learning curve, but the fact it becomes almost impossible to do anything the framework authors didn't envisage. React is just plain functions so you can do whatever you want, it never got in my way.
Now, if angular would prove substantially better in terms of performance or maintainability or so, that might've been ok. But they're not. Performance is on par, I find refactorings actually harder because of the heaps of boilerplate angular requires, etc. They invented way too complex solutions to solve problems that either don't exist, or other frameworks solved better.
That is an unfair comparison a fairer one is react + redux + hooks + middleware thunk + routing vs angular. You are still probably right in what is simpler. Just angular is kind of the kitchen sink option
I'm comparing my experience from rather big real world apps. So the react app had all of that (didn't use redux though).
To give just one example. If you want to dynamically import components, in react you just use a dynamic import, since it's just like importing any other js function. Compare this to the angular way and draw your own conclusions: https://angular.io/guide/dynamic-component-loader . Granted, angular may have things that are easier to achieve than react as well. And I don't like the looks of jsx and so on. But my generic experience was that angular was always working against me. It reminded me of my java EE days.
Have used Angular2 since alpha for a big project.
Switched to React + Typescript for the next project.
In my opinion React + Typescript is the way to go, especially if you'll use external libraries.
React and angular basically both do the same thing: render a component tree to (usually) the DOM. You use a framework to make this easier for you and I think react does that way better. But if it's all about raw data manipulation and using that canvas lib, you may not need either?
I think learning curve for Angular is steep compared to React. For React, all I need to know is javascript and I can start writing components but for Angular, I must go through some documentation to get basic idea of jargon it preaches before I can do anything substantial.
Not saying one is better than other but in my opinion, entry barrier for React is lower than Angular which may be an important factor for React's popularity.
Doesn't opinionated and professionally engineered structure mean "better"? Clearly most of the JS coders don't have expertise sufficient to engineer their structures professionally on their own - isn't it better to embrace a professionally engineered structure done for you for free?
If you have a corporate web app the connects to dozens of secure services, an opinionated framework specifically designed to manage that well is not “over engineered”.
Conversely, if your web app has one api to call, you may find an opinionated framework to be a rocket engine where only a lawn mower engine is required.
I have not done much react apart from a "hello world", but I have been using Angular2+ for years, having previously used AngularJS. Here are a few thoughts:
The learning curve is steep I agree. There does feel like there is a lot of ceremony and boilerplate required for even the more basic "hello world". Also if you are not familiar with RxJS before learning Angular then that is a second learning curve that you need to know too and it is a challenge.
The docs are also very frustrating:
- the API reference is usually just auto-generated with perhaps a single sentence saying "The FooBarDooDad does foo to bar" with zero other content, e.g. https://angular.io/api/core/Query
- the tutorial guides are absolutely huge epic documents, scrolling screen after screen after screen after screen and are far too long and far too convoluted to be useful in my opinion. It feels like they are several entire chapters lifted from a printed book or something, rather than something useful for a developer trying to implement something. E.g. https://angular.io/tutorial/toh-pt6 (and that is just part 6!) I've been doing this for years and I still hate having to go back to those docs.
- the tutorials are all talking about some "Heros" app that I have no idea what it is or what it is doing. I wish they just had examples for the simplest-possible case in stackblitz-widgets that does not need me to know the ins-and-outs of their sample app.
That said, once you are up and running with Angular I have found it is very easy to use, and RxJS is really nice once you get your head around it. Everything works largely as expected, and you can more or less forget about Angular and concentrate on the logic. As far as boilerplate goes, I have found that once you have done the boilerplate once, you just copy-paste from one file to another then do a search-replace for the name etc - takes perhaps 10 seconds etc before you are writing logic.
I would like the Angular team to add some sort of "official" state management feature though in the future. In my view, it is the biggest missing gap in the library and you either have to use NgRX as a separate library, or have to botch a global app state by using either a Service or a convoluted @Input/@Output chain
> Also if you are not familiar with RxJS before learning Angular then that is a second learning curve that you need to know too and it is a challenge.
You are not the only one mentioning this here. Do you believe it's wise to start with learning RxJS before you even approach Angular if you are a VanillaJS/JQuery "dinosaur" looking forward to learn Angular?
RxJS is very cool and well designed, and stands on its own. Worth learning about even if you don't use Angular, but definitely if you do! The basics are easy to understand, but there are a whole lot of deep profound operators that it will take a long time to master, although you don't need them all at first.
Reading the guide and pondering the following table helped me understand how other mechanisms in JavaScript work together and relate to each other, and the corner that Observable occupies:
RxJS is not made for normal people. You have to be some brainy CS wizard to get it. If you're used to more traditional "linear" coding (no matter if functional or procedural), RxJS is a brainfuck with its time/stream component. I hated it when I tried to use it.
Yep it might help to learn some RxJS "in isolation" before encountering it for potentially the first time in Angular.
No need to master it - probably spend an hour or two on RxJS tutorials & samples to get to know it before jumping in with Angular so you know where the join is between Angular + RxJS.
For me, I was first getting into web development before Angular 2 was out. I thought it was super cool that I could make an incrementing counter and a to do list but just couldn't figure it all out.
I then tried React and it just kind of made sense. Since then from the sidelines I've heard Angular has gotten much better but personally don't see any reason to use anything other than React at this point in time.
I think Vue's reactivity system just fundamentally doesn't work which is why Vue 3 is basically an entirely new paradigm/framework trying to masquerade as an update. I have a feeling its going to split the community and end the way angular did.
I haven't used Svelte at all but it looks very interesting.
My old company did the jquery to angular conversion when angular was still alpha. Initial curve was steep because no one was used to doing things that way. After that we were just as quick if not a little quicker. I did a pretty big angular 2 e-commerce site from scratch by myself in 6 months shortly after angular 2 came out. Just use the framework how it's supposed to be used and it all works fine.
on the other side, we went from jquery messes with a bunch of state machine issues to being able to comfortably add client-side interactivity with a lot less worries when moving to Angular 1.x
There were definitely Angular-related issues, but they were replacing a lot of "my state machine is out of sync" issues that just scopes and watching mostly solve (except for the prototype inheritence gotcha)
I rebuilt my company's homepage and SaaS customer area from scratch in half a year, after the old 20 people jQuery team had been stuck for months implementing framework-like features with no useful progress.
I guess whether or not you'll be productive with Angular depends a lot on your experience and expectations. I come from the C++ world and Angular felt like MFC, so oddly familiar.
A family member works at a software company that’s worth ~100MM less than it should be right now because they let Angular get into too much of their app before they settled on Vue.
Because a bunch of college kids and bootcampers only learned React and are afraid of the job market spotlight moving on from where they're standing.
Popularity is not a useful metric when evaluating frameworks. Community engagement and core team motivation are, and some people may use popularity as a proxy for those measurements.
I am working on creating a web app now and for some reason decided to learn Dart and AngularDart at the same and do it with these technologies and it's close to being nightmarish. There are way too many concepts and things that tie together sort-of magically -- all to get a few form fields on a screen. I wonder how people come back to fix issues or add features in their Angular app after a few months away from it.
That said, I think, for bigger groups/companies working on a complex product, I can see that Angular ensures a certain level of "architecture" and code organized correctly instead of being coded to each dev's personal style.
But way too complex for single-person apps or for simple SPAs.
All that to say Angular is less popular because it is too complex to learn and use quickly.
React: Write a function that generates a piece of HTML. Use standard event handlers to manage user interactions. Update state via setState methods. Ship it.
The method for passing data to a dialog component is to import a magic constant and inject a data field into it's constructor? It's a completely over-engineered, nonsensical solution for a problem that doesn't even exist in React. There's so much stuff you have to be familiar with in Angular just to build the simplest features.
Don't use this library as an example of Angular code. I've written dozens of Angular apps and none of them were so over-engineered. AngularMaterial is a good example how to not design API. I'm sorry if it insults some people - we all make mistakes, it's ok, I'm sure you'll next library will be better and I understand it's too late to change API in a project, when some huge Google apps are using it.
Not only is @angular/material the most popular component library by a huge margin but it's maintained by the Angular team itself. If it's as bad as you say it is that really doesn't inspire confidence.
The last time I looked at Angular Material was quite some time ago, but at the time I was really surprised because it didn't follow the conventions established in the docs, and the conventions it did use seemed nonsensical given the design of the Angular framework.
I can only guess that "same team" was a design-centric subteam for Angular while the engineering-centric team worked on the framework/documentation itself, or that Angular Material was under pressure to get implemented before all the best practices were established and by then they were stuck with the API.
Having suffered on a large Angular code based on Angular 7 and then Angular 8 for a couple of years, I just wish Angular would fucking die. Every small thing is a giant shit-pile of services, components and HTML templates that are all accidental complexity.
It reminds me of the whole .NET ecosystem. All of these custom magical special ways to do everything, compared to ‘dumb’ setups like node/ruby/go where the actual logic is just right there in front of you
And every release .NET just keeps moving closer to the dumb systems. Simple and raw is good, keep the magic away
I am really glad there are other people who think this way. I am experienced with Python/JS/Ruby web app development models and recently had a look at ASP.NET Core web api projects.
The amount of complexity is mind boggling.
I mean, look at Flask in Python. Or even Expressjs in Node, why can't Microsoft come up with a simple framework that can run well on the .NET runtime?
I am a huge fan of C#, having used it for Desktop app development.
I would love to have a framework like flask in the .NET ecosystem.
Ah, yes, expressjs, or as I like to call it, "the mutation ecosystem," where who knows what middleware has mutated which object in which way, and whether any state has leaked or whether any assumptions about control flow will actually hold true. Where it's common to see callbacks, streams, Promises, generators, and async/await patterns all thrown together in a mishmash that requires continuous syntactical context-switching.
Honestly I'd rather develop in vanilla NodeJS where the approach is at least consistent, than in the Express ecosystem where sure your problems may have been solved 1000 different ways already but where none of them really fit what you want to do, and where there are many layers of hidden incompatibility that are going to require you to make adapters for each library anyway.
Is something like Nancy [0] close to what you're after? I've not used it myself because I prefer the structure of the full approach but from my extremely brief interaction with Express in Node it seems similar?
If you have enough governance in an enterprise org to standardize on Angular, you should also have enough to standardize on a particular React stack, and not just "React".
Yes, same goes for Vue etc. You can hardly govern the freedom React provides. If you do, you can use Angular in the first place, because it has solutions out of the box. This is not to discredit React or Vue.
I am judging from my experience developing applications with 200+ developers across continents. You can write crappy code in Angular as well, but it helps you govern your architecture and your app. If you want modular components that can be reused, go for Angular. For smaller things or landing pages use Vue, React.
React: discover that function alone doesn't do all that is expected from an UI Framework, go hunting for a myriad of libraries to handle state, communications across components, tune performance 'cause FP approach makes GC do overtime, endless hours explaining to fellow devs what is this FP stuff all about,....
And honestly, if misused you can really tank performance quite easily. The learning curve can make it incredibly difficult to introduce to a team of developers with variable skillsets.
Yep, when I was studying Angular I kinda felt it was trying to reinvent everything, so personally I can wrap my head around React a little bit more. However I know people consider React more of a library, maybe Angular is more of a full on framework?
Stencil provides similar experience to React, plus Stencil compiles every component into typed web component, so it works with other frameworks as well.
9 major versions in ~7 years indicates that it's not remotely stable enough to be taken seriously, particularly for corporate stuff that will likely never get an upgrade. Even the "LTS" releases are only supported for 18 months.
React seems a bit better, but they don't seem to support older releases at all.
This couldn't be more wrong. The team does a great job handling upgrade paths post 2.0.
First off, Angular versions post 2.0 are nothing like AngularJS/1.x -> Angular/2.0. They are much more incremental and even the two times the entire renderer has been re-written it was an incredibly gradual process over multiple major versions with seemingly few changes to component and template APIs.
Second, upgrading between Angular versions couldn't be easier thanks to angular schematics. The process takes seconds and for specific rarer exceptions the team maintains this fantastic guide here: https://update.angular.io/
> This couldn't be more wrong. The team does a great job handling upgrade paths post 2.0.
The problem isn't how it's handled or how incremental it is, it's that there are so many upgrades with breaking changes, at least that's what they're communicating to me with their version numbers. There's also the lack of any real LTS versions I mentioned, 18 months doesn't cut it.
> They are much more incremental and even the two times the entire renderer has been re-written
Telling me that they've rewritten major components that frequently isn't exactly convincing me of the stability, its validates my previous belief that it isn't stable enough.
When they've got versions that are supported for 5+ years post release I'd consider it stable. It doesn't matter how good your upgrade guide is when you run into a bug or limitation with the current version and realize that you have to upgrade the entire framework and deal with all the breaking changes to get around it.
Compare that to react where you've got at least 3 years (assuming they follow semver) between breaking changes.
React has some really painful breaking changes over the last 3 years - Angular did breaking changes in a far more user friendly way. The last breaking change that happened from 16.8 to 16.9 partially ended up resulting in us calling bankruptcy on our main app and helped make the decision easier to rewrite it from scratch on a team where the core members who worked on the app have over 70 years of experience amongst 4 devs.
Fair enough, but I'm not sure you understand how nice schematics are. You can use them for a lot of things, but one nice use case is essentially update migrations. You literally just run `ng update @angular/cli @angular/core` and a majority of the time you're good to go...
I have a policy of only shipping "back-end" apps because I'm worried about performance, browser compatibility and SEO. I don't know if the situation has improved in Angular 9.
Does anybody here use Angular for their customer facing websites?
We use Angular for the Alabama Dept of Forensic Science's DNA Tracker and the Alabama Dept of Public Accounts. Both seem to work well and have good performance.
It is still early days, and isn't suitable for every use-case, but it could be the answer you're looking for. Continue to write back-end code only. But with the benefits of quick-response front-end app. I'm a total convert (evangelist) who has been increasingly put off by the evolution (devolution?) of front-end development over the past 5-10 years. This could be one way of the mess.
It's not Angular's architecture I have a problem with. As a former Delphi and current .NET developer, Angular fits like a glove, not to mention Typescript which was created by Anders Hejlsberg.
It's the output I'm worried about. The HTML outputted by Angular pre-Ivy is verbose and runs very slow on old browsers (IE9, with polyfills). A customer facing website can be visited by anyone, from a tech savvy Linux user to your grandma which uses Internet Explorer and thinks Facebook is the internet.
I don't want to face the wrath of clients who realize that their website is slow and non-optimized because I'm using Angular.
I've been running the RC's at least the last 6 months or more, upgrading usually within in day when the new one comes out. I've been impressed but what I've seen is that even though A9 is very good (Well done developers) when the real world hit you and your app. Its many times all the other nonsense you have to include in your app that makes it big and slow (GAnalytics,GAdsense, fb-pixel, crazyegg and and and)
Still wouldn't want to code without it !:)
There are no words on ESLint instead of the deprecated TSLint... :/
Would really like to do the switch, but official support by Angular is more important at my company.
I just upgraded and got 'Failed to load module script: The server responded with a non-JavaScript MIME type of "text/plain".' from my S3 through CloudFront.
Seems like it's not adding 'type="text/javascript"' to <script> in index.html. When adding this manually, everything works.
Just FYI if others upgrade and seem to get the same errors.
Modules, however, enforce strict mime type checking. As the comment below suggests, you should make sure your static file hosting serves JavaScript with the correct mime type.
Normally type=“text/javascript” is strictly unnecessary. You should try to configure whatever is uploading your site to S3 to set the Content-Type correctly as I believe that will also resolve your issue.
Can Web Components pretty much do everything without a framework now? I think Ionic moved to it for example. If we already have our own code for loading and rendering components, using Handlebars templates, what would we need to do to make them into web components instead, or make all of ours compatible with the latest React or Angular?
The specifics for anyone who cares:
When we began our own framework, way before React and Angular, we built our own, kinda “sane” reusable component engine. We called them “tools”. One tool on an element is a component. But you could also add multiple tools on a component, to add or remove behaviors:
Basically, we figured it would be easier to just let Templates, HTML, CSS and JS each do what they were intended for.
HTML side
1. We had <div class=“Q_Tool Streams_chat_tool” data-streams-chat=‘{“foo”: bar, ...}’> easily exporting json from php or templating engines, very readable and completely standard (no JSX or custom components). It was just slightly longer to write but provided useful metadata. It used to be called microformats back in the day. Multiple tools can be added on same element this way. The element didnt have to be a div.
2. We had handlebars helpers like {{&tool “Streams/chat” foo=bar}} and Q.Tool.setUpElement(“div”, toolName, options), or pass an element instead of “div” to add a tool on an existing element. We also had a jQuery fn method like $(“foo”).tool(“Streams/chat”, options).activate() .
3. Our users just called var element = Q.activate(Q.Tool.setUpElement(“div”))) in vanilla JS or $(“<div />”).tool(...).activate() if jQuery was loaded.
* CSS side*
1. We namespaced our CSS by Modulename_toolname_
2, Some tools took advantage of shared CSS classes defined in the module or a module they depend on
Javascript side
1. We just had Q.Tool.define(toolName, constructor, defaultOptions, methods) and the tool.state would be the options merged over the defaultOptions. It was all customizable and merging was done via a smart Q.extend() function that we tweaked to eg combine Q.Event handlers in the best way.
2. Ways to access tools on an element would include Q.Tool.byId() and element.Q.tools etc. The tool ids would be autogenerated so as to establish a hierarchy of which tool was a parent. Then you could do tools.children([filterName]) and tools.parents() and so on. Traverse faster without touching the DOM.
3. We had Q.activate(container, options) to activate tools within a certain container. Javascript for tools would be loaded on demand, and tools would be added/removed on demand. We had Q.Event.prototype.add(callback, key) take a String key or a Q.Tool, so events would be automatically removed when a tool was removed.
4. You could also do Q.Tool.define([toolName1, toolName2], toolName, constructor, defaultOptions, methods) to have tools require that previously named tools already be activated on the element. This is for composability of tools, something more general than inheritance. Let’s say you have a chatroom and you want to add support for @mentions to it and https://linkscraping.com as you type. So you’d make tools that work in top of Streams/chat.
It seems to me that ANYWAY your user will have to load a Javascript file that defined your web components. And ANYWAY they will have to load javascript on demand. And ANYWAY this javascript may be packed into a single file so you’ll have to actually check whether a variable has been set before loading modules dynamically so you dont want static loading. And ANYWAY your tools may want to use shared css so you may as well namespace your CSS. And ANYWAY your default options may include event handlers or other things you can’t serialize easily into attributes of an element. And you may want to compose tools or find them with CSS so what’s wrong with using CSS classes instead of the element name for that? And ANYWAY you will want to render your tools in a readable way so why not stuff JSON into data attributes which were allowed for exactly such purposes? And ANYWAY you may want to use a powerful templating engine like Handlebars. The only part I am not sure of is the last one.
Seems to me - but I am biased - that we have the optimal approach. If something else comes out we can just turn Q.Tool.define into a wrapper around window.customComponents.define. But our users won’t have to change a thing. They can continue to use Q.Tool and Q.Page and Q.exports(arg, arg) and Q.requires(module, callback) without worrying what’s underneath. Isn’t it better and more stable?
But everyone got into Angular and React with its JSX etc. I think the main sell was the dirty checking (the model in Angular, the DOM in React). So you can just render a large chunk. I never saw the benefit of that. You should reason about mutations imho. Components are views with their own viewmodel, that’s all. You can update a bunch of state parameters and then call stateChanged(“a”, “b”) which would requestAnimationFrame() and update stuff. Is it so hard to call stateChanged() after changing state.a and state.b ? Do you really need to instead grok digest cycles or a virtual dom??
I've been going down the long road of learning Angular recently, and I love it and want to learn more, but I have a couple naive newbie questions whose answers I thought should be obvious, but I haven't been able to figure out:
Is there a standard way to define local variables in an Angular template so you don't have to repeat the same redundant expression again and again (or so you can at least give an expression a self documenting variable name so it's not so mysterious)? Or do you have to define an instance variable on your component and figure out how to initialize it to the right value before the template gets executed, with no way to lazily (or repeatedly) evaluate it by putting the calculation inside conditionals (or loops) in the template so they're not run if they're not needed (or to calculate the local variables independently for every loop iteration)? Is there an angular hook or technique that's meant for that, and efficient, and hopefully doesn't involve much arbitrary non-JavaScript gobbledygook syntax, and is at least somewhat standard and well supported? Please don't tell me I shouldn't ever want to do that for some reason of ideological purity or separation of concerns (as if a templating language could ever be called "pure" or "elegant"). The common legitimate use case is ngIf="some expression is not null" then {{some expression}}, and also ngIf="some expressions" ... ngIf="not some expression".
I googled for it, and the solutions of "abuse ngIf's special goofy syntax to name the result of the condition and pray to God it's truthy or don't bother" and "abuse ngFor to loop over an array of one item to give it a name" are not acceptable answers. There were also a few competing and possibly out-of-date "install this non-standard ngLet directive that I hacked up but don't support, but don't call it with an "ng" prefix because that's reserved for the Angular team" -- but isn't there a standard way of doing such a simple essential thing, that the Angular team already thought of and included, such that other people will have some clue what's going on when they see it? And it would be nice to be able to define more than one variable at once per begin/end tag, if you know what I mean. Maybe even without using any begin/end tags, perchance to dream?
Also, is there a way to easily define simple light weight macros ("snippet reuse") so you can repeat the same pattern in one or more components, without defining a whole component in all its glory and splendor with multiple files that other multiple files need to import and declare? Or even a global file of shared macros that a bunch of other templates can import, like the globally shared css declarations you can include in local css files? I've seen "ng-template", but I am having a hard time getting my head around it, compared to the simplicity and power of Genshi's py:match, that's based on xpath, and py:def, that precisely follows Python function calling conventions and that you can easily call from any normal expression. And py:match is quite useful for defining concise custom tags (or xpath patterns) that can wrap embedded content. In comparison, ng-templates seems quite clumsy and limited, and confusing about calling and scoping and passing parameters and content, which is nothing like standard JavaScript calling conventions, and reminds me more of the abomination that is Zope METAL templates.
I've been using and loving Genshi with Python for more than a decade (and before that, Kid, which Genshi is almost the same as, and before that Zope page templates, TAL, and METAL templates, which inspired Kid and Genshi, but totally sucked), and I love its ability to drop into Python with <?python ... ?> to define some variables or import some functions locally in the template that you can use, with real honest to god multi-line indented Python "if" statements for logic (and Python comments for, err, commenting) instead of Christmas trees of deeply nested ternary ? : operators (or rather postfix conditional "foo if bar else baz" Python expressions). Genshi also has "with" for defining scoped local variables with tags, like <py:with vars="y=7; z=x+10">$x $y $z</py:with>.
And I also love Genshi's py:def for making locally defined or libraries of includable imperative "code snippet" templates you can call just like Python functions (with glorious optional named defaulting args, etc), and py:match for declaring xpath pattern matching templates that can wrap html content as a parameter (so the macro can cherry-pick out and transform different parts of the passed content with xpath), as well as taking attribute parameters.
Another nice feature of Genshi is that for all directives it supports both the attribute form like <div py:if="condition"> ... </div> attached to an element that you want to keep, or the element form that dissolves without leaving an element, like <py:if test="condition"> ... </py:if> . You can also attach multiple directive attributes to the same element, thanks to the way it executes them in a well defined ordered hierarchy that makes practical sense (like "for" above "if", so each iteration of the "for" loop can be conditionalized with its own "if" evaluation), and "def" above all else, so you can define a single tag macro that loops over something then conditionalizes each iteration, then sets attributes on and adds content to the included elements. It's quite concise and expressive!
<div py:def="FizzBusted(count)" py:for="i in range(count)" py:if="i % 3" py:attrs="{'class': 'orange' if i % 7 < 2 else 'blue'}" py:content="['odd', 'even'][i%2]"/>
Processing order of multiple attributes (precedence rules you must remember, but they make practical sense, and at least Genshi is quite minimal and only has a few directives):
py:def
py:match
py:when
py:otherwise
py:for
py:if
py:choose
py:with
py:replace
py:content
py:attrs
py:strip
These two features (local variables and code snippets) are so important to me, and I'm having such a hard time figuring out how to do them in Angular, that I feel like there's whole a chapter in the Angular templating manual that I missed somehow. Thanks for any tips on how to do this kind of stuff with Angular templates!
I've written more opinions about Genshi and templating on hn before:
Here is the one big important thing that Zope Page Templates (and Kid and Genshi) got right: don't violate standards and be incompatible with standard tools, for no good reason:
>As mentioned previously, Zope Page Templates are themselves XHTML documents, which means they can be viewed and edited using normal HTML editors or XHTML compliant tools (a big advantage compared to other template languages used for Web applications). Templates can also be checked for XHTML compliance so you can be fairly confident that they will automatically expand into proper XHTML.
> Is there a standard way to define local variables in an Angular template so you don't have to repeat the same redundant expression again and again
I usually define something in the component, and reference that. If you need to lazily evaluate it you can just reference a function in the component (e.g. "...{{ someFunction() }}...", and have the function do whatever lazy work and/or memoisation you need there.
If you need things to be initialised before the template is ready, you can use one of the life cycle hooks - e.g. ngOnInit(). More details of the different hooks here: https://angular.io/guide/cheatsheet
... that said, it might be easier (depending on context) to "learn to love the bomb" and just rely on Angular's binding to update the template as soon as the value becomes ready after the template has rendered - i.e. don't sweat about getting everything ready before the template loads, just let Angular handle the data binding and let it update the tempalte when the value is ready. This is where the RxJS stuff really shines since you can forget about a lot of the sequencing and just let Angular handle getting the right value on the page when it becomes available. Unless you are doing long network calls or heavy computation, everything is usually in place by the time your brain registers seeing the page anyway so it mostly works out OK and no one notices any thrashing of templates going on under the covers (... although there is a part inside of me that dies when thinking about the performance/wasted CPU cycles).
> is there a way to easily define simple light weight macros ("snippet reuse") so you can repeat the same pattern in one or more components
I have also suffered this recently. I am not sure how this is "meant" to be done, apart from making everything a separate component. I guess the argument is, if you need to use something in multiple places then it is an ideal candidate to become a component. For these "lightweight" components I will usually just use inline templates for the component decorator (rather than referencing a separate HTML template etc), e.g.
@Component({selector: 'snippet-one', template:`<b>My First Snippet</b>`}) export class SnippetOne{}
You can put a load of them into a single "snippets" module, import the "snippets" module when you need it, and then simply include that where I need it in other templates with <snippet-one></snippet-one> and so on.
I agree though that sometimes it would be nice to just have a file you can just easily drop in where you need it.
Here's another newbie question, if you don't mind: What would be the optimal place to hook to get a callback to draw something in a canvas whenever the DOM is updated?
I'm currently subscribing to changes in a BehaviorSubject<any[]> instance variable of my selection service "god object":
Is that a good way, or might I miss updates for changes to component instance variables and other reasons? Is there a canonical Angular callback that's recommended for stuff like drawing a canvas view after any changes have been made to the DOM?
You can use ngOnChanges callback to react to changes in the angular framework - i.e. if bindings/@Input()s/etc have changed and you want to do something special there when they change. But for just generic DOM changes happening outside of the angular framework that wont work (since angular does not know about random other DOM stuff going on elsewhere in the page and outside of the framework). E.g. if there is some static JS code in the page doing stuff to the DOM, angular won't trigger ngOnChanges for that.
For your approach, that looks reasonable to me in the 5 lines we have to look at :-) ... so long as you are consistent with the SelectionService and make sure all the changes go through that, you should be fine and your component will get all the updates.
This sort of requirement for consistent management of things like this - i.e. the application state - is a weakness of Angular I think. It is easy to start simple and end up coding yourself into a corner with god services etc. I have used a thing called NgRx in the past for managing state - its the redux pattern and seems to be quite good at making sure state is a bit more sane and well-mananged in the app (at the cost of some boilerplate). One day I hope that there is an official state management mechanism.
Thanks, that sounds like the right approach. I don't need to react to all DOM changes, but I have one jolly callback for changes to my one big happy god-owns-the-user-owns-the-world object (the observable), but the component has view-level properties like hiding and showing details, zoom and pan, etc, that aren't in the observable model, and I'd still like to redraw the canvas when they change. It doesn't take long to draw, but I just don't want to miss any updates, or have to pepper the code with explicit calls to redraw it every time I think something might have changed (causing a lot of pointless redrawing).
Fortunately my app is simple enough that I can just redraw everything whenever something changes, as long as I'm not doing it 37 extra times.
Thanks, that's great advice! Angular is really great when I can get away with just not worrying about the bomb -- it's amazing what little effort it takes (I just wish ng-component was spelled with only one or two letters). But there are still those things I'm used to being very easy to do in Genshi, that seem incredibly complicated in Angular, and don't leverage JavaScript. Granted they both have extremely different architectures, but local variables seem like a no-brainer, and lots of parts of Angular use them indirectly like ngIf and ngFor, but as far as I can tell, Angular just doesn't give you a pure direct form of ngLet that supports binding multiple local variables at once, for your own use. And ng-template is just weird.
I get the impression that <ng-template> is actually just directly exposing some low level implementation mechanism, and wasn't specifically designed to be a concise, powerful, general purpose, easy to use templating system, or behave in any way like JavaScript.
I keep trying to work my way through this otherwise pretty good tutorial:
>This is what happens internally as Angular desugars the more concise ngIf structural directive syntax. Let's break down what happened during the desugaring:
>the element onto which the structural directive ngIf was applied has been moved into an ng-template
>The expression of ngIf has been split up and applied to two separate directives, using the [ngIf] and [ngIfElse] template input variable syntax
>And this is just one example, of a particular case with ngIf. But with ngFor and ngSwitch a similar process also occurs.
At this point I'm starting to feel dizzy, like when Scorpius needs his cooling rod changed.
But when I got to the stuff about ng-template with parameter attributes prefixed by "let-", and tacking ";context:ctx" on to the template outlet name, and then having to stick some instance variable into your component source code (which is usually a separate file), my eyes glazed over and my palm hit my forehead. It's like learning a whole new set of cult-like jargon and mythological concepts (Outlets??! Why so many layers of indirection and different names for the same thing?), instead of reusing anything I already know about JavaScript, simply to pass parameters to a template. Maybe this is just a bad example and explanation of ng-template, but I haven't found a better one yet.
That's how ZOPE METAL templates felt: it was such a big fucking ordeal to pass every single parameter through a named "slot", each wrapped in its own special outgoing and incoming namespaced XML tag, like COBOL with angled brackets. When it's all just clean simple Python underneath, but that's hidden from you, and you can't just use Python expressions and calling conventions, or XML attributes, or xpath, or define concise custom tags with attribute and content parameters, or write general purpose Turing-complete macros like Lisp.
I just ran into another problem with Angular templates that illustrates the value of a templating system at least supporting the underlying implementation language's straightforward syntax and semantics for loops and conditionals and parameter passing, before going off and inventing all kinds of totally new unique special custom control structures, domain specific languages and micro-syntaxes, indirect ways to name and pass parameters, and other linguistic whoopee cushions:
How do I make an ngFor loop iterate through a range of numbers, without actually defining a literal array of numbers in the component for it to loop over?
With Genshi, you simply do it the standard python way, since Genshi for loops are equivalent to Python for loops: <div py:for="i in range(count)">$i</div>
But I can't figure out how to, for example, use ngFor to iterate from 0 up to n, since it requires an array argument, and there isn't a c-like form like for (init; condition; repeat), or a standard JavaScript way to make a range like python's range(n).
Should I just give up and make a "range" utility method on my "God" service object that I'm passing in anyway? The more gaps like that I have to plug with my God, the more it becomes a God-of-the-gaps object.
In my opinion, Aurelia has always been the less complicated and lighter option of the two. Aurelia 1 had some design choices that made it harder to tree shake down, but Aurelia 2 is around the corner with AOT and numerous optimisations that looks like will put it at the top of the benchmarks again.
This was a fast release cycle. It was back in November 2019 we were talking about 3.7, and now it's in.
I'm not even thinking about Ivy. But it's nice to have all the nice comforts of typescript ready and working out of the box. (I mainly work in React, but dabble with angular/vue to stay up to date)
And what a smooth update process (abbreviated):