DEV Community

Cover image for Angular struggles in 2020

Angular struggles in 2020

Lars Gyrup Brink Nielsen on July 21, 2020

Cover photo by Pixabay on Pexels. The views expressed in this opinion piece are entirely my own. They do not represent any organization. You're g...
Collapse
 
martinspire profile image
Martin Spierings

So Angular hasn't been doing well for a while now. Many devs have stepped away from the framework when it moved to 2.x and its not weird to see that happening. But I still think there are enough companies remaining to keep the framework alive. Something needs to happen at google to reorganize and perhaps take a few major steps (like removing some of the toxic but brilliant minds to get a more stable work environment). I don't believe the people that left are really the issue, there's a few guys leading the project that are difficult to handle and its time to get rid of them. Even if they mean a lot to the project.

Next a couple of things about the issues mentioned. Every project has those and its not that uncommon.

  • Bazel is neat but its not a must have. I feel that there's a lot of "oh this looks cool, lets see if we can get it working" without really realizing that many projects aren't really looking for that. Similar to that the stuff we need to do to set up projects and improve performance go beyond the issue. Sure you can optimize the start with 2ms but your code just got 10 times more difficult to read and understand. In the meantime devices are getting faster, less people use IE11 and whatnot, so all those optimizations are still insignificant for many projects, especially those in the western world (where still the majority of the framework lies)
  • TSLint is not that big of a problem. I recently tried to put ESLint on the project and noticed it wasn't really working out, so its clear it needs more work. If there's really a major issue with it, they could always fork it and fix whatever needs fixing. Is it a shame? Sure. Is it a big issue? Nah.
  • Angular Material is doing its thing and imo thats fine. Its a shame its not really going to be a good example for how you normally would set up a styling kit, but as long as the output is usable I don't really see an issue. Google wants things to be easier to manage, so be it. We still have lots of alternatives too and right now Bootstrap is still a big contender anyways (which will probably do something similar). I think styling overall could use an overhaul in how you develop it and how much baggage you get in each component. It should be easier to inherit parent styling and global styling without duplicating lots of code.
  • Ivy remains a difficult topic but its clear why and it just needs time. Meanwhile the project is still usable and migrations are coming along. If you thought this was going to be done in a month or so, you were mistaken. Again, switching something major like that is going to give issues and migration periods. Big whoop.
  • Protractor. While I see there's an issue, its not impossible. Plus I think right now Cypress is getting a lot of traction and moving to that is no big issue (when you got the right setup working, which the Angular team could port), moving to that wouldn't be an issue. I recently moved to it and it was a blessing on how easy it was to debug my E2E tests and still work with the framework. If Cypress keeps developing like it is, I can see them switching in the future. Same with Jest, though Karma/Jasmine is still much faster than that. But I found it to be much easier to work with. With stuff like this its up to the team to decide whether maintaining their own system is worth it. I already find that some of the stuff I use for testing (NG Mocks and NG Spectator) should be part of the framework to improve/simplify/speed up testing.
  • Angular Elements is nice but I never really saw that as a solution. Angular is best when its working as a package deal to do an app rather than components. Still, this is a development that will keep moving on. But I still think that React is a better fit for that, but that doesn't mean it should replace Angular.
  • ZoneJS has always been a sort of temporary solution. Again, if it really becomes an issue, there will be a temporary fix to fork it or whatever. Having ES2018 bundles is neat but still nothing useful for 90% of projects that still need to support older browsers. Mobile doesn't always get updates, especially for hybrid apps, and lots of corporate systems use old browsers. Its a similar situation where Android developers or pc app/game developers are in: people aren't always updating their shit and it will not change. I think that 2021 is only really going to make such a shift when most Edge browsers on Win10 systems have been replaced with the Chromium thing and more Android browsers are updated. Again, not a pressing issue.
  • Packages get abandoned all the time. From stuff that was launched with Angular 2, a lot isn't really supported. New frameworks come and go. Its how the web has always functioned. Lots of people jump on the bandwagon, see that its all more difficult than expected and either drop it or move to something different. And if you really look at some of em, there wasn't really a future in it anyways. The list for Angular 1.x is longer imo, even when it dominated the market.
  • The issues list, sure there's issues but that has always been the case. But has it been rising because of major issues with the project or because more stuff was found because people work from home and perhaps have more time to do their projects and whatnot. And with the changes in the angular project, you can't expect 100% productivity either (combined with issues for working from home and such). You are making conclusions that aren't really warranted. Yet.
  • Roadmap. Yeah this is a thing that bothers me too but I think right now the roadmap is just: fix whatever is broken (especially with Ivy) and maintain whatever isn't. Some things on your list are nice to have, others I think shouldn't be a priority really. Sure the observable stuff and dynamic rendering would be handy but I can still work without them for the time being.

