This article is originally published by Top of the Front. It is not reprinted in any form without permission. To apply for joining the group, please pay attention to the “front-end top” public account and send “Add group”.


After nearly 10 years of development, the front end from slash-and-burn to a hundred flowers bloom, prosperity breeds some trends and changes. Based on the present, how to see the front and back end separation? How to look at the full stack? What does the future look like for front-end engineers?


Tong Mu, focus on the front end for ten years, Alibaba B2B senior front end expert, GIT training camp lecturer. From browser to Web front end, from digital TV to Internet, from social to e-commerce, from technical architecture to team management, Teacher Tong Mu from these different perspectives, in-depth into the front-end field, accumulated a lot of experience, realized a lot of truth, has his own views on the development of the front-end.


>>>> please introduce your work experience and your current responsibilities in Ali, including the projects and teams you are in charge of.


Tongmu: My working experience can be roughly divided into three stages, from the digital TV industry to the social direction of the Internet industry, and then to the e-commerce direction.


When I was fresh out of school, I stumbled into the digital TV industry, doing front-end development on set-top boxes (the middleware architecture at the time, the UI layer was web-based, kind of like the later Web OS). I’ve been in the industry for four years, three front-end development and one browser development.


In 2011, a Q+ job AD sparked my passion for the Internet industry. Then I joined Tencent and worked in Jetong to make platform products, and was also responsible for the infrastructure construction of the team. In the second half of 2014, I joined Alibaba B2B and entered the category B e-commerce field. Since then, I have gained a different atmosphere and development space.


My current responsibilities focus on technical architecture and team management. My team is responsible for the basic platform business of e-commerce in 1688, such as commodities, trading, wangpu, membership, operation, etc.


>>>> What is the front-end project architecture you are responsible for? Did you use Hybrid mode? Why?


Tongmu: The basic business of 1688 has been developing for many years. In these years, the technology in the front-end field has been developing rapidly, so the front-end architecture has been evolving. WebView has left the veins and traces of technological development. For example, in some of the older businesses, there was the early Prototype and namespace to hang different module code, there was the later YUI code, and then the mainstream “jQuery + AMD Loader + jQuery Components” era, There is a lot of this code in existence.


In recent years, different teams of us have also tried ng, Avalon, React, vue and other MV * frameworks, and this direction has finally been gathered into the path of PC React, wireless Vue & React. In general, we don’t make many wheels by ourselves, the general context is YUI→jQuery→ MV *, and the engineering system is also the peripheral supporting of these things plus some of our customization.


Hybrid is certainly useful because, two or three years ago, there weren’t many options for striking a balance between dynamics, development efficiency, and user experience.


Hybrid solution itself is to make Native and Web learn from each other and complement each other in actual projects. In particular, some trade-offs need to be made for the future: in principle, what can be done with Web or try to do with Web; if there are standards, try to use standards; in case of fragmentation and uneven underlying capabilities, Polyfill will be adopted. Some of the things that are done for performance and experience are as transparent to Web developers as possible, architecturally orthogonal.


>>>> how does the project you are in charge of adapt to different devices and terminals? Is there any efficient method worth learning from?


Tongmu: I have already mentioned some of them in the previous question. Now I would like to mention two more points.


First, we managed to use one core code for PC and wireless in many scenarios, and one code for each end. On the one hand, the data and model of front-end model layer and back-end are combed and abstracted. There is little difference between different devices and terminals in the model layer. After this part is extracted, it is a stable and common layer. The View layer, on the other hand, looks different, but a lot of things are described semantically, again masking some of the differences. So in the end, the only difference is CSS, interaction logic, data adaptation and customization, and a little View customization.


Secondly, as for the fragmentation of the end, we smoothed part of it through Native ability, and introduced UC WebView to the other part, which greatly helped us to shield some underlying differences.


>>>> Do you think the separation of front and back ends is significant? Is there a real separation in the project?


