Emerging languages spotlight: Elm

Evan Czaplicki on breaking the HTML-CSS-JavaScript blockade with functional reactive programming.

Over the next few months I’ll be taking a look at new and emerging programming languages. The following piece is the first in this series.


The Elm Programming Language, created by Evan Czaplicki, tackles web interaction and takes on the big three — HTML, CSS, and JavaScript. I recently had the pleasure of sitting down with Czaplicki to talk about why he decided to take on this daunting project and how Elm could revolutionize web programming.

Czaplicki was working on a front-end web project and he was thinking about how is it that web development can be “so frustrating in a way it didn’t have to be.” That was the day Elm was born (he talks about that moment in this segment of our video interview).

Today’s websites bear virtually no resemblance to those from 10 years ago, so why are we using the same tools? Cyclical upgrades to HTML, CSS and JavaScript have certainly enhanced and improved upon older versions. HTML5 has taken some great leaps forward. But we’re still using the core.

Coming from a functional programming background led Czaplicki to think about web programming from the perspective of functional reactive programming. What is functional reactive programming? It takes away the idea that interaction between a website and user is static — updating only at certain moments or clicks — and inserts the capability to update as events happen, like mouse movements. Czaplicki gives more detailed insight here.

Ok, let’s say we buy into this … it seems like a new way of thinking about web programming that will take projects to a new level. But why would you actually change from tried and true HTML, CSS and JavaScript? Czaplicki makes a few good arguments worth mulling over as you think about what language you should use on your next project, starting with the foundational idea that all of the established web languages have “deep semantic problems.” Then he touches on how “surprisingly difficult” CSS and HTML can be to work with for simple tasks, such as vertical centering and text placement. And Czaplicki promises, “Elm allows you to create asynchronous code without callbacks.” That’s something JavaScript does not allow.

Compelling reasons, but will Elm make it to the level of any of these three powerhouse web languages? Czaplicki lays out his roadmap thusly: in the short term he wants to add more features and libraries, then try to garner industry support, and delve deeper into the theory of functional reactive programming as it relates to the implementation of Elm.

I, for one, think it has a chance and that Czaplicki’s paradigm-breaking look at how the web can be programmed helps all web developers.

Our full interview is available in the following video:

Related:

Related

Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Programming
  • http://www.facebook.com/profile.php?id=864770581 Cory Danielson

    It’s a very daunting task to create a ‘programming language’ that will get approval from a large number of developers as well as designers…

  • Ed M

    Why is it that most computer languages use English as their base language, if you will? Maybe this is simple to answer as English is widely used in all forms of communication. So maybe my question should be …

    Are their any computer languages not written in English?

    or

    Or do you see any beginning trends to write computer languages not in English?

  • leon

    Actually elm is still javascript. It requires javascript to run it, therefore it uses javascript. Therefore elm is a program created by javascript. You can look at elm.js and you will find that it is haskell.js. Note the .js file extension? Therefore it is still under javascript so as to run haskell online.
    Elm is slow. Go to the examples and play the example(image of mario). It’s slow. Next try legend of zelda game created by elm. Slow again. Get what i mean? It’s a program under javascript and is slower.

    • Jono

      I think there is some serious ignorance in your answer. I don’t mean this is a sarcastic way: have you ever ‘beta’ tested programs? Do you always expect something brand new to be at its best? Few languages come out of the gate fast, without even taking into consideration that javascript is one of the most blazing fast languages around and you are expecting a brand new language created by a student to be at the same level, using native libraries, on one of its first iterations, to be as fast as javascript? I think you’re out to lunch. And I also think you’re missing the point. If we stuck with the fastest, or most efficient way in everything we’d rarely innovate. Look ahead and see what might be possible, see what problem its trying to solve. Its not speed.