Front End myth and React.js

Tag: Height inf fill subscription number section compare back to technology share line

Front End myth and React.js

The front-end technology has flourished over the years, and this was when a few projects needed to do the front-end technology selection when relevant data were collated and some comments quoted from the community.

Let's go:

• At present, the Web development Technology framework is two types of 80%. This dramatic change lasted for nearly 6 years.
• Since its launch in May 2013, Reactjs has become the backbone of WEB development in the last three years.
  

Any component and frame has its application scenario, we should calmly analyze and weigh, first look at React.js

1 from the perspective of functional development, react is a good idea.
2 from a page design perspective, the traditional html+css and the same idea of the template is better.

Everyone developed the front-end thinking is not the Web page, but application. Most companies are not Facebook, not so many full-stack gurus. The team is good at writing business, not necessarily good at page layout, good at page layout, not necessarily good at writing business. So there will be a division of labor in the team, some people will focus on the implementation of the cool page effect, and react obviously unfriendly to this division of labor.
Why do I need react,why?

We need the technology stack to provide a good modular way, can be a web Component, can be a mechanism of non-web Component, no matter what library or framework, we need technology to give us the ability to complete an abstraction, build, multiplexing, and this process can not be too cumbersome, Can't do a very daily abstract half-day document.
We need data binding, to really implement event-driven on a variety of granularity, because we don't have to repeat our handwriting to automatically update from view to data from data to view, otherwise we have to manipulate the DOM, optimize DOM operations, maintain state, maintain state, It's going to be a vortex of state synchronization, wasting a lot of time and energy.
We need the technology stack to hide the subtle differences in the platform, write a piece of code can really achieve cross-platform, instead of our own entangled in those who should not apply development tangled, we need continuous and stable cross-platform support, the best transplant is not porting, which is of great commercial value.
We need a library or framework to learn, easy to use, from the first day can be rapid development, rather than have to go through a few months of learning curve that, because most of the team's programmer level there is a gradient, we do not want to because a technology stack to the beginner level of people outside the door for a long time, The ideal state is that the technology itself can be completely transparent to the recruitment work, the same duration, the same project, at any time to find people can, recruit when not to write too specific, as long as the JavaScript will be able to quickly get started, we need to concept burden as little as possible technology stack, really understand the simplicity technology.
We want the technology stack to have very good performance, both horizontal and vertical scalability, so we don't have to write half of the project back to the problem of performance that the application development team is hard to solve, and we need a well-balanced tool between rapid development and basic performance, Not because of the tools that emphasize a particular aspect and that are too few on the other.
The tools we need to use have a professional team or community to keep track of, and it's best that these teams and communities themselves put their stuff into production and use it, so at least there's a minimum of risk for us to control it. We don't need those whims, we'll never grow up because we never have the technology to dedicate.
We need techniques that ordinary people like to use and use well.
React satisfies some of the above aspects, does not satisfy other aspects, like other tools. You need react because of two.
First, you fully evaluate your project, understand what the problem you are trying to solve, is the rapid development, performance, ergonomics of the team, and in most cases the problem to be solved is the balance of multiple elements
Second, you fully evaluate the react stack, understand that it is the best tool to solve your specific problem, you really understand the situation of the non-use of react things
If you think react is fast so need, the fact is that react is not so fast, especially for large applications, small applications are not important, and all frameworks are fast enough.
If you think react development is fast so need, the fact is react and must be the best use, especially when you consider the composition of the team.

If you think react is a Facebook developer, my guess is that Facebook may not be able to solve the remaining 1% problems after a community adoption.
If you think react native is very hot so need, this may be a reason, but RN is not the only choice, from all aspects of evaluation, nativescript such a stack is not worse than Rn, perhaps a little better. If it is a big budget commercial development, RN should not even be the first choice.

Most people use two features when using React:

1. Virtual DOM

2. Modular

As for the other pseudo-characteristics, I think some students "a bottle of discontent, half bottle bam", out of the box. These pseudo-attributes include:

