Comparison between Reactjs and domcom--where is domcom?

After many years of JQuery's dominance of front-end JavaScript designed by John Resig, the heavyweight angularjs introduced by Google has brought a huge conceptual change to front-end development, giving a refreshing feel, while also driving the concept, technology, and framework of the front-end into fast iterations, A flourishing situation. Superseding, Angularjs is still on the top of the waves, Facebook launched the Reactjs and rise, again to the front-end Web application development ideas to bring a huge change, subversion of a lot of just become fashion concept. However, Reactjs still has a lot of problems, and domcom did it to simplify, become a very concise and elegant framework, can greatly improve the development efficiency.

Why Reactjs can rise after angular?

In pursuit of these traces of evolution, Qkxue.net concludes that JavaScript is increasingly even greater role from behind the scenes in front-end development, eventually replacing HTML as director and starring, occupying the center of the stage. Jquery,angularjs and Reactjs not only embody and promote this trend, but also represent the different stages of technological development and the constant evolution of ideas.

Why Reactjs can from the peak state Angularjs hand grab class seize power, smooth upper? One is because angularjs in the technical level there are some obvious shortcomings, reflected in the concept of more complex, learning curve steep 1, the combination of expansion capacity is not good enough, data transmission and management is not enough convenient and so on. More importantly, although ANGULARJS LED and promoted the concept of the front-end evolution, represents the trend of technological development, but also quickly reflected in the concept of evolution and development trend of the side. ANGULARJS Advocates single page application (SPA), attaching importance to data binding. From the perspective of progress, it is explained that Angularjs has begun to view Web front-end development as software application development, but the term single page indicates that it is a page-based concept. The idea of data binding also shows that the subject of application is a page-oriented data presentation and interaction. Therefore it is still in the technical design with HTML as dominant. Although JavaScript is the way the framework is implemented, the overall design intent of the framework is to point to the ability to extend HTML.

At the beginning of the ANGULARJS, the technical trend is quite consistent with the above state. At that time, the Web front-end development is mainly for the desktop large screen, basically a page-based Web site, providing more or less, or static or dynamic information services, for such demand ANGULARJS provides a very high-end solution. However, the Internet quickly moved to the mobile era. A new generation of Web front-end development is increasingly like a desktop system, with a more user-friendly experience, more task-oriented, and less information-oriented, so more different interface elements are needed to accomplish more complex interactions. In other words, the Web front end has now shifted to designing a web-oriented graphical user interface (GUI) for users of different sizes, while the central concept of GUI applications is widgets, not pages. This determines that Angularjs (1.x) will usher in a replacement, Reactjs is the wave of the stars stand out.

React's selling point and pain points

There are many articles on the principle and implementation of react. For example, 2, 3, 4, 5, 6 have some basic introduction. Articles about react learning skills are all over the web. This article does not make a special introduction to these, only talk about the selling point of react and pain points.

According to my understanding of the principle and realization of react, the current web front-end react development practice observation, I think react's selling point and pain points are reflected in the following aspects:

Selling

More inclined to JavaScript
Previous JavaScript libraries, including Angularjs, were based on HTML. If you use these libraries like a ballet dancer, then using Reactjs is like a modern dance, the whole picture is completely different, and the programmer is more free and creative. Although the react code has JSX code that looks like HTML, JSX is actually not really html, it's just a disguised JavaScript code. This is completely different from JQUERY,ANGULARJS and its similar framework, EMBERJS (requires handlebar template).
Modular programming
React is the first framework to view the development of Web front-end with component thinking as a whole. Unlike the jquery plugin, which is different from the angular directive, the react component integrates the data, UI, and interaction. This model gives us a new way of thinking about the application structure.
Facilitates code reuse
Reactjs's flexible component combination capabilities greatly enhance the ability to reuse code. Angularjs as a chatty framework, the reuse of code is very inconvenient due to design flaws. The granularity and probability of REACTJS code reuse is increased.
Virtual DOM
Because of the DOM features, virtual DOM can enhance performance in many situations. Of course, this is not absolute.
Pain Point

