8 ms·

Does anyone know how to get off Angular?

by rvense 5y ago

alifaziz 5y ago
Do you mind to share why?
- KronisLV 5y ago
  Would also like to know why! The old AngularJS was pretty horrible in my experience, but Angular 2+ was leaps and bounds better! As a "batteries included" framework i prefer it to the alternatives that one would typically consider for front end development instead: React, Vue, Svelte etc. (though i would pick Vue/Svelte for more lightweight sites and maybe React because of its ecosystem) That said, it still is pretty heavyweight which can certainly be a drawback, but not too much so unless you get into the reactive programming libraries and such, at least when compared with the alternatives: https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 https://medium.com/dailyjs/a-realworld-comparison-of-front-e... (this appears to be from 2020 though, someone should do a newer writeup) For the enterprise'y projects that i've seen, Angular seems like a reasonably stable and dependable solution to use. That's in contrast to React, which has needed way more updates in packages that it needs for the typical web project, due to its more fragmented nature. Of course, this might be viewed as a nitpick, but GitHub dependabot seems to page me more for React projects. Also, if you want to use TypeScript (which i might go for, but only in some projects), then in my eyes it integrates with it way better than, say, React or Vue. To me, using TypeScript in React just felt needlessly cumbersome, especially with functional/hook based components. When using React, i'd almost prefer to go for just JavaScript and enjoy the incredible productivity of being able to introduce and compose components very easily, way better than Vue seemed to let me. Of course, i'm probably in the minority here, because i'd go for functional view components and class based parent/container/logic components, but maybe that's just my antiquated way of thinking. Also to conclude my subjective post of sharing my views and experiences, MobX > Redux. It's just wonderfully simple and easy to use for state management.
  - kilburn 5y ago
    > To me, using TypeScript in React just felt needlessly cumbersome, especially with functional/hook based components. Out of curiosity: can you explain how/why? My experience has been quite simple, especially if only using functional components and hooks: interface Props { prop1: string; prop2: number; } const Component : React.FC<Props> = ({prop1, prop2}) => { // types are inferred correctly } Hooks have been similarly easy: React's core hooks auto-infer the proper types, and custom hooks built on them don't require any particular type-plumbing in my experience...
    - KronisLV 5y ago
      It's been a little while since i had to work in the React + TypeScript project (nowadays use Vue more often) so it's not fresh in my memory, but sure! For starters, even your example shows the awkwardness somewhat, it is essentially the same as writing the following (if you don't need the interface elsewhere): const Component: React.FC<{ prop1: string, prop2: number }> = ({prop1, prop2}) => { return ... } Suppose i want to add a new property: now i need to do it in two places (the interface definition, with either syntax). Want to remove one? Same story. Rename one? Sure, your IDE should let you do this, but the change is still necessary in two places. Why couldn't i do something like this instead (the answer is that the language is just not structured that way, but clearly having duplication for no good reason whatsoever isn't nice): const Component: React.FC(prop1: string, prop2: number) => { return ... } or const Component: React.FC(props: Props) => { return ... } Contrast that with a pure JS implementation (which is bad because it doesn't tell you about the individual props or their types, but surely one can also imagine just a list of different prop parameters): function Component(props) { return ... } Of course, that's more of a nitpick, but the code often reads worse than Java does in my eyes. Another thing that i disliked was working with union types, especially when you're stuck with loosely defined objects in a legacy codebase, where you can't always work with properly structured definitions of "this one thing is a union of BASE FIELDS but also ADDITIONAL FIELDS FOR ENTITY TYPE A that won't be defined in separate places, because if we split it up for some reason this one library integration will fail to render UI components properly". I started writing out more about that particular case, but realized that articulating precisely what was the problem in it and diving back into that older codebase to recreate code examples would take time and sadly i don't really care for doing that. But hey, JavaScript would let you just wing it and check each field individually before trying to access them, so you could let the code decide the behavior, not the type system, which is sometimes the path of least resistance. Personally, i think that strong type systems are always good in the back end, but i feel less strongly in that regard about front ends. Also, i'm not sure that building TypeScript on top of JavaScript was the best idea: surely from a support/target platform perspective it was brilliant, but sometimes you get all sorts of awkwardness. For example, the React TypeScript bindings themselves have something like the following: type Booleanish = boolean | 'true' | 'false'; Oh, and in regards to TypeScript in particular (though this is also annoying in Angular etc.), their implementation of even enums is awkward. Consider that in Java you can easily turn any string into an enum value if possible and can also have enums act as containers for additional data, for example: https://www.tutorialspoint.com/how-to-convert-a-string-to-an-enum-in-java https://www.tutorialspoint.com/how-to-convert-a-string-to-an...
- rvense 5y ago
  Mostly I have various stylistic misgivings with Angular. I feel like I spend a lot of time on ceremony and piles of RxJS that would've just been simple function calls in React, which is what I did before. There are some things related to state management, especially module initialization, that it seems to me is a leading to a lot of code bloat to handle an initial state with null state that shouldn't actually ever exist, but that might be user error. More acutely, though, since upgrading to version 12 a few weeks ago, build times have run into several minutes (most of it spent in the "Sealing" phase), and it's developed a habit of crashing the dev server process due to running out of heap (on 16GB machines). We've tried various suggested workarounds and they work for some of our devs, but not for me. The past week or so even a single character change means waiting for the dev server to run out of heap, then restarting it and waiting for a complete rebuild. This takes several minutes all in all and requires manually restarting the server in the middle of it. I tried addressing the issue but I couldn't find a solution that actually worked, so I tried to upgrade to Angular 13 in the hope that it might go away. That took a day to just get it to build, but then I couldn't get our application to start. So now I've put off upgrading, which is obvs also a worrying prospect. We're an early stage start-up in the middle of a major crunch and it's frankly a bit of a nightmare. I've been keeping busy in other parts of the stack as best I can, but as you can imagine that's really not what a three-person team needs. Is this the fault of me, my lack of knowledge of Angular internals, and our messy code base? Most likely! But I did years of React before and I was never in such a mess. I also find the Angular build system quite hard to understand and debug and I'm not entirely sure what the benefit is. Something about server-side rendering? IDK. I do some Elixir/Phoenix in my spare time, I feel like I get 99% of the functionality there for 1% of the effort (and machine resources). We're going to need to bring in outside help if I don't crack it in the next few days but I'm frankly not really sure what the budget is like. Fun times!
  - KronisLV 5y ago
    Heh, this seems like a case of different people having completely opposite experiences. Had to work on an Angular project or two, they were largely passable and didn't cause too many problems. Admittedly felt a bit close to writing back end code at times, even - pretty boring and predictable. In Angular the type system was also reasonably easy to use, even with things like non-nullable/nullable/optional values etc. Had to work on a few React projects, the JavaScript ones were pleasant to work with and develop (seriously, React's functional components are an amazing time saver for display components), but as soon as you introduced TypeScript and Redux as well as plenty of hooks and even custom hooks, it went down the drain. Perhaps that's a bit what you're experiencing with RxJS, which adds a ton of complexity in of itself - being able to start with just Angular and go from there (or in my case - using MobX instead of Redux which is just so much nicer to use) might have been more passable. Actually made a sibling comment like this, though it's not as detailed as i'd like: https://news.ycombinator.com/item?id=30220131 https://news.ycombinator.com/item?id=30220131 But hey, good luck with bending Angular to your will! If nothing else, i can acknowledge many codebases out there being a mess!
Joeri 5y ago
The only way is rewriting the front-end in a different framework. If you can, you probably should do it all at once. If doing it all at once is too much work, you can look at web components as a technology to have both in the same page. Angular elements allows wrapping angular code and putting it inside another framework. Angular also makes it easy to embed web components into its pages, so you could rewrite piece by piece in a framework that supports creating web components, like vue. The real challenge with the piece by piece approach is managing data flow and component lifecycle across the frameworks, and doing that requires codebase-specific solutions.
- spankalee 5y ago
  I've helped teams move from Angular to web components. It's much easier than any other alternative. The data flow just works in Angular 2, though sometimes requires a directive in Angular 1.
ildon 5y ago
I do have a lot of experience in porting angular to react, see for example my post https://anita-app.com/blog/articles/porting-anita-from-angular-to-react-resulted-in-20-less-code.html https://anita-app.com/blog/articles/porting-anita-from-angul... You can contact me on Twitter @ilDon_xyz
kansface 5y ago
I lead a project that did an in place rewrite from angular to react while still shipping new features. We wrote an angular -> react shim so that we could render react leaf nodes. We worked down the angular stack replacing increasingly lower level components. We had a cut over date of no new angular code, then essentially a code freeze for a month or so to do the rest (routing, data store). This project took 4 or maybe 5 months, but the resulting velocity on the other side more than made up for it.
- rvense 5y ago
  Interesting to know it can be done. We're probably not at a place where we can consider it, but it would be nice to plan for. Can you tell me more about your Angular -> React shim?
  - kansface 5y ago
    For some reason, this code [1] is still accessible on the public internet! This dates back to CoreOS and the Tectonic (CoreOS's k8s distro) Console. The code needed to be rewritten, I had familiarity with React, and after the nth time Angular 2 broke backwards compatibility in an RC, we went for it. It was a little different than I remembered. We moved all data into Redux and piped it into the various Angular bits. Then, it was a matter of making the angular-> react bridge (using ngreact) introduced in this PR. 1. https://github.com/openshift/console/commit/4cc9c5d79f3fdea13063bb60e1ffc533ab832a44 https://github.com/openshift/console/commit/4cc9c5d79f3fdea1...
ldiracdelta 5y ago
Do it incrementally, if you can. I started migrating to react by making new components in react and embedding them with ngreact. Yeah, angularjs and not angular, but the concept holds.

Does anyone know how to get off Angular?

by rvense 5y ago

Does anyone know how to get off Angular?

alifaziz 5y ago

Do you mind to share why?

KronisLV 5y ago
Would also like to know why! The old AngularJS was pretty horrible in my experience, but Angular 2+ was leaps and bounds better! As a "batteries included" framework i prefer it to the alternatives that one would typically consider for front end development instead: React, Vue, Svelte etc. (though i would pick Vue/Svelte for more lightweight sites and maybe React because of its ecosystem) That said, it still is pretty heavyweight which can certainly be a drawback, but not too much so unless you get into the reactive programming libraries and such, at least when compared with the alternatives: https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 https://medium.com/dailyjs/a-realworld-comparison-of-front-e... (this appears to be from 2020 though, someone should do a newer writeup) For the enterprise'y projects that i've seen, Angular seems like a reasonably stable and dependable solution to use. That's in contrast to React, which has needed way more updates in packages that it needs for the typical web project, due to its more fragmented nature. Of course, this might be viewed as a nitpick, but GitHub dependabot seems to page me more for React projects. Also, if you want to use TypeScript (which i might go for, but only in some projects), then in my eyes it integrates with it way better than, say, React or Vue. To me, using TypeScript in React just felt needlessly cumbersome, especially with functional/hook based components. When using React, i'd almost prefer to go for just JavaScript and enjoy the incredible productivity of being able to introduce and compose components very easily, way better than Vue seemed to let me. Of course, i'm probably in the minority here, because i'd go for functional view components and class based parent/container/logic components, but maybe that's just my antiquated way of thinking. Also to conclude my subjective post of sharing my views and experiences, MobX > Redux. It's just wonderfully simple and easy to use for state management.
- kilburn 5y ago
  > To me, using TypeScript in React just felt needlessly cumbersome, especially with functional/hook based components. Out of curiosity: can you explain how/why? My experience has been quite simple, especially if only using functional components and hooks: interface Props { prop1: string; prop2: number; } const Component : React.FC<Props> = ({prop1, prop2}) => { // types are inferred correctly } Hooks have been similarly easy: React's core hooks auto-infer the proper types, and custom hooks built on them don't require any particular type-plumbing in my experience...
  - KronisLV 5y ago
    It's been a little while since i had to work in the React + TypeScript project (nowadays use Vue more often) so it's not fresh in my memory, but sure! For starters, even your example shows the awkwardness somewhat, it is essentially the same as writing the following (if you don't need the interface elsewhere): const Component: React.FC<{ prop1: string, prop2: number }> = ({prop1, prop2}) => { return ... } Suppose i want to add a new property: now i need to do it in two places (the interface definition, with either syntax). Want to remove one? Same story. Rename one? Sure, your IDE should let you do this, but the change is still necessary in two places. Why couldn't i do something like this instead (the answer is that the language is just not structured that way, but clearly having duplication for no good reason whatsoever isn't nice): const Component: React.FC(prop1: string, prop2: number) => { return ... } or const Component: React.FC(props: Props) => { return ... } Contrast that with a pure JS implementation (which is bad because it doesn't tell you about the individual props or their types, but surely one can also imagine just a list of different prop parameters): function Component(props) { return ... } Of course, that's more of a nitpick, but the code often reads worse than Java does in my eyes. Another thing that i disliked was working with union types, especially when you're stuck with loosely defined objects in a legacy codebase, where you can't always work with properly structured definitions of "this one thing is a union of BASE FIELDS but also ADDITIONAL FIELDS FOR ENTITY TYPE A that won't be defined in separate places, because if we split it up for some reason this one library integration will fail to render UI components properly". I started writing out more about that particular case, but realized that articulating precisely what was the problem in it and diving back into that older codebase to recreate code examples would take time and sadly i don't really care for doing that. But hey, JavaScript would let you just wing it and check each field individually before trying to access them, so you could let the code decide the behavior, not the type system, which is sometimes the path of least resistance. Personally, i think that strong type systems are always good in the back end, but i feel less strongly in that regard about front ends. Also, i'm not sure that building TypeScript on top of JavaScript was the best idea: surely from a support/target platform perspective it was brilliant, but sometimes you get all sorts of awkwardness. For example, the React TypeScript bindings themselves have something like the following: type Booleanish = boolean | 'true' | 'false'; Oh, and in regards to TypeScript in particular (though this is also annoying in Angular etc.), their implementation of even enums is awkward. Consider that in Java you can easily turn any string into an enum value if possible and can also have enums act as containers for additional data, for example: https://www.tutorialspoint.com/how-to-convert-a-string-to-an-enum-in-java https://www.tutorialspoint.com/how-to-convert-a-string-to-an...
rvense 5y ago
Mostly I have various stylistic misgivings with Angular. I feel like I spend a lot of time on ceremony and piles of RxJS that would've just been simple function calls in React, which is what I did before. There are some things related to state management, especially module initialization, that it seems to me is a leading to a lot of code bloat to handle an initial state with null state that shouldn't actually ever exist, but that might be user error. More acutely, though, since upgrading to version 12 a few weeks ago, build times have run into several minutes (most of it spent in the "Sealing" phase), and it's developed a habit of crashing the dev server process due to running out of heap (on 16GB machines). We've tried various suggested workarounds and they work for some of our devs, but not for me. The past week or so even a single character change means waiting for the dev server to run out of heap, then restarting it and waiting for a complete rebuild. This takes several minutes all in all and requires manually restarting the server in the middle of it. I tried addressing the issue but I couldn't find a solution that actually worked, so I tried to upgrade to Angular 13 in the hope that it might go away. That took a day to just get it to build, but then I couldn't get our application to start. So now I've put off upgrading, which is obvs also a worrying prospect. We're an early stage start-up in the middle of a major crunch and it's frankly a bit of a nightmare. I've been keeping busy in other parts of the stack as best I can, but as you can imagine that's really not what a three-person team needs. Is this the fault of me, my lack of knowledge of Angular internals, and our messy code base? Most likely! But I did years of React before and I was never in such a mess. I also find the Angular build system quite hard to understand and debug and I'm not entirely sure what the benefit is. Something about server-side rendering? IDK. I do some Elixir/Phoenix in my spare time, I feel like I get 99% of the functionality there for 1% of the effort (and machine resources). We're going to need to bring in outside help if I don't crack it in the next few days but I'm frankly not really sure what the budget is like. Fun times!
- KronisLV 5y ago
  Heh, this seems like a case of different people having completely opposite experiences. Had to work on an Angular project or two, they were largely passable and didn't cause too many problems. Admittedly felt a bit close to writing back end code at times, even - pretty boring and predictable. In Angular the type system was also reasonably easy to use, even with things like non-nullable/nullable/optional values etc. Had to work on a few React projects, the JavaScript ones were pleasant to work with and develop (seriously, React's functional components are an amazing time saver for display components), but as soon as you introduced TypeScript and Redux as well as plenty of hooks and even custom hooks, it went down the drain. Perhaps that's a bit what you're experiencing with RxJS, which adds a ton of complexity in of itself - being able to start with just Angular and go from there (or in my case - using MobX instead of Redux which is just so much nicer to use) might have been more passable. Actually made a sibling comment like this, though it's not as detailed as i'd like: https://news.ycombinator.com/item?id=30220131 https://news.ycombinator.com/item?id=30220131 But hey, good luck with bending Angular to your will! If nothing else, i can acknowledge many codebases out there being a mess!

Joeri 5y ago

The only way is rewriting the front-end in a different framework. If you can, you probably should do it all at once. If doing it all at once is too much work, you can look at web components as a technology to have both in the same page. Angular elements allows wrapping angular code and putting it inside another framework. Angular also makes it easy to embed web components into its pages, so you could rewrite piece by piece in a framework that supports creating web components, like vue. The real challenge with the piece by piece approach is managing data flow and component lifecycle across the frameworks, and doing that requires codebase-specific solutions.

spankalee 5y ago
I've helped teams move from Angular to web components. It's much easier than any other alternative. The data flow just works in Angular 2, though sometimes requires a directive in Angular 1.

ildon 5y ago

I do have a lot of experience in porting angular to react, see for example my post https://anita-app.com/blog/articles/porting-anita-from-angular-to-react-resulted-in-20-less-code.html https://anita-app.com/blog/articles/porting-anita-from-angul... You can contact me on Twitter @ilDon_xyz

kansface 5y ago

I lead a project that did an in place rewrite from angular to react while still shipping new features. We wrote an angular -> react shim so that we could render react leaf nodes. We worked down the angular stack replacing increasingly lower level components. We had a cut over date of no new angular code, then essentially a code freeze for a month or so to do the rest (routing, data store). This project took 4 or maybe 5 months, but the resulting velocity on the other side more than made up for it.

rvense 5y ago
Interesting to know it can be done. We're probably not at a place where we can consider it, but it would be nice to plan for. Can you tell me more about your Angular -> React shim?
- kansface 5y ago
  For some reason, this code [1] is still accessible on the public internet! This dates back to CoreOS and the Tectonic (CoreOS's k8s distro) Console. The code needed to be rewritten, I had familiarity with React, and after the nth time Angular 2 broke backwards compatibility in an RC, we went for it. It was a little different than I remembered. We moved all data into Redux and piped it into the various Angular bits. Then, it was a matter of making the angular-> react bridge (using ngreact) introduced in this PR. 1. https://github.com/openshift/console/commit/4cc9c5d79f3fdea13063bb60e1ffc533ab832a44 https://github.com/openshift/console/commit/4cc9c5d79f3fdea1...

ldiracdelta 5y ago

Do it incrementally, if you can. I started migrating to react by making new components in react and embedding them with ngreact. Yeah, angularjs and not angular, but the concept holds.