DEV Community: Kenny De Pauw

Adopting React at Lighthouse

Kenny De Pauw — Mon, 17 Nov 2025 10:25:44 +0000

A decade with Ember.js

For over ten years, Ember.js has been the reliable engine behind Lighthouse's core platform. As a comprehensive, "batteries-included" framework, Ember provided the structural consistency and predictability necessary for a large enterprise application. This stability allowed the engineering team to focus intently on delivering product value with high productivity and minimal technical debt.

Lighthouse still considers Ember.js a quality framework built on solid principles, but a strategic decision was needed to ensure the long-term sustainability and competitiveness of the platform for the next decade. Now is the time to look forward. After extensive research and testing, a pivot is necessary to make sure we stay competitive and provide our engineers with the best possible experience.

Why we had to change

As the company scaled through significant growth, three critical, growing risks tied to continuing reliance on a smaller ecosystem were identified:

1. Declining market share

While Ember is a quality framework, its declining market share put Lighthouse at a disadvantage:

Talent pipeline: Lighthouse needs to ensure it could attract and retain engineers who want to work with the most in-demand skills. React's current unmatched market dominance and massive developer community solve this challenge, immediately expanding the talent pool and making the company more attractive to top engineers.
Ecosystem health: The team often struggled to find modern, maintained, off-the-shelf solutions for needs (like advanced table components or up-to-date tooling). They were increasingly forced to build and maintain fundamental tools themselves, diverting resources away from product innovation.

2. M&A integration and future growth

Lighthouse's growth strategy partly consists of successful mergers and acquisitions (M&A). The core framework must support a playbook for rapid integration.

React is the most prevalent frontend technology globally; standardising on it dramatically increases the probability that an acquired company's technology stack will be familiar or quickly convertible, reducing the cost and complexity of integrating new teams and codebases.

3. AI tooling and future productivity

Lighthouse is committed to integrating AI-assisted development into its workflow to boost engineering productivity. React's market dominance makes it the primary target for AI model training and tooling, ensuring teams have immediate access to the latest innovations in coding assistance and efficiency gains.

We are aware that a decision like this contributes to the very trend we are observing, making it a 'self-fulfilling prophecy' of declining market share. However, for a frontend engineering team of our size, the risk associated with being a smaller player in a shrinking field is immense. We simply do not have the internal capacity or intention to pivot resources toward the maintenance and enhancement of framework tooling. This would be a significant investment we can't make right now. Our strategic shift is therefore about mitigating that long-term business risk.

Why React over other frameworks

The decision followed an extensive evaluation, including rigorous Proofs of Concept (POCs) of both React and Angular.

Frameworks like Vue, Svelte, and others were ruled out as they presented similar, though lesser, risks concerning ecosystem size and long-term talent pool growth.

The 'batteries included' argument for Angular is a powerful one. However, the POC revealed that after its recent major upgrades Angular is currently in a period of flux. The introduction of new paradigms like Signals has created competing ways to solve problems, which can lead to a similar level of decision-making as React and a temporary inconsistency in best practices.

Lighthouse felt this made React's vastly larger, active, and more diverse ecosystem a much more compelling advantage.

The abundance of battle-tested, community-driven tools, such as the TanStack ecosystem (Query, Router, Forms), for everything from data fetching to UI components minimizes the risk of having to build or maintain their own specialized solutions.
This, paired with its focused, component-driven approach, offers superior flexibility for building complex enterprise features.

Our solution: a structured, enterprise-grade React

To ensure React apps do not become a "Wild West" of conflicting approaches, the platform team is dedicated to defining a highly opinionated set of rules and architectural standards designed specifically for Lighthouse's scale. This approach maintains the stability and consistency valued from Ember.

💡 Sneak peek at the Lighthouse React standards:

Architectural Decision	Lighthouse Standard	Rationale
Core Libraries	TanStack (Router, Query), Vite (Build Tool).	Provides enterprise-grade data handling, caching, and routing while maintaining high performance.
State Management	TanStack Query for server state; useState / Context API for local client state.	Clear rules here simplify application architecture and maintenance.
Architecture	Domain-Driven Design (DDD): We will adhere to DDD to make sure we have an easy to follow structure in all of our codebases.	Guarantees consistency, improves maintainability, and makes complex code easier to test and onboard new engineers onto.

What's next?

This transition will be strategic and phased. We are committing to a gradual approach. Each next phase is based on the previous phase's success. Lighthouse wants to be flexible, and if assumptions were wrong or expectations are not met, they can still reverse course or adapt the strategy.

