From JavaScript to Scala: Rediscovering the Urge to Build Again

I was writing C# when Node.js came along. You could run JavaScript on the server now. I was in awe. It wasn’t perfect. But it was freeing and dynamic. I went all in. Then came React. Its mental model aligned perfectly with mine. It was simply the V in MVC. Declarative and flexible. It just made sense. Those were good times. I felt like I was standing at the beginning and could clearly see the future. I went all in. Then JavaScript evolved. Ironically, it became rigid. TypeScript won, and now it’s everywhere. I like being able to define the shape of my data models. No more guessing at what the data arg is. But everything else? Sparks Joy Agony. ESM, while arguably a better approach to modules, just adds to the hard edges. I've tried ejecting from TypeScript and going back to plain JavaScript. But you quickly hit walls trying to tap into the JS ecosystem. Modern JS tooling seems lost without it. You end up having to roll your own everything. Eventually, you find yourself coming back to TypeScript, grumbling, "I can't quit you..." What used to feel flexible now feels boxed in. Kid gloves. TypeScript just doesn't do it for me. And that’s okay if it does for you. I started looking elsewhere. I picked up Golang. Bought the books. Built the apps. I liked it. And it worked. Cross-platform binaries out of the box. Hmm maybe Go was it? Maybe not... It felt too simple, if that even makes sense. I wanted more depth. Something that had room to grow with me. Go felt better, but it didn’t make me want to build just for the sake of building. Then, over a year ago, I had to jump into Scala. AKA Identity chose it for their data pipeline. I’d never given Scala much thought before. At first, I had low expectations. Scala had a reputation. Functional purists loved it. I pictured obscure, obfuscated one-liners. Sieve of Eratosthenes (n: Int) => (2 to n) |> (r => r.foldLeft(r.toSet)((ps, x) => if (ps(x)) ps -- (x * x to n by x) else ps)) source: 10 scala one liners to impress your friends Plus, I already wasn’t jazzed about Java. Too verbose. Too many iInterfaces. It didn’t fit my mental model. But I gave it a shot. Picked up a book. And couldn’t put it down. & there it was. That feeling. Scala could be powerful without being heavy handed. Expressive without being verbose. I could apply it creatively. Artfully. It reminded me of those early days with Node. The urge to build, creatively, outside of the box. It’s hard to explain. But it felt good. As I read, my mind adapted to Scala’s mental models. It was like the Tetris pieces were falling into place, at the right angle, every time. To say it was satisfying would be an understatement. That’s why I’m thinking about writing this series; from JS to Scala. I don’t think we should all switch to Scala. I still write in TypeScript, Go, and other languages. Scala didn’t replace them, it made me better at using them. It opened up my mental model and changed how I think about the problem at hand. It made me a more thoughtful coder. If you feel like I did, largely stuck and and a bit unsatisfied, longing for creative freedom. Maybe Scala will do it for you, too. Here is my proposed series: Async, Multithreading, Coroutines: As They Should Be Compare how Scala and Node.js handle concurrency and CPU-bound tasks. Why async in Node.js trips up developers, who think they are writing non-blocking code. It's easy to hit bottlenecks fast. Why Scala Gets It Right: Native multithreading and coroutine support mean true parallelism without blocking the main thread. Types: Practical and Reliable Typing Without Verbosity Why Scala’s type system feels more natural, less verbose, and more flexible compared to TypeScript. Using case classes and sealed traits for structured, type-safe data. How type inference reduces boilerplate without sacrificing clarity. Compare a simple implementation of returning [Error, GenericType] in TypeScript vs Scala. For-Comprehensions: Concise Async Control Flow Use for-comprehensions for asynchronous operations and data transformation. Replace complex callback chains or async/await patterns without reducing all errors into a single try-catch channel like JavaScript does. Real-world examples comparing JS async/await and promise chains to Scala’s for-comprehensions. Pattern Matching for Control Flow How Scala’s pattern matching offers a more intuitive way to manage control flow. Demonstrate pattern matching with both simple and complex data types. Show how pattern matching can cleanly handle data processing and branching logic compared to typical control flow you'd see in Javascript. Options and the None Type: No More Null & Undefined Shenanigans Compare Scala’s Options approach to TypeScript’s nullable types. Highlight the confusion between valid JavaScript and TypeScript's rigidity, where making valid JS work freely often results in weird and inconsistent handling of null, undefined, and other fa

Apr 2, 2025 - 02:46

From JavaScript to Scala: Rediscovering the Urge to Build Again

I was writing C# when Node.js came along. You could run JavaScript on the server now. I was in awe. It wasn’t perfect. But it was freeing and dynamic. I went all in.

Then came React. Its mental model aligned perfectly with mine. It was simply the V in MVC. Declarative and flexible. It just made sense. Those were good times. I felt like I was standing at the beginning and could clearly see the future. I went all in.

Then JavaScript evolved. Ironically, it became rigid. TypeScript won, and now it’s everywhere. I like being able to define the shape of my data models. No more guessing at what the data arg is. But everything else? Sparks ~~Joy~~ Agony.