Right now I think we should give Google a moment to organize and see where this is going. If by the end of the year its still in terrible shape, people should consider forking the project and take control ourselves (or have some other company run things). I wouldn't be surprised if a company like Microsoft is willing to take over, seeing how much they have been investing in Open Source and TypeScript. Perhaps improving the compatibility and portability of C# to web or something fancy.

These past few years have made it clear that Google doesn't really have a lot of interest in Angular, but their alternatives are also slimming down. Lots of people move to their competitors (React/Vue) and it doesn't look like Polymer is really getting there either (that project is in worse shape imo).

Overall I don't really see a need to start using other products, especially in the app-style projects that Angular is currently being used for. But yeah, the community needs to take a look and wonder if its still in the best hands at Google or that things need to change. You made a nice list on where they could start to focus on, but I think we should give them a bit of time. And instead of turning articles into doomsday negativity, rather give them feedback to build on and work together to get the project back on track.

Collapse
 
sebastienlorber profile image
Sebastien Lorber

Microsoft is investing in React and particularly ReactNative recently, with support for Windows et MacOS. Supporting TS does not imply supporting Angular ecosystem, we React devs also like TS.

Collapse
 
layzee profile image
Lars Gyrup Brink Nielsen • Edited
Collapse
 
gr3g5ki profile image
Greg Ski

I don't see how Microsoft is going to take over. They're pushing Blazor.

Collapse
 
layzee profile image
Lars Gyrup Brink Nielsen • Edited

As long as Blazor requires shipping a several MB client-side runtime or a chatty WebSocket connection, it only makes sense for enterprise. Angular shines in enterprises, so I guess it's a fair comparison.

Thread Thread
 
wa1gon profile image
Darryl Wagoner

Several MB that is cached on the browser isn't a big deal for enterprise users. Having a poorly supported framework with infighting between management and developers is.

Collapse
 
mlcmlapis profile image
Miloš Lapiš

Be a bit serious. Using formulations like "Many devs have stepped away from the framework when it moved to 2.x and its not weird to see that happening." and pointing on the version 2.x, where everything was created from the ground, doesn't sound me as a serious argument. On the other hand, I understand that there are some people who still like AngularJS.

Collapse
 
frosty profile image
Aaron Frost

A few people missing from this are Tobias and Chuck. These two were... irreplaceably smart. Not sure if Rob Eisenberg belongs on this list, too. But... if we're going as far back as Jeff and Victor leaving... it seems like that may be appropriate. Also, I think it is valid to say that we lost Jules. Even though we got her back, she did leave once. I think it is better that she is here. But... she did leave.

I feel that there are more too, though.

Kara is leaving for a well deserved promotion on another team at Google. Brad also left for a great opportunity. When Jules left, it seemed that it was also for a good move. Those are good moves.

Too many of those on your list, though, corroborate the same stories of manipulation, control, and abuse. Once more than one person says something, I tend to start listening. Once it's up to over half a dozen... if you don't listen you're choosing to enable the abuse.

Collapse
 
jeffbcross profile image
Jeff Cross

You know I love you Frosty :). But I know from personal conversations with some people you mentioned, their reasons for leaving aren't necessarily as positive as they seem. I don't want to speak on their behalf, so I'll leave it at that.

But your point is valid, some people have left the team because they were just presented with better opportunities, not to escape. I think it's a minority though.

When I left the Angular team, it looked positive because Victor and I were starting a company! It ended up being great, and I talked openly/publicly about all the good reasons to start Nrwl, but I didn't speak publicly for another few years about what really pushed me away from the team. You and I were friends back then (and still are), so you knew exactly what I was going through, but most people only saw the happy story.

Collapse
 
bradtaniguchi profile image
Brad • Edited

So lets make 2 thought experiments:

  1. We continue (the Angular team, and community) down this same path for the foreseeable future. What happens?

  2. We stop and ask for help. Assuming we can get what we want within reason, what should be done, in what order? Whats the "perfect version" of Angular?

Obviously these are thought experiments and I don't think there are any wrong answers to either, I'm just curious as to what sorta options there are.

I would hope Google get's Angular back together. If not it may end-up in the Google graveyard, where Google just uses something else internally. (Like Polymer, which is used on a bunch of user facing apps already) I honestly could see this happening. Probably not fast in any respect, but slowly and painfully.

I'm honestly not sure what the "best" move would be at this point. Obviously better leadership internally seems to be a big factor. This is open source, and a fork (gasp) might happen. Due to the surface area of Angular, this might be an insane
task in itself.

PS comparing Angular's combined issues to React and Vue seems rather unfair in that neither have nearly as much code/surface area as core Angular repos (the three listed and combined)

Collapse
 
jonrimmer profile image
Jon Rimmer