Tongmu: Actually, we don’t like the separation of the rear end in advance. We prefer the fusion of the front and back end. From a technical architecture point of view, there is a need to separate the data model from the presentation layer, which is called front and back end separation. What about fusion? It is about the implementation level and the human level, because the complexity of B-type business and the threshold to overcome the business complexity are often greater than the threshold to overcome the technical complexity. Therefore, if we can reduce the technical threshold on both sides through servitization, then when writing business, we can according to the situation, Let the front end write the Controller by servitization, or vice versa, let the back end write the View by servitization.


The real decoupling is decoupling at the architectural level, which means that regardless of whether you’re front-end or back-end, you don’t think about the View at all when you’re writing Controller, and you don’t think about the Controller at all when you’re writing View, except for a layer of Schema convention. We have explored a path in this regard, and we have some interesting ideas and practices that we will share with you in detail when we have the opportunity.


What are the advantages and disadvantages of hybrid development of >>>> App? Will it become mainstream?


Tong Mu: Hybrid development is mainly to achieve dynamic development and save development costs, but the running part of WebView is difficult to achieve Native performance and experience in any case. A lot of current technology development is actually in the transformation of WebView, trying to get rid of some baggage or historical burden. One might wonder, what are the historical burdens of a WebView? Here’s a closer look:


First, there is the baggage of standards compatibility. WebView, as a universal browser kernel, requires forward compatibility. For example, although the Flexbox layout browser can be more efficient with layout, it still has to be able to understand floating layouts, relative positioning layouts, and even table layouts in order to be compatible. These logics are very complex intertwined, affecting the whole body. If I fork out a new WebView and cut out support for flexbox, the layout logic will be much less complex and faster without optimization, but I can optimize the Flexbox layout for even greater performance.


Second, the internal mechanics of browsers and the design of the JS language also carry some historical baggage. For example, when the browser is designed from the very beginning, JS Engine and DOM Engine are two independent black boxes. When JS calls DOM, it is equivalent to an RPC call, and each call involves saving and restoring the context. Also, JS excute and DOM Render run in the same thread, and even if they are not called, dom must wait for JS to render. The result of both of these events is that the web will move back and forth between the two black boxes as it runs, with various context switches and various waits for each other, so that frame drops are inevitable. So, if we can make js Engine and DOM Engine work together at the execution level and change RPC calls to local calls, we can speed things up a lot. Further, if you can take advantage of multi-core effectively, combine JS Excute and Render in parallel under certain conditions, or combine style considerations and layout in parallel, you can also add new features.


Again, it’s true that webViews themselves are getting faster, but some OS limitations or the presence of older WebViews on some devices can lead to fragmentation issues that are slowing us down. We are familiar with this, such as iOS Nitro, WKWebView for UIWebView, and Chromium WebView after Android 4.4 for WebKit WebView.

Lao Guo’s BeeFramework/Samurai and Ali’s Birdnest are dumping the previous two burdens. On the one hand, they take a subset of Web standards, and on the other hand, they pull everything into Native Runtime. FB’s React Native and Ali’s Weex, which mainly discarded the burden of the first item (and partially optimized the second item); Mozilla’s Servo was working on parallelization and GC, mainly in the second category; Intel Crosswalk, wechat X5, Ali UCWebView, etc., are the third burden in a certain range… In order to get rid of these burdens, everyone proposed different solutions.

No matter which way you go, there’s one thing you can all agree on, and that’s a few standards for the Web. Because the Technical architecture of the Web is really well designed in terms of the descriptive ability and flexibility of the UI, and the relevant developers are easy to recruit. So if hybrid development means running a Web standard in Native, writing guIs in sync with the Runtime, and bridging some of Native’s capabilities to the Runtime to call, then it should be a perennial trend.


What is the exact meaning of >>>> full stack? Does Ali encourage engineers to be full-stack engineers?


