Comment by EugeneOZ | Hacker News Reader

Comment by EugeneOZ | Hacker News Reader

I use Angular 2 in production since November 19, 2015 (alpha.46). Currently I've built 3 web apps (40, 60 and 20 components each), 3 mobile apps (with Ionic 2) and my employer have plans for more apps.

Breaking changes during alpha stage were expected, so I didn't have issues with it.

Most positive things I want to highlight:

1. Components are encapsulated and truly reusable (and without dependencies hell).

2. You don't need any "bridges" anymore to use 3-rd party JS libraries inside your Angular app. Nothing need to be "angularized" - twbs, D3, all just works out of the box. Maybe it's even most important part for me.

3. Idea of `(events)` and `[attributes]` is awesome, works really effective and makes code much more easy to read.

4. Performance is great.

5. Community is friendly and have a lot of fun and patience, even to newbies.

6. TypeScript gives a lot of bonuses with zero price - you don't need to learn anything (you can just rename js to ts and it will work) and additions to JS are simple and powerful.

7. Cool abilities like AOT-compilation, server-side rendering and tree-shaking.

Congrats to the all devs who are using Angular, congrats to the Angular team! :)

Any chance you can do a quick cons review too? Specifically comparing to the weakness of Angular 1 like bloated complexities, issue with custom directives or scope life-cycle.

Obtuse error logging is my biggest problem. A lot of the times you have no idea what's going wrong.

That's a general javascript problem though as soon as you involve any third party library.

Something funky going wrong when jQuery's involved? Good luck stepping through that.

May want to give Sentry a try for error logging: sentry.io/for/angular2

Let us know if there's anything we can be doing better :)

That's pretty slick. Thanks for sharing.

Right now, some of the Angular 2 error messages are cryptic - I find it very difficult to figure out what goes wrong in tests currently with Angular 2, the only utility of some of the error messages end up being that there is an error in Angular's compilation of a component (for example).

This is the reason why I've been separating recent projects into two webpack bundles.

I put all libraries into a common bundle, which I blackbox in the browser debugger. This way only frames from my own code show up in the stack by default, and the debugger won't step into library code.

This also makes stack traces very easy to visually parse, as you can pretty much ignore all the ones ending in "... (common.js)".

React actually does a fabulous job of spitting out very readable error messages. It removes so many debug cycles from development that it alone is worth switching.

Anything that 'spits out' readable error messages in javascript hijacks the error stack.

Which is doubly shit.

The main con I can think of are all the extra tooling and dependencies required. However, even though angular-cli is yet another tool, it aims to solve the extra tooling problem so you don't have to know how the tools work and how to configure them. Managing third party dependencies with NPM still isn't fun and can be frusturating IMO, but it sure beats script tags.

BINGO! It smells like GWT all over again.

I love experimenting with ng-1: make a static HTML mockup; add a stub controller with a sample model and modify the HTML to insert the data and edit things as needed; add some event handlers with dummy actions. (add your REST calls later...)

