I am Richard Feldman, author of Elm in Action and instructor of the Frontend Masters Elm Workshop. The main open-source projects I'm working on right now are elm-test and elm-css.
I work at NoRedInk, where we have 80,000 lines of Elm code in production. We introduced Elm in 2015, and since then our production Elm code has thrown a total of zero runtime exceptions. We hired Elm creator Evan Czaplicki in 2015 to continue developing the language, and we're hiring!
I'll be here until noon Pacific Time. Ask Me Anything!
Top comments (119)
Languages tend to be designed one of two ways: By committee or by BDFL (benevolent dictator for life). Elm is clearly the latter, and it’s hard to argue against that considering how well Elm has turned out under Evan’s watchful eye.
One unfortunate consequence of this is that there’s quite a few native browser functions that don’t have Elm-equivalent APIs, or there are Elm equivalents that feel incomplete (shameless plug).
There’s this conundrum as an Elm user who’s come to appreciate Evan’s design sensibilities. I find myself frustrated over the tight control of elm-package (in particular, restricting native modules from the community), or long-standing issues without even a comment. On the other hand, I understand why it’s this way; It just doesn’t prevent it from being a source of frustration.
Evan is only one person, and this is beginning to become a popular language with diverse needs. Are there any plans to address this?
I totally get the frustration, but basically I think this is the least bad option. We've tried various ways to accelerate this, and all the cures have ended up being worse than the symptoms.
That said, Evan moves much faster than TC39, so catching up seems more or less inevitable—just not as quickly as we'd all like. :)
Are there any chances Elm development will become more open? It's easier to get info about future Apple products than to guess what's happening to the Elm language next.
How's Elm Software Foundation doing now? It was publicly announced about a year ago. But it's still not very clear what the purposes are, who's on board and what's the roadmap.
Thank you!
I think Elm doesn't have a concrete roadmap because Evan adapts his plans based on what he learns from the community. If you ask him "what will you be working on 6 months from now?" the answer will probably be "depends on what happens in the next 6 months." He does post periodic status updates on the elm-dev mailing list, if you're wondering what he's working on and how it's going.
My understanding is that the Elm Software Foundation is primarily for organizing money-related things. The main reason it exists is that Evan is friends with Python creator Guido van Rossum, and Guido recommended that he set up a nonprofit a la Python Software Foundation. It's not really for project management or anything like that.
That's great, but how can we get Evan interested in community feedback that have already been crystalized in "meta" issues on github for the virtual-dom, html, elm-compiler? Like this one github.com/elm-lang/html/issues/53
Actually, there is a status report on elm-dev now. Same day as I've asked this question :)
It was almost two months since the previous one.
how can we get Evan interested in community feedback that have already been crystalized in "meta" issues on github for the virtual-dom, html, elm-compiler?
Another way to phrase this is "how can we get Evan to stop working on what he thinks is the most important thing, and instead to work on what we think is the most important thing?"
Ideally everything would get addressed sooner rather than later, but there isn't time for everything, it's impossible to please everyone, and prioritization is hard.
For example, right now there are a lot of people who literally cannot use Elm because it doesn't have sufficient asset management tools to get acceptable performance on low-end mobile devices.
I don't think Evan is wrong to focus on that right now. :)
Another way to phrase this is "how can we get Evan to stop working on what he thinks is the most important thing, and instead to work on what we think is the most important thing?"
No, actually another way to phrase this is "how can we get Evan to start doing frontend stuff in Elm every day".
Your answer on another question about Evan's involvement in NRI day-to-day tasks is practically 0 is the saddest thing I've learned today. I might be wrong, but this is harmful to prioritization.
I think you're underestimating the amount of feedback he gets from all different corners of the community as to what the most important thing is. There are so many people with different priorities who think their particular thing is the most important.
If Evan worked directly on our production code base, he'd probably feel pushed to bump priority for the things that matter most to us, at the expense of all the other voices he hears. As members of this community, that would be a very short-sighted preference for us to have.
Can you explain the structure of the main NoRedInk Elm app? With it being the largest Elm app in the world it, would be really cool to know how it was structured and what you've learned along the way scaling up?
Sure! I should emphasize that we don't put a big priority on "getting this right." More than anything we try to be consistent (but don't always succeed), and the compiler makes it pretty easy to rename things if we change our minds, so we don't sweat it. (The biggest drawback to renaming is plain old vanilla merge conflicts.) So I wouldn't take any of this as advice so much as a data point if you're curious. :)
We have a series of pages, e.g. "Teacher Dashboard", "Grading", "Splash Page". Each of these has its own
main; back when I joined the company we were a non-SPA Rails app, and we have not transitioned to SPA yet. (We have long-term plans to head in that direction, and I don't expect the transition to affect our module structure much - outside ofmain, of course, butmainmodules are a small fraction of our total modules.)We have a top-level module namespace called
Nrifor things specific to our UI, as opposed to things that we might open-source someday (e.g. theAnalyticsmodule, theEmojimodule, etc). Here's an example of three related ones:Nri.QuizHeader.Model
Nri.QuizHeader.Styles
Nri.QuizHeader.View
So our Quiz Header has a model, and a view, and some
elm-cssstyles. (We've been migrating from Sass to elm-css and it's been sweet!) We don't have aNri.QuizHeader.Updatebecause the quiz header doesn't have any state. I think this is worth emphasizing, because I see people create a model/update/view any time they want to reuse code, and I think that's the wrong way to scale. Unnecessary state management is bloat! We had no need for anupdatefunction here, so it was simpler not to have one.Plenty of times we just have a module to hold
view, and plenty of others it's not even a separate module, it's just a plain old function inside an existing module, e.g.viewSidebar : User -> Html msgWe also have reusable views that are used across multiple pages, for example:
Nri.Tabs
Nri.TextInput
Nri.Toggleable
Nri.Tooltip
All of these are stateful, and their APIs looks like github.com/evancz/elm-sortable-table - they do not define their own
Msgtypes, and callers don't have to useCmd.map. Their states are super simple, and defining their ownMsgtypes would have been overkill - more trouble than it was worth. This is also worth emphasizing; immediately reaching for a customMsgandCmd.mapany time local state is involved is a surefire way to get needlessly overcomplicated wiring.My rule of thumb is that reusable views where
viewreturnsHtml msginstead ofHtml Msgare nicer by default, and I only reach for a customMsgonce I have enough state transitions thatCmd.mapwould reduce verbosity substantially.Finally we have some reusable data structures, which begin with
Data., for example:Data.Assignment
Data.Assignment.Decoder
We debated the right namespace for these and settled on
Databecause what they have in common is that they're about representing and encoding/decoding some piece of data.These are a mix of various union types and type aliases that represent common data structures in our app. Some of them have a lot going on, so it's decently common to have a data structure defined in one module, and then the decoder and/or encoder in a separate module. It's no big deal if they live in the same module, though. Again, we don't spend a ton of time on module structure because it's so easy to change reliably if we change our minds.
Hope that helps!
Very helpful, thanks
What is the most difficult part about switching 100% to ELM?
Have you thought about going back to JS at some point (at least for an specific project)? I mean, maybe something was really complex/troublesome to build in ELM instead of Js?
Thank you!
Legacy code - there's rarely a good justification to porting really old code that doesn't get used anymore. (So we haven't really done it!)
Only for Node stuff, as Elm is only built for browsers right now.
For browsers, it's the opposite: I don't think I can ever go back. I can't predict the future or anything, but right now I have a really hard time seeing myself applying for a JS job ever again.
That was super quick!
Thanks Richard and thanks for pushing ELM forward <3
Where do you draw the line of functionality in your 'let/in' before breaking out into multiple functions to accomplish the same thing?
I find myself commonly having 5 or more variables defined in my 'let' that are staged versions of the first and wonder if that is a bad thing.
I tend to pull things into the toplevel early and often, but I also tend to use the
(|>)operator wherever possible.That said, I wouldn't call having several declarations in the same
leta bad thing per se. So long as you find it readable, it's unlikely to cause problems outside thatlet, so I wouldn't worry about it. :)Richard,
I use some jQuery plugins, d3, and react in my application. We use a ton of Elm too!
We are having trouble embedding components in our Elm applications. Working with ports is a great abstraction to help us protect the purity of our lovely Elm world. However, many of the projects I embed in my Elm project hook up event listeners to DOM elements. This causes memory leaks because there's no way for the component to know it's being unloaded.
You seem to have some experience with this at NoRedInk - the jQuery Datepicker plugin by XD Soft.
Do you know if there's any intent on providing a mechanism for the modules we embed in our Elm app and interact with through ports to be notified when the DOM is being recreated or going away?
This is our last major hurdle for converting ALL of our frontend code to Elm. If we try to embed our D3 graphics in Elm it would cause MAJOR performance issues. I understand I could write this in Elm but it works great and would be costly to reimplement.
We haven't run into performance problems around this, but thank you for surfacing it! There was some discussion around whether this was needed, and the consensus was "in theory it would be useful, but in practice, who knows if it's actually necessary?"
Seems like you've found a case where it is! I'd post specifics of your use case on github.com/elm-lang/virtual-dom/is... - ideally with a link to the D3 code in question.
The blog post for Elm 0.17 mentions: "Generated JS is smaller and works with Google's Closure Compiler"
Do you have any experience/numbers on this? Do you know if Google's Closure Compiler is superior for making Elm's JS small (compared to UglifyJS, for example)?
At NRI, this isn't really a concern or issue. We don't use Closure compiler, and we currently don't need to. There's a bunch of posts on the mailing list about this though -> groups.google.com/forum/#!searchin... and groups.google.com/forum/#!searchin...
Yeah, I don't have any personal experience comparing them. Sorry!
When you first began using Elm at NoRedInk which parts of the system did you begin to port across first? What were the road blocks you encountered to begin with and any advice for other teams who are thinking of slowly moving away from React like environment to Elm?
We actually started with some business logic in our quiz engine. I wrote a guide for how to do this, but I haven't updated it since Elm 0.16. (This reminds me that I should really get around to that...) I forget where we first used Elm for actual rendering, but it started to snowball pretty quickly after that.
The biggest roadblocks were around build tooling. I didn't do a good job figuring out how production deployments (via Rails - we hadn't started using Webpack at that point) would differ from development builds, and the build tool plugin ecosystem wasn't as far along as it is today. (And it's still got a ways to go.) I guess maybe "roadblock" is too harsh, since we got past it, but even after migrating a bunch of stuff to Webpack we're still dissatisfied with our build process overall—and not just with the Elm parts.
Can you describe your experience with Elixir/Erlang/OTP so far? Do you have a rough estimate of the ratio of Ruby to Elixir being used for the backend @ NoRedInk? Do you see the company moving more and more of the backend to Elixir in the future?
Thanks,
-Josh
Elixir is super new for us, so the back-end is still almost exclusively Ruby.
We have one Elixir service in production right now, and it's not user-facing. We are currently working on our first (small) user-facing Elixir service, and once that's done, we plan to start working on a third (much larger and more mission-critical) user-facing Elixir service. A ballpark timeline for that third one would be getting it into production six months from now.
Our approach is generally to use new technology when we expect a specific benefit, not just because it's enjoyable. (Although it is certainly enjoyable!) So to the extent that we keep finding ways that doing more Elixir will benefit our code base, we'll keep doing more of it, but we're not going out of our way to rewrite Ruby code in Elixir without a tangible benefit in mind.
What are the next big things in store for Elm that you're excited about, what's it like writing Elm in Action, and what is the best way to start contributing to Elm (ex. Good starting places?)
What are the next big things in store for Elm that you're excited about?
Asset management - what Evan's working on right now - as well as the next release of
elm-test, and the improvements to the debugger Yosuke Torii has been working on.There are also lots of smaller things I'm excited about, like union types becoming
comparable, which is vaguely in the pipeline somewhere, and broader coverage of the Web platform. So much awesome in the works! 😸What's it like writing Elm in Action?
Time-consuming! It's swallowed just shy of my entire social life.
It's also one of the most rewarding projects I've ever worked on, so no regrets in committing to it. :)
What is the best way to start contributing to Elm (ex. Good starting places?)
Evan curates a list of projects at github.com/elm-lang/projects - but I'd also like to put in a shameless plug for elm-css - the CSS spec is huge, and there are lots of ways to improve our coverage of it!
Does this involve a focus on code splitting and/or techniques for lazy loading?
If you want to read about this, please check out the elm-dev mailing list. It's a google away :)
Awesome! Didn't know this was publicly discussed 👍
Thank you for the answers Richard! Looking forward to working more on Elm this year :)
I haven't asked others on the team, but the only times I can recall seeing any in development, they weren't a surprise - e.g. I was mocking something up with Debug.crash with the goal of "I'll finish implementing this later, but for now I just want it to compile so I can try out the rest of what I've done" and then reaching one of the code paths that called Debug.crash as I was playing around with it.
Of course that's what I expected it to do, and naturally I replace every Debug.crash with a real implementation long before making a pull request!
As the ops guy at NRI responsible for Elm, the main source of errors with Elm is actually during builds. From 0.15-0.17, Elm did not correctly handle the caching of artifacts, leading to occasional compile errors that were not reproducable easily. It was simple enough to fix - just wipe the artifacts. But that also slowed the builds down a lot.
I'm also fairly certain I'm the leading expert on runtime exceptions in Elm - it's possible to make them happen, but most of the time you have to really understand Elm to make them happen. Unless you're using Array or Regex, of course. Both of these can lead to runtime exceptions - e.g
Regex.regex "[a". However, you'll not likely run into that in production - unless you are taking using input as regex input.. which probably isn't a good idea unless you're escaping things.Any advice for a team looking to incorporate Elm into a large React-based app who relies heavily on server side rendering (SSR) in Node? In a similar vein, do you have thoughts on apps that are SSR'd vs apps that are single page applications?
See dev.to/rtfeldman/i-am-the-author-o... regarding SSR in Elm.
My thoughts on SSR in general are "don't do extra work unless it's going to solve a problem you have." 😄
I just know that the Elm is a programming language but... I'm a frontend dev and I like anything related with the web browser platform... If you can give me an advice related to learn Elm vs MVVM frameworks (Angular, React, others less popular), RxJS why I should give a try?
The first chapter of Elm in Action is a free download, and I go into this question there.
Hope it helps!
Since Elm seems to expose everything to the user, do you have a preferred method of keeping sensitive information from being presented? i.e. hiding API Keys
Have accomplished this with having a simple Python API set up parallel to the Elm app to feed Elm objects, but this seems overly complicated.
Yeah, for API keys I recommend creating something like
Secrets.elmand adding that file to.gitignore. Locally, developers have to create that file as part of setting up their systems, and then you have your build process swap in a different file (containing different constants) for production builds.This way you can easily access the secrets from any module, and if you forget to set them up locally, you'll get a compile error because the module won't be found!
I do this with the Frontend Masters workshop for GitHub API access tokens; you can check out the repo here github.com/rtfeldman/elm-workshop
EDIT: here's a blog post from one of our junior engineers about her experiences learning Elm in her first week! tech.noredink.com/post/15779255223...
We have new hires doing it in their first week, and that includes devs for whom this is their first job out of a bootcamp (and no prior programming experience before the bootcamp). We've done this several times now - we do lots of pairing when ramping people up, and it usually takes less than a week for someone to get productive enough to make production contributions on their own.
Take that with a grain of salt, though; we're talking "can literally contribute something useful," not "can hammer out features from scratch with no assistance."
I will say that I remember when we taught new hires React from scratch (back in 2014), and the learning curve for Elm today feels comparable to React + Flux + an immutability library back then. Yes it's a whole different language, but it's a simpler setup overall, and the compiler helps a TON. (That said, obviously in 2017 more new hires know React on day one, and the corpus of learning resources for React is much larger than it is for Elm.)