Has anyone considered building with TS--from the ground up--a React-like library? It seems like TS could help deal with lots of data and validation errors in a more concise and predictable way.
The React bindings for TS are quite good--I used them every day, and they're solid.
As for a ground-up approach, the bindings for ReasonML-react show how much effort it takes to have strong functional typing for React: https://github.com/reasonml/reason-react
I believe that there will be an effort to rewrite React in ReasonML in the future by core members. The goal is the leverage the power of Reason to obviate some of the weird parts of the current React internals. /shrug
For Redux I wrote Babydux [0], which is a simplified Redux with the goal of being 100% typesafe. It's the only Redux I've seen with that level of safety.
I have looked at Flow. I have to admit, I am biased toward good-looking code. Unless you use something like LightScript[0], Flow's syntax is not as clean or straightforward as that of TS.
Edit: I just took another look. I thought parameters had to be annotated via block comments (that's how you have to do it if using CoffeeScript 2). I was wrong.
Thank you. I edited my comment after looking at the Flow website. My incorrect understanding came from seeing the atrocious "block comment Flow annotations" in CoffeeScript 2 (an otherwise adorable language) and thinking that was how you had to specify parameter types with Flow.
Why would the type system need to be tightly coupled with the view library? Mithril works well with TS without having been designed specifically for it.
It doesn't HAVE to, but usually libraries designed with a JS mindset don't lend themselves to type safety very well (JS coders like their magic strings and very dynamic types). Somehow React still managed pretty decently in that area whereas vueJS is a catastrophe.
I'd be interested to know how many DefinitelyTyped contributors agree with the "usually" part. My impression is that problems specifying types for existing libraries are the exception rather than the rule.
Many non-trivial libs are typed improperly, even when they can be done right. There's massive abuse of "any" type the moment anything gets semi-challenging. Also, a non-trivial amount of type definitions don't work in strict mode, which make things worse.
Anything involving complicated higher order functions (like lodash/ramda's curry), or having a single method that can be used in various ways that don't fit well with TS' overloading mechanisms are often done wrong or poorly. Flow is a bit better at this, but the techniques it provides are not always well known, so the type definitions aren't that much better.
I used Ember for almost 2 years. My experience was mostly good (see my comment regarding Ember Data--which apparently has no counterpart for React), but it enforces breaking things up into separate files a little too stringently. Routes, Controllers (at least until Components can safely replace them), Components, Templates, and Helpers (even for the most trivial operations which, IMO, are OK to sometimes include in the view).
Not to mention Ember does not use standard ES6 classes yet.
You can scrap most of Ember and just use Glimmer Components, but then all you have is a View layer, so you are not much better off than you are using React. And you __still__ have to use separate template files and helper functions.
This is a side-topic, but I recently attended a Yehuda Katz talk about glimmer. It sounds great. I'm personally really fond of ClojureScript. Glimmer seems to be very much tied to its own tooling and ecosystem. Do you think it would be possible to target glimmer from a functional programming language like ClojureScript or Reason without jumping through a ton of hoops?