Ugly Jsx.
The purpose of supporting JSX is to attract traditional page designers to take care of traditional HTML-based page development practices. However, from the programmer's point of view, two different styles of code mixed together is ugly, but also does not conform to the pure programming language habits. This is a passive compromise in the face of historical tradition, rather than a proactive choice to adapt to future trends.
Not supporting OOP is a major impediment to higher-level code reuse
Many well-known GUI frameworks are based on OOP, none of which provides a practical class hierarchy, such as Mfc,wpf,qt,wxwidgets, Android Ui,cocoa, and so on. Many people have spared no effort in promoting Reactjs to belittle OOP and to function-type programming. In my opinion, this is a whitewash of reactjs design flaws. Functional programming has its proper application scenario, while the state-dominated web and GUI are not their forte. If this area must be incorporated into functional programming style, it is only fits, dancing with shackles. Because of the design bias caused by this kind of thinking, react had to use a number of special techniques to deal with scenarios that were suitable for OOP, such as Mixins (who later discovered mixins problems and began persuading people not to use mixin), high-level components, and so on.
The tedious API
It may be that the designer's coding style preferences, the Reactjs API seems quite cumbersome. The more obvious aspects include the naming of life cycle methods (Componentwillmount,componentdidmount,componentwillreceiveprops,shouldcomponentupdate, Componentdidupdate
Componentwillunmount,componentdidunmount), gets the method of the DOM node, about the design of refs, the binding of event methods, and so on.
Someone may not be very sensitive about this, or think the IDE can solve it. However, if you can design a cleaner API and rely less on tools, it's always better. In my opinion, a simple design is a beautiful design. jquery can be seen as a clear testimony to this. Why do people like to use jquery? The main reason, of course, is that jquery solves the transplant nightmare and offers some programmers the ability to welcome it, but there is no doubt that its simple and elegant API design is a selling point. Conversely, the native API is unpopular, and beyond the portability issue, there is no denying that a lengthy and difficult-to-remember name is a hindrance.
The pain of Renewal
React updates to components are based on a top-down scenario. The component initially obtains the initial props and Getinitialstate, however the sub-components that need to be updated are determined by the comparison of state when subsequent calls to SetState. The child component is not updated by default when the discovery state does not change. Therefore, when subcomponents occur that are not included in the upper-level component state management changes, or if a variable data structure is used, it can cause the loss of the update that should have occurred. The flaw in bridging this design is one of the reasons why react advocates the use of immutable data structures, globally, and centrally. Unfortunately, I see react advocates never mention this aspect of the real reason, instead whitewash, say what global data is better than local data, the global state is better than the local state. In fact, from good programming practice, State localization, private, encapsulation is a better style. Otherwise, it is impossible to understand why the various languages to provide modular mechanism, to promote the use of less global variables, global State, multi-function with no side effects, and can not understand the long-lasting javascript to solve the modular process.
React Family Bucket
Angularjs has a complicated concept and a steep learning curve. Reactjs has the pain of pairing. Because Reactjs design deficiencies, resulting in react must use JSX syntax, as far as possible to use immutable data, favor so-called unidirectional data flow, resulting in the use of good reactjs must also be paired with the JSX compiler (Babel), supporting the external library of flux mode (flux/reflux/ Redux), some scenes also need to use IMMUTABLEJS, these combinations are called react family barrels. There is no doubt that the family bucket brings unnecessary burdens to learning. Instead of being forced by the framework to select a set of libraries, programmers should pick a library of matches based on the application and domain requirements.
Diff type Virtual DOM performance flaw
At present, the mainstream virtual DOM methods are similar to Reactjs methods (such as the Virtual-dom Library). This approach is to place the generated component's internal structure code in the Render method. Therefore, the entire application will need to regenerate the entire application's component hierarchy tree and perform the diff algorithm each time it is render. Although it is theoretically possible to remove the entire DOM tree from the DOM and regenerate the new DOM tree, this is inappropriate for both user experience and performance. It is therefore necessary to compare the current generated component hierarchy tree with the direct differences in the previous cache component hierarchy tree each time you render, looking for an optimized solution. While the time complexity of the optimal solution algorithm for this comparison and substitution problem is O (N3), the current solution for Reactjs and similar libraries is simplified based on certain assumptions and, in most cases, very good performance, which is REAC so-called modulation (reconciliation) scheme. However, this scenario has a performance burden: First, there is still a considerable number of diff operations, there may be some unnecessary DOM operation, the third is the need for more manual intervention, such as through the shouldcomponentupdate and key key.
At the beginning of a framework design, there is always some limitations, and some problems may be considered while ignoring the other. As a framework designer and promoter, in order to dispel people's concerns, attract more users, expand the community, in the propaganda of the framework to make some whitewash is understandable. However, as a framework of the selection and users should not be the same, but should try to distinguish between facts and advertising, to differentiate between right and wrong; As a user, this can also help to better use the framework, with its director, to avoid its short. The pain point of the above Reactjs, some performance is very obvious. But because of the frame design promoter's whitewash, many specious conclusion unexpectedly all men say, presenting illegal weapons, becomes the Web front-end development mainstream viewpoint. Sometimes, of course, there are some accusations and complaints about these pain points, but there is always a lot of criticism from the public who have been fooled by propaganda. This is a very regrettable thing, and there are some obstacles to the development of this field.

