Finite patterns of machines
Looking at language features and considering if we need it seems that the future brings us actors and state machines.
1168 words, 6 min read
## Intro to ReScript
I stumbled upon an intro talk to ReScript by Jesse Warden. It's worth checking up especially for comparison with other languages that compile to JS. Jesse gives a good overview providing both strong points as well as weaknesses.
He also does a good job explaining what are the strengths of JavaScript and why it's worth using language that's strongly typed.
## What's ReScript?
It's a rebranded BuckleScript a OCaml compiler from Bloomberg with ReasonML syntax. Seeing that Reason blog didn't get any new post since 2018 I would argue that the whole community effort was moved to ReScript.
I started looking at ReasonML almost 4 years ago. I remember how hard it was to set up on Windows, and how slowly it changed. I remember writing a small feature in the project I was working on at work to show colleagues how easy it is (they weren't so excited).
I remember learning about esy which is a package manager for Reason/OCaml. As well as that OniVim 2 is being written in Reason, and they even created its own renderer Revery.
## One syntax different runtimes
The most inspiring was when I've learned about OCaml's ability to do unikernels, from Sean Grove's talk From Unikernels to Databases to UIs: Truly full-stack apps in OCaml.
With that and the fact that Javier Chávarri writing about running React on the server with OCaml a year ago I was expecting that someone would write a NextJS-like framework in Reason/OCaml that would run as unikernel savings ton of money.
I'm patient.
## Upcoming Nuxt and Svelte
Meanwhile Svelt announced the beta version of SvelteKit. Which is the Svelte version of NextJS. Svelte has its roots in Sapper. But in his keynote during Svelte Summit the author, Rich Harris explains why the change. I encourage you to watch Futuristic Web Development.
Out of curiosity, I've checked what is the progress on Nuxt 3. There wasn't any official publicly available information outside of few talks from recent Vue Amsterdam. The recordings are behind a pay-wall but I was able to find links to the presentations. I'm awaiting it cause it should bring full support for Vue 3 and its new reactive API.
### A quick sum up
Both Nuxt 3 and SvelteKit will use Vite internally which means instant development builds with hot module reloading. Also, both are built with Serverless in mind meaning you'll be able to create a serverless function out of every dynamic page. Something that I've seen in Next 8 about 2 years ago. The future
## New features
This road to parity in features among frameworks is a trend that I see happening also with the programming languages. Not surprising cause I remember seeing a talk by Erik Meijer a few years back when he was comparing Haskell and Java, and predicting that languages will have more and more of the same features. Sadly I couldn't find a lint to it 😟
### Pattern matching
One of the features I liked very much in Reason was pattern matching. I like it also in Rust and Scala. That is why I wasn't surprised to see this video about pattern matching in Python 3.10.
I think that pattern matching could easily substitute for the need for
if
s and switch
es, and all languages will have it.
There's an outgoing effort to bring it to JavaScript in this proposal. Sadly it's still on Stage 1.
Thankfully this can be done in some way in the userland, and it was!
You can read about it in this introductory post
on ts-pattern
3.
### Guards
Although pattern matching is a neat way around nested if
statements, a while back I started
to get suspicious about having nested if
s in the first place.
First I've read it in Refactoring.
Particularly in replacing Nested Conditional with Guard Clauses.
Apparently, this is so good a pattern that it was promoted to
language feature in Swift 2.0.
I also found that it's possible to bring it to Kotlin.
I think a good intro for why avoid if
s and focusing on guards is this
talk. Although long I found it very entertaining.
However I find correcting Edgar Dijkstra
a bit hubris, but maybe if you do your research as Jules did you have right to it.
Who am I to judge?
### Type guards
Let's not confuse guard clauses with type guards in TypeScript. For those I found this article to be a good explanation. Although it seems they changed the name, and call it type predicates instead of the guard as they used in the old handbook.
### Actors
Another feature that goes to more languages is the actor model.
Focusing mostly on the Frontend in recent years I never had a chance to try working with the actor model. But when I was looking at Reason I found the Nact framework.
When I was searching for a link to the actor model I've run into David's talks from RxLive Putting the "Act" in Reactive. In the middle of the presentation when he was talking about message passing and showing event listeners I got reminded about old Twitter framework called Flight.
## Advancing in TypeScript
Mark Dalgleish introduced me to this neat pattern
Fake Child is an ingenious way of not having to make parameters optional only because TS will yell at you.
Also, Kent C Dodds joined the TS game and wrote about
how to write React components in TypeScript.
What I like about this is that it breaks with the tradition of using React.FC<Props>
and arrow functions for your components. It's nice to see that others are questioning it too.
I'm bringing this up cause this week I read an interesting read follow-up story about Constrained Identity Function. At first, reading I thought that this is something that const assertions could handle, but it doesn't work with record types, and without a record, we would need to type functions ourselves for each operator.
The second TS lesson came to me from Christian Alfoni in a video where he tries to suggest better typing to XState. Sadly for me, this is too advanced yet.
## State machines
But Christian being Christian didn't stop there. The reason I found the typing video was because I watched his CodeSandbox Architecture explanation. Which relies heavily on state machines. I think to better understand how they will do it in practice you need to watch yet another of his videos where he explains his small state machine implementation react-states.
### State machinges in ReScript
It seems that I need to give state machines a try cause the Internet brought me to this article that shows how the state machines can work with pattern matching in ReScript.
### State machines catalogue
It seems that with time passing it will be harder not to use a state machine 😉
## Moving buildings
I find fascinated by this