More than 100,000 lines of Elm code in production: Rakuten shares the knowledge gained


Japanese e-commerce company Rakuten recently shared its experience of using Elm in production for more than two years. Rakuten’s code base includes several applications with approximately 100,000 lines of Elm code. Rakuten valued Elm’s functional UI approach, its type system, and the lack of runtime exceptions. On the other hand, Elm is not a mainstream language, which means that fewer reusable resources can be found via Google Search and Stack Overflow.

The Rakuten engineering team described what led them to use Elm for their application development as follows:

It all started in the summer of 2017 in the Berlin office of Rakuten. We were maintaining a medium-sized single-page application written in vanilla JavaScript when things got out of hand. […]
We decided to impose some discipline and rewrite functions pure style2 to regain control of our application. […]
We thought: “If only we could find a tool to enforce these rules so that we don’t have to rely on our self-discipline …” and then we came across the post office “Introduction to the Elm architecture and how we create our first application” […]. It was love at first sight.

The company gradually took over Elm and initially started with prototypes to try out the technology. While the results of the initial tests were encouraging, Rakuten reported that the Elm rollout has stalled due to a heavily server-side PHP code base. A stack change later gave the company the opportunity to expand the use of Elm:

Several engineers were already pushing for a more functional way to write code, and in a department that relied heavily on back-end APIs, there was a strong need for a decoupled way of writing user interfaces.

In rapid succession until 2021, Rakuten now has around 100,000 lines of Elm code for several applications.

Rakuten listed the benefits of Elm being a purely functional, statically typed, domain-specific language designed specifically for beginners.

Unlike TypeScript, type annotations are mostly unnecessary due to Elm’s strong type inference (however, annotations are considered a best practice to protect against infinite types). Elm’s strong type system enables the Elm Package Manager to enforce semantic versioning: API-breaking changes are recognized automatically and lead to major version updates. One Elm developer noted:

Compared to any versioning system where you have no idea whether something is going to break or not, you have a little more insight into the nature of the upgrade. You still need to test and qualify for regressions, but overall I’ve seen maybe 3 minor / patch regressions on hundreds of upgrades and none of them made it into production.

Elm specializes in the development of single-page web applications. While this can be a barrier to adoption in some architectural contexts, it also allows Elm to tweak its output for performance (fast and efficient JavaScript compilation, small asset size, and more) with minimal user intervention simply by the --optimize Flag. This is in contrast to the long list of constantly evolving techniques, tools, and configurations found in the typical JavaScript front-end code base (bundles, plugins, .rc Files). Elm’s performance on some benchmarks consistently ranks among the best of the compilation-to-JavaScript languages ​​and among the best of the purely functional compilation-to-JavaScript languages.

The Elm architecture is the core of functional UI techniques that have migrated to non-functional languages. The Elm architecture was transferred to Rust / Wasm (e.g. yew), JavaScript (e.g. 1 KB ferp, AppRun), TypeScript (e.g. elm-ts) and has many other languages ​​and libraries (e.g. B. Redux, SwitfUI, Dark). The Rakuten article provides the following illustration of Elm architecture:

(Source: Elm in Rakuten)

Rakuten also mentioned the downsides related to Elm not being a mainstream language. Almost a decade after its inception, Elm has not gone mainstream despite the aforementioned benefits of Rakuten – unlike TypeScript. Some developers think this is because Elm wasn’t designed with quick adoption in mind. Concrete consequences are that you cannot rely on Google Search and Stack Overflow as you can with mainstream languages. This means that if it doesn’t already exist or is no longer maintained, you’ll need to write a custom Elm library. Rakuten mentions having to write a library inspired by react-json-schema-form Create HTML forms.

Some developers have also reminded that Elm ports allow interop with JavaScript, but with Elm 0.19 and higher it is no longer possible for non-core team Elm code to call a JavaScript function directly (synchronously) from Elm. While the limitation helps prevent language runtime exceptions by isolating the Elm runtime from the JavaScript runtime, it has also resulted in some developers abandoning the language. Others may fear that they will encounter a technical roadblock in the future for which they have no escape hatch. Rakuten recalled:

Elm is likely not suitable for short projects that require a lot of integration with third-party JavaScript libraries.

The full blog post has the full list of pros and cons related to using Elm on Rakuten. Interested readers can read the full article online.

Source link

Leave A Reply

Your email address will not be published.