I'm going to agree with several of the comments that async/await sugar around generators would have been more welcome than non-nullable types.
Then again, I kind of find TypeScript itself of questionable value over es2016 + stage1 via babel.
I'm not sure why jQuery isn't using the built in Promise with v3, and/or requiring or even including a shim, only if it isn't available/set. I know that bluebird will show an error if there's an uncaught rejection in their implementation, pretty sure browsers are heading in that direction.
Pretty good comparison, although this is a really limited use case and will favor some frameworks over others. Also many apps won't be making this many DOM changes in this short of a time.
I'm particularly interested in the production payload size for inferno vs preact. I've used preact for a few small thing because the payload size is so small by comparison. The inferno memory footprint looks similar, so for a similar payload size, it might be worth switching them out.
I know monotype is probably making their comment in jest... just the same, specifically ng2 vs react, I think that ng2 has a *lot* in the box, however I find that once you get past how to initially use react (specifically jsx, and a state management library like redux), there are very few gotchas, and some room to tweak. With angular 2, at least from my limited experience, there were a *lot* of wtf moments, and places where you can easily shoot yourself in the foot.
I admit, I'm biased, but there is support for that bias. Not to mention, I tend to solve most problems with a more functional mindset.
Love the last paragraph...
And, no. Do not give me that bullshit about Android
or iOS being easier to develop for because they’re
single platforms. Nothing is stopping you from
sniffing user-agents, developing for a single browser,
and blocking all the rest with a big fat “Your browser
is not supported” notice, as bad as that’d be. How is
that any different from developing for a single mobile
operating system? Well, it’s different in that at least
on the web you don’t have to put up with App Stores, a
proprietary API, breaking changes, or licensing fees.
One comment, one critique... First, it's somewhat obvious English isn't the author's first language, some of the constructs are a bit out of order, which is actually okay, the gist of the message comes across.
What actually bugged me a bit more than the language/grammar, was that some events are just plain out of order, even with the dates it's would be harder to follow without having lived through all those changes.
What's funny is I kind of suppress most of the past in that regard, and simply push forward towards the newer syntax. I'm really glad that pretty much all of ES6/2015 is now in the browsers (IE now needs to die), and that even async functions should be common soon. With all the major browsers pushing frequent and mostly automated updates, it should get a lot better in the next year or so... right now, there's already modern/minimal transform options in babel, to let you use the latest features, without the full es5 transforms from even a year ago that were mostly needed.
I think it will be an interesting couple years. More interesting is some proposals to get a few F# operators into JS, that could be pretty cool. The combinator >> operator (used to combine functions into a new function) is pretty interesting, even if it shares the same operation as shift, it would need some tweaking to the standard. Although, fat-arrow syntax mitigates a lot of the issues, there are still leaner syntax operations that can now start to come in.
Nice, I'm glad he kept the Error serialization, though I did have two issues (pull requests made)
1) shorten to return new Date(obj); will clone the date.
2) don't return early from error object, some frameworks extend the error instance with things like exit codes, etc.
(note, I wrote the tracker1/safe-clone-deep author mentioned)
Love the last paragraph... And, no. Do not give me that bullshit about Android or iOS being easier to develop for because they’re single platforms. Nothing is stopping you from sniffing user-agents, developing for a single browser, and blocking all the rest with a big fat “Your browser is not supported” notice, as bad as that’d be. How is that any different from developing for a single mobile operating system? Well, it’s different in that at least on the web you don’t have to put up with App Stores, a proprietary API, breaking changes, or licensing fees.