I would propose two things: First, change the governance model of the Angular project to be more transparent and more open to collaboration with the community, particularly non-Google entities like Nrwl. This could involve transferring ownership of the project from Google to a foundation.

Second, be realistic about engineering capacity vs. ambition and reduce the scope of the framework's core to what can actually be maintained. Move some parts of the framework out of the core into community-managed projects. For example, both reactive forms and the router have seen very little attention from the core team, but as long as they are official parts of the framework, it is very difficult for alternative implementations to gain traction.

Collapse
 
fxck profile image
Aleš

My thoughts exactly.

Collapse
 
layzee profile image
Lars Gyrup Brink Nielsen

Thank you, those are great suggestions. I don't have an answer, but something needs to change. We need to be discussing issues and alternatives like these in the open.

Collapse
 
ahmadalfy profile image
Ahmad Alfy

Move some parts of the framework out of the core into community-managed projects.

Hell no, look where did that get react native

Thread Thread
 
antonmelnyk profile image
Anton Melnyk

Where?

Collapse
 
jwp profile image
John Peters • Edited

All news to me, but as I read Jeff's letter to the Angular Team, it described something very familiar to me.

2 Root Causes of a Failed IT Utopia

Bad Management

  • The environment of any IT shop is the responsibility of the management chain. This goes all the way to the (ba-zillionaire) owners, their (millionaire) board members, and their (highly paid) 2nd and 3rd line managers as well as the lowly (paid) 1st line manager. People in the trenches are mostly aminable, except for the 'zoomers' (those that want to zoom to the top).

If we decide the environment is toxic, then we :

MUST GET OUT QUICKLY to save our health, mental well-being and minimize the PTSD.

Unfortunately it's the PTSD that lingers for months and even years. Its like coming out of a cult.

Self appointed CZARS

  • There are self appointed CZARS at every corner of the IT workplace. These are the zoomers. Their intelligence is often over the top, but they are anti-social. They are self appointed spies attempting to win at any cost. They sabotage anything that may zoom past them (upward). They keep the lid sealed on entire teams. Sometimes management buys in hook, line and sinker.

  • Amiable Zoomers are people that are promoted for being nice. They are often not top notch technical folks, but work on anything as directed. They can cause PTSD too because; as managers, they never address anything for fear of offense.

How to Spot Toxicity Early

It all boils down to one easily identifiable trait, Selfishness! We all know what selfishness looks like. We need to assess our environment regularly asking just one question. Do I feel included in this effort?

You should NEVER feel like a foreigner, or a low-life less-than-par person.

Angular will Survive

  • Remember, Angular is not a profit center for Google, it's an expense other than the business they may get from it for their Cloud offerings and other contracts.
  • Angular and the V8 engine are mature. We're only going to see incremental improvements from here out.
  • Entire teams are often swapped out for a fresh team along with lesser amount of people. All software maintenance and enhancements are expensive.
  • We see Angular is open sourced, which is good. It needs to stay there and perhaps have the Google team pull back just enough to work on new features.

Comparisons of the past

  • Java was a rage. Today's it's just Java with a ho-hum support team.
  • C# stole Java and went though major innovation, today something like string interpolation (in JavaScript style) is a huge line item on the new release.
  • WPF is still alive today but is ho-hum due to the team being moved to other projects. It was open sourced way after the community declared it dead. That lateness was too late.
  • C++ was the rage, it's still alive today but makes many people want to vomit.
  • JavaScript was a stupid language made popular only because it was integrated into the browser. Are we still using JS2015 in 2020? And did it only recently get better once Typescript started disrupting it?

Today there's new rages brewing like HTML5 Components (which hasn't taken off like it should). Rust is even being adopted by MSFT? IE is now using Chrome Engine?

To the Metal

Should we ditch all of these framework in favor of HTML5 components that are closer to the metal? Yes. But we won't because it's way to convenient to return to our old pal Angular. We know it, it works and we are tired of learning new things every other day.

BTW

The pain Jeff described is a very real thing, the idea that we go to our workplace torture chamber everyday, and staying because we "believe the dream". This Leads to heart-attacks, super-low self esteem, bad eating habits, high blood pressure and treating family members poorly etc.

Jwp

Collapse
 
thorstenhirsch profile image
Thorsten Hirsch • Edited

The developer experience of Angular isn't that bad at all. I currently re-learn Angular with v9 and v10 and see a lot of appealing features:

  • it's a complete framework with solutions for all my problems (so far)
  • integration of material-ui
  • rxjs (I find observables easier to understand than async/await)
  • good documentation
  • upgrade from v9 to v10 was easy
  • typescript rocks(!)

Well, the upgrade from v8 to v9 was not so easy due to Ivy, but I only had to migrate one library of my app to succeed... and I'm a total noob in frontend development. So should I worry about all this stuff, even though I'm quite happy with my Angular based app?

Collapse
 
