State of the Art JavaScript in 2016

We all have our opinions and I would say take this article with a huge grain of salt (as well as my comment). State of the art javascript should still be considered a browser + editor + files. There is no need to overcomplicate things, and unfortunately Webpack and Babel do. It is terrifying to see javascript turn into the new Java - build steps and compile steps and configuration and everything you don't need except for distraction from getting real work done.

Build your app first. Then when you are unhappy, see if these tools make your life easier. But play with them first, don't make upfront commitments.

> TypeScript has has union types i.e. "number | string" which are similar to algebraic data types.

I understand that you said "similar", but there's actually a big difference that should be mentioned explicitly, namely that algebraic data type (ADT) sums always have "constructors" which you can use to disambiguate with. That means that you can meaningfully do the equivalent of "int | int" whereas for union types that would just be "int". (I'm sure you already know this, I'm just pointing this out for those who may not know or appreciate the subtleties.) Example:

    data Maybe a = Nothing | Just a

In this example the "constructors" are Nothing and Just.

Of course, you can emulate first-order ADT sums using union types by just introducing artifical container classes and doing a union on those. While this works for simple cases, I believe (but cannot prove) that it's impossible to emulate GADTs using union types -- my intuition is that the presence of constructors to match on is an essential part of being able to "narrow" the types sufficiently to actually act upon what they "contain" (for each case).

However, and notwithstanding all of that... the use of union types in TypeScript is absolutely the best way to align with JavaScript since there's so much JS that just takes/returns values of type "whatever" (string | number | ...).

Btw, also agreed on the productivity boost. In the short term, it may not appear that you're getting faster, but once your application starts to grow beyond "trivial" you really start to notice the fact that you can refactor without fear.

Wow never knew. That's a pretty huge barrier that more people should know about.....

> You may think this is no worse than not having a patent rider at all. But that's not the case. If there is no patent rider then there is an implicit grant which cannot be revoked.

I believe a couple of lawyers have suggested that this could, maybe, arguably be true. However, no court has ever ruled as such, and the consensus among IP lawyers is that it's an unlikely outcome.

If you're worried about potential patent lawsuits, I would NOT suggest relying on the vague hope that someday a court might read an implicit patent grant into the BSD license, especially when you'll be facing off with Facebook's lawyers.

Or do you have some citation for the "implicit patent grant"? In particular, a court decision finding one?

Wow, this is nearly our teams exact stack. One addition would be superagent instead of fetch. I really like Fetch, especially for react-native but superagent is just so simple and easy to use