All of the above can be done w/out any server or compile process - just keep reloading the page when you make changes (perhaps using something like python's SimpleHTTPServer module to serve files from your development directories). Once you get things about how you like them, start on the server side. This approach won't work for a page with a complicated workflow, but you can still prototype quite a bit for an initial learning experience.

Cons:

1. Typescript. If your team isn't familiar with it it's not trivial to get everyone on board. The up-front cost can absolutely be worth it in the long run, but there's some friction in the day-to-day work with managing type definition files and looking up esoteric lint-errors from the Typescript compiler.

2. RXJS. Canonical NG2 should use Observables, and rxjs is not a trivial library to learn the ins and outs of. Add to that that there's no clean way of doing testing with Observables at the moment (integrating with the rxjs testing schedulers is very finicky). This is doubly true if you're using ngrx (which you probably should).

3. Template language. I'm one of those who don't think it's a very good idea to bring a new DSL into html. I'd much rather do it the React-way of bringing HTML into JS instead of relying on a very complex compiler to do magic behind the scenes. This becomes a bit better with the template pre-compilation, but it's still new syntax that you need to learn and keep in mind. Some of which is not intuitive nor well documented (i.e. how pipes and parentheses work together).

4. It feels unfinished. This is to be expected since it's just on it's initial release, but the sharp edges do show up quite a lot. For example we very often have to do manual subscription and unsubscription of Observables in Components. This feeling also goes for quite a few of the community addons, such as the browser-extension. While I absolutely applaud their efforts, it's far from reaching the quality of e.g. the Ember-Inspector.

5. Sub-par debugging experience. When you get any errors there's a mile long stack trace filled with rxjs and zone.js garble, making it very hard to actually figure out what's going on. When there actually are custom error-messages they are not very informative, with you having to fundamentally grok how parts of NG2 works to even come close to understanding why it's not working (getting this a lot with the change detection).

6. Lack of documentation. I tried to stay very far away from Angular 1 since I found its documentation to be very low quality (probably a symptom of Angular 1 being poorly engineered as well). The NG2 docs are definitely better, but I feel like my mental model for reasoning about how things work was still very weak when I had finished going through the docs. There's some really huge gaps in there (testing) and a lot of the really complicated stuff that you will stumble over is only really documented in semi-old blog posts.

> I tried to stay very far away from Angular 1 since I found its documentation to be very low quality (probably a symptom of Angular 1 being poorly engineered as well).

I haven't found either of these to be the case. Is your experience recent? If so, will you expand on it? I like Angular 1(.5) quite a bit, but I'd be interested to hear more about a different perspective.

My experience with Angular documentation was similar, as well as the getting starting guide.

I remember posting an issue on stack overflow about an issue I was having on the first few pages of the guide, I realised I had misread the docs, and I answered the question myself. But that post is now my top voted question on SO, so I don't think I was alone on my experience with the Angular docs. Mind you this was 2014.

Compared with my experience with the Ember docs, the Ember docs & getting starting guide was way more readable & easier to follow. (also in 2014)

In 2014 when I started using Angular, I could not make heads or tails out of the docs and went stright to 3rd party tutorials. Today, if I know what I need and just need to remember the syntax, I will go to the official docs, but if not, I search elsewhere. I still don't think it's suited for learning.

I had the same reaction. What made it worse for me was that there was no "standard" way of doing things so different third-party tutorials would take different approaches. There was nothing I could find that suggested what the team would recommend how to approach different things.

Other libraries and frameworks have multiple ways of doing things but most times the documentation would provide an example that could be considered the way to do things.

It's very strange to me, any one of the cons from 3-6 will make me avoid a framework. Do you think the pros of the framework outweigh these serious cons?

Hard to test, hard to debug, poor documentation? Yeah, sounds like I don't want to be near it.

To be fair, outside of testing I have generally found the documentation to be excellent. Also, the debugging tools seem to be pretty nice. In particular, Angular Augury looks amazing: https://augury.angular.io/

However, if you dislike the approach to templating, you will definitely dislike angular. This is one of those things that is controversial, regardless of which approach they had chosen.

At the moment? No, I don't think so.

To be brutally honest I think the only reason why this is on HN frontpage is because of its name. It's quite telling that they kept the name despite it being a totally different beast with (imho) an entirely different audience. No way they'd get this much support from the webdev community otherwise.

However I do see the potential, and one should not forget that this is just the first version, straight out of the oven.

Give it some time and I'm sure it will improve.

It kind stinks because they iced the growth of angular 1 when they announced it.

Solid list. Having just used Angular 2 on a side project, I'd also add that I'm not the biggest fan of passing properties between components. @Input and @Output don't seem particular intuitive nor necessary, but maybe I'm just used to React.

I haven't tried ng-2 yet but that does seem like an improvement over ng-1 where AFAIK the best way to do this was to declare some service that directives could depend on.

I felt like I was writing really bad code passing stuff around like this. My project became ugly to look at, even though it worked. This was in February and I'm hoping that either better docs will prevent this from happening to me again or maybe that some changes they made in the 7 months since fixed all that.

I dread to go look at that code...

On 3. I've found Aurelia templates to be much better in that regard. Their templates are valid HTML and compile well. I'm not a huge fan of embedding html within the JS (even with JSX) been easier to work with separate template files and keep as much JS out of them as possible. This has helped reduce harder to debug errors that crop up when the JS inside templates fails.

I concur. Aurelia feels much more like the standard HTML that I've been working with since the 90s, only more powerful. Hence we get power without unnecessary complexity.

Well 3 is a preference (as you've indicated), while I have nothing against transpiling I'm not a fan of having a XML DSL in my Javascript. I can't speak for angular, but I much prefer templates along with a build system that bootstraps everything.

RXJS and it's learning curve, not just getting it to work but getting it to work idiomatically has been my biggest struggle with NG2.

The lack of documentation about testing is a major annoyance. I really thought that they would fix that before declaring a final release of 2.0.

We've converted all our node apps to typescript and I've even started messing around with replacing all our back end promises/callbacks with rxjs.

You might want to reconsider using RxJS on backend, since it is significantly slower than Bluebird promises (which you should be using instead of native V8 promises at least for now) http://bluebirdjs.com/docs/benchmarks.html

> looking up esoteric lint-errors from the Typescript compiler.

Thought that's a lot better than hunting down bugs in production.

> 5. Sub-par debugging experience. When you get any errors there's a mile long stack trace filled with rxjs and zone.js garble, making it very hard to actually figure out what's going on. When there actually are custom error-messages they are not very informative,

And they said your angular 1 experience wouldn't carry over.

> 5. Sub-par debugging experience.

I've worked with AngularJS and React. After spending enough time with each framework that I'm "productive" with them and don't get constantly confused by what's going on, this is now by far the most important reason to me when adopting a framework. React(and Redux) just spoil you with an awesome debugging experience, and it's just painful for me to go back to any set of tools that takes some of that away. The rest of the points I've already "suffered" through with AngularJS, and it is my opinion that they are a rough, but surmountable cost. Having a poor debugging experience, however, just kills my willingness to work.

(For the record, AngularJS has some debugging aides - you can inspect scopes pretty easily given a DOM element. However, the watches and digest cycles, which do all the heavy-lifting, are pretty much opaque - you need to have a good understanding of how your watch expressions are compiled into watch functions and place conditional breakpoints deep within the framework in order to inspect why a certain watch is not being called/being called too many times)

They were going to re-write their router for the 3rd time. The back button's broken in some angular apps now.

Filter and order by pipes removed :) (for a good and documented reason, but still something I've been missing)

1) Build (compilation) system is complicated enough and all of these providers/declarations are not intuitive;

2) amount of boilerplate code for unit-tests (not e2e - everything is fine there);

