A Decade‑Long Journey of Frontend Framework Selection and Component‑Based Development
The article recounts a Chinese company's evolution from an IE‑only HTC‑based UI stack in 2007 through a Flex‑driven heavyweight solution and finally to Angular, highlighting the technical, organizational, and strategic challenges of adopting component‑based front‑end architectures across multiple browser generations.
In 2007 the team needed to refactor a product whose front‑end was built on HTML Components (HTC), simple native‑JS wrappers, and synchronous XMLHTTP communication that only supported IE5‑7, causing the UI to freeze during requests.
With the rise of Firefox, the team faced a cross‑browser requirement and evaluated ExtJS versus core JavaScript libraries; ExtJS was rejected for lack of customizability, and Prototype was chosen over jQuery and others because the project did not need a class‑based system.
Using Prototype they rapidly built essential controls—data grid, tree grid, custom calendar (supporting Persian and Nepali calendars), pagination, dynamic forms, and an internationalization scheme—within a two‑to‑three‑month window with a small team.
The resulting version remained IE‑centric, and subsequent branches struggled with IE8 compatibility, leaving little room for further core library improvements.
By the end of 2009 the team revisited framework selection, considering HTML5, but ultimately adopted Adobe Flex for a heavyweight solution, while using jQuery and Bootstrap for lightweight, portal‑type applications.
Flex offered a component model, lifecycle management, and browser‑independent performance, which helped improve development efficiency and UI aesthetics, though it introduced challenges in training developers on component concepts and managing complex component hierarchies.
The experience highlighted the need for strict control of custom controls, comprehensive component governance, and a testing platform to avoid a “sham” component process.
From 2012 onward the team observed the emergence of AMD/CMD module systems, Backbone, Knockout, Angular, ES6, and Web Components, eventually favoring Angular because the team had already embraced component‑based development and data binding, making the learning curve low.
Angular’s data‑binding model aligned with the Flex‑style proxy mechanism the team used for dynamic data models, and the team also explored module dependency management ideas similar to npm, later finding Webpack addressed many of those concerns.
Reflecting on the past six years, the author notes the rapid turnover of front‑end technologies, the importance of continuous learning, and the enduring value of component‑oriented thinking despite the obsolescence of specific tools.
Qunar Tech Salon
Qunar Tech Salon is a learning and exchange platform for Qunar engineers and industry peers. We share cutting-edge technology trends and topics, providing a free platform for mid-to-senior technical professionals to exchange and learn.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.