What is Elm and Why Should I Care?

I gave a talk at Pandamonium 2016, the Instructure engineering conference earlier this year about Elm, the front-end programming language (https://pandamonium2016.sched.org/event/5w4r/what-is-elm-and-why-should-i-care).

The talk is about diving into some of the clever ideas of the Elm programming language and how they can be applied to modern JavaScript development.

After a short introduction to the language, I go into a discussion on the following Elm concepts and their corollaries in the modern JavaScript ecosystem:

  1. Static Analysis
  2. Signal Graphs
  3. Tasks and Effects

The following are the slides from that talk:

Alternate format: http://tgroshon.github.io/elm-pandamonium-pres

What is Elm and Why Should I Care?

Defending JavaScript

In a forum thread, a member brought up the following critiques of JavaScript.  I quickly recognized many of these arguments as ones I have heard before and really wanted to address. In my attempt to not hijack the thread (which was not about “To JavaScript, or Not To JavaScript”), I collected my thoughts here.  This is not meant to be a passive-aggressive post, but rather as an aboveboard rebuttal in a logical discussion.

The Argument Against JS:

…(skipped for brevity)…

I think Javascript has gone a long ways since [I] first started using it, but here are some issues that I have had with it over the time I have used it:

  1. Javascript has a lot of “cute” and “neat” tricks in it, and I feel like people abuse those tricks constantly. In Python there are some cute tricks that you can use, but the community tends to frown upon it.
  2. NPM is such a good and bad experience. Compared to some other package systems its kind of messy. The other issue is that they have this
    “microservice” where instead of writing a one line piece of code they instead pull from NPM to get the same thing done. There was an issue a few months ago where one developer removed his package that thousands of people depended on, and it caused a “dependency hell” per se.
  3. Documentation is lousy on almost all javascript projects. The documentation tools for javascript projects are pretty lousy. When you have worked with docutils/sphinx for python you start to wonder what is wrong with the javascript documentation process.
  4. Lack of stability – this is getting better, but still pretty lousy at times. Almost all javascript projects including node has this issue. Everybody is so into “progressing” the platform that they push
  5. Too many kludges to make it imitate OO
  6. Poor unittesting tools.

My Defense of JavaScript

The arguments above use Python as a language reference point. That’s great! I have used Python for years and love it as well; so I will focus on comparing JS with Python.

1. (Terrible) Language Tricks

Every language has “cute and neat tricks” (read terribleness). JavaScript has more than some languages, but also less than other languages. Many of the “terrible things” in JS are a result of how it runs in the browser (DOM, globals, namespacing) rather than language problems (although JS itself has some bad ones)

The BIG difference with JS you are forgetting is that almost every language can break compatibility relatively freely (e.g. Python 3, Ruby 2, Lua [every version]). JavaScript can’t, because it would break the internet. Bad, wrong-headed decisions can not be removed once people start using them. Websites need to stop using features before they can be removed. Very few other languages have these strict deprecation requirements.

Python has it’s share of weirdness that people use and had a rather large set of breaking changes with Python 3.  Let’s read from the official sources about Python 3:

There are more changes than in a typical release, and more that are important for all Python users. Nevertheless, after digesting the changes, you’ll find that Python really hasn’t changed all that much – by and large, we’re mostly fixing well-known annoyances and warts, and removing a lot of old cruft.

Python had (still has) a big problem with Python 2.7 -> Python 3 upgrades.  Even now, years later, many projects still rely on 2.7 and haven’t upgraded. That situation would never work on the world wide web!

2. NPM

Your argument is against how people have used NPM, not against NPM itself. And the issues you cited are definitely problems, but they are problems for every package manager that reaches the nexus of popularity and ease-of-use. RubyGems had the exact same problem with excessive “micro-gems” 10 years ago.

And that NPM “left-pad” issue that broke everything earlier this year … yeah that could still happen on NPM, PyPi, RubyGems, INSERT_PACKAGE_MANAGER.  Nothing special/bad about NPM made it happen.  Just that a guy decided to be a jerk and remove a package that everyone depended on.

Compare PyPi to RubyGems and NPM and it makes sense why it was such a big deal for NPM: PyPi is notoriously fractured and wierd to publish on (hence smaller); RubyGems and NPM are notoriously easy (hence bigger). The problem of package management is a classic hard problem that nobody has figured out completely from JavaScript, Python, and Ruby to widely used Linux distributions.

3. Docs

JavaScript sucks because a lot of projects don’t write good docs? Not sure I follow the argument. But if you wanted to argue it, you could easily attribute that to the massive number of JavaScript projects vs. Python projects. JavaScript actually has many excellent automated tools for documention.

4. Instability

Patently false. Microsoft, Google, Facebook, Walmart, Mozilla, etc. have poured so much time, effort, and money into the JS ecosystem (specifically Node.js, NPM, and JS Engine implementations) that it has become one of the most stable platforms you can be on. And don’t forget the JS language guarantee that language features can’t be removed until most websites stop using them. Even among browsers, the consistency of good implementation of JS features is at an all time high.

Any instability in Node.js specifically has been largely mitigated with the new release process (Stable and Current distributions). The only “instability” to speak of is the massive volume of updates that V8 goes through to keep up with ECMAScript features, and those only matter to the native library maintainers not using node-gyp (which most use afaik). And even then, Google and Microsoft now work closely with Node.js maintainers to help with API changes in their JS engines.

5. Not OOP

Everything in JS is an object. It just doesn’t use Classical OO. Your argument sounds more like you mean Classical OO vs. Prototypal OO. JS is the latter, and it is just as Object-oriented as Classical; but fundamentally different because Prototypes are objects as well and can be changed at runtime.  To help people wrap their heads around prototypes, ES6 even introduced the keyword class (although I’m not a big fan of it).  In some ways, prototypes are a more true and powerful kind of OOP.  Classes were introduced after OOP landed and primarily to help with static-type checking, not to enable better OOP design.

In the end, JavaScript is multi-paradigm just like Python with a mix of Object-oriented, Functional, and Imperative paradigms.

6. No Unit Testing

Patently false. You will undoubtedly find many testing libraries of very high quality in JS.  And if you want to talk culture of testing in a community; in my experience, in a room with a Rubyist, Pythonista, and JavaScripter, the Python guy is the least likely to be writing tests.


JavaScript as a language, with all the warts and weirdness, is easily one of the fastest evolving languages in the world.

10 years ago, who would have thought this about JS:

  1. Most widely used programming language on earth
  2. One of the fastest scripting languages ever
  3. Largest package ecosystem ever (npm)
  4. Popular as a server backend language

I once shared your disdain of JavaScript, but with the recent incredible work being done on the language itself, it has become one of my favorites.

I’ll close with this slide by Brendan Eich, the creator of JavaScript:

Screenshot 2016-09-01 17.53.16

Defending JavaScript