otijhuis profile image
Okke Tijhuis

If you're happy, don't worry about it. To be honest, if your app is small to medium size and not very complex it doesn't matter much which framework you choose. People issues (communication, lack of requirements etc) are often way bigger problems than the technology choice.

That said, we started with Angular 2 and are now on version 10. My experiences with it haven't been that good. From build issues to having to write lots of workarounds and custom components because features are broken, half-baked or don't exist. It's quite a big application and a pretty complex one at that. And since the upgrade to Angular 9 the dev server has been incredibly slow.

I see quite a few people mentioning the fact that it's a 'complete' framework as a pro. If it was flexible enough that you could easily switch parts out in case they didn't meet your needs then I'd have no problem with it. The thing is, with Angular you're often stuck doing it 'their' way, otherwise you're out of luck. I like the way how Vue handles this. Vuex/vue-router are maintained by the core team so you know those always integrate well, but if you really want to switch them out you can.

RxJS itself I like. In some cases streams make things a lot easier, but I don't like it when a framework forces me to use them in situations where they aren't adding any extra value. It's also another thing to learn and I find that many developers don't understand them well enough, and do things with them you really shouldn't (subscribe within a subscribe, settings variables outside of the stream, forgetting to unsubscribe when not using the async pipe and so on).

I have to disagree with the good documentation. I find it only covers the basics. Anything beyond that I just google right away because I'm never able to find it in the documentation.

Most upgrades are easy yes. But most of those releases are just minor, not major like the version number would suggest. My main issue with the releases is that I can't even remember the last time there was actually something in there that would make my life easier. I often find that the typescript improvements that come with the upgrades are the ones I'm looking forward to the most, which is sad. Improving bundle sizes and so on is a good thing but it doesn't make the development any easier. I use Vue as well and I feel that team has a much better grasp on what's important to developers. I see quality of life improvements basically every single release.

Typescript is very nice but you can use it with almost any framework these days. It has its own quirks as well though.

What I've never been able to understand is why people say Angular provides more structure. They provide a default folder structure, that's it. The way code is structured is still completely up to the developer. If you don't have developers who really care about code structure/architecture and simple solutions you will inevitably end up with a mess, no matter the framework used. It's a people problem, not a framework issue. I personally find it easier to make a mess in Angular because of all the workarounds needed when the framework forces me into a more complex solution.

I will never choose Angular again if I have a choice. Vue and React can do anything Angular can do, that's not the case the other way around. You just don't have the flexibility in Angular and it especially lacks features when it comes to dynamic components. If I could I wouldn't even use a front-end framework anymore and just use Elixir/Phoenix/LiveView :)

If you enjoy working with Angular and it does everything you want then don't worry about what anyone else says. No matter what you choose there's always a compromise. I've been programming for over 25 years in lots of languages so I've seen my share of code and formed my own opinions. And there's always more to learn. Have fun, learn more about Angular. See what you like/dislike. Do what makes you happy. You'll write your best code when you're enjoying yourself.

Collapse
 
itsasine profile image
ItsASine (Kayla)

Re: Protractor

Protractor has been under the Angular umbrella for a while. Protractor 6 was going to be the big move to the most recent Selenium Webdriver version to nix the Selenium baked in Promise handling and go full into async. With how hard Protractor leaned in to wrapping Selenium, including maintaining their webdriver-manager package for getting the latest browser drivers, I'm not terribly surprised that got shelved.
I've been following that for a year or so so they were trying to move Protractor forward for a while. My understanding of the diff between 5 and 7 is more just bumping dependency versions since all the actual work for the past year+ was in 6. On one hand, I'm glad I don't have to rewrite my tests that are a weird blend of forcing Protractor to work in ES5 if they had bumped versions. On the other hand, though, you're right that they just coughed up a version to look like progress when their 6 release didn't pan out.

Interesting thing about the 6 release was when they did it, it was out for a bit before they pinned the npm package at the latest 5 release, before doing another 5 bug fix release, then doing a 7 release... 6 existed and was out for a few months. The problem was downloading it meant you needed to be on the bleeding edge of everything else in the Google ecosystem. I'm not writing e2e tests for beta Chrome versions and pre-release versions of Selenium... so I kept to 5. Checked back a month later and they removed 6 from the versions list and were on 7 as a marginal bump from 5.

TL;DR: Protractor 6 is like Angular 3 -- it never happened.

Re: the list of names: Aww, Brocchi is one of the best people

Collapse
 
jwp profile image
John Peters • Edited

Cypress has disrupted all Selenium products. Selinium is in sunset mode.

Collapse
 
itsasine profile image
ItsASine (Kayla)

Eventually. I'm more interested to see how things shake out when it's not the new hotness.

For the sake of a thread about Protractor, though, Angular apps will always benefit from the coupling Protractor has with the Angular hooks. As long as Protractor is around, I wouldn't use Cypress for Angular E2E.