Foundation Building: The platform team will finalise these architectural decisions and build the initial React design system library.
Product Pilot: Before making the plunge, one of the new applications will be built in React with the envisioned architecture decisions. This will be seen as a more in-depth trial run and is still easily reversible if the POC assumptions turn out to be wrong.
React adoption: Lighthouse will begin building all new products in React, starting with one of the acquired products already planned for a rewrite.
Future Consolidation: Once the new standard is stable and proven, a long-term plan will be developed for the gradual migration of the existing Ember applications.

This decision marks the start of an exciting new era for Lighthouse Engineering. The team is confident this move will not only secure their technical foundations but will empower teams to innovate faster than ever before.

In a next post, one of the lead engineers on this project will follow up with the detailed technical implementation of the new React architecture.

Why we use Ember.js at OTA Insight

Kenny De Pauw — Mon, 04 Apr 2022 14:26:12 +0000

We always choose the stack that is right for the job. We often get asked why we use Ember.js. It’s not the most popular framework, or the largest community, but it is the right choice for the products we are building at OTA Insight. From our first product, Rate Insight, to the four after that, all of it is built with Ember.js. And for good reasons. We were able to create new features quickly, have a codebase that’s scalable and have a good developer experience. All of these are reasons we choose Ember.js. But let’s go in a bit more detail.

Batteries are included

It’s a phrase you’ll see floating around the Ember.js community and it’s one of the reasons why we were able to move so fast here at OTA Insight. The strong focus on convention over configuration enables you to move quickly as you don’t need to reinvent the wheel every time. It also gives developers new to your codebase a good guideline on how to write code. There’s no 100 ways of doing things.

There were times we had to make something custom, going against the conventions put forth in the framework. This can become difficult, requiring some research into the inner workings of Ember.js, but this hasn’t occurred all that much. The benefits of having strong conventions and guidelines on how code should be structured are more than worth this tradeoff.

What steep learning curve?

The thing I hear developers fear most is the steep learning curve of Ember.js. Not sure where this comes from, especially with the latest move to Ember Octane. After this milestone, Ember.js is making use of the latest javaScript features and it feels pretty close to working with standard javaScript. Gone are the days of having to call custom get/set functions, using EmberObjects, etc.. Now everything is done with class syntax, decorators etc. If you know javaScript, you’ll have no problem getting started in Ember.js.

The templates used in Ember.js are close to basic HTML with the ease of Handlebars added on top. You separate your concerns, having the template and styles separated from the logic. All of this provides a clear overview for developers starting with the framework.

Of course there are still Ember.js specific features you need to know. How is the app structured? What are the lifecycle hooks? What is the Ember.js way of doing things? But this is what you’ll see learning any framework.

Bonus is that here at OTA Insight we have a whole team of people with experience in Ember.js who will be happy to help you out. All you have to do is ask.

Modern frameworks and Ember.js

We’ll regularly check our tech stack and see if we can improve it. Our use of Ember.js is no exception. We recently built a Vue.js prototype of our application to see how it compares. We focussed on 4 factors to determine how they compared:

Developer experience
Performance
Scalability
Community

I won’t go into too much detail here, that may be a post for later (or if you want to know more, feel free to reach out).

Regarding developer experience it was clear the conventions defined in Ember.js really allowed us to develop things quickly.
Speed was comparable to Vue.js thanks to the Glimmer components recently introduced in Ember.js.
Even now with 5 products, the codebase is still scalable as well, although using a framework like Nuxt you could probably come to a similar result.
Even though there is a larger community with Vue.js, we found Ember.js had a clearer roadmap for the future.

After our research was done we had to decide, is it worth changing our framework to Vue.js? What was clear is that the two were comparable. Ember.js outperformed in some regards, and Vue.js in others as you can see above. We decided that if Ember.js can compete with one of the top three frameworks out there right now, it’s clear this was the right choice back in the day and we are still proud to be developing in Ember.js.

Paving the way

Ember.js is the right choice for our main application. But it isn’t always the right choice. For example, our design system.

Frameworks come and go in the frontend development world, but web components are forever. That’s why we have built (and are expanding) a design system using Stencil.js. Web components can be used in any framework and Stencil.js makes it easy to create new ones.

We did not build this in Ember.js on purpose. While Ember.js has its use, and while we still believe in it now, who knows what the frontend landscape will look like years from now. Having our design system, and so our most generic and most used components be framework agnostic is a huge benefit. It opens the door to have them used with other frameworks (or with no framework at all!) We have several smaller apps, some use Ember.js and some are just plain HTML, CSS and javaScript. In the future we might even have one running in React or Svelte. All of these can use our design system.

We don’t cling to Ember.js just because of a choice we made all those years ago. We do it because we still believe it’s the right choice for our main app. For the design system it wasn’t. We always choose the stack that is right for the job.