The language has undergone many changes since its initial development, which consisted of a whopping 10 days, but all of these changes are just polishing a turd.
Freedom or Death
What options do we have?
We could decide not to develop applications for the Browser. We could revert back to the days where we developed Client/Server Applications in a number of different languages.
Taking this tact would require us to develop for all platforms and devices. This certainly would feel like Freedom but it would mean eventual Death. The costs of such an approach would outweigh any idealogical upsides.
But our Browser would be completely incompatible with every single web site on the planet. This may appear to be Freedom at first but it most definitely is Death. No one but the most fervent would adopt this.
We could develop a Browser Extension that allows for a better developer experience. This too has been tried before and since we’re reaching a near monopoly in Browser development by only the largest of companies, our initial taste of Freedom could, on a whim of a corporate giant, be transformed into sudden Death.
Most affected by an oppressive environment are too busy trying to survive in the current climate than to overturn it.
Revolutions are rare, dangerous and costly but subversion isn’t.
If you can’t beat ’em, join ’em (sort of)
A Microprocessor has a single instruction set that can never be superseded by any other. Not without completely replacing the hardware.
Yet, we don’t call for revolution but instead work to insulate ourselves from the deficiencies of such a system. We did this over half a century ago when we created high-level languages.
Any flaws or complexities in the underlying architecture are squelched by an abstraction layer that frees us from having to regularly consider the pitfalls.
By writing a compiler, we freed ourselves from the tyranny of a single platform and by using this same approach, we can free ourselves from our current dilemma.
A Horse of a Different Color
These solutions do not give us the benefits that we’re hoping for. This is the equivalent of writing in Assembly Language instead of Machine Code.
I’m going to concentrate on Functional Programming Languages only because it’s becoming very clear that Functional Programming is the future of our industry.
This is evident by the mass adoption of Functional Features in today’s most popular languages. This is historically what’s been seen right before a major paradigm shift is about to occur in the software industry.
For the curious, Richard Feldman does a wonderful job of making this argument in this entertaining and illuminating talk The Next Paradigm Shift in Programming.
Elm is a great beginner language for Functional Programming. The ecosystem is mature and I have personally been responsible for a team that put over 160K lines of Elm code into production without a single line of Elm code producing a Runtime Error.
Elm is a dialect of ML and a very small subset of Haskell.
If you want to dip your toe into the Statically Typed, Purely Functional Programming world, then Elm can be a great starting point (https://elm-lang.org/).
Unfortunately, Elm’s lack of power quickly shows as your application becomes complex and the resources for learning are somewhat limited. The go-to book for learning Elm is Elm in Action.
Facebook uses Functional Programming Languages, one of which is Haskell, the granddaddy of them all. The other notable language is the one they developed called ReasonML. It’s a dialect of OCaml, which is a dialect of ML.
Unfortunately, Reason isn’t a Pure Functional Language and so it suffers from many of the problems that Imperative Languages do. It’s a compromise the way that TypeScript is a compromise.
Fable supports most of the F# core library and most of the commonly used .NET APIs (https://fable.io/).
Unfortunately, like ReasonML, Fable is not a Pure Functional Programming language either.
I couldn’t seem to find any books on it but here’s a free online “book”, The Elmish Book. The use of the word “Elm” in the title seems to be coincidental and has nothing to do with the Elm language.
PureScript was developed by Haskell developers who stole as much as they could from Haskell while making some great improvements along the way.
It’s a Pure Functional Language (hence its name) just like Haskell. It is the most powerful of all the languages listed here but unfortunately has a big downside.
The learning curve is pretty steep. That’s what motivated me to write my book to make that process as painless as possible. Once you put in the work to learn PureScript, it will pay you back ten fold in dividends.
There are 2 books I know of. The free one, which is great if you already know Haskell, PureScript by Example.
If you’ve never seen a Functional Language or if you have no idea what Functional Programming is and you’re interested in the most powerful of all of the aforementioned languages, then I’d suggest you consider my book, Functional Programming Made Easier: A Step-by-Step Guide.
It’s a complete Functional Programming course for Imperative Programmers of any language. It starts from the very beginning of Functional Programming and by the end, you’ve developed a web-server and front-end single page application in PureScript.
Too Good to be True?
These are Functional Programming Languages. You might be thinking that what you’d really like is Java, C# or Python but in the Browser.
But the biggest gains in program safety and developer productivity is only possible from a Functional Programming Language.
That’s a pretty bold claim and for the unconvinced, I invite them to ask programmers who routinely program in a Functional Language in their professional work and ask them if they miss their old Imperative Programming Languages.
I’d be willing to bet that 99 out of 100 would say that they’d never go back to the old way of programming. Then ask them how much effort it took to learn these new fangled beasts.
And that’s the rub. Learning Functional Programming is hard. (I’d invite you follow this link and read this article to understand why.)
Since I wrote that article, I’ve been working hard to write a book based on a course I’ve been teaching to my developers at work. It makes learning Functional Programming so much easier.
It’s the book I wish I had 5 years ago. At the time of this writing, there is no book like this: Functional Programming Made Easier: A Step-by-Step Guide.
It’s priced extremely reasonably for a book that was 2 years in the making. I wanted to make sure that professionals all over the world could afford this. Not just rich Americans, which is why if you contact me through LeanPub’s Email Author link and let me know what country you’re from and what is affordable and reasonable for you, I will send you a coupon for that price.
If you’ve been professionally programming for a couple of years, then this book will take you very slowly, step by step from an Imperative Programmer to a full-fledged Functional Programmer.
And if you don’t use my book to help propel you into the future, please consider the aforementioned languages and their corresponding books. I believe they are are the path to the future of our industry.