Thread Thread
 
jwp profile image
John Peters

New hotness for Cypress? It won't shake out because it's just easier to write e2e tests than Protractor. But unlike protractor, it's inbound and outbound http interception allows it to be way more than just for e2e tests.

The javascript community and in particular the React people scream the superiority of declarative programming every day. Cypress is the declarative king for test.

Protractor has been disrupted.

Thread Thread
 
itsasine profile image
ItsASine (Kayla)

It's fine that Cypress is the new king of React testing or whatever.

For Angular, I'd still use Protractor. Because Protractor is specifically made for that framework.

Anyone who was using Protractor for React/Vue/etc was using a hammer as a screwdriver so any screwdriver is going to work a lot better.

Thread Thread
 
jwp profile image
John Peters

Interesting because even though Protractor has been around since before the Angular CLI, the Angular schematics to this day don't use Protractor. Instead they spin up the ridiculous Karma/Jasmine tests for each new component. Using Protractor has always been a choice whereas Karma/Jasmine were defaults.

But Karma/Jasmine solutions are ridiculous in my opinion. The Angular Testing Library is plug replaceable with Karma/Jasmine and a much better product.

Still Cypress reaches deep enough into our applications that it's now my preferred and only "real" test framework, I still use Angular-Testing lib, but don't spend much time on each test.

Thread Thread
 
layzee profile image
Lars Gyrup Brink Nielsen • Edited

The end-to-end test suite generated when creating an Angular application project with Angular CLI is using Protractor.

Protractor has the benefit of hooking into NgZone. Cypress sometimes has issues with waiting for an element to appear. You end up having to put random timeouts into your tests to wait for Angular to stabilize. Sometimes it works, but it's a flaky test waiting to fail.

Protractor is able to support legacy browsers like Internet Explorer and Edge Legacy.

Thread Thread
 
jwp profile image
John Peters

Thanks for the reminder Lars, yes Angular sees Protractor as E2E and not unit test.

Collapse
 
owenmecham profile image
Owen Mecham

What do you think the path forward is? I would love for Angular to get back to the days when the community was excited about the next release.

Collapse
 
nombrekeff profile image
Keff

Crap, I don't follow Angular development and did not know about all this shit.

We use it in most of our projects at work and I'm kinda freaked out about this TBH. I'm going to talk to my manager and see if we should take a closer look at the whole situation.

Personally I love angular, it's a shame it has fallen in such a path, shame on you google.

Collapse
 
vikramkadiam profile image
Vikram Kadiam

Amen !

Collapse
 
martinmcwhorter profile image
Martin McWhorter

Can you link to discussions on Angular Material switching to Material Component styles?

Collapse
 
layzee profile image
Lars Gyrup Brink Nielsen

It's mentioned in the Readme. Work is in the @angular/material-experimental package. github.com/angular/components#what...

Collapse
 
chandlerbaskins profile image
Chandler Baskins

As someone who just started learning Angular this is sad and concerning. I love angular and everything about it. I don't want to go back to React 😭

Collapse
 
cryptoquick profile image
Distributed Hunter Trujillo

