2017 what is the front-end framework? 2017 framework

2017 what is the front-end framework? 2017 framework

> This article starts with the popular AngularJS ReactJS Polymer frameworks and analyzes the key technical points of the front-end framework in recent years. It serves as a reference for front-end technology selection of 2015. Abstract:

-Initial Experience
-Technical Features
-Componentization
-Application architecture

### Conclusion

** 1. Initial Experience **
Use TODO as an introduction.
! [] (Http://upload-images.jianshu.io/upload_images/8373224-4e10488b2196f18d.png? ImageMogr2/auto-orient/strip % 7CimageView2/2/w/1240)
Angular implementation
! [] (Http://upload-images.jianshu.io/upload_images/8373224-5966342b1a65597b.png? ImageMogr2/auto-orient/strip % 7CimageView2/2/w/1240)
React implementation (non-flux Architecture)
! [] (Http://upload-images.jianshu.io/upload_images/8373224-fdd1c5436dfee33e.png? ImageMogr2/auto-orient/strip % 7CimageView2/2/w/1240)
Polymer implementation
! [] (Http://upload-images.jianshu.io/upload_images/8373224-e39a00c0f65ac2e8.png? ImageMogr2/auto-orient/strip % 7CimageView2/2/w/1240)
Comparison between the three
! [] (Http://upload-images.jianshu.io/upload_images/8373224-2e20982ca8e05655.png? ImageMogr2/auto-orient/strip % 7CimageView2/2/w/1240)
In Angular, the concepts of controller and component are separated, while react and polymer only have the concept of component.
In fact, there is not much difference between the three in the simplest use cases. Angular and polymer templates and code separation methods are closer to the traditional front-end practices, while React writing is more like backend rendering. There is no argument about who has a high learning cost and who has a low cost. When MVVM has been popular for so long, the entry thresholds of the three are almost the same, however, to make good use of the operation mechanism, you must go deep into it.

** 2. Technical Features **

In fact, the so-called MVVM framework has one key technology: Data and view binding. In Angular/polymer/knockout/vue/aveon, the implementation of this technology can be split into two key points: Template analysis and data monitoring.
The main purpose of template analysis is to collect tags such as {title. After the collection is complete, a view update function is generated. The function stores the Dom fragment of the tag and related data names, when the function is called, the data corresponding to the data name is retrieved again (or the corresponding data is passed as a parameter by the external system), and the dom fragment is updated. In this way, the view is updated. Generally, the framework analyzes the template at startup and generates corresponding view update functions. When data is updated, these update functions are called to update the view. The question is, how can we detect data changes?
Knockout/angular/aveon represents three solutions:

-Use custom data objects and their specified get and set functions. For example, you can only use user. set ("name", "john") to assign values to the name attribute of the user object, because it can know the attributes modified in the set function, only the corresponding view update function is called. This method is not so nice because it changes the method used by the original JS object.
-The get and set functions of Object. defineProperty are used to detect changes to Object attributes, which are essentially no different from the previous ones. However, it has a defect that it cannot detect newly added or deleted attributes. Some Frameworks supplement this scheme through Object. observe, but Object. observe currently only supports chrome. This method improves the development experience above. You can operate your data like using a native JS object. However, the implementation is complicated.
-Dirty check. This is a mechanism that angular is using. It cannot trigger an update callback as if the data changes in the first two methods. Instead, you must call some methods provided by angular, or trigger events on elements such as ng-click on the page. These triggering times are implemented internally by angular, so you can hardly feel them. This method is called "dirty" because it saves the last value of all attributes and detects that all attributes of the object are traversed, compare it with whether it is the same as the last value. If it is a deep object, it will traverse through layers. This detection method combines the advantages of the above two methods, but imposes a burden on performance.

Now, the two key technical points have been clearly explained. Let's review them with a diagram.
! [] (Http://upload-images.jianshu.io/upload_images/8373224-7c3f8defccefd595.png? ImageMogr2/auto-orient/strip % 7CimageView2/2/w/1240)
In React, React is relatively simple. React uses a mechanism similar to repainting. After setState is triggered, it is completely re-rendered (not immediately triggered, there is a mechanism similar to cache performance improvement ). This seems to be simpler than the previous solution, but it is amazing because of the virtual dom implementation. Virtual dom refers to a data object used internally by React to simulate real dom. When re-rendering, it is actually the virtual dom like this, and then compare it with the previous virtual dom to find the difference, finally, it is enough to update the different parts of the real dom by react. Because virtual dom is always in the memory, there are very few real dom operations, and the previous frameworks often have a large number of dom operations when updating views, therefore, react significantly outperforms the previous framework in terms of performance. Meanwhile, Because virtual dom is still a standard js object, "server rendering" is also possible. It is worth noting that, although React itself does not thoroughly check which part of the data has changed, it can be found through addon and immutable officially provided. js to further improve the performance of this module.
(Web Front-end learning and communication group: 328058344 chat prohibited, not welcome !)

** 3. componentization **

In terms of componentization, react and several other frameworks have almost separated each other. From the angular2.0 design and the new aurelia framework, we can see that everyone is trying to approach webcomponent. Polymer claims that the code of the next version will be greatly reduced, simply because the browser will implement the standard. The advantage of approaching webcomponent is that any framework will not be closed. Using custom element as the interface layer can achieve ecosystem convergence. Although react can also be encapsulated into a custom element, react does not call the custom element solution generated by other frameworks. "Using custom element like using native dom elements" means respecting native dom usage, including dom events. This is contrary to the basic direction of react "not operating real dom.
The differences between react and other frameworks do not seem to be good or bad at present, because webcomponent is still not fully supported by other browsers except chrome. In addition, considering the special national conditions, large companies still have to face ie8. Unfortunately, the polyfill of polymer is now only IE9 at the lowest. React does not support ie8. Considering the mobile browser, the technical resistance of using react is far less than that of webcomponent.
In general, webcomponent will certainly be a trend and will promote more open and easier integration of various frameworks. React will continue to rely on its own advantages in implementation. Maybe new things will be born in the middle of the future.
Release react and webcomponent for the moment. We will continue to dive into two very few but very important issues (the component issues discussed below are all based on encapsulated into custom elements ):
-How can I make components more reusable? Specifically:
-When using a component, I need to re-adjust the order of elements in the component. What should I do?
-What should I do if I want to remove an element from the component?

-How can I make components more scalable? Specifically:
-What should I do if the business side constantly asks to add functions to components?

In response to the first question, my team currently proposes a rule called "template Rewrite", which is divided into two types: "completely rewrite" and "partially Rewrite:
! [] (Http://upload-images.jianshu.io/upload_images/8373224-fa4f09d37ea116cc.png? ImageMogr2/auto-orient/strip % 7CimageView2/2/w/1240)
 
** Partial rewriting **

! [] (Http://upload-images.jianshu.io/upload_images/8373224-3cdbf825598ef138.png? ImageMogr2/auto-orient/strip % 7CimageView2/2/w/1240)
This solution has been implemented in angular. In addition, it has been proved very useful in systems with high Component Reuse Rate. However, it also has a defect because you must know the implementation method of the current component and the original template before rewriting.

The second problem can be solved in a way called "shared scope. For example, in the above example, story does not display the number of like, so it is displayed now. There are two common solutions:

-Modify the component and add this function to the component.

-Add an api to the component to obtain the statistical data. When the statistical data changes, an external event notification is thrown.

The problem that may be encountered in the first solution is that when the change occurs again, for example, the statistical data should not be displayed in the component. You have to change it to the second solution. The problem that may be encountered in the second solution is that there may be new demands constantly raised, and at last every internal state has to be exposed, and every operation process throws an event.

The "Scope sharing" sharing solution is: introduce an external html section into a component by using a special tag "import-to" to participate in "template Parsing" and "Data Binding ", when the process is completed, the original position is put back. In this way, the external html can obtain any status and data inside the component. This kind of solution looks a bit like hack, but in fact it is just a different way to understand the component: the component is divided into two parts: Data and view. In theory, a view should be constrained only by whether its logic is cohesive enough, rather than whether its child elements are put together. However, we currently use dom as the basis of the view, so the view is constrained by the html structure, which is unreasonable. Let's use a diagram to compare the scenarios before and after "Scope sharing:

! [] (Http://upload-images.jianshu.io/upload_images/8373224-cddbe4ace31d7d1e.png? ImageMogr2/auto-orient/strip % 7CimageView2/2/w/1240)

Of course, the defect of this solution is that you must know the specific implementation of components. However, this is not an insurmountable defect. Let's take a look at aurelia's design. It designs key parts such as templates into pluggable forms, this structure means that a general template syntax may be implemented in the future to implement the above two functions. In this way, it is no longer coupled with the underlying layer.

** 4. Application Architecture **

The application architecture is too broad. Here we only discuss applications that are well componentized, or applications that are not componentized but have a clear hierarchy. We use the React FLUX as the starting point.

! [] (Http://upload-images.jianshu.io/upload_images/8373224-5b9215333e5428dc.png? ImageMogr2/auto-orient/strip % 7CimageView2/2/w/1240)

Let's take a look at each part with the official facebook FLUX code example:

! [] (Http://upload-images.jianshu.io/upload_images/8373224-a4d8d0fb2c5ff03a.png? ImageMogr2/auto-orient/strip % 7CimageView2/2/w/1240)

When facebook introduced FLUX, his main point was: "MVC is not scalable enough, and FLUX is highly scalable ". For the moment, we will not discuss the differences between FLUX and MVC. Let's first look at how it expands. From the code above, we can see that ACTION is not just generated by click events on the interface, ajax requests and even an initialization process can generate actions. "actions" are just an abstraction. The action will be passed to the dispatcher, and a dispatcher will trigger the store registration callback. You may think that the dispatcher has nothing to do with it. What is the difference between defining a method and directly calling this method when an event is triggered? The difference is that when an application adds features and expands, multiple parts of the application may need to respond to the same action collaboratively, in addition, different coordination parts may have strict order of execution.

> For example

If I want to add a "Statistical block" to TODO, and if it is a traditional MVC method, you may need to add a statisticModel, then add code to createTODO and deleteTODO in the controller to operate the new statisticModel. FLUX does not need to modify any existing code. It only needs to write a new store and register some callbacks to createAction and deleteAction. So it can be seen that the "C active M" in MVC is reversed to "M to determine when to run" (of course, this situation does not have C ), but it is better understood as a "Event System" variant. This is the difference between it and MVC. Strictly speaking, FLUX is not something facebook "invented". Such a model is common in many event-driven backend frameworks, such as [zero] (https://github.com/sskyy/zero), [yii] (http://www.yiiframework.com/), but get the front-end as the application architecture is relatively new.

FLUX is currently a highly recommended application architecture. It does not have a mandatory library or framework, so it is not limited to react and can be freely implemented in angular and polymer. In particular, application development in angular and polymer does not have any best practices for application architecture. Modularity in angular does not have the function of asynchronous loading or scope isolation. It is very useful in actual use. However, the dependency injection, filter, and service in angular are designed comprehensively. If the FLUX architecture can be added, the power should not be underestimated. The situation is simpler for polymer. It should be because polymer currently only takes the element layer into account, so the upper application architecture can be freely implemented.
It is worth adding that the store and dispatcher in FLUX can be enhanced better. Store can use libraries that automatically support REST to simplify development. dispatcher can use advanced event proxies that support custom sequences.

** 5. Summary **

2015 will be a year for the integration of front-end frameworks. With the implementation of webcomponent, everyone is approaching the standard. There is certainly no problem in reserving Technology in advance. Go deep into the technical details of the framework, we can see that in the "rendering mechanism", "Data Binding", "componentization", "modularization", these key technical points, each framework has a wonderful implementation, worthy of in-depth learning. React has emerged, and we recommend that you keep an eye on it. Especially in the "application architecture", FLUX has indeed played an inspiring role throughout the industry. I believe it will become more and more popular and there are more and more implementation methods.