ESM, while arguably a better approach to modules, just adds to the hard edges. I've tried ejecting from TypeScript and going back to plain JavaScript. But you quickly hit walls trying to tap into the JS ecosystem. Modern JS tooling seems lost without it. You end up having to roll your own everything. Eventually, you find yourself coming back to TypeScript, grumbling, "I can't quit you..." What used to feel flexible now feels boxed in. Kid gloves. TypeScript just doesn't do it for me. And that’s okay if it does for you.

I started looking elsewhere. I picked up Golang. Bought the books. Built the apps. I liked it. And it worked. Cross-platform binaries out of the box. Hmm maybe Go was it?

Maybe not... It felt too simple, if that even makes sense. I wanted more depth. Something that had room to grow with me. Go felt better, but it didn’t make me want to build just for the sake of building.

Then, over a year ago, I had to jump into Scala. AKA Identity chose it for their data pipeline. I’d never given Scala much thought before. At first, I had low expectations. Scala had a reputation. Functional purists loved it. I pictured obscure, obfuscated one-liners.

Sieve of Eratosthenes
(n: Int) => (2 to n) |> (r => r.foldLeft(r.toSet)((ps, x) => if (ps(x)) ps -- (x * x to n by x) else ps))
source: 10 scala one liners to impress your friends

Plus, I already wasn’t jazzed about Java. Too verbose. Too many iInterfaces. It didn’t fit my mental model.

But I gave it a shot. Picked up a book. And couldn’t put it down. & there it was. That feeling. Scala could be powerful without being heavy handed. Expressive without being verbose. I could apply it creatively. Artfully.

It reminded me of those early days with Node. The urge to build, creatively, outside of the box. It’s hard to explain. But it felt good. As I read, my mind adapted to Scala’s mental models. It was like the Tetris pieces were falling into place, at the right angle, every time. To say it was satisfying would be an understatement.

That’s why I’m thinking about writing this series; from JS to Scala.

I don’t think we should all switch to Scala. I still write in TypeScript, Go, and other languages. Scala didn’t replace them, it made me better at using them. It opened up my mental model and changed how I think about the problem at hand. It made me a more thoughtful coder.

If you feel like I did, largely stuck and and a bit unsatisfied, longing for creative freedom. Maybe Scala will do it for you, too.

Here is my proposed series:

Async, Multithreading, Coroutines: As They Should Be
- Compare how Scala and Node.js handle concurrency and CPU-bound tasks.
- Why async in Node.js trips up developers, who think they are writing non-blocking code. It's easy to hit bottlenecks fast.
- Why Scala Gets It Right: Native multithreading and coroutine support mean true parallelism without blocking the main thread.
Types: Practical and Reliable Typing Without Verbosity
- Why Scala’s type system feels more natural, less verbose, and more flexible compared to TypeScript.
- Using case classes and sealed traits for structured, type-safe data.
- How type inference reduces boilerplate without sacrificing clarity.
- Compare a simple implementation of returning [Error, GenericType] in TypeScript vs Scala.
For-Comprehensions: Concise Async Control Flow
- Use for-comprehensions for asynchronous operations and data transformation.
- Replace complex callback chains or async/await patterns without reducing all errors into a single try-catch channel like JavaScript does.
- Real-world examples comparing JS async/await and promise chains to Scala’s for-comprehensions.
Pattern Matching for Control Flow
- How Scala’s pattern matching offers a more intuitive way to manage control flow.
- Demonstrate pattern matching with both simple and complex data types.
- Show how pattern matching can cleanly handle data processing and branching logic compared to typical control flow you'd see in Javascript.
Options and the None Type: No More Null & Undefined Shenanigans
- Compare Scala’s Options approach to TypeScript’s nullable types.
- Highlight the confusion between valid JavaScript and TypeScript's rigidity, where making valid JS work freely often results in weird and inconsistent handling of null, undefined, and other falsy values.
- & How ultimately, Scala’s Option makes handling potential value absence straightforward, eliminating null and undefined entirely.
Writing APIs That Feel Native
- Imagine being able to define a custom operator in TypeScript, like Akka’s ! operator in Scala, to send messages with a simple syntax: myService ! "Hello, World!".
- In TypeScript, achieving this would require writing a custom compiler plugin, and even then, it would be cumbersome to adopt and maintain. In Scala, the ability to express syntax like this is built in. It enables creative expression, to solve the problem at hand.
Pragmatic Scalability: Avoiding Clever Code
- This will show that Scala can be written using simple and pragmatic semantics. Which is especially important for new comers.
- Discusses the reality that Scala can also enable very obscure, albeit clever, code. We should apply this thoughtfully and artfully.
- Highlight libraries that promote pragmatic Scala usage, like those by Li Haoyi (e.g., lihaoyi’s libraries).
- Practical examples of balancing expressiveness with readability.
Building and Deploying a Scala App: From Nuts to Soup
- A full example of building, testing, and deploying a Scala application. It can be a lot easier than you'd think.

& potentially more after I groom my past notes from the books I've read.