React has gotten a lot better. Hooks really saved it, and they came out of beta over a year ago. TypeScript works really well with React now, too, and there's a lot of projects like Navi and TypeStyle that are implemented in TypeScript and have excellent React support. I've also heard good things of React Query (not to be confused with jQuery... I suppose it's been long enough).

Also, look into Redux Toolkit, it's not the same Redux of old. Gone are the case statements for object literals, and immutability is managed, allowing developers to take shortcuts instead of doing immutability gymnastics. Most of the time you won't need Redux now, or if you do, it's only for certain parts of the app, and it's quite clear where the separation of concerns should lie.

There's more exciting stuff we're seeing already implemented, just not yet out of beta, and the transparency of the React community is pretty good. There was a bit of Twitter drama about React a while back, with it being heavy, and some devs having toxic reactions, but Dan does his best to lead the community by example, by his approach. A developer's approach can be even more important than the solution.

Collapse
 
luigi198 profile image
Luis

Nahh I feel Chandler, working with React in big projects is a complete nightmare, I know Hooks and worked with hooks for a while now and they are just a mess, every single dev I've worked with in React has a different way of implementing hooks, their own 'Custom Handmade Hooks' and for me is an organizational chaos.

AngularJS was a sensation.
ReactJS fucked up AngularJS and was a sensation
Is time to look for a better solution to React, it's almost impossible to see 2 React projects with same structure, is so free that in the same company, if you are moved to another React project, you need to relearn the whole React structure used there to understand and work on it. Angular fixes this, if you don't follow good behaviors in angular, you're doomed.

I agree with you on most points but just as Chandler, I'm running away from React, React devs and React ecosystem.
After using React, Angular and Vue
Vue > Angular > React
In user experience and organization, not even performance and documentation, using React makes me want to quit Web Dev completely

Thread Thread
 
chandlerbaskins profile image
Chandler Baskins

Exactly my reasons. It's the wild west. I feel safe in Angular and when I pull up a repo I have a good idea how it's going to be laid out. I don't think I'd go back to React. Listening to the podcast on the Angular show made me feel better. I think there will be some changes.

Thread Thread
 
cryptoquick profile image
Distributed Hunter Trujillo

I see your point, and I think it has some validity, but in practice, I'd never seen a React project that surprised me by its novelty.

One could argue that the lack of a prescriptive folder structure, standardized routing scheme, and a styles stack everyone uses, has hurt React. I'd actually argue the opposite. The diversity of thought and inclusiveness of ideas based on their merit is better than leaving thousands of pull requests hanging.

I think the diversity of thought and idea inclusiveness has served React well in that, if you're not happy with something, pull something else in. And with basic tooling and testing, such as TypeScript, ESLint, Jest, and Cypress, these refactors tend to go well.

One could also argue, React has taken the Unix philosophy and applied it to the web. Do one thing, and do it well. Sure, it could be said that React didn't do things well in the past, but also, we once wrote websites in jQuery and Backbone, so, tech gets better all the time.

I've refactored projects with hundreds of thousands of lines of React code alone, for Fortune 500 companies, and our tooling improvements alone resulted in a dramatic increase in developer productivity, but that's just been my experience.

Collapse
 
jwp profile image
John Peters

But the negative impact so far is non existant. Angular 10 is working much better than all prior releases.

React is simply gaining more popularity every day.

Collapse
 
chandlerbaskins profile image
Chandler Baskins

Since writing that there was a Podcast episode on the Angular Show that made me feel better. Besides I continued on my learning journey and I couldn't be more happier.

Thread Thread
 
jwp profile image
John Peters

I feel the same way, Angular appears to have overcome a lot of compiler and web-pack interface issues with Angular 10. I just don't have any of the same issues I had before. I'm pretty sure the real culprit was NPM package system anyway which continues to be a terrible module delivery system.

Many years ago the desktop environment went through a similar module loading issue known as dll hell. But both Java and C# solved that problem each having loaders that supported name spacing. What NPM can't do that is simply dumb. There's something to be said about a closed system framework like .NET or Java, they don't have these huge and very deep hierarchies like the node_modules folder shows us every day. In addition security threats were minimal back in those days.

Collapse
 
sebbdk profile image
Sebastian Vargr

This is what you get when you try to invent a rocketship to cross the road.

Angular 2+ was broken from the startline, writing their own HTML parser/custom-language, re-using the module system despite native modules having been standardized, deciding to in practicality force the usage of ngzone, a magic library that is big, slow and majorly fucks up debugging worse than angularjs. Etc etc.

What the hell did they expect? :)

Collapse
 
jwp profile image
John Peters

I agree with you, the whole ngmodule system is an absolute disaster. Whoever dreamed that cluster up should have been fired.

Collapse
 
sebbdk profile image
Sebastian Vargr

I can forgive it in AngularJS, different times, we did not even have a standard way to include libraries back then.

Angular2+ using it while requirejs, commonjs and other module loaders being a thing.
That's just senseless.

Thread Thread
 
jwp profile image
John Peters • Edited

And really all the NGModule is for, is the compiler. As if the Angular compiler couldn't hunt down @NGModule, @Component and all other required decorators... It's a typical Angular opinionated way of doing things. All we need is for the compile to create index.js files after compilation. This is all that NPM uses for libraries anyway. To duplicate the majority of the index module system is bad, get rid of it Angular.

Some even argue it's not duplication! Sheesh.

Thread Thread
 
layzee profile image
Lars Gyrup Brink Nielsen

We also had Require.js and CommonJS back in the Angular.js days. That is ancient technology 😃

Thread Thread
 
layzee profile image
Lars Gyrup Brink Nielsen

Svelte's compiler is a lot more advanced in this area.

Thread Thread
 
sebbdk profile image
Sebastian Vargr

Yeah, but they were not as commonly used or known back in 2010. :)

You plugging Svelte made me think:

I've never used Svelte, and I have only looked at the examples.
I figure if state management is separated from the display framework, and I can make a less than 14kb initial payload website with Preact, htm, and Parcel, then why bother looking at new stuff for now?

Why would I learn a new language to do something I can already do perfectly well?

And by extension, how does dividing the development community by adding yet another transpiler add any overall value in terms of not repeating the same CRUD form again and again and again.

Maybe it's a preference thing, but it's the exact same reason I always thought Coffeescript was a waste of time when it came out. :/

I know I am speaking from a place of ignorance here, but what's your take?
What is the unique selling point I am missing here?

