Over 100,000 lines of Elm code in production: Rakuten shares lessons learned

0

Japanese e-commerce company Rakuten recently shared their experience using Elm in production for over two years. Rakuten’s code base spans multiple applications on approximately 100,000 lines of Elm code. Rakuten really liked Elm’s approach to functional user interface, its type system, and the lack of runtime exceptions. On the other hand, Elm is not a common language, which results in less reusable resources that can be discovered through Google search and Stack Overflow.

Rakuten’s engineering team described what prompted them to start using Elm for their application development as follows:

It all started at Rakuten’s Berlin branch in the summer of 2017. We were maintaining a mid-sized single page app written in Vanilla JavaScript when things started to get out of hand. […]
We decided to impose some discipline and start rewriting the functions in a 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 “Introduction to the Elm architecture and how to create our first application” […]. It was love at first sight.

The company gradually adopted Elm, starting with prototypes first to test the technology. While the results of the first trials were encouraging, Rakuten reported that Elm adoption has stalled somewhat due to a heavily server-side PHP codebase. A battery change later gave the company the opportunity to expand its use of Elm:

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

Fast forward to 2021, Rakuten now has around 100,000 lines of Elm code in multiple applications.

Rakuten has listed the benefits of Elm being a purely functional, statically typed, domain-specific language specifically designed to be beginner-friendly.

Unlike TypeScript, type annotations are mostly unnecessary due to Elm’s strong type inference (annotations are considered good practice, however, to guard against infinite types). Elm’s strong type system allows Elm Package Manager to enforce semantic version control: API breaking changes are automatically detected and lead to major version updates. An Elm developer noted:

Compared to arbitrary version control systems where you have no idea if something is going to break or not, you have a bit more information about the nature of the upgrade. You still need to run tests and qualify for regressions, but overall I encountered maybe 3 minor regressions / fixes out of hundreds of upgrades, and none of them made it through. the 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 optimize its performance (fast and efficient JavaScript compilation, small asset size, etc.) with minimal user intervention, who simply use the --optimize flag. This contrasts with the long list of constantly evolving techniques, tools, and configurations to manage in the typical JavaScript front-end codebase (bundler, plugins, .rc files). Elm’s performance on certain benchmarks is consistently among the best of JavaScript build languages, and the best of purely functional JavaScript build languages.

The Elm architecture is at the heart of functional user interface techniques that have moved on to non-functional languages. The Elm architecture has been transposed to Rust / Wasm (e.g. if), JavaScript (e.g. 1KB ferp, AppRun), TypeScript (e.g. elm-ts) and has inspired many other languages ​​and libraries (e.g. , Redux, SwitfUI, Dark). The Rakuten article provides the following illustration of Elm architecture:

(Source: Elm in Rakuten)

Rakuten also mentioned the downsides that elm is not a common language. Almost a decade after its inception, and despite the aforementioned benefits of Rakuten, Elm has not made its way to the mainstream, unlike TypeScript. Some developers believe this is because Elm was not designed for rapid adoption. The concrete consequences include not being able to rely on Google search and Stack Overflow as can be the case with traditional languages. This means having to write a custom Elm library if it does not already exist or is no longer maintained. Rakuten mentions having to write a library inspired by reaction-jsonschema-form to create HTML forms.

Some developers further recalled that although Elm ports allow interoperability with JavaScript, with Elm 0.19 and higher it is no longer possible for non-core Elm code to call a function JavaScript directly (synchronously) from Elm. While the restriction helps ensure that the language will not execute exceptionally by isolating the Elm runtime environment from the JavaScript runtime environment, it has also led some developers to abandon the language. Others may fear that they will encounter a technical roadblock in the future from which they will have no escape route. Rakuten recalled:

Elm is probably not a good choice 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 of using Elm at Rakuten. Interested readers can view the full article online.



Source link

Leave A Reply

Your email address will not be published.