Home >Web Front-end >HTML Tutorial >My architectural experience series of articles

My architectural experience series of articles

WBOY
WBOYOriginal
2016-06-24 12:00:59908browse

Framework level: The front-end has developed rapidly in recent years. The reason why the front-end is called the front-end is that it can become an independent profession. JS is no longer the toy it was ten years ago. In the past, the application of rich client RIA You may use flash/flex or silverlight, but now you can use js to complete most functions. Therefore, js as a front-end support language is not just a simple coding, more and more framework things are appearing. . More and more development models are changing to a situation where the backend just spits out json data sources, while the frontend does all the UI things.

MVC
MVC is very good for achieving separation of responsibilities. Most websites will introduce the MVC framework on the back end. For a website where the front end is responsible for all presentation and front-end business logic, it is also very good to use the MVC framework. There are benefits. There are many MVC frameworks for Javascript now. Each framework actually has its own characteristics, but the front-end MVC framework will be somewhat different from the back-end one. For example, the front-end MVC framework may do some two-way binding of M and V elements, but for the back-end, it is often one-way. By introducing the MVC framework, we can do many things on the same page. We can realize the foundation of an application through a page that does not refresh. We can also clearly separate MVC and highlight the concept of M. This is something that cannot be done without a framework. of.

Communication
For a more complex page, there may be more Javascript modules. If you want to communicate between modules (for example, a page has a left menu, navigation and list, click on the left menu After level classification, you need to notify the navigation to add this item, and the notification list re-reads the data and refreshes it. Then if you delete this selection from the navigation, the notification list needs to re-obtain the data, and the notification menu displays all). For more complex communication, if the modules are strongly coupled and directly call the functions of other modules, it will not be conducive to maintainability. I think a publish and subscribe mechanism can be introduced to publish the information after each module has been modified. People who care about this information can subscribe to this information and perform corresponding operations in the callback function. You can use Amplifyjs as a publishing and subscription framework.

Template
For the front-end, just like the back-end, a troublesome problem is that HTML is often mixed together in the script. I personally think this is the case. If it is a very trivial DOM modification problem, it will Not big. If large chunks of HTML are spliced ​​together, and data, HTML or even CSS are mixed together, the maintainability of the code will be very poor. At this time, you can consider using some template engines to separate data and performance, such as Twitter hoganjs. Since many template engines, such as the Big Beard engine, are not only for the front end, but also have corresponding engines for back-end languages, templates can even be placed in text files. The front-end and back-end use a set of template engines together, which means that now If the code is biased towards server-side rendering, then use templates on the back-end. If you want to change to client-side rendering in the future, this set of templates can be used directly by the front-end.

Class libraries
In addition to frameworks, there are many class libraries, such as jquery, underscore, linq.js (linq to javascript), jscex (wind). Anyway, what is available in the backend and now what is available in the frontend, enjoy Use your imagination. Making good use of these frameworks can greatly improve productivity, and scripts can really do more than you imagine. I do back-end and don’t know much about the front-end. What I list here may only be a drop in the bucket.

Dependencies
You can use components such as Requirejs and Commonjs to manage dependencies between scripts. There are many benefits. Our modules only need to write clearly what they need to depend on, and Requirejs will naturally help us follow certain requirements. Load them in order, so we don't have to worry about the order or the version number of the component. Based on Requirejs, it has rich configurations. Even if we merge static resources, it can be fully processed. We only need to configure the components to a path generated by the same server through configuration. However, when doing it before, we found that it would automatically Add the .js extension, but it can be completely solved by changing the Requirejs source code. In terms of architecture, my point of view is that since you are using open source things, you should not be afraid of changing the source code if you encounter problems. We must not stop as users of the framework. It is not that difficult to customize the framework or even contribute your own code to the author. Design level:

Concept of separation of responsibilities
Although we all know CSS styles, JS behavior and HTML structure. Personally, I think only HTML is necessary. That is to say, if a page has no style or script, it should be a clear page that can roughly express the content that the page needs to express, but it looks ugly and is interactive. If many functions are implemented by Ajax, then the interactive work is transferred to the server to implement server-side rendering. More styles just make the layout look better, more scripts just make it more interactive and there is no need to refresh the page, but having less does not mean that the website is useless. There are many concepts now with the same purpose. If we cannot reach this state, at least we must clearly let css, js and html perform their responsibilities and not give too many things to irrelevant components. For example, try not to include operational script code in HTML. Instead, you should directly select DOM elements in the script to operate. Try not to include large sections of HTML code in the script. Instead, you should read from the template and fill in the data. Also try not to include a large number of embedded styles in the html code. Instead, style assignments should be selected through selectors.

Hierarchy and directory structure
For a relatively complex and large-scale project, it is also very important to plan the directory structure reasonably. You may say that scripts and styles can be divided into two directories, but if one Does a complex project have hundreds of scripts all listed in one folder? The back-end has the concept of layering. In fact, the front-end can also have the concept of layering. There is a presentation layer, a business logic layer and a model layer, and then the following data access ajax layer. Of course, there will also be constant files. I asked back what I think the front-end The layering can be relied upon for very large projects in ios or android programs. For example, in the example of an iOS program I made before, I personally think that such layering is relatively clear.

The balance of merging and splitting
Many times, architectural things are a trade-off. If there are fixed standards, there will be no need for architects. We only need to follow the fixed standards. . For example, if 10 script files and 5 style files are used on a page, it stands to reason that merging them into two files can achieve the minimum number of requests, but is this necessarily a good thing? Many of these 10 scripts and 5 style files may be shared by other pages. If they are simply merged together, it may increase the user's download traffic. Therefore, how to plan to combine common things into one file and separate the framework files? , and each page has its own unique script and style, which is also a kind of knowledge. Performance level:

Performance testing
Tools such as YSlow and PageSpeed ​​can analyze front-end performance problems, which will not be discussed here. For the front end, the situation is not so simple because it involves the user's client environment and network environment. However, what we can do is to minimize the number of user domain name resolutions and reduce the amount of data downloaded by users within our controllable range. Increase concurrency and more. In fact, to put it bluntly, we are cleaning the pipes to make them bigger, or adding more pipes, or trying to reduce the water in the pipes so that they can run more smoothly.

Performance Analysis
Now there are some tools that can conduct detailed analysis of Javascript performance and even DOM parsing, such as dynaTrace AJAX Edition. Through such tools we can analyze our script code and page layout Whether it is reasonable or not, we should comprehensively understand and optimize our front-end code from a development perspective. Although the client's resources are not as important as the server's resources, in order to provide users with a better mechanical experience, it is best to optimize the client's performance consumption.


Reply to the discussion (solution)

It looks good, but the asking price is too high

Okay I’ll accept it based on experience

Learn from experience

The writing is quite good and the price is good. In fact, I came here specifically to receive points.

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn