But how can we do that with our application currently in production?

A cut-over rewrite was not an option. It would take at least a year to release a frameworkless version of our project, and this scenario was not acceptable by our client. So we came up with a more feasible approach, the StranglerApplication pattern.

Photo by Kate Ausburn on Unsplash

To apply this pattern, a new application is created. This new application will slowly replace (or strangle) the old one, until the old application is so small that you can safely remove it.

In our specific case the old application was AngularJS web application built with Grunt, and the new one is a frameworkless application built with webpack.

After the creation of the new application we imposed ourself a very simple but strict rule: no commits on the old application. Every new feature should start in the new part of the application, and every change request or fix to the old part should start with the porting of the old code in the new environment, adapting it.

A schema of our StranglerApplication

In this post I will not go in detail about the code part, I will just say that:

we converted every service to a standard ES Module

to a standard we converted every controller or directive to a custom element

or to a every ES Module is accessible by the old part as a service using a simple bridge function

If you are interested in more details about how to implement this kind of solution for your project you can checkout this GitHub example. In that repo it’s possible to see how, with every commit, a piece is moved from the old application to the new one.

I’ve also talked about this topic at JS Day 2018 in Verona. In the talk I explain briefly how the bridge function is designed.

My talk at JS Day 2018.

What we Learned

We learned a lot from this refactoring. The first and probably most important thing is perfectly summarised by this quote from Gerald Weinberg.

Don’t be rational; be reasonable.

What I mean is that when we first tested this solution during an Architectural Clash, we felt that it was too “strange” to really work in production. But we decided to give it a try and we loved it. Ideas that seem “not right” but that are good enough for your context, need to be explored with some experiment before deciding that they are really “not right”.

Another thing that we learned the hard way is that strangling a web app is a very long and laborious process. So when we design a new piece of software we try to design it in a way to make it easier for it to be strangled in the future. One of the principles that we adopt is the Sacrificial Architecture always by Martin Fowler.

At last we learned that working without frameworks on the frontend is completely doable with the right people in your team. From this experience we decided to create the Frameworkless Movement: a group of people interested in developing without frameworks and helping everybody make mindful technical decisions.

If you want to talk about StranglerApplication pattern, legacy frontend applications or the Frameworkless Movement just contact me on Twitter, my DMs are open.