Hacker News new | ask | show | jobs
by Bahamut 3390 days ago
As someone leading development of a non-trivial product in Angular 2 (team of 8-10 engineers, 2 QA, has varied some with resource shifting) with having to solve some tricky problems (drag and drop, web audio for playback, audio recording, etc., I have found using Angular 2 a mixed experience, if generally positive.

Performance is pretty much phenomenal - for those who put in the work to optimize via build toolchain config and code, there are a lot of areas where Angular gives you room to implement improvements. Observables also allow very clean push-based reactive component systems, avoiding the need for unintentional changes most of the time - lifecycle hooks help you with the rest.

Implementing AOT compilation to avoid shipping the whole Angular compiler to the runtime is super painful though - it is easily one of the most frustrating experiences for a developer to do currently. I find TypeScript to be a mixed bag - it doesn't let you go all out on FP, mostly due to its flaws in typing with function composition. Testing can be slow due to the compilation of everything via the TypeScript compiler & Webpack (the interlay between the two might be the culprit). Stack traces are sometimes mysterious - I spent a couple of minutes debugging a failure from a test I wrote that resulted in an ambiguous stack trace...all because I forgot to spy on my function.

Personally, I think I would enjoy creating an app in React more, but I do notice significant productivity gains for my team with Angular 2 and TypeScript, and better code design.

I am probably one of the biggest experts in Angular 1 outside Google out there, and pretty knowledgeable in Angular 2, although not as sharp since I have moved into management currently, if that helps give some context.

4 comments

My biggest hang-up on switching to 2 has been waiting for a full Angular Material 2 release. I work in smaller teams and don't always have a UI help, so I rely a lot on UI frameworks.
We are similar in size for our Angular2 application. We've also had very similar problems, especially setting up AoT compilation took pretty long and was a painful process.
What makes it difficult and what can we do to make things easier in the future? Is this something the @angular/cli should consider making default so as to surface pain points in as many scenarios as possible?
There just isn't enough documentation/articles out there on implementing AOT compilation. A lot of people are not using the CLI, since it wasn't mature enough when they started their Angular applications - Webpack is quite common these days. There is a nice plugin for Webpack maintained by the Angular team, @ngtools/webpack, but when trying to wire it in, the error messages are cryptic.

I was fortunate to have some key help at times from Rob Wormald of the Angular team, giving me some key insights about making sure my classes, interfaces, etc. are all exported publicly so they can be statically analyzed, and making sure to split my webpack configs & tsconfigs for dev & prod builds since AOT compilation is too slow for typical dev workflows (although you also want to be able to do it on dev to debug AOT compilation related errors) - I ended up with 4 different webpack configs for sanity's sake.

That said, the CLI does support AOT compilation and has that support built into it now - if I were starting an application now, I would probably just use the CLI.

Are you guys leveraging ngrx?
We are - we have had state issues as a result of ngrx/store & doing some dirty manual resetting at times to work around it, confirming my distrust of redux being essentially a global store...but that is a whole other discussion.
that redux devtools extension tho! oh man oh man. It was like Christmas in March when I first discovered it.
> but I do notice significant productivity gains for my team with Angular 2 and TypeScript, and better code design.

Compared to a React/Redux whatever team or what do you mean?

For a couple of years I had done full stack work on an e-learning application that when from Ember to Angular. For the last year and a half though I have been working specifically in backend.

Recently I started doing some light work with React and I think the biggest difference between Angular 1 (even Ember to some extent) and React that I have found is Flux (https://facebook.github.io/flux/). Technically Flux is a "pattern" but I believe it is more or less required if you plan to do a non-trivial application in React.

I won't give an opinion about it since I haven't really worked long enough with React to really do so, but I thought I would mention it for you to consider.

Compared to Angular 1 at least. My team hasn't done a serious app in React yet, so I don't have a baseline to compare to there.