"Make the Back-End Team Jealous: Elm in Production" by Richard Feldman

How often do you find a back-end team jealous of the language the front-end team gets to use? Having modernized many legacy front-ends over the years, I can unequivocally say that introducing the Elm programming language to a rich web app (previously built on a mix of React.js and legacy jQuery) has yielded the most reliable, clean, and performant result I've ever seen. Elm's benefits to this mission-critical code have felt like the programming equivalent of the "After" photo in an infomercial.
In this talk attendees will learn how to cleanly introduce Elm into an existing JS front-end from start to finish. Highlights include Elm's Time-Traveling Debugger, its uncanny ability to catch nearly all runtime exceptions at build time (no more "undefined is not a function"), and a package manager that guarantees and automatically enforces semantic versioning for every package.
Attendees are assumed to be comfortable with JavaScript and CSS, but no other knowledge is needed. Come see how nice your front-end programming experience can become!
Richard Feldman
NOREDINK
@rtfeldman
Richard is a functional programmer who specializes in pushing the limits of browser-based UIs. He's built a framework that performantly renders hundreds of thousands of shapes in HTML5 Canvas, a JavaScript immutables library that seamlessly interoperates with normal JS collections, and a Web App for long-form writing that functions like a desktop app in the absence of an Internet connection.

[@NoAlbatross]

Outstanding. I had wanted to do a talk on Elm for my company's devcon, but showing this video is the way to go. For one thing, no one will believe how easy and pleasant Elm is. You make the point nicely!

[@RasmusWriedtLarsen]

I feel like this is a great introduction to some of the awesomeness of functional programming to all the bewildered js lovers :) Also really makes me want to check out elm in more depth.

[@gewalli]

Great talk. Is there any good examples of the type of interop you are talking about (when switching an app from regular js)?

[@hondinatos]

Using ports to talk with javascript like an API: guide.elm-lang.org/interop/javascript.html

[@MiracleBlueOfficial]

In the TodoMVC perf, what versions of each framework was used for the test?

[@BorisBarroso]

Instead of why can't be ruby more like elm, just use Elixir

[@aion2177]

A video on Time Traveling Debugger can be seen here. th-cam.com/video/vS3yzUo7l8Y/w-d-xo.html. Make sure you first watch "Inventing on principle" by Bret Victor.
The elm debugger was greatly improved since then.

[@ZhioN360]

The compiler magic doesn't really solve the problem of back-tracing a nonexistent or undefined variable. It's fine in such a simple example, but in complex apps I'll still need to go weed-whacking for half an hour to find out where the problem is.
In terms of the UX of the language, it's nowhere near languages like Python or Ruby (Maybe.withDefault 0?). That said, it enforces a really secure way of working that JavaScript currently lacks, which I think is nice.

[@qwerty-mz8is]

+Byron Houwens Have you even tried Elm or Haskell ?
You will never get a undefined variable in runtime.
The DX is awesome, it's just different.

[@MichaelCampbell01]

In elm there ARE no non-existent or undefined variables, so... there's that.

[@Fabroskii]

First impressions: there is *NO WAY* I am going to start writing code like `first = Maybe.withDefault 0 (List.head numbers)`
After watching in full, it turns out this is just advertorial propaganda trying to build support for a new attempt at enforcing a coding standard on top of javascript.
All the "bugs" this "amazing" compiler "catches", simply aren't a problem for skilled developers who pay attention to what they are writing. This is just another layer, existing only to try and move software development into the realm of people incapable of thinking like a programmer.

[@oliverweiler8113]

+Fabroskii Kids these days...

[@tryptamigo]

+Fabroskii that you don't yet understand why "Maybe.withDefault 0 (List.head numbers)" is vastly superior to "numbers[0]" only suggests that you are inexperienced with all the problems it solves.

[@Tibaltube]

+Fabroskii there's nothing unusual here, with js you can always write:
var const = numbers[0] || 0;
Though it would be great if compiler could find this potential problem for me.

[@ZhioN360]

+Dan Neumann The problem is not with the catches the "superior" option will make, the problem is with actually writing such a thing out. In terms of UX, what the hell is a Maybe? And why do I have to declare its withDefault method on something that shouldn't have anything to do with it?
Really, it could have used something like "numbers[0]" and invisibly made default values on its own, instead of using cryptic internal systems. I suppose that comes with learning a new language, true, but anything to decrease the learning curve will increase adoption.

[@MrPatrikNygren]

+Byron Houwens the thing is that "Maybe Int" is a type. So this is for ensuring that the compiler catches the error at compile time and not during run time. I guess you could do a lot of these checks for undefined or null or something, but Maybe is more describing that it Maybe returns a value, it is being more declarative about the insecurity. And all functions using this Maybe Int needs to take the case that it could return a Null value into account. If you forget to handle that case. The compiler will tell you again.