Hacker News Reader

Comment by ralmidani | Hacker News Reader

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.

View on HN

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

Mobx is built with typescript. https://github.com/mobxjs/mobx

To be fair, mobx is more of a not-anything-like-react-like library.

Disclaimer: I like mobx

Not React, but he has a React library as well, but not written in TypeScript.

React is already typesafe.

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.

[0] https://github.com/bcherny/babydux

"Redux for babies" sounds like an insult.

It reminds me of this Nathan For You episode:

https://www.youtube.com/watch?v=BNuuiydKlI0

Looks like a nice library, but I'm not sold on the name

Not "duckling"?

React is built with Flow. Since Flow and TS achieve the same thing, I'm not sure a React-like library based on TS would bring anything new.

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.

[0] http://www.lightscript.org/

The following example written in TS works in Flow too:

  type MyComponentProps = {
    prop1: string;
    prop2?: number;
  }

  type MyComponentState = {
    foo: number;
    bar: string;
    baz: number;
  }

  class MyComponent extends Component<MyComponentProps, MyComponentState> {

Same syntax.

Also, not sure how this could be more straightforward.

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.

Well, there are over 10,000 occurrences of 'any' (which effectively gives up on type checking) in the DefinitelyTyped repository:

https://github.com/DefinitelyTyped/DefinitelyTyped/search?q=...

It's true it's easier now that typescript has richer types (nullable, mapped, etc)

Nerv is a React alternative that's been built with TypeScript. Check it out: https://github.com/NervJS/nerv

This is what you need:

https://dominicstpierre.com/using-typescript-to-publish-a-te...

Glimmer.js faster and more elegant than react. https://github.com/glimmerjs

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?

Reply on news.ycombinator.com