3) some things were removed by performance reasons - I think would be smarter just rename them with prefix "slow". Sometimes it's more important to have some functionality than don't have it, even if your app is blazing fast.

No thanks for the next 1 year, after Backbone, Angular 1.x, React-Redux, I am going to take a break from learning a new framework. React-Redux is simplistic with most of my coding being JS, I don't want to keep looking up documentation for ng-this and ng-that. If the framework really takes off in 12-18 months then I might consider investing some time in it.

I really really really wish they'd called it something like Bosium just to make searching for issues a lot easier. I keep coming across angular 1 solutions.

I think we should all agree and call it ng2?

Anything but Angular. ng2 works for me.

I wonder if Angular will develop into a sort of "Perl 5 vs 6" thing? Perhaps if many people just aren't ready, willing and able to make the jump to the next version.

> 3. Idea of `(events)` and `[attributes]` is awesome, works really effective and makes code much more easy to read.

This is encouraging. I always thought that looked aweful so it's nice to hear that it actually makes sense.

Well it's a bit confusing / weird at first until you get used to it but the real confusing syntax is the mix of both for bidirectional binding, e.g. [(ngModel)], but after reading the docs it kinds of makes sense. Awesome job, love it so far.

Having used ng2 in production for a while, I personally dislike the model behind this, mainly because it is not actually symmetric as it appears from a first look:

- input:

  ```
  <foo [x]="y"></foo>
  ```

- output:

  ```
  <foo (x)="y = $event"></foo>
  ```

To me this seems unfinished and inelegant; note also that everything is inherently mutable, but change detection will work best when the bound input values are reassigned, but if they are instead mutated at some deeper level, Angular will have trouble tracking those changes, and may behave in weird ways, which are often tricky to debug.

try [()]

I haven't used Angular yet. From it's description it seems to be geared for making single page apps. Or a app with a few pages because it's good a binding data to an interface.

Is this accurate? What is a good use case for Angular?

I think you've basically got it.

I have used Angular in multi-page application, using Angular as a better JQuery in Spring MVC application. This setup worked well combining the best of both frameworks. Angular provided two-way binding, rendering templates (in loop), dialog box interactions, better AJAX, etc. Angular based component libraries provided calendar controls, dynamic tables, etc. Spring took care of the routing pages, handling UI requests and returning JSON response from services.

I think we should not discount this style of building a web app. I've also had success with it.

You need to think hard about whether you really need a SPA for something complex, or whether you can go back to the server completely in some instances.

Did you use a templating engine at all?

Taking the load off of your server, and making the user's PC/tablet do more work, as well as greatly simplifying the server code to focus on data flow, business logic and data integrity, rather than mixing in presentation and minor U/I workflow complications. Having much of what you give to the remote client be static/cacheable content, with minimal data such as JSON passed rather than ballooned out JSP/JSF (etc) templated HTML, helps bring down bandwidth requirements, as well as server processing.

Of course, now you have A LOT of event handling in a client app on top of your middleware / micro-services, but I feel it is a helpful separation of concerns.