1. Cross-platform . Although reactnative can be used on multiple platforms, Reactnative does not encapsulate APIs for different systems. In this respect, the goods are not even Weex.
2. easier to organize logic . This is obviously something Flux/redux does. And Redux has made it clear that not only applies to React, other frameworks can also be used redux. Do we really need two of these features? Virtual DOM

Virtual DOM solves the frequent manipulation of DOM
Performance issues that arise. Then the following facts are bound to lead to a "no Future" feature:

1. The hardware performance of the device is getting better and the performance will no longer be a problem in the future.
2. If we are to solve performance problems, compared to virtual DOM,
The following solutions are better:
1. The browser implements the virtual DOM. And this is the correct scene and posture that the virtual DOM is applied to.
2. Do a diff instead of the virtual DOM based on the location of the data. This is the correct use of Cache/diff. Component of

One important purpose of the component is to improve development efficiency. Do you want to take a look at the high efficiency of using React?

Folk: Want to work overtime with React

In order to illustrate the React development efficiency, it is advisable to open two links to see the number of lines of code. The following two links all implement a chat application, the exact same function:

· React Version: 187 lines

· Riot version: 53 Lines of react deficiencies

purity, immutability and problem-solving ideologies

Don't get me wrong, I really appreciate react's pure function coding and concise rendering, which is a good thing in practical applications. What I want to say is something else.

If you have thousands of development teams in your company and you decide to develop your own syntax for static types in PHP, or if you are moving from Haskell to JS, then a degree of rigor and purity is very useful. But most companies don't have a large-scale development team, and they don't have the same big goals as Facebook. I will explain this in more detail below.

JSX it sucks.

I know it's "just JavaScript with special syntax". Our front-end designers put form elements inside the div in order to make beautiful forms, and they don't care about pure or ES6 at all. Designing react components still takes a lot of time, because the readability of the jsx is poor. Another bad thing is that you can't use normal if statements in your HTML code. React's loyal users will tell you that with ternary operations, there is no need to use conditional judgment. But I assure you that when you read or edit the code again, you will find that they are still a mixture of HTML and JS, even though they can be compiled into pure JS.

<ul>

{Items.map (item =

<li key={item.id}>{item.name}</li>

)}

</ul>

Many developers think this strict restriction can help us write more modular code, because we have to put blocks of code in the tool function and call it in the render () method, as the man suggested:
http://stackoverflow.com/a/38231866/1132016.

Jsx even had to divide 15 lines of HTML code into 3 components, each containing 5 lines of code.

Don't think this will make you a better developer, you just have to do it.

And the truth is this:

If you're developing a relatively complex component, and you're not going to post it to GitHub tomorrow, the above approach will only drag you back, especially if you're going to solve real business problems. But don't get me wrong, I'm not saying it's bad to split into small pieces.

Of course you know that by splitting up, you can improve the manageability and reusability of your code. But only if the business logic entity can be placed in a separate component, instead of splitting it every time a ternary operation code is written! Each time you create a new component, you will have to pay a price for your stream of consciousness, because you need to switch to "management thinking" from the business mindset (you need to add some HTML code to run it when you remember the state of the current component)-you need to create a separate file for this component, and consider how to add attributes to the new component. and to map them to the state of the component, but also to consider how to pass the callback function in, and so on.

You are forced to write code using this overly immature component modularity, which reduces the speed of coding, and the modularity you get from it may not be what you need. In my opinion, immature modularity is no different from immature optimizations.

For me, the readability of the code is very important , but it is also important to be able to derive pleasure from coding. It's not fun to create six components to implement a simple calculator control. In most cases, this is also not conducive to maintenance, modification, or control overhaul, because you have to jump through a lot of files and functions, checking each small block of HTML code individually. Again, I'm not suggesting using monomers, I just recommend using components instead of widgets in everyday development. This is a common-sense problem.

in the React using forms and Redux It's going to make you too busy to stop.

Remember, react is designed to be pure and clean, one-way data streams. That's why Linkedstatemixin is not seen, you need to create 10 functions for 10 inputs, and 80% such functions contain only one line of This.setstate () code, or a redux call at a time (you might also need to create a constant for each input). It may be acceptable to generate the code automatically if you think about it in your mind, but there is no IDE that can provide such a feature.

