A Journey from JavaScript and TypeScript, to Rescript/React, via Elm, OCaml & Haskell.
Or how to get from the dangerous, and buggy imperative hell, to the safe functional heaven of the top 1% developers.
What is happiness for a programmer? For me, it means no null or undefined, no any types, 100% type-soundness, no run-time errors, and being able to code new features, instead of constantly debugging old ones.
I would prefer to keep all of this a secret. Because the more people know this, the more competition. It’s like when you tell your friends about this great almost hidden restaurant, and a week later you can’t get in, because it’s fully booked.
In each society, industry, and profession, you always have an elite, the 1%, and everyone else, the plebs, the 99%. This elite makes a lot more money for less work, gets incredible perks, drives better cars, flies first class, stays in 5-star hotels, and lives in bigger houses. And it's almost impossible to get from the 99% to the 1%. There are hurdles that you cannot cross, no matter how hard you try.
But for programmers, there is a secret path. It’s not easy, it takes a lot of time, blood, sweat, and tears. But it is possible.
You only need
- an open mind,
- some time,
- a few books,
- a computer with an Internet connection,
and some directions, which I am about to give.
It’s up to you if you choose to use this secret information to your benefit, or not. This is a blue or red pill moment.
Who’s this for?
- If you have a job coding in JS or TS, and want to make sure you don’t get fired in 2022, or/and you want to increase your salary, and get more job opportunities, continue reading.
- Or, if you are totally new to coding, and you don’t have a Computer Science background, this post will give you a clearer path on how to become as good as someone with a CS degree, so you can not just compete, but outcompete 99% of the others.
- Or, if you are like me, and you like building stuff, and you want to spend more time coding new features, instead of debugging old ones, this post will give a recipe for how to get there.
A side-effect will be that you will become part of the top 1% of programmers, with all the perks and benefits this entails.
Can you do it?
Yes, you can. Seriously. If I could do it, so can you. To put things in perspective. I started coding from scratch at 45. Yes, that’s not a typo. I started at an age, at which most people are written off by society, and are expected to start thinking about getting their affairs in order or even preparing their funeral arrangements [sarcasm detected].
For any JavaScript or TypeScript developer, it is perfectly normal to freak out the first time seeing Haskell, Ocaml, or even Elm.
Hearing about Lambda functions, monads, or monoids is almost intellectual torture, but only the first time. After a few days, you’ll wonder how you could live without monads and you’ll see them everywhere.
Everything is hard at first. It’s like looking at Mandarin Chinese for the first time.
Don’t be afraid. It’s perfectly doable. If you invest the time and get past the first hurdles, you will succeed. Just stick to it.
And it always helps to see how someone else has achieved a difficult goal, especially if that person was just like you, without a Ph.D. in math or brain surgery. That’s why I am sharing my journey.
How much time does it take?
Think of yourself as a Startup, and the time learning as the capital invested. The more you invest, the higher the value of the Startup.
Learning is always worth the time. It will increase job security and give you a competitive edge. Most people around you won’t learn. That’s good for you. You’ll outcompete them. That’s Darwinism in action.
How much time do you spend a day writing unit tests, trying to find what caused the latest null or undefined bug in your, and even worse, other people’s code?
Think about that for a moment, before you start complaining about how much time you need to invest in learning something really useful.
I became fluent in Functional Programming in Haskell, OCaml, Elm, and Rescript in roughly 16 weeks. That doesn’t mean I am a master at it, but I am already highly productive. After a year or two, I will be just as good as the top 1%.
I learned several functional languages, read many books, watched and rewatched lectures. It’s as if I emigrated to planet Functional and immersed myself totally. I approached it almost like a religious fanatic, taking time off from everything else, focussing full-time on studying 8 to 10 hours a day, only taking one day off during weekends.
You don’t have to be that fanatical:). It helps though. If you have a full-time job or a life, you can spread your learning over a longer period, and it will probably be a lot easier. You can also focus only on Haskell or only on OCaml first, and go from there. You don’t need to do both. If I could go back in time, I would probably just focus on Haskell, because there are both high-quality books and high-quality lectures available for it.
Make a learning plan, and follow the plan strictly, doing at least one hour, ideally two hours, a day of functional programming.
My journey: Starting with JavaScript
Like most self-taught programmers, I started watching online JavaScript tutorials, went through online courses, online boot camps, and read lots, and lots, and lots of blog posts. Some were good, most were not. But when you are starting, you can’t separate the chaff from the wheat. The result was that I learned bad practices, unproductive habits and got addicted to convenience shortcuts. Every tutorial always starts with ‘install Vscode’, then install this and that plugin, copy-paste this, or even better use snippets, and most importantly, write as little code as possible by using boilerplate everywhere. And before even thinking of coding, check npm first. This is what they teach you most of the time.
As a result, without even realizing it, I was molded into becoming an IKEA-style assembler instead of an actual programmer. Let me explain. Most JavaScript development is actually not coding, but looking for libraries, reading manuals on how to use those libraries, and then assembling them to form an application. It’s similar to going to IKEA, selecting a closet, bed, chairs, and a table. You then get a list of all the parts, where to get them, and an easy-to-follow guide on how to assemble all the parts. Sounds familiar?
An actual furniture maker starts with the base elements, like wood, and then uses tools like a saw, meter, sanding paper, screws, glue, paint, and other tools to construct any type of furniture. That is programming. What I described above, isn’t.
It doesn’t matter how many IKEA closets, tables, chairs you assemble, from already pre-built parts, you will never learn the skills of an actual furniture artisan. Ever. That’s why seniority is irrelevant.
You can tell the quality of a tutorial, or the absence of it, by watching the first 30 seconds. Does the ‘tutor’ use a mouse to create a folder or a file? Does he make typos. If so, you can just stop there. It’s like a secret handshake. Real programmers use Vim-like editors or Vim itself, they touch-type and if they touch the mouse, it’s usually by accident and not to create a file or copy-paste. No self-respecting real programmer would ever do that.
For all the good that the Internet did, it also made it possible for anyone (read idiot) to share anything, and get distribution, without merit. I am still surprised why quality educational content never gets the distribution it deserves. Is it really so hard for Google to fix its recommendation system? It’s been decades. There is so much amazing, useful, extremely valuable, and even free educational content on the Internet, but you can’t get to it because of the overwhelming noise of all the crap.
In my experience, JavaScript is 10% coding new features, 15% writing tests for them, and 75% debugging. And once you have a JavaScript code-base, this is what you will be doing forever. This will never end. Ever.
At the end of my learning JavaScript, I was considered a full-stack MENR (Mongoose, Express, Node, React) developer. But I didn’t feel happy, because I spent most of my time fixing my own, and even worse other people’s bugs. I didn’t feel confident in my code, ever after writing lots of unit tests.
From Loving TypeScript
Then TypeScript appeared. Everyone in the JavaScript community was raving about it. Everyone was learning it, advocating it, and apparently loving it. It seemed like the best thing since sliced bread.
Overnight JavaScript became last season's fashion collection, which even at the largest discount, no one even wanted to try on.
I went all in. But this time I tried a different approach. No more online tutorials or influencers. I got some actual books:
- Programming TypeScript by Boris Cherny
- Effective TypeScript by Dan Vanderkam
That worked a lot better. 2 months later I managed to unlearn some of the bad practices, and I was able to build a real understanding of modern JavaScript and TypeScript.
to Hating TypeScript
But. Once you master TypeScript, you realize that it’s still JavaScript, but with a lot more noise, a super-slow compiler, which destroyes your workflow, kicking you out of the ‘zone’. You still have errors at run-time. You still have to write tests, as you did before. Seriously? And now you don’t just have null or undefined to worry about, but also about the ‘any’-type. In the startup ecosystem, venture capitalists would call that over-promising and under-delivering. VCs would dump TypeScript like a bag of potatoes if it was a startup.
Imagine a box of condoms, where some of the condoms were secretly punched with a needle by a Microsoft employee. You don’t know which ones. And now and then, you take a condom from that box, assuming you’ll be safe. And most of the time, you’ll be fine. But one day, when you least expect it, you’ll be f****d over beyond repair, and you won’t even know what hit you. This is TypeScript. It gives you a false sense of security.
The more I learned about TypeScript, the more I wanted to stop using it, until one day, I was so annoyed that I just decided enough was enough. I cut my losses and threw it completely out everywhere. And although it took some time, it was almost a positive therapeutical experience, like going to a spa. You should try it.
There is a reason why Microsoft needs to spend over $30 million a year in TypeScript ‘marketing’. I wasn’t aware of that when I got in. Were you?
Exit TypeScript, what’s next?
Thank you Jordan Walk
Everything changed when I stumbled upon a talk ‘React to the Future’ by Jordan Walk, the creator of React. That made me take a serious look at ReasonML, and subsequently, at Rescript, a ‘dialect’ of ReasonML.
Just so you know, the ML in ReasonML stands for Meta Language. For some reason, people often mistake it for Machine Learning.
Unlike TypeScript, Rescript:
- is 100% type-safe or type-sound (check!)
- doesn’t have Null, undefined, or any (check!)
- is immutable by default, mutable when needed (check!)
and, if that’s not enough, it allows 100% type-safe bindings with any JS library. Huh, really? Who wouldn’t want that? Count me in.
Yes, but Rescript is not popular! Who cares?
The wrong way to get into Rescript
I started frantically reading the Rescript documentation, trying to figure it out, and writing some code. But it didn’t really work. When I faced a block I posted to the Rescript forum. The people were extremely helpful. I received advice and solutions either within a few hours, or the next day. Kudo’s to the Rescript community. They’re amazing.
But, as I was looking at their responses, I realized they were speaking a different language. It looked like JavaScript, it felt like JavaScript, but it wasn’t. What I didn’t realize back then, was that we were actually from 2 different planets. I was from planet Imperative, and they, the Rescript community, were from planet Functional.
The problem is that Rescript has this JavaScript-like syntax, which gives you a false sense of familiarity. You can only apply the syntax if you come from planet Functional.
I was trying to use the syntax to code in patterns from planet Imperative. And obviously, that didn’t work. Before getting into Rescript, I first had to become a true citizen of planet Functional.
Intermediate stop at Lambda Calculus
Yes, most, if not all books on functional programming start with a little math. So what? It’s not rocket science-level math. It’s kid's stuff. Trust me, it won’t kill you to dig a little deeper and understand what Functional programming is based on. If I could handle it, so can you.
Knowing a little lambda calculus will empower you to reason inside the functional paradigm. And this in turn will help you pick up Haskell, OCaml, and Elm a lot easier.
Becoming a Functional Programmer
I looked for books or tutorials on Rescript, just like I did for JavaScript. None existed. Since Rescript is based on ReasonML, so I tried looking for that. I found 3 books, which I bought. But they were not worth the paper they were printed on.
Since that didn’t work, I started looking for resources on OCaml, which ReasonML is based on. And there I got lucky, finding high-quality books, used as teaching material in universities. At the same time, I stumbled upon a talk by a Haskell programmer, who was comparing Ocaml to Haskell. That’s how I found out that learning Haskell was also a good way to get into the functional paradigm.
And for Haskell, there were even online university lectures available, so I decided to learn both.
Revisiting Rescript with the Mindset of a Functional Programmer: Happy Times.
A little over 2 months later, once I got to a point where I felt more or less comfortable truly thinking as a functional programmer, I went back to the Rescript documentation. Everything immediately made sense.
The documentation felt more or less complete and useable. I just needed to learn the syntax, find out which Rescript APIs I would use, and correctly do JS-interop.
React + Rescript: The Ultimate Combination for building UI’s
Once you start building React components in Rescript, you will never want to go back to doing it in JavaScript or TypeScript. You can still use the libraries you used before, and Rescript makes it easy to create type-safe bindings, so unsafe JS libraries become fully type-safe. That is the best of both worlds.
What about Elm? I love it.
Too many people mistake programming languages for religions, which need believers, haters, popes, and priests. And so they start putting one tool over the other and going on actual crusades, defending one or the other, like religeous zealots.
This may come as a surprise, but programming languages don’t have feelings. They can’t get offended. They can’t be sad or happy. They are just tools. Nothing more, nothing less. This is how you should approach any programming language.
Learning Elm will make you a better React developer because Rescript also allows you to model types and components, just as you would do in Elm.
And that is very powerful. But there are no tutorials on how to do that in Rescript. On the other hand, Elm has a lot of very well explained examples, and a really amazing book “Elm in Action”, which is really great at introducing and teaching you important concepts.
Once you know how to do that in Elm, you can apply the same principles in Rescript/React. Be careful though, a side-effect may be (pun intended), that often you will use Elm for some projects. But that’s perfectly fine. Elm is fun.
The more tools you master, the better you become. If you would compare coding with cooking, then Elm and Rescript/React are just different knives for different purposes. One you use for cutting vegetables, the other for cutting meat. But you need both to be a good all-around chef.
But I can’t use Rescript | Elm | Haskell | Ocaml in my day job?
Mastering any functional language will empower you to become a better JavaScript and TypeScript programmer. Both JS and TS offer support for functional programming patterns. You can even use libraries to mimic immutability. It won’t be as good and you won’t have all the benefits. But your code will be more readable and easier to reason about.
Knowledge of any purely functional language gives you an unfair advantage over even more experienced and senior developers, who only code in the imperative paradigm.
High-Quality Learning Resources
The best way to get into the functional paradigm, it to use books. Sure you can also watch recordings of university lectures. But start with books.
When buying books, go for O’Reilly, Manning, and Coherent Press. All the books I mention below, I bought on my own dime, and I would buy them again. I often recommend them to friends. They are the best investment you will ever make. Far better than crypto will ever be. But you need to read them and use them.
Books I read, re-read and … :
I can’t stress this enough. Focus on books first, and use lectures in a supporting role. The books below are real gems of knowledge.
- OCaml from the beginning by John Whitington. (Learn by doing, exercises with hints and solutions).
- More Ocaml by John Whitington. (Getting a little more advanced.)
- Real World OCaml by Yaron Minsky, Anil Madhavapeddy. (After you read the two books above, you can further lock in your knowledge. The beta version is available online for free. I wouldn’t recommend it as a first introduction though.)
- Domain Modeling Made Functional, by Scott Wlashin (Examples in F#, but great for learning how to use the Type system correctly, to model types and make invalid states impossible.)
- Get Programming with Haskell by Will Kurt (Solid introduction to Haskell)
- Elm in Action by Richard Feldman. (Practical and fun.)
Lectures I watched:
Just look for recorded lectures online instead of going to sites with structured courses on educational sites. The multiple one-hour recordings of actual university lectures are far better. It’s like sitting in an auditorium. There are true treasures of knowledge available online for free. This is a small list. There are a lot more.
- Lectures of Kahle German University in the Haskell Programming Language (English)
- Haskell Functional Programming Fundamentals — Dr. Erik Meijer.
- Functional Programming in Haskell by CSC — Computer Science Center (Very good but it’s in Russian)
There are lots of online lectures on Lambda Calculus from universities and conferences. You may need to rewatch them a few times though, to really grasp the concepts. An example is:
- Lambda Calculus for People who can’t be bothered to learn it — by Steven Sarek.
And sorry for sounding like a broken record, but books are better.
Conclusion
I realize that much of what I said about TypeScript and JavaScript, is painful to hear. I am not apologizing.
JavaScript and TypeScript are inferior when compared to Rescript. There’s no way around it. No amount of propaganda, mental conditioning, pr, marketing, political correctness, wokeness or sugarcoating can change that. It’s not an opinion. It’s a fact.
