Re-writing Vy.no in Elm

[robin.heggelund]

A colleague of mine and me wrote an experience report about the use of Elm at Norway’s largest transport provider. Thought it might be of interest to others, so putting it here:

Re-writing Vy.no in Elm

[psb]

The article says that there are 13 Elm applications, so I assume that it is not a SPA. I am curious about the bundle size of each application, since (I believe) the Elm runtime will be packaged into each bundle. Were there any issues, concerns or worries?

I am currently creating separate Elm applications/bundles, but sometimes I wonder if it makes more sense to go the component route and have one runtime/framework bundle plus component bundles

[rupert]

I had a question about this:

“These applications rely on 7 private packages for common functionality”

How did you handle the private packages. Was it a monorepo approach for example?

===

I saw the answer further down: elm-git-install

[rupert]

Also intrigued about this:

“Vy’s vision is to make it easier and more accessible to purchase tickets, so that even more people can travel using environmentally friendly public transportation.”

I am guessing as a website for public transport accessibility was very important, a non-negotiable requirement even. Did this present any particular challenges when adopting Elm?

[robin.heggelund]

These are great questions:

• Why not monorepo?

There are several reasons. Partly it was due to the re-write. The old site was not an SPA, so instead of re-writing the whole thing as a single SPA, we instead converted one “page” (one url) at a time, and performed url redirection to and from the app. This allowed us to integrate new code with the old, so that we could get into production quickly.

The second reason is that the web site is actually kinda complex. Elm is most happy (and easiest to use) when it can control the entire page. That is not an option for us. The header is a React component. The footer belongs to the CMS system. Several pages mixes static and dynamic content. All our Elm apps therefore have to work as single components. We can’t really rely on the backend shipping the same index.html on every request, and then let the Elm application handle routing from there.

Another aspect, which ties directly into the monorepo vs multirepo approach, is that keeping everything strictly seperated allows for more experimentation. We can make as many changes as we like on a single page, knowing it can’t affect other apps (changing the CSS for buttons doesn’t require us to check if we’ve broken the styling on a different page, as different pages can run different versions).

It also makes it easier to gradually upgrade dependencies and compiler in our own time. For instance, the upgrade from Elm 0.18 to 0.19 was pretty painless, as we only needed to upgrade the apps we were working on right now. All new code could happen in 0.19. Bugfixes on older apps didn’t require a compiler upgrade. Same thing if one were to convert to a new mayor version of an important library.

So, to summarize. We went for multi-repo mostly because it made the re-write easier to do. And now we actually quite like it so we don’t waste much time thinking about binding everything together as an SPA.

When it comes to bundle size… It’s not much of a priority. If you want to purchase a ticket, you’re likely to download a bunch of json that pertains to your order, and those objects will in a lot of cases be bigger than Elm bundle. In Norway we’re also pretty blessed with great mobile network coverage and broadband solutions. We’ve yet to hear anyone complain about the performance of our site. And if we were to get complaints, the biggest win would be in optimizing the latency of our api response, not how much is downloaded from our CDN.

• how we managed all our private repos

elm-git-install. In fact, elm-git-install was created because we had this problem. In 0.18 we had elm-github-install, but it was abandoned because 0.19 removed the possibility of calling native JS code. So in 0.19 we had to make our own solution.

• Accessibility

We haven’t had any problems with accessibility and Elm. We spend a lot of time on accessibility, and I’m sure we could do a better job of it than we are doing now, but that’s not because of Elm.