Hi fellow Elmers,
IBM has just released Decision Composer, a free and limited offering of our Operational Decision Management (ODM - ex ILOG JRules) product.
A good portion of the front end is written in Elm, so I thought I’d share the link here, and post some feedback.
The app is live here (requires registration) :
It basically allows business users to model and implement complex Decisions via graphical tools and human-readable artifacts instead of code. Decisions are then compiled to executable artifacts, and deployed to runtimes for consumption in other applications/services.
It is based on the DMN standard, spiced up with our own BRMS expertise.
The app is a SPA that (in short) displays a diagram, and allows to edit various artifacts in the diagram nodes, like textual rules (with syntax highlighting, code completion etc) and Decision Tables (a la XL).
Most of the app is built over existing technology and components from the ODM product. The server relies on our Java APIs for many things (parsing, validation, compilation, etc), and the front is an Elm SPA that embeds some editors written in Dojo.
In the above screenshot, for example, the Diagram is a Dojo component, with its own dom tree (and svg), and the rest of the page is Elm. Same goes for rules and tables. We use parent-child for “pages” of the app as well as for some components that are reused across the app.
What we’ve learned
Functional programming ! The Elm language is a good introduction to FP, especially for people with an OO background like us. Only problem :
- Tooling isn’t mature. IDE plugins, time travel “debugger” : they cannot compare yet with our usual Dev XP for TS, Java, etc.
TEA is pretty simple to understand, people get quickly used to it. You don’t wonder where things are or should be, everything has its well-defined place. There’s one way to do things, not 50. Still :
- It requires a lot of boilerplate
- It can be hard to scale / componentize (e.g. when to do parent-child ? how to reuse “components” in several apps ? …
- Designing clean modules is not necessarily easy, and requires experience. We do have a few ugly Models here and there that need refactoring !
Elm is really bullet proof, it’s not fake advertisement. We have had no runtime errors, as promised. Refactoring is easy, with the compiler telling you just about everything. And yes, really, when it compiles, it works ! Apart from the quite slow 0.18 compiler (fixed in 0.19), it’s really amazing.
Elm can interop with “graphical” JS pretty easily. We have embedded pretty big components (like the diagram or the decision tables editor) into the Elm virtual DOM, and we interact with those through ports. It works, but :
- Ports == lots of boilerplate and “loose” typing : we pass Values because we need to encode/decode ourselves… codegen to the rescue ?
- Careful with the virtual DOM when dealing with native JS. Don’t touch vdom nodes that contain your “native” dom, make sure you properly destroy things, etc. All this requires work and attention, and bugs can be pretty hard to track down. Custom elements would probably have helped a lot here.
- Sometimes you’d like to do synchronous calls, but you can’t. We wrote native modules for that. I know, booooo !
The build (elm make) is really simple. Compare this to your average WebPack “config”. And the UMD module can be consumed easily too : we include it into a dojo AMD layer build.
It doesn’t require to patch your code because there’s a new release every month. We migrated from 0.17 to 0.18 pretty easily. The 0.19 migration is a bit bigger, especially because we have a few native modules, but still, it’s nothing compared to the number of updates we would have had with React+Redux+TS.
It was quite a bet when we started with Elm (0.17). Many co-workers didn’t understand. Everyone was about React back then. Even Elm’s syntax was subject to religious debates. “What ? No JSX ??? Square brackets ??”…
Also having a big player like facebook on one side, and a weird student on the other, that didn’t help (with all my respect to you, sir Czaplicki, you are doing a fantastic job) !!
Eventually, as usual, it took some coding to convince : as soon as we started shipping things, most of the skepticism about Elm stopped.
Today, we, the developers of the app, think it’s been a good choice. The “framework” is simple and yet solid. It never really got into our way, instead it helped a lot to have this common architecture/design for everybody. We basically followed The Elm Architecture, and it worked. Of course, the app isn’t perfect, and there are many things we could do better, but it’s not because of the framework, it’s because of us, who didn’t model things correctly and stuff like that.
It took a little time to get used to Elm, especially for OO-raised people like me and most of my team. But it eventually paid off. Once you’ve understood the basic principles, you realize that coding in the browser can actually be productive, safe, and even fun.
I hope this post will help people who have problems convincing their management of using Elm, just because it’s not mainstream. Yes, you can use it for pretty complex apps, it does scale. And yes, even big companies like IBM use it !