What would you like to know? I love Elm. I'm absolutely hooked. I don't want to go back to doing Frontend work in JS, and I hope one day there can be an Elm-like experience for backend development as well.
Just off the top of my head a few bits of what I like about Elm: - You can actually write code, have no errors, and then move on, and never return to the project again. When I was doing JS, everyone I knew just took it for granted that you would be maintaining everything you ever wrote for the rest of your career. Not with Elm! You can actually finish projects and never return to them. - Its a simple and small language that is designed to interact with human beings. The compiler really talks to you instead of spitting out error codes or spaghetti. Apis and variables have human readable names instead of mathy terms of symbols. - For everything theres one way of doing things and the one way is usually really good. This strong consensus orientation of the Elm community means everyone is speaking the same language about every problem.
Gotta go, bye.
https://reasonml.github.io/docs/en/what-and-why
I've really been digging slowly into ReasonML and the biggest gain I can see is that valid reason === valid ocaml (and there's some good server libraries out there for ocaml)
I also like that JSX is the templating language, not that it matters.
Also, have you had any success with manipulating Elm to output static HTML/CSS as well as JS? I know it can do it, but I've never been able to manipulate how it does it (most recent version I tried with: 0.18)
Regarding static html/css, I havent done that either, so I dont know about it.
ReasonML (OCaml) allows impure functions but the best practice is to stay pure whenever possible. It's a very pragmatic language so despite providing all the functional and immutable programming features, it allows you to cut through the bureaucracy if you need to.
Haskell?
Haskell has a huge syntax and a ton of language features. It has a big ecosystem. Haskell is very mathy. Elm is the opposite in each of those regards.
How do you manage that? Migrating from 0.18 to 0.19 wasn't hard in my limited experience, but it wasn't "finish and never return" either.
You call it stateful tho. I dont know that drag and drop needs to be all that stateful. For drag and drop, the information your model needs is whether you have mouse-down-ed on something, the coordinates on the html element you mouse-down-ed, and the coordinates the mouse's current location is. 2 pairs of coordinates and a maybe type? Not too bad. I guess there is the code too, but at least the data is just few values, and not a complex and nested data structure.
On my team at work, we avoid state. Complex nested state is a big code smell for us.
We migrated pretty easily from 0.18 to 0.19, we only had to import a bit of code here and there from libs that would not migrate or update where changes had been made, strong typing and the compiler made it a rather pleasant experience.
The only thing we did not do was migrate to an SPA ; the scope of the app was wide and the cost to achieve this was too high I guess.
Few pain points, amongst which:
- Sometimes you have to do something you would expect to find off-the-shelf (like a souped-up drop-down or a tag editing system) but it's ususally a matter of designing your ui well and can be fun (plus you get to really design the user experience).
- Sometimes you have to do a bit of JS for stuff that aren't designed in Elm (anymore, ie websockets) and use ports to communicate.
- If you're building incrementally, and make mistakes (over-design, useless code to conform to an unrequired philosophy, etc.) it's a good thing to sometimes challenge the bad old choices and get them smoothed down ; thankfully the compiler is your friend here too.
- The learning curve, especially if your team isn't fond of functional programming, can be daunting if you don't have an Elm advocate. That was me in my team, and we grew fond of it, but made quite a few beginners mistakes on the way. All very fixable though.
Well, that's about it ; if you want help getting people started and boosted on the functional programming paradigm, please have a look at my blog: it's Elm-centric, focusing on the most important functional programming concepts that'll get you up and running on what's happening there :) https://medium.com/wat-the-elm-ist And it might even explain what monads are ;)
It's a blast, it's a wonderful developer experience, it's changed my life as a developer after having to fight with Angular and React and the myriad of tools you need to use to have a decent experience.
It would be difficult for me to consider a position where I would not use Elm anymore, and if I did it would have to satiate my thirst for functional programming by letting me work with other cool similar languages.
1. Healthcare
Fall 2017, I started integrating Elm into an AngularJS application after experimenting with it on a couple of side projects. After a successful initial feature, I convinced the team to use it for new features. Another couple of developers helped to create the initial version until late 2018. We started in Elm 0.18 and converted it to 0.19. Now a sole part-time college student maintains and adds new features to it.
2. Transportation management
Since January 2019, I work on an Elm project, once again weaved into an existing AngularJS app, with ~34k lines of Elm code. I inherited it with no interaction from the previous developer. It looks like it was introduced in mid-2017 and is currently on Elm 0.19. Although it is not perfect, not always following best practices, it is much easier to maintain than anything I've worked on in the past. On JS apps, I've torn my hair out trying to figure out what is going on and attempting to add new features.
With Elm, I refactor daringly and rest more easily.
Please let me know if you have any specific questions.
Watching a simple example in the elm website, the codes make judicious use of new lines, would you say those 34k lines would represent 17K in js?
I wouldn't consider that a problem with Elm it's just that our users are mostly on desktop Chrome so we don't test very often on mobile Safari.
I've also written a bunch of small mathy apps, e.g. https://jxxcarlson.io/apps/
Elm has been a joy to work with.
https://www.reddit.com/r/programming/comments/992qe5/elm_019...
Upgrades have been pretty painless, and each new release brings a new level of ease of use.
We have made some architectural mistakes as we have learned the language. And since it is a newer language there are not as many established conventions for code organization – but we are figuring out.
The company now has 4 production projects with Elm as the sole frontend tech.
Do you have specific questions ?