Nemcue

Cool stuff! I built the same thing but with configurable size grid using Hammerspoon.

> If the test isn't necessary, then neither is the code.

How did you come to this conclusion?

What if the code is just glue code for different libraries?

.. manipulate some of that data to improve their ads.

Afaik it's so complex it can't keep up with Lua though.

For context: thelocal is not a reliable newspaper, you shouldn't base your facts from their articles.

Why would flow + es6 be better?

I don't think you're familiar with what TypeScript is trying to achieve. It's not supposed to be another language entirely, but a standards-compatible type-safe version.

You need to realize most mid- and junior programmers simply aren't good.

The difference is that you're spending time learning about concepts that you are unfamiliar with, as opposed to learning Angulars many APIs.

For instance if you've already spent time learning about Redux you'll have a very easy time re-using those in Angular 2 (with ngrx).

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.

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 wish people would just stop pointing this out. While technically true when people refer to React they're referring to the canonical stack that people use (i.e. + Redux).

Except very few actually take the time to understand the data model..

I too switched to VSC from Atom recently, mostly due to the TypeScript-support being vastly superior in terms of both stability and speed.

Really, really wish they would focus on providing a proper crashlog. Right now I'm getting intermittent crashes with no way of reproducing it, nor a good way of providing feedback to the team.