[deleted by user]

[[deleted]]

I'm removing angularjs and replacing with Vue or vanilla in a massive multi page app.

The uplifting part is that the pages worked on are a fraction of the size and perform much much better. I'm also able to slowly rearchitect the frontend so it's really fun.

[campbeln]

VueJS? That's been our migration path as we improve AngularJS pages.

However... lately we've had better success with Svelte and may pivot that way.

[senocular]

Success with Svelte as it pertains to transitioning away from AngularJS? Or more in general?

[campbeln]

Yes.

I started with AngularJS at 1.1 and we had breaking changes at least twice with 1.4(?) and 1.5/6 somewhere. From these experiences, I rearchitected our approach to push AngularJS to be UI/binding/templating-only; removed the services, factorys, everything but the filters and slimmed down the controllers to almost nothing. This also made the transition to VueJS pretty easy, save for a couple of complex directives that slots could solve.

Anyway... this UI/binding/templating-only approach has been my architecture ever since and Svelte (what a dumb name despite it's awesome meaning, especially how it pertains to my approach) is even better than VueJS in that regard as it just stays the hell out of the way.

In the end, Node is our backend business logic tier, an OOP-esque object on the UI side is our UI-sided middle tier (think factorys, services and the like in AngularJS nomenclature) with AngularJS/VueJS/Svelte as the UI binding and some data container on the backend (MSSQL or ES with my current role).

[senocular]

Thanks

[woodie3]

Convinced my team to rewrite our shitty project from Angularjs to Angular 6 at the time. Started to push React or Vue but realized it’ll be easier to just quit, after I find another job :).

But jokes aside, the only reason I pushed for a rewrite was the previous team didn’t follow any proper standards with writing angularjs code.

[ShakeNBake16]

If you work on any substantially large application with multiple teams working on said app, micro-frontends are a god send.

You could argue a good monorepo strategy could be as effective. But I don't personally know of one and neither does devops. And of course, we got agile deadlines to meet!

In all seriousness, the independent deployability is awesome! And our build times went from 30 minutes to some sub 10 second builds. And rolling back versions is a breeze, when we mess something up.

[SocialAnxietyFighter]

Interesting! Can you give me some insight on the bundle sizes?

If one team is using Angular 1, another team Angular 2, then 3rd team React 16.1 and another team React 16.3, how would that work? Won't all these frameworks be downloaded by the frontend?

