Shulou(Shulou.com)06/01 Report--

This article mainly introduces "how to correctly select the front-end framework of the website". In the daily operation, I believe that many people have doubts about how to correctly select the front-end framework of the website. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts of "how to correctly select the front-end framework of the website". Next, please follow the editor to study!

With the continuous innovation of the front-end framework, many IT enterprises are faced with the choice of "how to choose the framework" and "whether they need to reinvent the wheel". Szeto Zhengmei, the front-end architect of Qunar Network, analyzes the advantages and disadvantages and applicable scenarios of the main popular frameworks, and gives the corresponding front-end technology selection schemes for companies and projects of different sizes.

In recent years, front-end technology has developed rapidly, and a mainstream framework has emerged almost every year. Every time you open a new line of business or start a new project, the first thing to do is to struggle: what frame to use and what wheels to recreate?

RequireJS, a watershed in the development of front-end technology

Five or six years ago, before the rise of mobile, we had no choice but jQuery. Some people will say that jQuery is only a class library, not a framework; but at that time, the front-end business was not as onerous as it is today, and all the things that were originally done at the back end were moved to the front end, because jQuery alone could dominate the world. JQuery is not enough, and there are thousands of jQuery plug-ins. So the problem arises one by one: there are too many jQuery plug-ins on one page and too many requests, so we have to package them. Packaging requires us to have a plan for the plug-in. As a result, this requirement has gradually formed some rules in the community, the most famous of which is the AMD specification, which is reflected in the RequireJS add-on library.

RequireJS is a watershed in the development of front-end technology. JavaScript did not have its own loading mechanism before ES6, and the emergence of RequireJS means that the front end can develop on a larger scale. In the future, when I talk about technology selection, a very important screening point is whether there is a loader mechanism or conforms to a certain module specification.

The selection of the front-end framework should take into account the framework itself and the team situation.

Back to the original topic, choose the framework from two aspects, one is to look at the ability of the framework, and the other is to see the ability of your team.

From the perspective of the framework, we consider whether it has rich functions, how active the community is, how active the domestic community is (some are popular abroad, but only the marginal projects of start-ups or some large companies are testing the waters), whether the documents are complete, whether they are updated in time, how the test coverage is, and how easy it is to get started. However, the foreign framework that can enter our field of vision is basically a leader in a world where wheels are flourishing through many battles. JQuery, Angular, KnockOut, Emberjs, Polymer, React, Backbone, Zepto, we basically revolve around these. Of course, there are larger things, such as EXT, YUI, Dojo, EasyUI, Bootstrap, which are at the UI library level.

The following is a purely technical assessment of the 12 popular JavasScript MVC frameworks by foreign countries in 2012:

Obviously, our first step is to delineate the most popular frameworks and libraries for evaluation, and then screen them according to the situation of our own company. Is your company a construction company or a company with its own products? If it is a site-building company, the page will not be so complex, basically jQuery+Bootstrap is done, do not think too much, it is them. If you have your own products, to maintain a lot of customer data, to deal with customers, it is not difficult to imagine the existence of a very complex CRM system, according to Chinese characteristics, this thing will only become more and more complex, which should be carefully considered. This is often a maintenance upgrade that lasts for a decade, and we need to see if a framework is as long-lived as your product, and whether the update of the framework is frequent and smooth.

Big projects should avoid Google products as much as possible

If your project is a big project with a span of more than three years, 90% is a tar pit in the term "man-moon myth". We need to use more robust and mature technical solutions, we need to focus on avoiding Google's products, many of its products are ticket-playing, GWT, Closure, Darty is a lesson from the past. Polymer is built on many new technologies, of which Object.observe (), Custom Elements, HTML Imports, Shadow DOM, and Model-Driven Views are far from standardized, many of which are exclusive and variable, which is why the tragedy shown in the following figure occurs. Angular is not I hack it, this thing also likes cliff upgrade, it is compatible with IE6-8 at 1.08, it needs to be patched compatible with old IE,1.3 at 1.2, abandoned the compatibility with old IE, and directly deleted all compatible code from the source code, so all patches are powerless, and do not support global Ctrl functions, many modules need to be referenced independently, 1.4 does not support animation modules. 2.0 is built from at to ts. Due to the use of Object.observe (), IE6-11 Chrome 30 is not supported.

EXT, EasyUI,avalon and other excellent domestic frameworks can be considered in the background system, which is also worth considering.

If your product is a background system, you have two options: use major UI library solutions such as EXT and EasyUI, where EXT is so exclusive that it is difficult to use with other front-end solutions. What module organization, packaging, data visualization, it has all been able to help you. It is well documented and moderately difficult to get started, but it requires your team to be very stable, so it is difficult to recruit a full-time EXT front end. EasyUI is a relatively big domestic UI framework, although closed source, but it is not difficult to expand it.