Why do you want to knock on so much code? Because bidirectional binding is considered unsafe, especially in large applications. I can say for sure that the code readability of bidirectional data streams is really not good, and that angular 1 's two-way binding is worse. But that's not a big problem.

Redux looks more like a wordy pronoun. Developers complained that Mobx turned react into angular because it used two-way bindings--see the 1th before. It seems that a lot of smart people just make their code look purer, but they don't do much more (but if you don't have a deadline, it might not be a big deal).

Excessive tool binding

React is a bit messy. If you leave a whole bunch of npm packages and ES5 compilers, it's impossible to make a react application. A simple application based on react's official basic package development contains about 75MB of JS code in the Node_modules directory.

This is not a big problem, it is more like the JS World, but the use of react will still only increase our frustration. Current status

v15.5.4 April 11, 2017

Facebook is developing a new architecture based on the popular JavaScript framework react. This new design, called react fiber, changes the way and timing for detecting changes, which can improve the responsiveness of browsers and other rendering devices. The new architecture was originally released in July 2016, and it contains the work that Facebook has been improving over the years. The architecture is backwards compatible and completely rewrites the react coordination (reconciliation) algorithm. This procedure can be used to determine when a change occurs and to pass the change to the renderer. Latest News

May 4, 2017, Facebook open source Team technical author Joel Marcey in the Hacker News community published a "Prepack to help improve the efficiency of JavaScript code," causing extensive community discussion.

Officially, Prepack is a tool for optimizing JavaScript source code, which is actually a part of the JavaScript evaluation (partial Evaluator) that can be executed at compile time at runtime. and to improve its execution efficiency by rewriting JavaScript code. Prepack replaces the global code in the JavaScript code package with a simple assignment sequence, eliminating the intermediate calculation process and the operation of the object assignment. For re-initialized code, Prepack can effectively cache the results of JavaScript parsing, optimized for optimal results.