Domcom Solutions

No JSX, More concise code
In the mode of using JavaScript widgets, the current web front end has been transferred to the time when the programmer controls the entire interface. So domcom in the API design is completely inclined to programmers rather than the habit of the page designer, the purpose is to ensure that even without XML-like template language can write a simple and elegant program, to avoid the ugly code of mixed jsx. The existing Domcom API fully achieves this goal. Whether it's using coffee-script, or native JavaScript (although ES6 is better, even ES5 is feasible), domcom app code is more concise than JSX Reactjs.
Encourage functional programming and embrace OOP
Unlike react, which can inherit only the Component class (class X extends Component, or React.createclass ({})), all parts are flat to each other and cannot form an inheritance hierarchy. The need to reuse common code requires the help of mixin or higher-order components. Domcom itself has provided a set of Lean base class hierarchies, on which the user program can continue to expand in a way that inherits from the class. For example, you can use tag > Button > ImageButton to let subclasses reuse the code of the parent class, rather than Reactjs the expedient method of using mixin or higher-order components.
Simple API, easy to learn and easy to use
Domcom to design the API as concise as possible, using a short name, most methods and functions require only 0-2 parameters. This is very helpful for learning and using. For example, the common methods of tag components draw on the jquery API, including Prop,attr, CSS, show, hide, bind, unbind and so on.
Flexible and robust update scheme, more convenient to expand
All parts in the domcom contain data members that identify the validity of the part and provide the effectiveness of the API's bottom-up control component. The system itself has completely realized the failure management of the parts, and the user program does not need to intervene explicitly. Most of the time, when you need more optimized performance, just use a more appropriate response function. At the same time, the system allows the development of different update scenarios using this effectiveness management mechanism and the API provided. Examples of this can be referred to nullabletagmixin.
Domcom don't need a family bucket.
Domcom is designed to embrace the features of the JavaScript language, not hostile to JavaScript's inherent features. Therefore, domcom does not force you to use Babel because of the demand of JSX, and does not motivate you to learn immutablejs because of the need for immutable data, and does not motivate you to use flux/reflux/redux because of the global data requirements. Domcom is a self-sufficient framework like jquery, you just have to include domcom.js in the page, or you can import the Domcom module and use the API under the DC namespace. With domcom, you can focus on your business needs by not driving you to a family bucket because of the frame.
A more appropriate virtual DOM scheme to avoid the performance flaws of the diff-type virtual dom
As mentioned earlier, Reactjs puts the component internal structure declaration process into the render method. In fact, we can completely avoid the problem of diff two Trees simply by moving the declaration process of the internal structure from the Render method forward to the constructor. This scheme is more reasonable, natural, more declarative, easier to manage the DOM nodes of the widgets, reduce the creation/loading/unloading of Dom subtrees, and achieve better performance.
Conclusion

To sum up, domcom is a react concept of the Web front-end framework, but also in the concept, design and implementation of a step forward to make up for the shortcomings of the react. It stands on the shoulders of giants, to the complexity of Jane, pupil surpasses, the overall is a better choice.

Talking is cheap, show me the code. Talk less, put the code over. The following two articles compare one to two frameworks from the instance code level: 1. React with domcom – comment box tutorial, 2. React with domcom – some code comparisons.

Comparison between Reactjs and domcom--where is domcom?