Eco-design at MobileThinking: Languages and Frameworks
Fourth challenge: reducing impact by establishing the best technical framework
What if choosing a different language or framework could make all the difference?
This is what Jules and Jérôme aimed to verify by deciding to look under the hood, where technical choices genuinely influence consumption.
Their goal: to compare the most widely used languages and frameworks in our context (and globally) to identify those that consume the least... and rethink our technical choices according to their environmental impact.
It’s a bit like when choosing a fridge or a washing machine: for the same usage, some consume significantly more than others. So why not apply the same reasoning to our code?
Initial observation 🧐
As a company specialised in web development, we use several languages and frameworks depending on the projects.
We often choose them for reasons of performance, productivity, or preference.
However, we had never really considered which one consumed the least energy. Yet, it is likely that some are much more resource-hungry than others.
So the question arose: what if we integrated this criterion into our technical choices? Should we, in the future, prefer one framework over another if its environmental impact is significantly lower?
To gain clarity, our dynamic duo decided to test and compare the actual consumption of some of the most popular frameworks.
Identified issues 🤔
Throughout the morning, several concrete questions emerged:
- Are the most popular frameworks also the most energy-efficient?
- Can we truly measure the energy impact of a complex API call, involving a database, business logic, and serialisation?
- And on the frontend side: to what extent are the results biased by the computer, the operating system, or even the browser used?
In other words, measuring is good... but comparing on equal terms is a real challenge.
What we tested 🧪
To objectify the differences in consumption, Jules and Jérôme established a simple testing protocol that is representative of real usage.
👉 On the backend side, they simulated a classic GET request in our APIs:
- Passing through an authentication middleware
- Request to the database
- Serialisation of data (user profile + associated book list)
All measured with Scaphandre, an open-source tool that estimates energy consumption in microjoules (µJ). → Each framework was tested on 200 requests, under the same conditions.
👉 On the frontend side, they compared the most commonly used frameworks (Vue.js 3, React, Angular) based on estimates of annual consumption, while considering the limitations related to hardware (OS, browser, machine, etc.).
Results 📊
Backend
➡️ A striking result: the same processing can consume 28 times more energy depending on the chosen framework.
Frontend
➡️ Likewise, the differences are significant: Vue.js is the most energy-efficient of the three, while Angular is the most resource-intensive.
Our avenues for improvement
This challenge has allowed us to identify several levers for the future:
- Reduce the impact of JSON serialisation, often underestimated yet energy-consuming.
- Document the results and build an internal comparison database.
- Integrate the notion of energy consumption into our technical choice criteria, alongside maintainability and development speed.
- Create a standardised testing protocol to easily benchmark with each new project.
What we take away
- Not all frameworks are created equal: some consume significantly more than others for the same output.
- These discrepancies have a concrete impact, project after project, request after request.
- The frontend remains difficult to compare objectively, but clear trends are emerging (Vue.js is more efficient than React or Angular).
- With tools like Scaphandre, it is possible to measure, compare, and make informed decisions.
To be continued... ✨
The challenges have continued to pile up: optimizing images, better distributing processes, revisiting our architecture, and finally... choosing the most energy-efficient technologies.
Each team has contributed, everyone has had the chance to test, tinker, and be amazed. What we thought were mere technical adjustments... have turned into a collective awareness.
Now that we have the cards in hand, one question remains: what do we do with this information?
👉 The answer in the next and final episode: from collective reflection... to a new way of designing
