Loading Components Dynamically in Angular 2 | Hacker News Reader

Loading Components Dynamically in Angular 2

syntaxsuccess.com

44 pointsthelgevold31 comments

What's the general consensus on Angular 2? I've built a few apps with it, and generally like it, although it's quite opinionated.

Most of the time I've seen something Angular-related appear on HN, there's generally a facet of the community lambasting it as too big/too enterprisey.

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.

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.

Angular feels like Google's GWT (Google Web Toolkit) re imagined in JavaScript.

It's not bad by any means but the layer of abstraction is too thick for my taste. Like GWT or Rails, Angular makes easy stuff trivial but you start chafing against the framework if you're doing things angular was not designed to do.

TLDR: It's going to suck working on ng2 apps 15 years from now.

I'm weary of building things in it because, IMO, the biggest downside of all encompassing frameworks that gives you lots of abstraction is that they age really badly.

I've been burned over the years by a bunch of these. What you run into is applications that can't be gracefully updated. When you're entire app is tied to a jumbo framework and it gets outdated or abandoned you pretty much have to throw the app away and start over.

In the big corporate environments that angular seems aimed at you can count on applications hanging around for 15-20 years. I would much rather maintain something modular that I can slowly swap out as needed than a monolith. Something built with a react clone and 5-10 standalone libraries is going to be a lot easier to update than a 20 year old version of angular some day

Can you give an example of something that won't "suck" to work on 15 years from now?

Every legacy product I've stepped into sucks to work on, that's why people are often hating legacy code refactoring.

Everything old sucks, but there's fixable and unfixable suckage.

IMO stuff like old PHP sites are fixable suckage. Usually minimal layers of abstraction and no crazy hooks affecting the vanilla behavior of the browser and HTTP. If they used libraries, it's usually for small stuff and they can be replaced without rewriting swaths of code. I can generally add new widgets to existing pages without fucking with what's there.

Webforms is a good example of unfixable suckage. The abstraction away from how the page and HTTP works is so thick that it's impossible to refactor slowly. Like angular, webforms takes over the page lifecycle. Client side code and MVC patterns just don't work nicely with it. I can't add anything to webforms pages outside of webforms because all these page reloads happen at unpredictable times and I can't stop them without breaking everything.

Every time I work on a webforms site with user complaints the most reasonable solution is to scrap it and start over. At least with other old shit that doesn't try to reinvent the wheel I can cordon off the really bad stuff and refactor

I think that a lot of the 'unfixable suckage' comes to exist by people not wanting to rewrite boilerplate code to achieve a seemingly simple task, so they import someone else's boilerplate (angular) and use it to achieve their ends quickly. The fact that multiple boilerplates don't all work well or that one doesn't work in every case is hardly surprising.

I'd be curious if the time tradeoff in the "Rewrite the whole goddamn app" bucket is smaller than the one in the "Churn out boilerplate code and maintain it yourself" bucket.

On the one hand, it's great for a large, distributed team of developers who are responsible for multiple programming disciplines... Mostly because the documentation is all in one spot, and angular material is very comprehensive.

Personally, I prefer react, with small swarth of libraries such redux and tcomb to fill out the rest. However, it can be confusing for non-full time JS developers to discover that react isn't an all-encompassing, monolithic framework, and get lost trying to figure out which libraries are responsible for the different pieces of the puzzle.

It can (and has been) done, but I do understand why people would rather use Angular in that scenario- the "don't think out of the box, it's got everything you need" mindset reminds me a lot of ember, which certainly has its fans and upsides as well.

Pick something, get comfortable with it, then pick up something else. All of these choices solve similar problems from different perspectives, and understanding them will help you get a bit of a deeper understanding of the trade-offs when more new updates and tools come out.

It's unfortunate that the JS framework debate is so biased and subjective. I personally like to play around with several of the frameworks. My conclusion is that all the major players are of comparable quality (Angular, React, Aurelia etc). I think it really comes down to how you use the framework, rather than which one you end up with.

I'm currently using both Angular 2 and React concurrently. I've previously used Angular.

There are some points where I feel the opinionated aspects of Angular 2 makes things marginally quicker. However, the one thing I find most consistent is that issues with ng2 seem to frustrate me more than issues with React.

It seems that the this might be a combination of quality and length of tracebacks in ng2. Quality seems to be spotty (sometimes very helpful, sometimes not), and the length of tracebacks in a ready-for-prod project are easily enormous (although sometimes only small). Leading to much more frustration while trying to find what the issue is - probably a matter of not declaring a service in a module or something.

Similarly, the whole injection and declaration process feels tedious and unnatural to me, compared to React, where you just import components from wherever you'd like and use them.

They both work fine, I'm just noticing that my frustration level is generally lower with React. I'm curious how it is for others that are using both concurrently, to compare.