In addition, the domestic Taobao Kissy, NetEase Nej is also good. There is a lighter solution: MVVM. MVVM is best at making these interactive products. For example, in order to develop a variety of huge behemoths such as DataGrid, jqGrid, and FlexiGrid corresponding to the complex interactive Gird,jQuery community, it is not as crisp and scalable as several circular bindings of MVVM. Currently, KnockOut, Emberjs, Angular, and avalon, which I wrote, are such frameworks. Angular is a bit of a pitfall, but if you use it from 1.3 and don't care about IE, it's still a good choice, and its active community brings unlimited possibilities. KnockOut is very popular among .net people. Microsoft is the ancestor of the front-end MVVM framework, but it needs to do too much processing on the back-end data because it itself does not support the binding of nested objects. Emberjs does not have a good godfather, but has a good biological father. The author Yehuda Katz is the core member of such famous frameworks as jQuery, Rails, SprouteCore, Merb and Handlebars. Tiger father has no dog son, and Emberjs is now the second largest MVVM framework abroad. Avalon is more suitable for the national conditions of MVVM, it is specially compatible with the IE6 version, easy to use, high performance, many video tutorials, if something goes wrong, you can catch the author, which is its major selling point.

Heavy SEO products, jQuery+Bootstrap+RequireJS combination can be considered

If your product is a repeat product like this in the mall, there will be requirements for SEO, and MVVM will not be suitable. At present, only Angular and avalon are working on the back-end rendering mechanism, but they are not on the table yet. JQuery+Bootstrap+RequireJS is very easy to use at this time. The role of RequireJS is not only to provide an on-demand loading mechanism, it also allows us to organize larger code. If RequireJS is not used, another domestic option is SeaJS, and its specification is CMD. There is also the CommonJS specification, which cannot be run directly on the front end and needs to be merged with build tools such as fekit, FIS, and Webpack. In any case, the framework you choose at this time must have either AMD, CMD, or CommonJS loading specification, which makes it easier for you to scale out later. As for plug-ins, widgets tend to use UMD, which can be loaded by any kind of loader such as AMD, CMD, or CommonJS.

The mobile technology is confusing and needs a multi-pronged approach.

If your product is mobile, it is basically SPA architecture, because this will reduce the number of waits, full page refreshes and requests. At present, this field is very chaotic, unlike the PC side, there are N times more compatible browsers, and for the sake of performance, browser vendors hack functions or change some browser features, which often lead to some strange BUG. At present, the community is sorting out these holes and antidotes. But at present, there is no framework that can solve all the problems, and a multi-pronged approach is needed. My opinion is:

RequireJS (load on demand, can not be packaged on mobile, make good use of 304cache. Tencent has come up with a more awesome incremental update loader MT, or you can try it) + Backbone (organization code and route management) + Zepto (lightweight DOM operation) + fastclick.js (click penetration and delay processing) + Hammer.js (various touch screen events) + iScroll5.js (scroll bar processing) + Animate.css (CSS3 animation) + Enquire.js (handling responsive layout).

It can be seen that every part of the mobile end is rotten to the core, and each part needs special tools to repair. Mobile is very experience-oriented, there are all kinds of animations in every small corner, but the browser or its own WebView is very bad, so the topic of Native and Hybird has been so hot. Some people say that since DOM is the most performance-hungry, let's just use Canvas instead (see http://zhuanlan.zhihu.com/FrontendMagazine/19967854 and http://www.ruanyifeng.com/blog/2015/02/future-of-dom.html). Facebook has launched its own similar scheme, React Native, and has implemented its own set of GUI, but the writing language is JavaScript. It is implemented using its original ultra-high performance wheel React. This may be a road. But the advantages and disadvantages are also obvious, just like Angular's strong Java style, React inserts a large segment markup language (JSX) into the logic. At the same time, React is also very exclusive, so it is difficult to use with other libraries. At the same time, we can see that jQuery Mobile, from a famous jQuery family, was not shortlisted, and the performance was so bad that it was not even as good as Sencha Touch. The above is only the core library, and has not been moved out of the UI library yet. There are not a few UI libraries known as Mobile First, and you can use CSS3 boldly because you ignore IE. At present, the outstanding ones are Foundation, Semantic,Refill and Ratchet. If you just want to run on the tablet, the performance problem will not be so tight. We can also try inoic, Sencha Touch, Kendo UI Mobile...

There is no best, choose what suits you best.

Basically, I've listed some mainstream frameworks for each platform, but that doesn't mean you can handle it. The pony passed the horse, the old cow was below the knee, and the squirrel drowned half to death. That's what it was all about. Startups like the new framework because they can afford to hire one or two front-end guys, and they do almost all the pages, so there's no difference between using Angular or Ember. Small companies are careful, there is a large turnover, and jQuery+RequireJS is a panacea. Large companies basically have their own technological precipitation, in other words, they should have their own front-end framework, unless it is too old to recommend reinventing wheels. The advice for large companies is to set up their own technical committees and select the framework according to their own staffing. There is a good saying, not the best, but the most appropriate. Some frames belong to the fierce people in the hands of the fierce sparkle, two people in the hands of a mess. For some medium-sized companies that are growing especially fast, this is the most important thing to guard against. There are awesome people, but 70% of the main body of the operation is newly trained interns, which is difficult to use, and frameworks with incomplete Chinese documents must be filtered out. I also do not rule out the possibility of building wheels, after all, some companies are full of talent, can launch some reliable open source products to benefit the community.

But no matter what frame we choose or decide to build our own wheels, don't forget that technology must make our working lives easier and happier-we only choose the framework we can control, and we can't guarantee whether it will be out of date in a year's time, but at least it won't become a stumbling block. To paraphrase Adam Smith (taxation is a necessary evil), framework is a necessary evil, it is strongly constrained, so it must be chosen carefully.

At this point, the study on "how to correctly select the front-end framework of the website" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.