Collapse
 
angularnodejs profile image
AngularNodeJS 🚀 • Edited

I decided to give up on Angular, a bloated over-engineered and complex to learn mess! I cut my teeth with Angular and made a lot of money consulting as a Angular dev. I drank the kool-aid and use to champion it. Now I know better, I would never recommend using Angular for enterprise dev, too much time wasted fixing breaking changes. The larger the project the more painful and wasteful these upgrade cycles are, there is angular, rxjs, ngrx and yes crappy angular material with its own set of bugs that never get fixed or accessibility issues that have gone unfixed.

With Angular the developer is forced to (keep) re-learning the eco-system over and over as none of this over-engineer complexity was designed with the developer in mind.

I switched over to Vue.js, it is smaller, a lot faster with rendering, forget the Ivy hype! Plus Vue.js is really well designed and doesn't get in the way like angular does. Easy to learn and to remember skills learned, the routing and global store (vuex) is a joy to use! Gone are the boilerplate coding in Angular + batteries! With Vue.js 3.0 out, switching away from Angular has never been a saner choice!

Collapse
 
aisone profile image
Aaron Gong • Edited

Between AngularJS, Vue and React, my best experience was with VueJS.

I never moved to Angular it was too much of a shock for me, what if I had many large scale projects already on AngularJS... it would be painful.

And the whole concept of Angular feels like a monolith, like Dojo toolkit and Sencha ExtJS, hard to turn around when things change (e.g. mobile screen size introduced).

Vue 3 with Vite3/Snowpack, ES Modules etc. is a game changer. I mix it with HTML Custom Elements, and use Javascript native APIs to reduce exposure to technical debt and breaking changes in dependencies.

Even VueJS ecosystem is not immune to changes... the Vee-validate is one such example, major version change requires rewrite of the validation code... imagine if just one application has 20 forms and each form has 20 fields... One would be better off working with native HTML5 Validation.

All those supporting UI frameworks like Bootstrap, Ant Design, Material UI, etc... for vue/react/angular/etc were designed as monoliths...

Moving to HTML Custom Elements (aka Web Components) should help make your UI less susceptible to underlying vue/react/angular/etc framework changes...

At the end of the day I do not want to revisit and rewrite what I have written.

The only big advantage I know of having to keep rewriting and updating is that this will help keep one employed perpetually...

Collapse
 
blackjyn profile image
ZVHR El Ekhsaan

I ditched Angular since 2015, right when they throws version 2+ at alpha.
I'm moving to Svelte

Collapse
 
jwp profile image
John Peters

Yes but compare the job postings and vue comes in last.

Collapse
 
layzee profile image
Lars Gyrup Brink Nielsen

This certainly depends on the region of the world you're looking for jobs in.

Collapse
 
thegoldyman profile image
talamaska • Edited

I personally have avoided Angular until v4 was released. Sure there were hick ups with some bugs in the cdk, but not in the Angular it selfq at least i didn't encounter such. I always wonder, what are people doing in order to provoke so many issues and to me really edge cases. I've been using Angular for 3 years and never had critical issues, there was always another way to make it work. Sure there are some issues with material components, but I'm itching to see how the current migration to mdc will look an how it can be customized, I hope for scss to css vars with conditional loading with @support or something. Comparing the number of the issues between React/Vue and Angular is just ridiculous, there is no other thing to compare with Angular. To compare correctly you should include all the 3rd party packages you use in order to make a react app work - router, forms, cypress, jest, styled elements, or w/e. Saying that React is more feasible to use to provide web components is just not true, because React can't Shadow dom. Maybe ionic's Stenciljs is a better example of what Angular Elements could be. I'm also not a big fan of async await, as I always will remember the hell of thens, I embraced rxjs from the first moment. Plus like someone before me said, there are still a bunch of old browsers in intranets and whatnot which can't gain from native async/await so it's not a major issue, respectively zone will continue to work fine for me. I'm only concerned about Ivy and TSLint. I do believe/hope eventually we will see a migration to ESlint maybe at the end of the year. There were several open discussions and with a list of what's done - github.com/typescript-eslint/types...
There always will be issues between great minds. There will be ups and downs and that's normal. I'm kinda disappointed that AngularDart is not gaining traction, I find Dart better at times than Typescript, having in mind this language gained more popularity around Flutter. To think that Angular will end up in the graveyard is not realistic. There is huge amount of Google's projects written in Angular, to imagine they will rewrite every one of them on Flutter is just not feasible. I hope such posts will not hurt Angular's popularity more, I don't want to write React ever.

Collapse
 
jwp profile image
John Peters

Angular 10 is stable and strong.

Collapse
 
imsabodetocode profile image
Sabyasachi D Maven

I am not aware about the internals of the Angular team at Google. But, it's also true that the core members leaving the team which we hear from their social media updates.