React 16 (under development) is an innovation, but it also uses the same public API. For more than 30,000 Facebook users (! Component, where only a small number of changes are required, and the few components are used primarily by behaviors that are no longer supported or formally documented. Therefore, it can be said that 99.9% compatibility is fully guaranteed. This also makes us convinced that react 16 can basically be applied directly to your code. AngularJS

In the rich application development, with angular completely no ratio, in the same skilled conditions, angular development efficiency = five times times react= three times times backbone= 10 times times jquery, but the virtual DOM does not have any confusion, 21st century, efficiency for the king, Angular Long live, it represents the front-end of the most advanced productivity, represents the front-end advanced culture forward direction, representing the most broad front-end of the fundamental interests, but all the plagiarism angular wheel technology will be the history of the wheel crushed, shattered.

Angular a very clear disadvantage.

-Angular Dependency Injection is ugly, in order to minify also use array to write two times variable name

-Angular module and ES6 module compatibility is not good

-Scope chain can only make people more confused. Controller as has not improved too much.

-Provider, Factory, service is actually the same thing

-Current best practice is that everything on the page is directive, forcing the component (so why not just use react?)

-Intrusive too strong, need to learn a lot angular unique syntax, track by, Transclude, $ Start all variables, scope, promise. HTTP must use the dynamic that it provides

The Angular team announced the release of the 4.0.0 version, which is backwards compatible with most 2.x.x applications. The main changes in 4.0.0 include smaller applications and faster, updated view engines, reduced generated code of nearly 60%, and the introduction of an animation library as part of a pre-built core library. For more information:
Https://angular.cn/blog/angular-400-now-available.html
Https://hackernoon.com/top-8-resources-to-explore-angular-4-ff2c1b42020a?gi=151b442f3045#.3fgnc8ibr

Angular 2 paired with react Native

Angular 2 can be run on the desktop via Angular Electron, or on the mobile device side of the Microsoft UWP, Angular 2 offers options such as ionic 2,nativescript or react Native. For the last one, there is a library that makes it possible to render angular 2 applications with react native. Developers can invoke all react native provided APIs and Polyfill to use the native features of iOS and Android, and then callbacks can be executed in angular zone as needed

React and angular 2 have a lot in common, and they use similar principles in dealing with application frameworks and data. On the other hand, implementations of each feature are used in different ways (the lifecycle of a component invocation is still exactly the same). These differences do not imply the difficulty of application development, each offering a sufficiently sophisticated tool to develop a large, rigorous, and flexible application core.

Of course react is smaller and covers only view/component operations – this is what I want to compare here. The lack of an extension mechanism to HTML is undoubtedly the only disadvantage of react.

Angular2 is more stable, scalable and more complete. But it is still in beta-and has an advantage over the opponent because it has a better idea of merging than the ANGULAR1 or react experience. Vue.js

Vue.js is one of the fastest-growing JS frameworks in 2016, and I think its rise is not due to the excessive popularity of fans, nor to the authority of a big company.

Vue.js The advantages

Vue.js a good balance between readability, maintainability and fun. Vue.js is between react and angular 1, and if you take a closer look at Vue's Guide, you'll find that Vue.js has borrowed a lot of design ideas from other frameworks. Vue.js from react, prop, unidirectional data streams, performance, virtual rendering, and awareness of the importance of state management. Vue.js the template from angular, and gives better syntax, as well as bidirectional data binding (in a single component). Judging from the use of vue.js by our team, Vue.js is easy to use. It does not enforce the use of some kind of compiler, so you can use Vue in legacy code and transform the previously messy jquery code.

Vue.js can work well with HTML and JS. You can develop very complex templates without compromising your focus on the business, and these templates are generally good readability. When the template expands to a great extent, it shows that you've made progress in your business implementation, and you might want to split the template into smaller components. You will have a better grasp of the overall "image" of your application than when the project starts.

This is not the same as in the react: Vue.js saved me a lot of time. In react, you can easily get lost in messy code by splitting components into widgets and micro-functions in the first place. In react, you need to spend a lot of time finishing prop and refactoring the widgets again and again (these components may never be reused), because if you do not, you will not see the direction when you modify the application logic.

It's easy to use forms in Vue. This is when two-way binding comes in handy. Even in complex scenes there will be no problems, but watcher at first glance will remind people of angular 1. When you split components, you often use one-way data streams and callback passes.

If you need to use some of the compiler's features, lint, postcss, and ES6, you'll get what you want. In Vue.js 2, Vue's extended features will be the default way to develop common components. By the way, the out-of-the-box component CSS looks like a good thing, and they can reduce the dependency on CSS hierarchy naming and Bem.

The core of Vue.js has a simple and effective State and prop management mechanism, and its data () and props () methods can work effectively in practice. A better separation of concerns can be achieved through VUEX (it is somewhat similar to the MOBX in react, and includes some mutable states).

Most vue.js scenarios do not require VUEX-provided state management, but a choice is not always a bad thing.

Vue.js the deficiencies

1. One of the biggest problems: the run-time error description of the template is not intuitive, which is a bit similar to angular 1. Vue.js provides a number of useful warning messages for the JS code, such as when you try to change prop or improperly use the data () method, it gives a warning. This is also from the react reference to come from the relatively good aspect. However, the run-time error handling of the template is still a weakness of Vue, and its exception stack information always points to the internal method of Vue.js, which is not intuitive enough.

2. The framework is still very young and there are no stable community components. Most of the components are created for Vue.js 1, and it is sometimes difficult for novices to differentiate their versions. But you can do a lot of things in Vue without using other third-party libraries, you might need some Ajax libraries (if you don't care about homogeneous applications, you can consider Vue-resource) or vue-router, which balances Vue's shortcomings in terms of components to some extent.

3. It is not surprising that the code in the Community software package has many Chinese comments, because vue.js is popular in China (its author is a Chinese).

4. Vue.js is a project maintained by a single person, which is not a big problem, but there are other factors to consider. Yu Yuxi is the author of Vue, who worked at Google and Meteor, after which he created Vue. Laravel was once a single-player project, but then it was a success, but who knows? Comparison

5 best JAVASCRIPT frameworks in 2017

https://www.dunebook.com/5-best-javascript-frameworks-to-learn-in-2017/
https://da-14.com/blog/5-best-javascript-frameworks-2017

React vs Angular 2:comparison Guide for Beginners

https://www.codementor.io/codementorteam/react-vs-angular-2-comparison-beginners-guide-lvz5710ha

Comparison of official vue.js with other frameworks

Http://cn.vuejs.org/v2/guide/comparison.html

· The difference between react:react and angular & Ember is its limited application scope and space occupancy. Angular & Ember is the framework, and react is primarily as an application "view". React does not include dependency injection or "service" support, does not require "jq-lite", and does not rely on jquery. Developers can write tags directly using jsx without ember handlebars. React maintains a "virtual dom" and updates the real DOM with it, avoiding unnecessary rearrangement and redrawing. In short, he is very fond of react the use of this relatively exclusive characteristics. Moreover, react allows him to cut down complex applications into smaller components.

· Falcor: This is an open source, very new library by Netflix. Unlike the traditional rest API, it provides only one endpoint. With it, developers no longer need to request different data from different server endpoints, but instead request different model data to the same endpoint. The server side can identify the request parameters and invoke the appropriate router function by Falcor router. In other words, Falcor provides a more intuitive API, which is the developer's data model. This ensures that the server never returns unnecessary model data, saving bandwidth. Falcor clients can also use cached data to serve continuous requests, reducing server response times. To learn more about Falcor, you can view videos of Jafar Husain.

· Webpack: As a module binder, Webpack can provide further support for react component modularity. It makes it easy for developers to compress and connect CSS and JavaScript, and make debugging work much easier by generating a source map. When the configuration is complete, Webpack monitors the code, and each time the code changes, it generates a new bundles. The client does not need to import a large number of CSS or JS files, but only imports bundles, reducing the number of HTTP requests when the page loads. In addition, Webpack provides a number of plug-ins, for example, using Jsx-loader to convert JSX to JavaScript, using Babel-loader to convert ES6 code into code compatible with ES5.

· Es6:ecmascript 2016, the latest specification for JavaScript, defines a number of important new features, such as FAT arrow functions, classes, string interpolation, block scopes, and so on. For more information, see the ECMAScript 6 Reference guide on the Mozilla Developer network. Web development should not be so complicated

The design team of the system is bound by its production system, and the production system is decided according to the communication structure of the design team.

---- Conway's Law

The law of Conway says that the structure of a software product is an image of the organizational structure of its creative team.

The client-side rendering framework we're using, from Google and Facebook, has thousands of developers, two of whom are affiliated with dozens of teams, and the organizational structure is like this:

The problems your team faces are likely to be different from what Google and Facebook face. When we use those client frameworks, we're chasing performance, and every decision we make is right, but together we look at the results and we get a tiny performance boost that costs a lot of engineering. If we go further down this road, the road will become narrower. Development website

To say now with react do site setup cumbersome? Of course, to set up the eslint,babel,webpack, with boilerplate eventually still want to understand the different things are doing, but these blame react is not too appropriate, after all, the entire front-end ecosystem has evolved. With angular 2 or ember, you still have to use this. React the cumbersome basic are on the Redux, Creatstore also have to join middleware also need to connect to the store, and bring the concept of high-level formation is not easy to understand.
React has its own shortcomings, after all, where do we find the perfect thing? Boilerplate too much, setstate is asynchronous, context API very pit Dad, server side render various pits (set HMR, which call is done on the server, which can only be run in the browser, etc.), Animation There is no such a good plan now.

But is react worth it? Of course it's worth it, it gives you a modular page, an introductory function, a clear unidirectional data stream (dispatch (action)->reducer->render), and a deep compensability of high-level components, can find selector and reducer In fact also compostable, shun with the use of various tools (Eslint, Babel, Webpack), careless can also into the elm and Clojurescript pit.
There is also a frequently mentioned benefit is react redux do the site, refactoring is very convenient, in the ever-constant demand of the world is also a big advantage.

On the question of react, there are several points to be said:
1, react does have the performance problem of component nesting, but can be decoupled by redux to achieve the goal
2, for most of the introduction of Immutable/reselect is not a necessity, the finer the granularity of the component, the less the state uses, the less the need to introduce shouldcomponentupdate, in fact, in the project really useful to them how much?
3, react the application of large and medium-sized projects is not too big problem, the domestic ant.design has been in a large number of ant financial platform and or various internal platform use, although Vue also has, but only experimental version, also did not go to upgrade. Abroad: Is Facebook a big app? It has already applied the React version of Alpha, in order to test the pit, so that is React in large applications have problems?
4, react is a threshold, and indeed no mv** so quickly easy to accept, need to have a certain JS foundation and development experience. Front-end separation

We are not suitable for the separation of the front and back, why? Because

1. The addition of an intermediate layer (of course programmers to solve problems by adding an intermediate layer) has the advantage of having a clear mandate; but there are disadvantages: artificially stretched the front. In contrast to figure I and figure three, you will find that the structure becomes more complex, and one can do things that require two people to do.

2. There is no real change. The previous backend structure was also called Service logic, and now it's just for the front end to be done with node. js. I didn't see any promotion except to put a tight front-end manpower in a field he was not good at. The only advantage here is that the front-end is expanding the sphere of influence.

Identity is " All-stack engineer ". Why should a business be divided between two people? Take the form submission as an example, the backend to verify the data, the front-end to do. Why should I have two people write it once? The front end says you can let the backend also write node. js, so you can take the code. The backend wrote Java for three years. You're telling him to start all over again? The back end is certainly reluctant. Contradictions are in the "back-end" and "front-end" of the two positions. It is understandable that large companies subdivide the backend and the front end.

The disadvantages of front-end separation:

1. Most sites should not be divided into front and back. Unless your front end is very, very, very complex. But most of the site's front end, is not so complex!
2. The front and back ends are prone to fragmented situations. Blame, credit, despise each other, not listed.
3. Someone asked a person how to learn back end and learn the front end? My advice is to make the front-end thin, if not necessary, do not engage in what Angular, React. Use native JS or jQuery to satisfy most websites. At the same time back-end to Rails learning. Where local interactions are complex, dynamic loading is used to interact.
4. Some people say you are the front-end traitor, you do so the front-end there is no future.

In fact, the real theme is: The front and rear end of the separation is not the inevitable end.

Is it not good to split back and forth?
There is only one benefit: good recruiting. After all, it is extremely difficult for you to recruit a good full stack engineer.

Ideas

1. Keeping the front end simple and complex is packaged in a native way, specifically to encapsulate complex components with custom tags. In this way, back-end colleagues can still develop the page, because it is only a custom label, the essence or HTML
2. Try not to add watcher in the development state, the purpose is to let the backend can be used directly, do not need to know so many tools. Translation is done in the developer mode of the WEB framework, and it is not difficult or complicated to see less requests escaping into CSS.
3. The front end is only auxiliary (this is mostly web site, not including heavy-duty Web applications), the front-end to be good service: a sound document, a friendly interface.
4. The front end also need to learn back-end knowledge, not in that self-hi.
5. Small companies do not engage in the separation of the front and back, the increase of complexity! Unit Test

After the front-end separation, it means that more business logic will be incorporated into the front-end program, corresponding to the need for front-end engineers to complete the corresponding business logic unit testing to ensure that the front-end quality will not gradually fall.

• JavaScript-based unit testing proved to be an efficient test method in which 71% of organizations performed JavaScript unit tests, while 84% of organizations believed it was beneficial!
• Jasmine and Mocha are the most popular JavaScript unit test frameworks, Jasmine primarily with AngularJS for unit testing, while Mocha is used in conjunction with REACTJS.

The current front-end Automation unit Test Community Situation:

Jasmine & Protractor (72.4%),

Jasmine & Karma (67.7%),

Jasmine & Jest (58.3%),

Karma & Protractor (58.6%).

Service side

Component is one of our infrastructure, the service side (. NET, Java) also want to do more common components. But often the project or product development cycle is tight, and some organizations do not have enough time to develop generic components. Weigh

When we are more, we should think about the balance and the optimal combination:

Under what circumstances should the background render, and under what circumstances should the foreground render.
Under what circumstances should use Html+css control page, under what circumstances should use JS control page.

The so-called "page component" in React.js does not refer to a checkbox, or a fine-grained component such as input, which can be understood to be more granular in the encapsulation of a "single page area of functionality". While a checkbox is also required to encapsulate components, it is finer grained controls, and the React.js component concept is not a level. It is better to use jquery instead of using react rather than with other classes of libraries to be dead.

The demand for engineering is also much higher than in previous years, last year I used grunt, later with Gulp, then Browserify came, 2016 with Webpack,babel, tool replacement means that the development experience is also getting better. In addition JSX is not HTML,JSX not html,jsx not HTML.

React satisfies some of the above aspects, does not satisfy other aspects, like other tools. You need react because of two.

First, you fully evaluate your project, understand what the problem you are trying to solve, is the rapid development, performance, team ergonomics, in most cases to solve the problem is the balance of multiple elements

Second, you fully evaluate the react stack, understand that it is the best tool to solve your specific problem, you really understand the situation of the non-use of react things
Just a Marketing promotion page, only a carousel, a few text boxes of the form of very shallow interaction, I still recommend the use of native/Zepto/jquery stream. If you care about the volume, the network Environment (2G/3G), and so on, you can use server-side rendering or non-blocking UI (that is, add placeholders), using a cdn,react with gzip can absolutely within 100K, if exceeded, we recommend that you use on-demand loading. I believe your server should be adding caches such as 304/etag.

For medium to large projects, react is indeed a good choice, and of course you can try Vue to iterate over small and medium projects. Flux/reflux/redux is not only used in react, but also in vue/angular and other frameworks, just a data flow idea that you selectively use.

For large projects, Webpack is recommended to build the business code, Rollup to pack your small wheels. Use RX to optimize your data flow. Typescript strong your code to improve your development efficiency (the first week may be a bit painful). But after that, the gains are very high. For small-to-medium projects, recommend React/redux/react-router to build your code summary

because there is no perfect frame, only suitable for the application scenario, choose our own more suitable.
Frameworks are simply designed to be efficient and organize project code well , not entirely for performance. Note that the IT era is changing, any technology will evolve, whatever exists, is reasonable.
Service-side research and development engineers also have few full-stack engineers . React.js is suitable for long-term, user experience high interaction with many projects or information systems products.

--------------------------------------------------------------------------------------------------------------- -----------------------------

Come here today, I hope to you in the team management, project management, product management, system architecture has a reference role, you may be interested in the article:
Front-end Engineer Skills Finishing
Lean IT organization and shared leadership
The myth of enterprise Informationization and software engineering
Introduction of enterprise project management
Elements of success in software projects
A brief introduction to interpersonal communication style
Lean IT organization and shared leadership
Learning Organization and Enterprise
Enterprise innovation culture and grade concept
Organizational goals and personal goals
Recruitment and management of start-up companies
Talent company environment and corporate culture
Corporate culture, team culture and knowledge sharing
High-Performance Team building
Project Management Communication Plan
Build efficient research and development and automated operation and maintenance
Practice of a large-scale electric clouds platform
Design ideas of Internet database architecture
IT Infrastructure planning scenario one (network system planning)
Customer analysis process for catering industry solutions
Purchasing strategy formulation and implementation process for catering industry solutions
Business design process for catering industry solutions
Supply Chain Demand Research checklist
Evolution of real-time measurement system of enterprise application performance

If you want to know more software design and architecture, system it, Enterprise Informatization, team management information, please follow my subscription number:

Petter Liu
Source: http://www.cnblogs.com/wintersun/
This article is copyright to the author and the blog Park, Welcome to reprint, but without the consent of the author must retain this paragraph, and in the article page obvious location to the original link, otherwise reserves the right to pursue legal responsibility.
The article was also published in my Independent blog-petter Liu blog.

Front End myth and React.js