The modal itself presents a single issue I see a lot in modals... in that if the vertical space on the screen doesn't show correctly, the modal won't scroll, also, the page in the background does scroll[1].
I generally put in the effort to work around this.
[1] https://github.com/juanbrujo/tinyModal/issues/4
IIRC, flow doesn't/didn't work on windows, which is a non-starter for a lot of users... not sure where this stands now, last looked at it when using flow types to be able to use angular 2 without typescript, as I mentioned, I didn't see the point as I still needed bits from babel.
But flow adds type support (same as typescript), and can also be used with babel... flow only does one thing, so better integration. Typescript doesn't offer much beyond types (and flow does that) over babel.. and as you say, you're using babel anyway.
Because at runtime, typescript doesn't provide type checking... ie: when interacting with a foreign API... Beyond this, with small, well-organized modules, TypeScript tends to only add boilerplate, and doesn't tend to prevent as many errors as the time to write boilerplate prevents.
I can see why some would like it, I just don't find much value in it.
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.