I definitely agree that there is a bit of a learning curve to Angular. A big pivot for people who are used to version 1.

The thing I like the most is how they are pushing the framework to reduce the footprint. In the upcoming version (4) they have made even more progress on this. There are also plans to introduce the Closure compiler in the build chain, which will lead to further optimizations.

Should your UI framework ship with an IoC container? you wouldn't expect your ORM to do that, this is a separate concern. If your UI framework is to complicated to be used without the IoC container then there is an issue with it. Even Hibernate or Doctrine don't make using an IoC container mandatory.

So when you eliminate the IoC container, what is left? the router? it's OK but not fantastic. The databinding? again nothing special about it.

The directives and components? these 2 things are really why we are all using JS frameworks today (bonus for test-ability).

So the latter are good yes, but they are no better than React or Vue system. The framework that will succeed now is the one with the largest ecosystem of plugins and collection of components.

In that sense Angular4 is no more entreprisey than the competition.

>Should your UI framework ship with an IoC container?

Angular 2 is not a UI framework, it's a fronted application framework - it has IoC, HTTP stack, Router, internationalization, etc.

If C#/Java like tooling and design patterns sound appealing to you (eg. enterprise roots) then Angular 2 is going to feel better than React and others, if you're more of FP guy and you prefer to cobble together for flexibility then React is a better choice - this is from my experience.

And by far the best option I've tried for HTML front end was Angular 2 Dart - Dart default tooling beats NPM/WebPack/whatever ecosystem by a mile.

> Angular 2 is not a UI framework, it's a fronted application framework

> it's a fronted application framework

it is absolutely meaningless.

Angular 2 is a UI framework, calling by any other name won't change that fact. The fact that is has 3rd party dependencies wont change that fact either. You use Angular because you want to use it to design user interfaces in the browser and that's it, that what a browser is for, to display content. internationalization, http calls or routing are separate concerns.

> If C#/Java like tooling and design patterns sound appealing to you (eg. enterprise roots) then Angular 2 is going to feel better than React and others, if you're more of FP guy and you prefer to cobble together for flexibility then React is a better choice - this is from my experience.

Which is bullshit of course. React is closer to what you can find with Java FX or XAML than Angular actually is with its string templates. And neither desktop solutions mandate IoC containers, nor forces you to use their own IoC container, so my point absolutely stands even more. Neither mandate a specific http client, or an internationalization solution either. So stop pretending that Angular 2 is more "enterpisey" than the rest. But I'll let the developer community speak. The lack of popularity of Angular 2 is a sign that it is not going to drive most enterprise front-end.

>internationalization, http calls or routing are separate concerns.

If you view Angular as a UI framework then they are separate, but when you're developing client side applications they are not separate at all - and since Angular is an application framework it ships with those.

>XAML than Angular actually is with its string templates.

String templates ? XAML comparable to React ? Have you actually written a WPF app or worked in an enterprise framework ?

Sounds like you want to argue for sake of arguing or don't understand what you're talking about.

>Should your UI framework ship with an IoC container? you wouldn't expect your ORM to do that, this is a separate concern.

I'd rather compare Angular to Spring, which is also built around IoC and has it's own IoC container.

> I'd rather compare Angular to Spring, which is also built around IoC and has it's own IoC container.

Angular isn't like Spring, it's like JavaFX or SWT, or WFP. Angular isn't a web-server framework. The fact that it tries to come with its own IoC container is a mistake, and a legacy of Angular 1 mindset.

always lots of different opinions on this, HN seems very React biased... which I use in a couple of products, but I find it a bit verbose. I'm finding Vue ( with Quasar ) quite nice

I also like a lot Vue. I have implemented one project with NG2. What I did not really realized on NG2 until "too late" that it is true SPA framework, it does not work well like NG1 where I could just have parts of site (or page) as an "app" and the rest would be normal website. But Vue does that perfectly and so easy to learn comparing to Angular and React.

Could you clarify this a bit, what is the big difference here between AngularJS and Angular in terms of how much of the page you have to put under its control? I am just picking up Angular, coming from v1.

With angular there is no easy way of mixing it with html content from a CMS (something that was powerful with angularjs).

Looks cool! Sometimes I think incremental initialization will be the ultimate performance optimization strategy, and this is definitely a great way to achieve that!

For the debate on ng2, I have been using ng2 to build Huula for about a year, which has some amount of ng2 code. So here are my two pennies for folks who are considering using it. I don't like to be constrained by a framework, so angular's routing system always stands on my way (including ng1), so I ditched angular routing entirely. I never used angular's inline styles either, for me sass works better. Ng2's change detection can be stupid sometimes, especially for stuff similar to drag drop, but there are solutions to those cases, although a bit clumsy and convoluted, so be careful .

Reply on news.ycombinator.com