I suppose in my case it helps that I would rather do more of the app in Javascript, and less in Java. YMMV, substantially - I'm pretty sure I have a minority view at work :-)

We are working on a rewrite of a largish app (for a small team, anyway) at work. We already have a second, alternate, client app for our back end for a pilot project that we can now easily tackle with the new architecture. There were very few changes required on the server, just an alternate login method to automate an initial connection to a third party app (which then runs our alternate U/I in a frame), rather than an interactive SSO form.

We have a "Few Pages App", rather than Single Page App. By design, we reload a small number of alternate pages after a longish task, just in case (e.g. - resource leaks, whether from our own mishandling, or some library) - not because of known issues, mind you, but just out of my own paranoia that I would rather plan to allow for minor errors rather than requiring perfection.

Can someone elaborate on point 2 about 3rd party JS libraries? How does Angular 2 allow these libraries to work out of box? For example, masonry or Google Maps JavaScript SDK.

In Angular 1 the only way to use them without resorting into angular-XYZ libraries is to put them in a directive and use the link function to write all the logic and DOM manipulation. What's different in Angular 2?

Angular uses Zone.JS for it.

Op probably mean, that there is no Angular/ outside world barrier ( which often required using $apply function ).

>In Angular 1 the only way to use them without resorting into angular-XYZ libraries is to put them in a directive and use the link function to write all the logic and DOM manipulation. What's different in Angular 2?

Well, there is no $scope in Angular 2, so there is no need for link function ( which was used for linking scope and DOM)

Do you know of any large projects that use Angular 2? I just want see how readable the projects are.

Google AdWords - hope thats big enough.

A caveat: they are using the Dart fork (now maintained by the Dart team) which is not what this announcement is about. Not sure what the biggest Typescript app is.

As far as raw TypeScript apps, VS Code and TypeScript itself are pretty good examples.

https://github.com/Microsoft/vscode https://github.com/Microsoft/typescript

I'd like some good examples too that aren't barebones tutorials.

Not sure if this helps, but trying to learn Angular2 I wrote a weather app with it using RC5. It is not the cleanest and I never used Angular 1 so I can't do a comparison.

https://github.com/mattsmithdev/weathercard.angular2

you can refactor those nested observables using mergeMap:

  this._settingsService.settings$.mergeMap(settings => {
  
          this.settings = settings;
          return this._weatherService.getLatestWeather(this._location, settings);
      })
      .subscribe(
          weather => this.weather = weather,
          error => this.errorMessage = <any>error
      );

Thanks. Learning observables was definitely a little challenging, so I appreciate the insight.

Thanks you for sharing such a beautiful weather app.

I asked around at ng-conf earlier this year, and nobody outside of the speakers were using Angular 2. I did some proper digging again a month or two ago and still couldn't find any examples of large NG2 projects in the wild.

Not very promising...

React on the other hand, I stumbled upon looking at the source of the Wall Street Journal the other day. It is everywhere now.

There is an example of an ng2 app using ngrx platform that is reasonably large -- ngrx is a redux using rxjs (more-or-less).

https://github.com/ngrx/example-app

The Weather Channel. Lucidchart. Both in production, IIRC.

Granted, not open source, but definitely drives home the point that it is trusted in production environments.

I am really surprised to know that there are people that use an alpha version in production. I would never ever do that even if it was allowed, and obviously it is not allowed in my company.

alpha guys do that.

Oh, so that's what all these "alpha man" stuff on the Internet is about: folks who are manly enough to use alpha versions in production. Makes sense now.

People who only take it up at the beta stage are obviously inferior, and hence denigrated as "beta men". And then there's the detestable wimps who go only for 'stable' versions, I suppose they must be "omega men", not even worthy of a mention in discussions.

Glad to know Real Programmers[1] still exist amongst us.

[1] https://www.cs.utah.edu/~elb/folklore/mel.html

We started using it for internal web app, were satisfied by the level of quality and then switched main site to Angular 2.

What about angular CLI - ? have you found that useful in your workflow?

I have found Angular CLI productive, because it helps quickly generate components (each component has an html, ts, css, and spec.ts file with some boilerplate code). It is fairly quick to get up and running with angular-cli as compared to writing a webpack configuration file. However, since angular-cli is in beta, it lacks the flexibility that using webpack directly would offer. (P.S: Angular-CLI latest release would be using webpack internally)

their tutorial is still based on systemjs instead of webpack, not sure which loader ng2 is preferring, I hope it's the latter.

I'm waiting when they implement some more flexible (configurable) tool, and meanwhile I use angular2-seed.

Reply on news.ycombinator.com