Yahoo Mail Evolution
This is a translation of the Evolving Yahoo Mail publication from the Yahoo developer blog.
Mail service Yahoo Mail was originally launched in 1999. For 15 years, the code has evolved from a server-based Web 1.0 application to one of the largest single-page YUI applications on the Internet.
')
Yahoo held a React JS mitap last month at the head office in Sunnyvale, CA. Mitap ( slides from mitap ) was visited by more than 120 people, where we shared our knowledge and ideas about developing applications 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.
At the moment we are using Model-View-Controller as an architectural pattern in Yahoo Mail on both the client and the server. This pattern gave us a great platform for our components. But, unfortunately, any code that a large number of developers have been working on for several years becomes harder and harder to maintain. As in any MVC architecture, controllers request data and basic models, models initialize events, which, in turn, are processed by views, views initialize events, which are processed by other views. Events stick together the entire structure of a web application and YUI provides us with an excellent platform for working with these “interesting details”.
But such code becomes very hard to debug. The initialized events spawned 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 in the team.
For the new Yahoo Mail application we wanted:
We looked at various technologies, including Ember and Angular. Both frameworks have forced us to follow a specific architecture. Based on previous experience and trends among developers, we realized that the era of “big” frameworks is coming to an end. Therefore, we began to consider KnokOut, Durandal and Rivets microbibraries. 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 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 had the opportunity to use one programming language on both the client and the server. 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 Flux Action-Creator and the Flux Store, which we will write about in the next post.
Mail service Yahoo Mail was originally launched in 1999. For 15 years, the code has evolved from a server-based Web 1.0 application to one of the largest single-page YUI applications on the Internet.
')
Yahoo held a React JS mitap last month at the head office in Sunnyvale, CA. Mitap ( slides from mitap ) was visited by more than 120 people, where we shared our knowledge and ideas about developing applications 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.
At the moment we are using Model-View-Controller as an architectural pattern in Yahoo Mail on both the client and the server. This pattern gave us a great platform for our components. But, unfortunately, any code that a large number of developers have been working on for several years becomes harder and harder to maintain. As in any MVC architecture, controllers request data and basic models, models initialize events, which, in turn, are processed by views, views initialize events, which are processed by other views. Events stick together the entire structure of a web application and YUI provides us with an excellent platform for working with these “interesting details”.
But such code becomes very hard to debug. The initialized events spawned 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 in the team.
For the new Yahoo Mail application we wanted:
- Predictability / Easy debugging;
- Independently hosted components;
- The speed of learning new team members;
- No dependency on large components / frameworks.
We looked at various technologies, including Ember and Angular. Both frameworks have forced us to follow a specific architecture. Based on previous experience and trends among developers, we realized that the era of “big” frameworks is coming to an end. Therefore, we began to consider KnokOut, Durandal and Rivets microbibraries. 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;
- Virtual DOM allows you to render views on both the client and the server;
- Client and server use javascript;
- Actively developing community of developers.
The “one-way” or “unidirectional” data flow 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 had the opportunity to use one programming language on both the client and the server. 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 Flux Action-Creator and the Flux Store, which we will write about in the next post.
Source: https://habr.com/ru/post/242407/
All Articles