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.

Sounds like something the US would do.

I too do my absolute best work in that kind of mode. However, I'm thoroughly lacking on the "take a well deserved rest" part after crunching on my own. Since no one actually sees me working so hard, I have no idea how I would go about making sure client/boss would be happy with that.

Oh great, now everyone can enjoy the immense horribleness of TFS.

You're probably being downvoted because you come off as incredibly smug.

No, it needs HTML for silly technologist not to whine when their browser extensions break the web.

That's an incredibly dehumanising way of viewing the world. A view I guess is shared by the ones who conducts your tortures and carries out your murders. Shame on you.

To the citizens of nations that are being bullied by those organisations it's NOT a feature.

which was never a real problem in the first place...

You obviously haven't worked on any legacy app built in jQuery.

Sometimes a solution — or a variety of different solutions — still have a significant pain point attached to them.

Just because of that, you can't derive with absolute certainty that there's "a better solution". It might just be the nature of the problem has no solutions that everyone "likes".

Not easier to reason about?

I would argue the opposite — it is immediately easier to reason about, since I see what functions are called, and I can go look up the documentations for those functions without having to go through a precompile-step.

One big feature in my mind — and I've used both Handlebars, Mustache, and HTMLbars a lot — is the fact that it compiles straight down to a JS data structure.

Especially with Handlebars it's always kind of tricky to debug, because there are all sorts of strange conventions going on, and it ends up being very hard to mentally parse.

With JSX (of course the same with Mithril) you get a data structure that is very easy to reason about.

That is because you're used to JSX. They are equivalent to me, and — disregarding the fact that you used arrow functions in one and not the other — equally easy to read.

What would make it "hard" to read? The fact that the third argument is the text?

That's just a tiny convention.

"I'm still yet to be convinced that JSX is a good idea, why break existing tooling and significantly complicate parsers for what appears to only be a minor convenience at the surface level?"

Because the template is already so coupled with the view logic that you might as well put them in the same place.

And when we've reached that point, it make sense to make the template as legible as possible. Hence JSX.

Also, no one is forcing you to have the JSX and views in the same file. You could have them be separate, with a different file prefix (.jsx) for the template and not break any existing tooling.

And lastly, https://github.com/insin/msx (Mithril + JSX) is also a thing.

What— you don't approve of the sleek aluminium unergonomic mushroom-key:d Apple Keyboards?

Heretic!

You have no idea what you're talking about.

Because they are libraries, not frameworks.