But, we should not be pessimistic about the Angular future. Angular has come a long way from 1 to 10 and there are so many improvements been done in the user experience, DOM rendering, etc

One thing for sure, technology doesn't go bleak all of a sudden. If we see, the native technologies like asp.net, wpf, asp.net MVC still exists and the enhancement is still on.

So, coming to the Angular side, we might not see a big leap every version but updates will always be there.

So, we should be positive and keep learning, exploring Angular.

Collapse
 
leob profile image
leob

Didn't follow Angular or work with it (apart from a "Hello World") after version 1, but with the arrival of React it seems Angular was doomed (and it's probably even being surpassed by Vue in terms of market share).

Reading this article, with the team falling apart and becoming toxic, it's even more doomed than I thought it was.

Frameworks and communities this big don't easily die completely, but they will need some sort of brilliant plan to revive it, or it will wither on the vine. Go down the Web Components path? Go down the Svelte path with a compiler?

Collapse
 
m98 profile image
Kermani

They are handling many things at the time, it seems the project itself getting too nasty, but there is still hope, at least it seems that the code base is very clean and can be improved by the next people who join the team.

It seems like Google still does not recognize the Angular as its own! Or maybe that's their management style that lets everyone (without the formal title) decide on the project's path

Angular is a very elegant way of creating web applications, even though many improvements on the speed and quality is needed. We really can't suffer again from another framework deprecation. So people need to give enough courage to the team to make a good decision and only get rid of people who are in the way of true progress.

Collapse
 
robboclancy profile image
Robbo

Choosing Angular 5 years ago was easily the worst mistake I've made as a developer.

Collapse
 
antonmelnyk profile image
Anton Melnyk

It's not like framework choice is written in the stone. In the end if you are good developer you can switch to any of them.

Collapse
 
pdina profile image
Paolo E Basta

it takes time

Collapse
 
nni123 profile image
nni123

Will Flutter face the same treatment? I put myself into this situation and start avoiding google technology stack.

I hate JS framework but simple 90s pure JS won't cut the deal for today's enterprise (brainwash up to some extent) . So I decided to invest in GWT and later on Angular. While I was doing angular I kept an open mind and looked at Flutter extensively in free time.

After learning about this I am worried that investing in google technology stack is an utter waste of time. Google can stop Fuchsia OS development (experiment) anytime without any explanation. As we know they're planning to use flutter to develop apps on Fuchsia. Golang is awesome as well but not spending too much energy on google stack to be safe. Now people will say choose technology stack based on requirement but sometime you choose what you love and enjoy doing it.

Collapse
 
beggars profile image
Dwayne Charrington

Developers need to abandon Angular and switch over to Aurelia. It's a batteries-included framework that has a non-toxic community and a great open-minded core team that value all community contributions.

Collapse
 
jwp profile image
John Peters

Rob proved he is unreliable.
Switching to this is a career killer.

Collapse
 
akiwams profile image
Alhassan Kiwamdeen

All frameworks and libraries got their ups and downs. The fact that you do not work with a particular framework does not make it ill for others. I don't believe in such post which can easily ruin the interest in aspiring developers. Your MVP award needs to be question!!

Collapse
 
layzee profile image
Lars Gyrup Brink Nielsen • Edited

I use Angular every day. I contribute code, reviews and docs, speak about it, blog about it, podcast about it, use it at work for many teams.

Collapse
 
mlcmlapis profile image
Miloš Lapiš

It is a bit of a mystery to me that the team management does not take any public position, fully aware of what is otherwise widely discussed, so they must be aware that this is a significant issue. As I have said elsewhere, it is now in the position of "about us without us", and this is not a situation for anyone to be satisfied within the long run.

Collapse
 
gr3g5ki profile image
Greg Ski

People come and go all the time. The smart people constantly need challenges. It's a long bow to draw between people leaving over a number of years and decline of a framework.

Collapse
 
coderjai profile image
Jai Marshall

Should I even still try to learn Angular on my tech journey? I'm learning React and want to try Vue next.

Collapse
 
drumstix42 profile image
Mark

Vue is a lot of fun to develop with and easy to get started. I definitely recommend checking it out!

At the end of the day, go with what you are interested in.

Collapse
 
coderjai profile image
Jai Marshall

I heard Vue was easy to get started with. I will check it out.

Collapse
 
sproket profile image
sproket

How is any of this surprising?

Collapse
 
sanidz profile image
sanidz

"Apparently, the Angular team now owns Protractor."

Here goes nothing...

Collapse
 
blackjyn profile image
ZVHR El Ekhsaan

Angular is DEAD

Collapse
 
maximaximum profile image
Maksym Kobieliev

Agree, this article clearly defined the issue in Angular that I've been thinking about during the last years. Angular is dying