I Switched from TypeScript to ReScript

https://medium.com/att-israel/how-i-switched-from-typescript-to-rescript-637aa5ef8d3

by ronenlh • 6 years ago

62 45 6 years ago

ecmascript4• 6 years ago

Why not simply use Javascript? Today it's a fine language. You may complain about fatigue etc which I can buy, but Rescript is simply not solving that.

netdur• 6 years ago

the only reason I'm using typescript over javascript is types, once I converted a huge code base, there were instances where I fed javascript wrong number of args, or just wrong type of args and it did work (failing subtly on runtime), otherwise is perfectly fine.

ficklepickle• 6 years ago

I also like it for not having to constantly check properties before using them. I parse the data once at the application boundary (like after an API call) and then I can use it with confidence.

ecmascript4• 6 years ago

Ok well that is true and may happen sometimes. Personally, I have just dabbled with type definitions, configs etc much more than I ever had those kinds of problems in javascript.

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.

root_axis• 6 years ago

Because of static types. If you're building software that needs to be maintained over time, types are always preferable to a lack of types. This is because types codify the shape of application data structures that exist whether you explicitly define them or not. A lack of types is a form of technical debt that every future developer has to repay as they discover application data structures through trial and error.

fulafel• 6 years ago

Obviously there are a lot of people who disagree. I'd expand but it would feel too ad hominem due to your nick :)

laurent123456• 6 years ago

Refactoring a large code base is way easier with TypeScript than it is with JavaScript for example. Getting familiar with such a large codebase is also easier with TypeScript thanks to good auto-completion in editors like VSCode.

fergie2• 6 years ago

I was using TypeScript all through 2019. Went back to plain old JavaScript at the beginning of 2020. Still using plain old JavaScript by default, and break out React when I _really_ have to. No regrets, many benefits.

polyterative• 6 years ago

typescript is liteally a superset of js. what are your benefits

fergie2• 6 years ago

The biggest practical benefits of plain JS over TS are that:

* 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)

schwartzworld• 6 years ago

I'm not op, but here's my opinion:

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.

throw_m239339• 6 years ago

People here are forgetting that Typescript is first and foremost a static code analysis tool for Javascript. You can run Typescript's compiler WITHOUT writing a single type declaration as part of your CI, and you should. You don't have to write a single .ts file to use Typescript.

sradman• 6 years ago

ReScript is not just a rebranding: it’s a ReasonML which freed itself of the yoke of the OCaml ecosystem. By doing so, it forfeited compilation to native code and OCaml library interop, but gained a freer syntax which further resembles JavaScript

See also BuckleScript & Reason are now called ReScript:

https://rescript-lang.org/bucklescript-rebranding

frou_dh• 6 years ago

Here's a great comment explaining all the permutations:

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.

globuous3• 6 years ago

Generally speaking, I am pretty happy with the (small) syntax changes from Reason to Rescript [1]. No necessary semi-colon, arrays, object declaration & access. We can finally pattern match on arrays [2] which I think was not possible with Reason (only lists were).

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...

richeyryan• 6 years ago

A couple of years ago I was a big advocate of ReasonML and went so far as to run a meet up. I honestly believed in the technical value of it and saw it as a better alternative to Typescript.

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.

atom_arranger• 6 years ago

I find the dropping of native compilation to be unfortunate.

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.

I would like to write these things in one language.

ReasonML could do this, ReScript cannot.

codewithstein• 6 years ago

I'm actually a fan of JavaScript. Even though TypeScript/ReScript might add some cool features, I don't feel the urge to switch...

ronenlh2• 6 years ago

My interest in ReScript is that it doesn't aim to add more features to JavaScript, it's a completely different language which has a JavaScript-like interface and compiles to JavaScript.

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.

joekrill• 6 years ago

I think the best point in the article is this:

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.

Cthulhu_• 6 years ago

It's a common challenge with any kind of software; as a company, you want to avoid adding more to your stack, even if it means using a suboptimal or boring technology. Every new technology adds complexity and difficulty. Actually I'll just link it, it explains the concept much better (and with pictures!) than I can: http://boringtechnology.club/

fxleach• 6 years ago

TBH I'd stray from using TypeScript in your company stack as well, but I guess I'm just boring.

chenglou• 6 years ago

I help maintain ReScript. That it _seems_ to change the way code is approached is an artifact of an early community excited to try FP concepts in it. Nothing wrong with that; however, the ReScript team (me included) don't really approach things this way. Our goal, outlined at (https://rescript-lang.org/docs/manual/latest/introduction), is to provide:

- 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.

JacksonGariety• 6 years ago

Simply renaming the file extension won’t work, as the compiler stops completely at type errors.

Why did the author think that this would work exactly?

onion2k• 6 years ago

It works in TypeScript - just rename something from JS to TS and the you have the benefits of TS's types, warnings, and features but your code will continue to work. Untyped things default to 'any', which is useful if you want to migrate a project from JS to TS. It's a very useful feature if you have a mature project in JS that you want to improve.

pantsforbirds• 6 years ago

I think it was supposed to be a comparison to Typescript. Since TS is a strict superset of JS you can simply rename a file and refactor into TS as you go.

ronenlh2• 6 years ago

That's how it is with TypeScript, CoffeeScript, SCSS...

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.

znpy• 6 years ago

So what now, TypeScript is not hipster enought anymore ?

I Switched from TypeScript to ReScript

Related Stories