Framework layer: In recent years, the front-end has developed rapidly. The reason why the front-end is called the front-end is that it can become a profession independently, and JS is no longer a toy ten years ago, in the past, rich client Ria applications may use flash, flex, or Silverlight. Currently, JavaScript can be used to complete most of the functions, therefore, JS, as a front-end support language, is not only simple coding, but more and more framework things have emerged. More and more development models are being transformed into backend data sources that only spit JSON data, while the front end is doing all the UI tasks.
MVC
MVC achieves separation of duties. Most websites will introduce the MVC Framework on the backend. It is also beneficial for a website with a front-end responsible for all the presentation and front-end business logic. Javascript has many MVC frameworks. Each framework has its own characteristics, but the front-end MVC framework is somewhat different from the back-end. For example, the front-end MVC framework may be bound to some M and V elements in two directions. For the backend, there are usually many one-way connections. By introducing the MVC framework, we can let the same page do a lot of things and implement the foundation of an application through a non-Refresh page, we can also clearly separate MVC and highlight the concept of m, which is not implemented by the framework.
Communication
For a complex page, there may be many JavaScript modules. If you want to communicate between modules (for example, a page has left menus, navigation, and lists, after clicking the level-1 category in the left menu, add this item to the notification navigation, and read and refresh the data in the notification list. If you delete this option from the navigation list, you need to notify the list to retrieve data again, the notification menu shows all ). For complex communication, it is difficult to maintain the maintainability to directly call functions of other modules through strong coupling between modules. I think the publishing and subscription mechanism can be introduced, what changes have been made to each module to publish the information, and those who care about the information can subscribe to the information and perform corresponding operations in the callback function. You can use amplifyjs as the publishing and subscription framework.
Template
For the front-end and the back-end, the problem is that HTML is often mixed in the script. I personally think this is the case. If it is not a problem for very trivial Dom modifications, if a large part of HTML is spliced, the data is mixed with HTML and CSS, so the code is very poorly maintained. In this case, you can consider using some template engines to separate data and performance, such as Twitter hoganjs. Because many template engines, such as the bearded engine, are not only for the front-end, but also for the back-end language, you can even place templates in text files. The front-end backend uses a template engine together, that is to say, the current Code tends to be rendered by the server, so the template is used at the backend. If you want to render this template on the client later, it can be directly used by the front end. The most professional UI front-end framework!
Class Library
In addition to frameworks, there are many class libraries, such as jquery, underscore, LINQ. js (LINQ to Javascript), and jscex (Wind). Let's take full advantage of what the backend has and what the front end has. Using these frameworks can greatly improve productivity, and the script can do more things than you think. I do not know much about the backend front-end, but I may only list it here.
Dependency
You can use components such as requirejs and commonjs to manage dependencies between scripts. There are many advantages. Our module only needs to clearly understand what needs to be depended on, requirejs will naturally help us load in a certain order, so that we do not have to worry about the order or component version number. Based on requirejs, it has rich configurations. Even if we merge static resources, we can simply configure the components to a path generated by the same server, however, it was previously discovered that it would automatically add. JS extension, but it can be completely solved by modifying the requirejs source code. In terms of architecture, my point is that since open source is used, don't be afraid to change the source code if you encounter any problems. We must not stay at the users of the framework. It is not so difficult to customize the framework or even contribute code to the author. Design Level:
Concept of separation of duties
Although we all know the CSS style, JS behavior, and HTML structure. I personally think that only HTML is necessary. That is to say, if a page has no style, no script, it should be a clear page, which can roughly show the content to be displayed on the page, but it looks ugly, it is also interactive. If many functions are implemented using Ajax, the interaction is transferred to the server for rendering on the server. More styles make the layout look better. More scripts are more interactive and do not need to refresh the page, there are many ideas for the same purpose. If we do not reach this level, we should at least clearly let CSS, JS, and HTML fulfill their responsibilities and do not assign too many things to irrelevant components. For example, try not to include operational script code in HTML, but directly select DOM elements in the script for operations, try not to include large HTML code in the script. Instead, read the code from the template and fill in the data, try not to include a large number of embedded styles in HTML code, but assign values to styles using selector selection. The most professional UI front-end framework!
Hierarchy and directory structure
For a complex large project, it is also important to plan the directory structure reasonably. You may say that the script and style can be divided into two directories, but if a complex project has hundreds of scripts listed in a folder? The backend has the concept of hierarchy. In fact, the front end can also have the concept of hierarchy, including the presentation layer, business logic layer and model layer, and then the following data access Ajax layer, of course, there will also be constant files. I think the front-end layering can depend on iOS or android programs of super-large projects. For example, I used an example of an iOS program. I personally think this layer is quite clear.
Balance between merge and split
In many cases, architecture is a trade-off. If there are fixed standards, there is no need for an architect. We only need to follow fixed standards. For example, if 10 script files and 5 style files are used on a page, it is reasonable to merge them into two files to reach the minimum number of requests. But is this always good? Many of the 10 scripts and 5 style files may need to be shared by other pages. If they are simply merged, the download traffic may increase, therefore, it is also a kind of knowledge to combine common things into a file, and the framework file is separate, and each page has its own unique script and style. Performance Level:
Performance Detection
Tools such as yslow and pagespeed can analyze the front-end performance issues. We will not discuss them here. For the front-end, because it involves the user's client environment and network environment, the situation is not so simple, but what we can do is to minimize the number of user domain name resolution within our controllable range, reduce the volume of downloaded data and increase concurrency. To put it bluntly, we just need to clean up the pipeline to make the pipeline bigger, or add more pipelines, or try to reduce the water in the pipeline to make it smoother. The most professional UI front-end framework!
Performance Analysis
Currently, some tools can analyze the performance of JavaScript and even Dom parsing in detail, such as dynatrace Ajax edition, with this tool, we can analyze whether our script code and page layout are reasonable, and fully understand and optimize our front-end code from the development perspective. Although the client resources are not as important as the server resources, it is best to optimize the performance consumption of the client in order to give the user a mechanism experience.
My Architecture Experience series-front-end architecture
