November 5, 2014 at 18:24The evolution of Yahoo Mail
This is a translation of the Evolving Yahoo Mail from the Yahoo Developers Blog.
Yahoo Mail was originally launched in 1999. Over the course of 15 years, code has evolved from server-side Web 1.0 applications to one of the largest YUI single-page applications on the Internet.
Last month, Yahoo held a React JS mitap at the main office in Sunnyvale, CA. More than 120 people visited the mitap ( slides from mitap ), where we shared knowledge and ideas about application development using Javascript, React, Flux, etc. We also talked about the evolution of Yahoo Mail and the reasons why we chose ReactJS + Flux as the basis for our new Mail product.
We are currently using Model-View-Controller as an architectural pattern in Yahoo Mail on both the client and the server. This pattern has given us an excellent platform for our components. But, unfortunately, any code that a large number of developers have been working on for several years becomes more and more difficult to maintain. As in any MVC architecture, controllers request data and basic models, models initiate events, which, in turn, are processed by representations, representations initiate events that are processed by other representations. Events glue the whole structure of the web application and YUI provides us with an excellent platform for working with these “interesting details”.
But such code becomes very difficult to debug. Initialized events generated a series of related events in other parts of the application and fixing any bug required more and more knowledge about the code of the entire application as a whole, which significantly complicates the process of learning code for new developers on the team.
For the new Yahoo Mail app, we wanted to:
We looked at various technologies, including Ember and Angular. Both frameworks forced us to follow a certain architecture. Based on previous experiences and trends among developers, we realized that the era of "large" frameworks is coming to an end. Therefore, we began to consider the micro-libraries KnockOut, Durandal and Rivets. Using these libraries along with a couple of other micro-libraries, we could get a good platform for our new application, but in the end we settled on React + Flux.
A number of reasons why we chose React + Flux:
The "one-way" or "unidirectional" data flow has attracted us with its approach to the interaction of UI components. Also, debugging applications has become much easier and more understandable. With React, we also got the opportunity to use one programming language both on the client and on the server. The virtual DOM allows us to render the same components in the browser and on the server.
Unfortunately, not all interactions in the application can be represented as a “one-way data flow” and we try not to complicate our interactions between the Flux Action-Creator and the Flux Store, which we will write about in the next post.
Yahoo Mail was originally launched in 1999. Over the course of 15 years, code has evolved from server-side Web 1.0 applications to one of the largest YUI single-page applications on the Internet.
Last month, Yahoo held a React JS mitap at the main office in Sunnyvale, CA. More than 120 people visited the mitap ( slides from mitap ), where we shared knowledge and ideas about application development using Javascript, React, Flux, etc. We also talked about the evolution of Yahoo Mail and the reasons why we chose ReactJS + Flux as the basis for our new Mail product.
We are currently using Model-View-Controller as an architectural pattern in Yahoo Mail on both the client and the server. This pattern has given us an excellent platform for our components. But, unfortunately, any code that a large number of developers have been working on for several years becomes more and more difficult to maintain. As in any MVC architecture, controllers request data and basic models, models initiate events, which, in turn, are processed by representations, representations initiate events that are processed by other representations. Events glue the whole structure of the web application and YUI provides us with an excellent platform for working with these “interesting details”.
But such code becomes very difficult to debug. Initialized events generated a series of related events in other parts of the application and fixing any bug required more and more knowledge about the code of the entire application as a whole, which significantly complicates the process of learning code for new developers on the team.
For the new Yahoo Mail app, we wanted to:
- Predictability / ease of debugging;
- Independently placed components;
- The speed of training new team members;
- No dependency on large components / frameworks.
We looked at various technologies, including Ember and Angular. Both frameworks forced us to follow a certain architecture. Based on previous experiences and trends among developers, we realized that the era of "large" frameworks is coming to an end. Therefore, we began to consider the micro-libraries KnockOut, Durandal and Rivets. Using these libraries along with a couple of other micro-libraries, we could get a good platform for our new application, but in the end we settled on React + Flux.
A number of reasons why we chose React + Flux:
- React provides a one-way data stream;
- The virtual DOM allows rendering views both on the client and on the server;
- Client and server use Javascript;
- Actively developing community of developers.
The "one-way" or "unidirectional" data flow has attracted us with its approach to the interaction of UI components. Also, debugging applications has become much easier and more understandable. With React, we also got the opportunity to use one programming language both on the client and on the server. The virtual DOM allows us to render the same components in the browser and on the server.
Unfortunately, not all interactions in the application can be represented as a “one-way data flow” and we try not to complicate our interactions between the Flux Action-Creator and the Flux Store, which we will write about in the next post.