will start a new project, the whole station front-end architecture to start to conceive, thanks to the previous Yahoo relationship some or success or failure of the practice summary, or should start from the architecture level, to solve some front-end team development problems. Today there are a variety of JS libraries and frameworks, but the library and the framework are very different, first of all, "library" is a collection of widgets, characterized by easy to use simple, reference examples only need to refer to a script tag to the page, plus some simple similar a.start ( config), and the framework is the site's tree-like structure of abstraction, including module relationships, the dependencies between functions, the order of the entry, as well as the performance of the hack and so on, fortunately Ali or very wise chose Yui as its front-end structure of the bottom, Just because of YUI2 's powerful and rich widget library, most people think that Yui2 is more of a library than a frame, and Yui2 's Yuiloader is just an optional module, which dilutes Yui2 's flexible and powerful expressive force at the framework level, Personally think that if the site does not have to Yuiloader set up the module tree to do support, YUI2 role is undoubtedly a sledgehammer only used to kill chickens. In Yui3, this situation has a fundamental change, the framework level of modularity instead of a simple library, which is the team developed a large web site is very enlightening.
Of course, in the front-end development, the use of loader is bound to write a few lines of code, more than a few packages, and trouble and inconvenient, so what is the good place to do it. This topic is probably a long story, here only from the size of the site and the characteristics of the project to make a simple explanation:
Such a large web site, such as Taobao, front-end development occupies a small proportion, such sites will generally be divided into different products according to large categories, each product equivalent to a separate complete site, only the overall style and components will be consistent with the main battle.
So from the Web front-end point of view, this kind of Web site contains roughly four parts content:
1, the site under the jurisdiction of the required global variables and functions, including all sub-stations common parts
2), sub-station frame (public-tail)
3), the main content of the Web page
4), Component
According to the characteristics of the three, the respective reuse situation is:
1, global variables and functions for all stations: almost every page has to be used
2), the sub-station frame: Almost every child station pages are consistent
3, the main content of the Web page, can not be reused
4, components: high reuse rate, but the invocation is selective, only when necessary to refer to the component
From a demand point of view, this kind of site is characterized by frequent updates, from the engineering point of view, the maintenance cost of code is greater than or even far greater than the cost of code development. That is to say, over time, the number of projects that modify functionality is much larger than the development of new features, and in the middle and late stages of the project, engineers spend most of their time not writing new code, but spending a lot of experience reading old code, or performing performance optimizations or improving on new requirements. Whether it's performance improvement or demand improvement, will increase the entropy of the Code, Code pollution will become more and more serious, maintenance costs will be dramatically increased, which makes the project later development engineer miserable, part of the reason is the project early document incomplete, lack of code necessary to write the constraints and conventions, and then the annotation is not timely and norms, resulting in poor code readability, the third is the uneven level of engineers, some people in the process of modifying the code will inadvertently destroy the structure of the original code, four is the time pressure to reduce the quality of the code, five is the unreasonable frame structure.
Improve the documentation and specifications, increase the training of new recruits can solve a part of the problem, but this is often related to the system and enforcement efforts. In terms of the project life cycle, the project is divided into iterations and rapid development, rapid development is a short development time, do not need and other projects in parallel, timely development and timely testing timely packaging online, and other projects conflict is very small, simple iterative development model is based on branch and backbone of the parallel development of multithreading. The front-end development on this basis is also the iteration of maintaining and synchronizing the development of the latter segment. The advantage of iterations is that the project is parallel and reduces the occurrence of conflicts. From a back-end development perspective, often many people develop the same page, but each engineer is responsible for the different modules, in general, the page only include the entrance, and then invoke the code of their engineers, so that the code in the page pollution is relatively low, but with the increase in page complexity, The latter code will more and more directly appear in the page, such as using more echo instead of template, HTML code nested more if judgments and for loops. This will increase the level of code contamination. From the front-end development, it will often appear that many people collaborate to develop the same page, is also responsible for the different functional modules, there are two cases, 1 is a lot of people at the same time to develop different application modules, the two have no dependency, 2 is the development of multiple people framework and application, the two have dependencies between the application of dependency framework. The coupling between the two should only be used as an interface by the portal call, so the front-end framework should take into account the case that the front-end functional code developed by many people should be separated as much as possible.
In the JS code, nature recommended that the code is encapsulated into the page of the JS file, in the page only to leave the entrance. However, this is not the case, in the absence of framework constraints, most people will not choose to read the bad code before the basis of adding their own code, usually directly with the most simple and brutal script tag to lead a JS, followed by a script code block to write the boot entry, Even the script tags are rotten writing, directly in the original code block directly to open up a section of their own code. How should this approach be treated? From the library point of view, the library to give a lot of examples of modules, the use of modules are mostly handwritten a script tag cited a JS file, and then the page to add the launch portal. That's what happens when multiple people develop different features in the same page:
First, a feature is implemented in the page, roughly like this:
<script src="base.js" /><!--库的种子-->
<script src="a.js" />
<script>
a.start();
</script>
b also implements another function, roughly like this:
<script src="base.js" /><!--库的种子-->
<script src="b.js" />
<script>
b.start();
</script>
b In coding most cases will not go to review page code, or review the page's rotten code can not read, or say two people in parallel development, do not know the other side of the realization. This causes the Base.js reference to be duplicated.
Alternatively, if an example is more complex, you need to refer to multiple JS files, such as:
<script src="base.js" /><!--库的种子-->
<script src="a.js" />
<script src="b.js" />
<script>
m.start();
</script>
Then the a.js and b.js of the Order of reference need special attention, but in the actual development, and can not guarantee that everyone will be careful to the JS file order, if the order of the chaos will need more debugging costs. Therefore, the pure based on the "library" mode of development will bring a lot of hidden dangers, here only mentioned the development process often encountered problems, in addition, the handwriting JS tags to refer to JS file is also a lack of semantics and sacrificing performance (each script src occupies an HTTP request?) At the same time, inline script block walks in every corner of the page, and although each script block is closed by anonymous functions and developed quickly, the code is not structurally sound and obscure to others, and when the cost of maintenance in the later part of the project is high, So no one wants to take over the maintenance of such a coding project. Therefore, it can be argued that the code contamination caused by this coding approach greatly reduces productivity (productivity in this area includes both the development and maintenance of the two parts) and page performance.
The YUI3 enforces the use of ylaoder, which guarantees code quality and readability to a certain extent. According to Yui3 's thinking, the prophase of the project should spend a lot of energy to do the dependence of the module, on this basis to develop a rich widget, the use of the process to need the load module name, without going to the relationship module needs to rely on those JS, and the order of these JS is what. In addition, through simple hack,loader can be yui3 and all the project JS combo together (Taobao ASSETCDN now do not provide this function, but will soon have), in many modules are merged into a JS HTTP request, plus a seed, A page of JS HTTP request only two.
So is it possible to say that a large web site, such as Taobao, which is complex and changeable (with frequent changes in demand), can be structured with YUI3 to avoid deep code contamination? Non-also, YUI3 is not designed to meet such a portal like Taobao. What should be the relationship between the four components of the Web site, the global, the outer frame, the main content area, and the components? Obviously, the page rander, should first load the global variables, and then initialize the load page belongs to the public head and the public end of the sub-station, and then execute the page logic, so the site three levels of logical relationship is very clear, so the three are bound to occur coupling, The framework needs to minimize the coupling between these three levels, because, the reality may be that many people at the same time develop framework functions, modules, page master logic and the maintenance of the underlying library, so it is necessary for each part of the responsible team code to isolate each other to ensure that there is no conflict in parallel development, in view of this, There are three types of purely YUI3-based code structures:
1, through Yui (). Use () nesting to express the logical relationship between the levels, for example, a code belongs to the framework, B code belongs to the application, C code belongs to the child application:
YUI().use(*,function(){
//a的代码
YUI().use(*,function(){
//b的代码
YUI().use(*,function(){
//c的代码
});
});
});
Nesting of three closures, this level of code is more clear, the code of A as a framework, B code as the application, C code as a child application, the call relationship at a glance, that is, after the framework is finished loading and executing the application code, the application code loaded and executed after the child application code.
But three pieces of code are very tightly coupled, and code conflicts will often occur in the team's parallel development. If the code is not modified once, this writing is not serious, often the code needs to be repeatedly modified, so this display depends on the coding style can not avoid the occurrence of code pollution. And the most likely part B code is the most polluting, because the application may contain multiple child applications, such as the Product List page Gongs page and the details page may contain the same right side ads, so that B's code may contain a number of peers Yui (). Use ().
Another point, each Yui (). Use is equivalent to a loader, each loader load will be required in this closure of the module in the corresponding JS file loaded into the page, so if three times loader loading has duplication of circumstances can not go to heavy, The resulting unnecessary HTTP request will increase by more than one times, seriously affecting performance.
2, a closure, the respective entrance
YUI().use(/*a,b,c的modules*/,function(){
a.start();
b.start();
c.start();
});
This kind of writing is more refined, call order at a glance, similarly, if the code is no longer modified to write this is a good way, considering the frequent modification of the code, this method still has three shortcomings, 1,a,b,c each need to refer to their respective modules, Each module is written as a parameter in the non-reciprocal first parameter of use, who is not clear which is a module, which is the module of B, which is the module of C, this kind of difference code is to be avoided in the multi-person collaboration project. There is no dependency between 2,a,b,c's code, and in fact, calls between frameworks, applications, and child applications should be sequential, while in code maintenance the order of A,B,C calls can be modified. 3, three of people write code is still together, do not guarantee that each modification will be the module package to the page, once someone opened a precedent diagram of the module code directly written in the closure, the subsequent changes will be out of control, resulting in each change in demand will be more polluting code. This situation occurs frequently in the development of the Yahoo relationship, and eventually leads to extremely bloated code, which takes half a month to develop a small function similar to tabnew.
3, the respective closure, mutual interference
YUI.use(*,function(Y){
//a的代码
});
YUI.use(*,function(Y){
//b的代码
});
YUI.use(*,function(Y){
//c的代码
});
Three of people write code completely separate, there is no problem of mutual interference, moreover, even if a person's code to write a mess, it will not affect the health of other people's code. But the downside is 2, 1, like the code in the previous section actually has dependencies, and here's no dependencies, 2, the same performance problem.
As a result, many of the resulting code contamination and maintenance costs associated with inadequate framework constraints should be addressed through stronger frameworks. The Cubee framework currently under development will largely address these issues.
Well? What's the use of Cubee,cubee? First of all, Cubee is the framework, not the library, the original intention is to solve the team project code pollution and reduce the high maintenance costs, about Cubee design details later to share it.