Tong Mu: the word full stack is quite fashionable, the meaning is not what do, snake oil.

In fact, a long time ago, we were all engineers. We had to do everything from database design to interface implementation to front-end presentation, from stored procedures to load balancing to deployment and maintenance.


But as the industry evolves, and each segment becomes more complex, it’s not impossible, it’s not too hard, it’s just impossible. If they did, they would only know half a bottle of water in each field, and what they would produce would be toys. So what to do? This needs professional subdivision, after the division of labor, each goes deep to develop.


But the problem comes again, after the division of labor, we still need to connect the links, which put forward requirements for interface design, but also to consider the link of joint adjustment. After the division of labor, there are upstream and downstream relations, we also need to cooperate with the construction period.


Another scenario: Suppose we have two businesses, and the business logic is very complex, and we have two people doing it. If it’s one front end and one back end, most of the details of those two complex businesses are for both people to understand. This is common because type B businesses are particularly complex. At this time can not directly return to the original “cure-all” mode, how to do?


This is where the full stack model comes in. The difference between full-stack and the earliest panacea models is that each domain hides a great deal of complexity and detail in a servitization approach. Full-stack engineers focus on business logic and business architecture, as well as the technologies and solutions at the front and back end of the servitization boundary that they must master in order to implement the business architecture. This allows two people to carry two complex pieces of business at relatively low cost.


As for whether to encourage the full stack, in fact, as long as it is conducive to improving overall productivity is definitely encouraged. Does full stack improve productivity? It depends on the business characteristics, the level of servitization at the front and back ends, and the structure of the team. In addition, personal wishes need to be considered. So we’re pushing this from two sides. On the one hand, it is possible to make this happen by improving the level of servitization in the case that it is recognized that the full stack can indeed improve productivity, which is the external cause. On the other hand, through the optimization of career development routes, promotion standards, Job models and other supporting facilities, with the cultivation of technical freshness and sense of accomplishment, and even a large number of benefits, to promote a group of students who are professional and have full stack intention to develop in this direction at ease and steadily, which is the internal cause.


At present, Ali has a lot of BU to promote the full stack, and everyone has made different progress at different stages. As for the final result, let’s wait and see.


>>>> in the front-end field, how to base on the present and face the future?


Tong Mu: This topic is very close to my heart. Not only in terms of technology, but also in the process of career development, technology management and architecture governance, I find that many experiences in the past are more or less related to this sentence.


To mention an early example, in the embedded browser era, WebKit didn’t catch on. At that time, we were maintaining an in-house browser engine, and the JS engine and layout had various bugs, which were very difficult to solve in terms of design. By the end of 2009, with WebKit on Android 1.5, we realized we had to drop the Web Core and switch to WebKit. This is a big turning point, of course, middleware to Andorid, is also irreversible trend. In this case, it shows the importance of vision and future direction.


Future-oriented, reflected in career development, from the radio and television industry to the Internet, and stick to the front end when the surrounding front-end to iOS/Android, there is no right or wrong in this, but behind it is also a judgment of the trend and a belief in the future.


Future-oriented, also reflected in the choice of technology architecture. For example, whether it is Bird’s Nest or Samurai, the early DSL design is far from the Web standard system, and then they all switched to the HTML+CSS+JavaScript standard. This reflects a principle, that is, we should do as much as possible on the Web as we can. If there are standards, we should try to use standards. In case of fragmentation and uneven underlying capabilities, we should adopt polyfill.


Future-oriented, but also reflected in the interface design. But here’s a counter example.


For example, there is an antipattern that is often said today: “Don’t extend native objects unless you explicitly know you are polyfilling.” What’s the harm in that? Someone might blurt out: “Extending Prototype breaks for… In is the purity of the object. Well, that’s one reason, but because of the legacy, people are used to it now. HasOwnProperty is used to filter in.


