I Switched from TypeScript to ReScript
medium.com
medium.com
> ReScript, as with other statically typed functional languages, aims at changing the way code is approached at a fundamental level.
We currently have a project written in ReScript and it's an absolute nightmare. Most of our stack is JavaScript/TypeScript/Flow, so no one can just jump in and work on it very easily - they first have to learn ReScript and all of it's different concepts, approaches, and nuances (or refresh themselves if they've done that but haven't worked on the project in a while). It's a HUGE context switch. At least TypeScript is a superset of JavaScript so it's very easy to get up to speed on for a JavaScript developer, and switch between.
For a side project this is fun. But I would never consider this for a "real-world" project (i.e. something you get paid for). At least not anytime soon. Maybe in a few years if there's wider adoption, but that's a long way off.
Practically all major libraries provide a Typescript definition. Especially React, which has become the boring choice for a lot of client side programming. And you were going to end up using some sort of cross-compiler and packager for significant browser code anyway, just to wrap up all that risk about multiple browsers.
That's a bit less clear on the server side, where you have more control. But two things are going for you: if you're going to use Node you might as well use the same language on both sides, and you can cleanly escape to plain Javascript if you feel compelled.
(Personally I'd prefer a less sucky language, but honestly, TS makes JS pretty good. Not great, especially with all the legacy warts, but decent, and at least you get to share code with the browser.)
TS has survived long enough and become endemic enough that it doesn't look like much risk any more, and it's a vastly better language than plain Javascript -- especially for reducing the risks that come with long-term boring projects. If you're writing JS and like boring, Typescript is looking increasingly like the good, boring choice.
- a more solid type system - and a much faster compilation speed (a growing pain in TS projects) - to write mainstream code - for products (as opposed to a focus on intermediate FP libraries)
The fact that it leverages some FP concepts here and there is just a mean, not the end.
The marketing of this is really hard, because FP usually attracts the crowd you'd expect, at the expense of several of the above emphasis. But we're still working toward it.
Having seen some ReScript codebases in the wild, I definitely know where your team comes from. We do try to approach it with the "different TypeScript" angle, but understandably userland doesn't always write code the way we'd like to recommend.
In the spirit of https://news.ycombinator.com/item?id=25846479, we’re trying to become a boring technology. Unfortunately boring technology had to have gone through a hype period.
See also BuckleScript & Reason are now called ReScript:
https://news.ycombinator.com/item?id=25426438
At least from a branding perspective, it seems the whole thing has been quite bungled. But obviously what's more relevant is how well the technical goals actually get met.
However, there are no custom infix operator with Rescript [1], which is quite sad as it makes monadic code cleaner, whereas they were supported by ReasonML.
[1] https://rescript-lang.org/docs/manual/latest/migrate-from-bu... [2] https://rescript-lang.org/docs/manual/latest/pattern-matchin...
At the time, the waters were muddy enough with Reason, Bucklescript and OCaml but you could explain it away. The rebrand and change of syntax that came with Rescript was the end of the line for me. Issues like async await have gone unaddressed for years and instead the community is caught up on syntaxes and compilation targets.
I turned to Clojurescript since. It solved most of it's problems years ago and its functional enough that I don't miss the static types. The large standard library also avoids the questions around whether you should use Belt or Tablecloth or any of the other "standard" libraries.
There are 3 categories of code I’m interested in writing:
- Client code, must compile to JS.
- Server code, ideally would compile to native.
- Tooling code (e.g. Webpack / Babel replacements), ideally would compile to native.
ReasonML could do this, ReScript cannot.
* code is terser
* the JS standard is more stable/standardised
* code can be distributed uncompiled
* code has broader tooling support
* code can be reasoned about and debugged directly and natively in web browsers without the need for sourcemaps/plugins/etc.
* file sizes are generally smaller
* there are fewer config files
* there are fewer moving parts and therefore fewer sources of error
* there are fewer levels of abstraction and therefore fewer sources of error
* etc.
(TS diehards will argue that typing ameliorates higher error rates)
I've been using vanilla JS when not using Reason and it is pretty nice. I hate that safari does not support arrow function methods though (as they allow you to not have to bind `this` in the constructor).
concerning you post scriptum in brackets, what I like with types is:
1. refactoring becomes simpler 2. understanding APIs becomes simpler
[1]: https://caniuse.com/mdn-javascript_classes_public_class_fiel...
Now, if you’re working with something like Angular, TypeScript makes sense and is portable within that ecosystem, but that’s it.
I once wrote a widget/plugin in pure JavaScript and it worked perfectly well. However, because the project’s “standard” was to use Coffeescript, I was forced to rewrite it in that. Luckily I found a Javascript to Coffeescript converter, which in the end I found extremely amusing because that of course gets compiled to Javascript, which had been written in Javascript in the first place. The resultant code looked like a bad translation of English to Italian and back to English again.
And our code is setup to compile to ES2015, I believe.
The reason is simple. Typescript's compilation to JS is really straightforward. You can predict the code that will be generated trivially, because the vast majority of the time it does nothing more than stripping away types.
Since we compile down to ES2015, there are a few additional trivial transformations to handle unsupported features like "let" correctly, but they are also trivial to understand.
I'm willing to accept the basic hypothesis that's static typing makes for less runtime errors. The type system in well thought out languages like elm or rust makes coding in them pretty simple. I don't think that typescript's type system is good enough to actually deliver on this promise.
It's very easy, in my experience, to spend 5 minutes writing a function that I am 100% sure will work fine in JavaScript, and then spend 15 minutes trying to figure out how to type it. I'm sure that this is partly due to my own lack of understanding. Typing is basically a huge add-on to the cognitive load when using this superset.
Of course, it could just be that I'm not very good at typescript. But it's a new technology, and it's very possible to find yourself on a project with people who aren't that experienced with it.
Additionally, I think the type system really pushes you towards object oriented programming. This is fundamentally at odds with the way most people write ReactJS.
Lastly, while deno is becoming a more viable option, most JavaScript development is taking place in node, meaning you have to transpile it. TypeScript adds the overhead of needing a build tool. Using `.mjs` files makes it so easy to spin up a project without any dependencies, something the HN crowd is always kvetching about.
I can only share my experience in multiple companies and products that it does deliver and it can result in a dramatic decrease of defects.
> I'm sure that this is partly due to my own lack of understanding. Typing is basically a huge add-on to the cognitive load when using this superset. [...] Of course, it could just be that I'm not very good at typescript. But it's a new technology, and it's very possible to find yourself on a project with people who aren't that experienced with it.
Tools don't come for free. You need to understand TypeScript in order to use it effectively. In my experience having at least a couple senior or principal developers with TypeScript proficiency makes a huge difference, not just because they can assist and guide you, but because with TypeScript they can create a well typed ecosystem that results in it being easier for developers to code safely and following a well thought-out architecture (or rather, make it harder to not do it right), and set up linters & autofixers and other tooling to make things even easier.
> Additionally, I think the type system really pushes you towards object oriented programming. This is fundamentally at odds with the way most people write ReactJS.
I'm curious what gives you this impression. The codebases I've worked with are heavily functional, with very little OO code —sometimes it makes sense— and if anything TS helps us do FP better.
Why did the author think that this would work exactly?
This works which most language supersets. My point was that it was a trial and error way of discovering that this was not so.
Seeing it as a separate language, I agree that the statement doesn't really makes sense.
I just feel typescript usually gets in the way, sometimes in a good way, but all too often in a bad way.
Plus my main gripe with typescript is that microsoft owns and controls it so I won't use it just because of that.
I also feel Typescript is good, but sometimes it is hard to use because of so many typing. It needs VScode always for auto complete helper. I remember javascript as an old good days...
Instead, I spent a whole bunch of time wrestling with the tooling and configs in order to get my (previously working) code to compile.
I'm not trying to make the conclusion that typescript is bad, as I've hardly even used it at this point. But from my experience, it's not exactly the 1:1 from JS that some people argue. My takeaway is that there can be real value to be had from static typing in JS, but it might not always make sense to introduce the tooling overhead for tiny codebases that are developed by a single maintainer.
People go in this trap again and again, including myself.
"Oh this FAANG uses this, it must be great and suitible for us" - no, it's suitible for them because they have completely different problems than you and have to do stuff in a much more complicated way than you need to.
It's a statically-typed functional language from the ML family, which is a huge deal. It implements a completely different approach to code, even if it looks similar.
It's currently academical, "ivory tower," but in my opinion it will trickle into industry. Someone described ReScript as ECMAScript 2030.