This content originally appeared on Bits and Pieces - Medium and was authored by Fernando Doglio
Did we really need another one?
CoffeeScript, TypeScript, PureScript and now we also have ReScript. Granted, it’s not “new new”, but it’s recent and it’s trying to take the place of the good old, and Microsoft-backed, TypeScript.
So what do you think? Do we need yet another JavaScript alternative? Should we stop playing around with these languages and start using JS accepting its flaws and defects? Aren’t we tired of alternatives popping up every year?
Welp, apparently no, we aren’t.
What’s the deal with ReScript?
Really, what makes it different from all alternatives?
Like many of them, it’s an opinionated version of what JavaScript with a strongly typed system should look like. According to their website (and from the tests I’ve made myself), the type system is:
- Better than Typescript’s because it’s simpler and inferred. Yes, TS can infer some types but it doesn’t encourage you to let it do it. However ReScript does and their interpreter is quite good at catching those typing errors.
- Static, because it’s not used during runtime. Which if you ask me, it’s an oversimplification of the problem. But who asked me? Nobody. According to them, the static inference during compilation is all you need to make sure your code is safe from those nasty bugs.
- Fast. And I can attest to that after my tests with the language. With the VSCode plugin, all you have to do is save the file and you’ll get immediate feedback.
Granted, their type system sounds awesome, but that’s not all they try to sell you as a better alternative to TS. There is the fact that they don’t try to be a superset of JavaScript, but rather a curated list of features.
That means they distilled the original language into what they deemed appropriate (thus, the opinionated part). In practice this means you don’t have constructs such as classes, loose global objects such as console or semicolons for that matter (that’s right, they finally settled that age-old argument: semicolons aren’t needed, deal with it).
For you, as a JavaScript (or TypeScript) developer looking to educate yourself on a new thing means you have to re-learn the language. It’s not just about adding type annotations with RS, you have to re-learn how everything works. Is it too much of a hustle? For the basic stuff not really, especially not if you’ve also worked with other languages such as Ruby or Python.
For instance, the IF statement now changes to:
The parenthesis on the IF ‘s condition aren’t needed anymore and the body of the IF is an expression that returns the last executed line. You can assign the whole construct to a variable, like you would with a ternary operator in vanilla JS.
What’s new with ReScript in regards to JavaScript?
As a JS developer, what value can you expect RS to add? That’s a great question.
Let’s see, other than the inferred typing system, you have:
- Pipes, which are a way of writing function calls in reverse. In other words, if you had myFunction(argument) you can do argument->myFunction thus emulating the missing OOP approach. Granted, that is nothing but syntactic sugar, but it’s definitely new!
- There is no const anymore. In fact, let me rephrase that: everything is a constant now. Or in other words, now you’ll declare your variables with let as if you would with const in JS. Why not get rid of let instead? Beats me! You can however, re-define the variable with let thus replacing its old value, while not recommended (clearly!) it’s a way of achieving mutation.
- Pattern matching. Yes, RS adds pattern matching to the otherwise ugly-looking switch statement. In fact, now it looks even uglier, but at least you get some interesting features. With pattern matching you’re able to test for the shape of your records/variables instead of their values. This is a much-needed feature given the fact that any OOP pattern meant to solve this problem wouldn’t be available to you.
Given Pattern Matching is the best feature after type inference from RS, let’s take a quick look at an example:
To make things clear, we’re declaring a record (I’ll explain records in a second) of type Teacher with a particular shape, and as you can see inside the switch there is also a type of record called Student . The switch ‘s pattern matching feature allows us to check the shape of the variable person1 and do different things depending on whether we’re dealing with a Teacher or with a specific Teacher or something else. Even inside each matching block, you get to destructure the matching object into variables which you can then use.
This is definitely a powerful feature that, as I said, is sorely needed since you can’t declare multiple classes and encapsulate that behavior inside them.
But other than that, is there anything else that RS brings to the table? Absolutely, a whole lot of renaming of already known concepts, let’s take a look.
What’s new but really isn’t?
RS does a great job at renaming or changing the way we deal with old concepts in the name of their strong typing system.
Let’s take a look at some of their gems:
- Tuples. Since arrays have to be typed, meaning, they need to only contain one type of variable inside, you can define a tuple which is a fixed-size array with anything inside. It’s also immutable and ordered. But hey, it’s just a good old array that the language won’t let you change!
- Records. If you ever did some C, this is your struct . If you ever did some Javascript (rolls eyes), then this is your object literal. I was going to say “without methods” because their documentation doesn’t specify, but after testing it, you can even assign functions to the properties of the record, so yes, this is your object literal. Granted, it’s also immutable, but that’s the extent of the innovation.
- Variants. JavaScript doesn’t have the concept of an Enum, but if you’ve tried other languages (or even TypeScript) you’ve seen them. It’s just a list of constants groups together. That is what a variant is, with the added exception that its properties can receive parameters. For example:
In the above snippet, you can see how I’m comparing 2 variables with the same enum value assigned, however since they received different parameters (lines 6 and 7), then they won’t be the same. If on the other hand, you re-assigned val1 and val2 with NoValue then the IF condition would become true .
Is this a revolutionary concept? I don’t think so, not enough to merit the adoption of a new language to be honest.
- Lazy value. This is another one of those that makes little sense to me. A lazy value is a block of code you can make to be “lazy” thus you declare it, but it doesn’t execute until you force it to execute. When it finally does, it also gets cached, so next time you run it, it will return the cached value. Honestly, this is a memoized function, that’s all there is to it. Granted, it’s nice to have native memoization but then again, it’s not that complex of a topic and hiding it behind a concept such as “lazy” makes no sense to me.
Mind you, these aren’t bad features, they’re either fancy names for already existing solutions or plain not worth the trouble of learning a new language to get.
The bad parts
Aside from the shiny new exterior of a new language, RS comes with some bad parts, like everything else in life really.
So let’s take a quick look at the bad parts I found during my short testing of the language:
- Inferred types mean no “truthy” values. Granted, this may not be a problem for you, but I really like using the implicit casting to boolean you can get. With RS you need to make sure whatever expression you’re using inside the IF statement is a boolean. This is definitely a minor setback, but a setback nonetheless.
- Moving out of the basic stuff is complex. I did some basic tests around type inference, and some of the other interesting features and everything worked like a charm. Then I had the brilliant idea of importing a module from Node.js and I then spent 2 hours trying to understand how that worked. I later found out there is a nice Node global object you can use. Hey, live and learn, but if I wanted to import an external library that’s not part of Node’s standard offering, then I would have to go through the same hustle. You see, working with other ReScript files is relatively straightforward, but importing something already done in JS, boy-oh-boy that’s a nasty syntax right there. And let’s be honest, if you create a language that compiles to JS is because you expect your users to benefit from the existing JS ecosystem, so that part should be easier.
- Error messages aren’t that great. And this is what did it for me. You can have the craziest syntax, rename known concepts after pizza toppings I don’t care, but if you expect people to use your language, error messages need to be clear and easy to understand. What do you think the following error message means?
I personally have no idea, because:
- I don’t have a single line of code in that place.
- What argument is it referring to, the code has several.
The answer to that question was that I used let to define the Enum — I mean, Variant — instead of using the type keyword. Clearly not the error message I was expecting.
How about the next one?
That was my last attempt at trying to import the fs module from Node.js. See the error? The message reads “index out of bounds”, there is no code there! What gives?!
I’m sure someone versed in ReScript understands the error, but this is not a good Developer Experience, it hinders the adoption and really, it makes me want to go back to JavaScript, plain and simple.
Is ReScript going to be the new standard?
Hard no on that one, I don’t think this is happening anytime soon, if anything for the last issue with the error messages. As it stands right now that problem acts as a barrier for newcomers instead of helping them get on board the RS wagon.
Besides, a little detail I haven’t mentioned yet: this is not a new project. The language is currently on version 9.1 and its website is incredibly detailed. Honestly, hats off to the person (or group of people) working on documenting everything, there are definitely lots of details there.
However, the fact that’s on version 9.1 and still having these problems tells me there is not a lot of people using it or caring enough about it to either report or help solve these problems.
ReScript definitely shows some promise and some of its ideas are interesting, however, there is still a lot for the team to improve before they can rival TypeScript.
Have you tried ReScript before? Would you try it now that you’ve read about it? What other flavor of Javascript have you seen around? Leave a comment and let’s discuss!
Develop & share independent components with Bit
Bit is an ultra-extensible tool that lets you create truly modular applications with independently authored, versioned, and maintained components.
Use it to build modular apps & design systems, author and deliver micro frontends, or simply share components between applications.
- Bit: The platform for the modular web
- Independent Components: The Web’s New Building Blocks
- Building a React Component Library — The Right Way
- Standardizing the Development Environment of Different Teams in the Same Organization
Yet Another Javascript Alternative: ReScript was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Fernando Doglio
Fernando Doglio | Sciencx (2021-06-02T20:32:58+00:00) Yet Another Javascript Alternative: ReScript. Retrieved from https://www.scien.cx/2021/06/02/yet-another-javascript-alternative-rescript/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.