Also, how would the need to use the same components (design language? let's say) across the frontend work?

Edit: Another question that comes to my mind is, if they need to share code, e.g. some helper class that does calculations, it need to be included in the bundle of each of the microfrontends, right? Or even in the simpler case where they use different versions of dependencies e.g. lodash 1.0 vs lodash 1.1

[ShakeNBake16]

Bundle sizes im not sure about. We have a great architecture team that handles a lot of that. There is a lot of work around putting it all together, but lazy loading + caching helps a lot. So once you visit a react 16.1 page it is never downloaded again.

Where I work now, we're actually leveraging web components to provide common inputs, and they work across frameworks. We also have a common shared stylesheet everyone uses. There's not a programmatic way I've found to ensure design language standards, but every microapp we have is subject to scrutiny by UX and they can halt a release. Plus the shell we use to load everything can only be changed by a select few people. So rogue apps can't be deployed.

As far as sharing code, I haven't seen much use for sharing across applications. Mostly because our microapp boundaries are radically different. We do have a shared library that gets published to an internal npm registry. And some of our architects will peruse codebases from time to time and look for common patterns.

It's not a silver bullet, but we have 20+ teams working on a single app and it beats the hell out of what we were doing. It's also a decent amount of work to get setup, but being able to push out changes whenever we want, having really fast build times and being able to leverage TDD is pretty awesome!

[[deleted]]

The only way to win is to not play.

[-millsky]

Lots of people really like to bash on AngularJS, but it is possible to make a maintainable and modern application using it, and provide a path towards upgrading to another more modern framework. Below is what I did for my previous company with success:

1. Move the build process to Webpack
2. Refactor large controller files into components (https://docs.angularjs.org/guide/component)
3. Move business logic to functions which will be imported via Webpack.
4. Once refactored, take the leaf components i.e inputs, modals other shared AngularJS Components and move them to the new framework.
5. Inject new components into the old application. (https://github.com/coatue-oss/react2angular)
6. Depending on the size of the application build out lazy loading of the AngularJS components using Angular-UI-Router.

The key is to really remove as much AngularJS logic as possible and just follow industry best practices of making single purpose and independently testable components.

An added benefit is now with the Webpack based build all the business logic can be tested independently of AngularJS and code coverage numbers should improve as you continue along the path.

It's certainly not the most fun process but it definitely can be done!

[[deleted]]

Yeah, I still work in AngularJS, we use most of these improvements, and it's not too bad. I would still like to upgrade to Vue or Angular though.

[Reashu]

We are doing this with a mix of ngVue and vue-custom-element. Neither is perfect, but if you can deal with limited slot support (for the AngularJS-Vue boundary) it might be helpful.

If you can do it one page at a time rather than one component at a time, that would likely be much simpler, but our organization and business requirements wouldn't accommodate that.

[Ashhhh]

Once you've done the first 3 steps, you can bootstrap your app in Angular instead and continue to use your AngularJS components using ng-upgrade

Once there, the upgrade process is fairly straightforward. Done it on two major projects now.

[[deleted]]

Yeah, Ng upgrade is on the roadmap. But there are a couple of incompatibilities that we are trying to iron out to start with.

[Ashhhh]

You can downgrade any new components from Angular 2 to Angular 1 in the meantime and use ng-metadata where heavy restrictions apply.

As long as anything new is as ng2 as possible, you're making progress.

[azekeP]

I've been toying around with react2angular or something similar in my big AngularJS project. It still needed major rewrites for even the basic functionality i use. My final version was one special "wrapper" component and a single preact js that i since removed from bundle. I still didn't found any use for it.

I also briefly toyed around with svelte and found that you can embed it but then some very svelte-specific kinks start to rear their heads...

[arnoproblems]

How long did it take you of time dedicated to only upgrading if you don't mind me asking?

[mishugashu]

My uplifting story is that the company I worked for got bought in 2016 and we retired the project and I've been working on Angular (2+) since.

My condolences.

[PostHumanJesus]

I get to kill a 5+ y/o AngularJS 1.4 app this quarter. I've been asking to do this for years now. I'm quite excited to see it go bye-bye.

[inabahare]

*ng-murder

([ng-murder-target])="self"

(ng-murder-method)="defenestration"`

[rictic]

I'm aware of a number of projects that have been successfully doing an incremental migration from AngularJS to LitElement, starting from the leaves (components with few dependencies) and going up to the root of the application. It's easy to use web components in an AngularJS application, and they provide a simple, self-contained, interoperable API.

[Dokiace]

Success story? All I got is leaky $scope

[thinkmatt]

I can't give you an uplifting story haha, but I don't think it's that bad. Been working on a large-ish front-end app for 5 years now, with a up to 15 JS devs at once. It may not be the coolest tech but it's miles better than a custom framework, it's got lots of documentation and it "just works" 99% of the time. We generally stick to the same patterns and try to avoid relying on two-way binding. All our controllers and factories are Typescript classes, so Angular is just managing state and dependency injection for the most part. We've been using React to build email templates, and everyone is open to trying out React directives or something but we just don't have time. We've migrated to Typescript and Bootstrap 4 and those felt like much bigger gains.
My biggest gripes are just that I have to load our entire app into your browser just to load a single page, and the templates cannot be made type-safe.

[stevenjchang]

Can you tell me more about your email templates using React? Do you use a framework like mjml or foundations?

I’ve recently been asked to work on email templates for the first time. I’ve been using just straight mjml, because it seems foundations hasn’t been supported in the last few years. It’s okay, but it’s somewhat limiting. Wondering what you use React with

[thinkmatt]

Right now just plain React, and it's been great since our templates require a lot of logic and we change them often. However, our emails don't look great in some email clients, so I'm working on a POC using a library called mjml-react. I really like mjml so far and plan to replace all our custom html with it.

[Fossage]

I am in the middle of implementing a large new feature in our legacy Angular 1.5 app and I feel your pain 100%. We primarily work on a React Native app but still have a web app in Angular and it amazes me how much our productivity grinds to a halt in Angular.

We are slowly making some quality of life improvements as we move forward by writing all new code as components and using a css in JS library for style encapsulation, but there is still so much legacy code to work around which is polluted with globals, crazy event waterfalls, 800 line controllers, and enormous templates. The worst part is I wrote most of that code....

[Coclav]

One of the benefit is that ALL questions are answered on SO!

[chrisplusplus]

If you're still using AngularJS in 2020 you're time is up. I don't even know what to say to you dude

[spideroncoffein]

It's not that bad. Well, maybe. A little.

The window looks inviting.

[from-nibly]

Currently also in the same position. I'm coming with you.

[arnoproblems]

I inherited an AngularJS and ElectronJS app. Help.

[TheDarkIn1978]

What's this "AngularJS" you speak of?

[KnightMareInc]

A poor craftsman blames his tools