Exactly my experience, when they've introduced Context API in the latest version of react (16.3?) I and was seeing all these blog posts about them on all my feeds, i looked them up and tried to understand what the fuss was all about, and when I finally understood, I was like "Ok so it's solving exactly the same problem that @Injectable Services solve, but in a way more convoluted manner)
Full type inference, pattern matching with exhaustivity checker, modules, abstract types, ...
But to be honest, it's not very useful to do checklist-style comparisons — writing OCaml/Reason code is a completely different experience.
For me it results in less worry about how my code would sustain under refactorings — this is one of the reasons I feel more productive with it rather than with TypeScript or Flow or (of course!) plain JS. I can start writing code and don't worry about getting everything right upfront — refactorings are cheap.
I have replied to this question on SO [1], here is quote:
In a large application you will need a lot of features, which are provided by default in ReasonML: strict types, runtime validation if you encode/decode JSON, fast compilation time, immutable data.
In TypeScript you will have to add:
1. ImmutableJS + its typings.
2. Runtime validators like json-schema + its typings. Then you will have to write types in TypeScript, and also defined a schema in json-schemas. They can become out of sync very soon.
3. Some crazy hacks to tell the difference if variable is of specific type (like in official docs of TS: https://www.typescriptlang.org/docs/handbook/advanced-types...., Paragraph "User-Defined Type Guards"). This checks are done using side effects like a.swim !== undefined. In 6 months this 'if' statement will contain more and more checks.
4. You are lucky if a package you use has official and maintained type definitions. Or you will end up with custom typings.
5. If you develop hybrid app in JS + TS, then TS Compiler cannot create a bundled final d.ts file which you can import in other parts of your project. You will have to write separate d.ts files, which are bundled by tools like dts-bundle. If you have everything in TS, then this issue is not applicable.
6. Large apps take a lot of time to be compiled by TypeScript.
With ReasonML:
1. Immutable data is in the language.
2. Runtime validators are present (bs-json has them by default).
3. Pattern matching saves you from these crazy checks.
4. You are lucky if npm package you want to use has BuckleScript bindings.
Hi, I work on Reason: To add to other comments:
One thing that ReasonML can do that TypeScript cannot do, is take advantage of the world-class OCaml compiler to generate very fast native executables. If you learn Reason, then you are also a "native developer" in a sense.
In my opinion one of the most useful features is first-class support for algebraic data types. Using records and variants ('sum' and 'product' types) in Reason one can be much more expressive in terms of how program state and other constraints are defined.
One can get some of the same benefits of sum types in TypeScript using discriminated unions - but the syntax is cumbersome and requires boilerplate as compared to Reason.
Yeah... It would honestly be cool to have a TypeScript native React(as crazy as that sounds). There are some really great projects out there killing it like Nest, MobX, TypeORM, etc.. The React typings have come a long way though.
I do quite a bit of TypeScript for the server though(less context switching and is mostly GoodEnough™) so still handy.
Angular plays very well with typescript, because the entire framework is written in it, more than that, Angular Team is working with TypeScript Team to help make TS better, and vice-versa.
The problem with Sails is that unlike Rails or Django, it's not very popular. This not only means a lot less documentation and help for you but also help for the maintainer (financial or code-wise). This means a slow rate of development, bug fixes, and updates.
I do agree with another poster in that if you want a opinionated just works stack, use Ruby or Python.
> I would be so happy if someone took away my power to choose and just forced me to use something that will "just work".
That's basically what Google did on the front end with Angular for people who had the exact same problem with React. Maybe we'll see something like this happen on Backend Javascript, I mean there is Sails, but it doesn't "just work" as well as Angular does on the frontend.