But the biggest reason is not that, but that it “loses compatibility for future extensions”. How do you understand that? Let me give you a concrete example to make it clear: In the early days of the Prototype library, it was popular to extend native objects to add useful features. Therefore, many people used to add methods to Array by adding prototypes. ForEach =fuction(){array.prototype.foreach =fuction(){… }.


That might seem like a good idea, but what’s the problem? Let’s think together:


How did you know that the specification wouldn’t add forEach to Array in the future? Well, I really don’t know, so TO be on the safe side, I’ll add a defensive if(! Array.prototype.foreach)


So how do you know if the standard internal implementation of forEach will look exactly like you? Well, luckily for you, the internal implementation is exactly the same.


So how do you know what the parameters of this function are before the specification comes out, in what order?

To be honest, this is very difficult to predict in terms of design. For example,in jQuery’s $. Each method, the order of the three parameters is index,value,array, while in the later specification, the order of the three parameters of forEach is value,index,array. So imagine if you had extended array. forEach with the above argument sequence, how would you change it so that all the code on the site would be able to play happily with the new code based on the standard method after the standard came out?


In addition to facing the future, we need to base ourselves on the present.


I have some examples of architecture governance and technology management around me, but because there is too much background to explain, I think I can give an example of the BATTLE between HTML5 and XHTML2 standards.


Why did HTML5 beat XHTML2 to become the de facto standard? Some argue that browser developers have more of a de facto say, so they win. But I would say it’s more the philosophy HTML5 follows that wins. Let’s take a look at some of the ideas behind it:


  • Avoid unnecessary complexity: The key is to avoid unnecessary complexity without hindering use in existing browsers

  • Forward compatibility, smooth degradation: the old writing method even if the design has defects, but also to ensure that the runtime will not be destroyed, but we can use tools to guide you to avoid the defects of writing; Some new features give users a better experience if they are supported and a basic experience if they are not

  • Pragmatic and down-to-earth: strive to absorb and improve folk solutions, not obsessed with the pursuit of theoretical perfection.

  • End user first: In case of conflict, end user first, author second, implementer second, standard setter second, theoretical perfection last.


These concepts ensure that a standard can be implemented in a gradual way, from point to point, without damaging and subversive effects on the existing ecology, and with the support of as many people as possible.


Of course, incremental reform can sometimes be a bit timid, and nothing is absolute, including shock therapy. What is said here is a way of thinking and strategy for solving problems in a complex system, and people need to make different choices according to their goals, scenes and applicable groups.


>>>> You focus on the front end ten years, in your opinion, the development of the front end will bring a breakthrough change?



Tong Mu: Actually, the development of the front end has made quite a breakthrough in the past two years. In the past, it was the expansion of some boundaries (server and mobile), then it was the improvement of engineering and ecology (modularization and package management), and recently it was the evolution of language and standard itself.


Ultimately, the development of the front end is inseparable from the evolution of devices and the way they interact. Are the changes in devices and interactions between the web we visited ten years ago and the web we visit now disruptive? No, our devices, from PCS to phones, have changed in terms of screen size and interaction, and their respective machine performance and Runtime performance have improved accordingly. But none of these changes is revolutionary.


What about the next decade? Will devices and interactions change?


As you may have seen, VR and AR are hot these days. As far as we can see, I believe the revolution will come with VR and AR, where a large part of the skill tree on the front end will change completely, standards will move forward, and even the boundaries of the front end will change dramatically. At that point, it might be more appropriate to call front-end engineers “visual and interaction engineers.”


On the other hand, I’m a bit conservative. I don’t think “visual and interaction engineer” will be around for too long, and I don’t think some VR and AR products I’ve seen recently are mature enough. Apps built on native apis don’t have enough resources to create an ecosystem and standards on top of it, and form a unified platform for UI and interaction like browsers. It will be a while before the front end engineer becomes the “vision and interaction engineer” of VR.








The top of the front develops with the top of the front and shares the same skill without ceasing learning to climb the top of the front