Write it at the very beginning

This is a scientific article for mobile developers, starting from the initial process of front-end development, combined with the demonstration code, discuss the evolution of the development process, hoping to cover part of the front-end development technology stack, so as to form a preliminary understanding of the concepts related to front-end development.

Some sample code will be provided in this article, but they will not run and do not need to be fully understood. It is more for readers to have a more concrete feeling and a clearer understanding of related concepts and solutions.

In the process of writing, I read and learned taobao’s blog on the separation of front and back end and the evolution of front-end development technology, and benefited a lot. Relevant articles are listed in the references at the end of the article. At the same time, due to my limited ability, MY understanding of many concepts is relatively simple, even wrong, welcome to exchange correction.

The difference between mobile and front-end

In the process of developing an App, we don’t think about the development process, because everything seems very natural. What can be determined locally is written to death, otherwise asynchronously initiates network requests and dynamically modifies, and finally compiles the source code into executable binaries for the client to install.

Front-end development is fundamentally different from mobile development. The final presentation style of a web page is influenced by HTML + CSS, while JavaScript scripts are responsible for user interaction. Instead of being compiled into an executable, a page consists of several text files that are sent to the browser in clear text by the server and drawn to the screen.

The concept of “rendering” may be mentioned repeatedly throughout the rest of this article, but unless otherwise noted, it does not refer to parsing an HTML document (DOM) and drawing it to the screen, as this is done by the browser kernel and generally requires little understanding or intervention.

Web pages can be divided into two types: static and dynamic. The former is an HTML file, while the latter may be just a template. When requested, the data is dynamically calculated and finally spliced into HTML strings.

Another significant difference between front-end and mobile development is that while HTML can be debugged locally, the HTML content actually needs to be deployed on the server so that HTML text can be returned when a user makes an HTTP request.

The chaotic age of front-end development

In the beginning, we didn’t have any tools, just brute force. We know that servlets are server-side programs written in Java that can easily handle HTTP requests and returns, so we can directly return HTML text as a string, which is the same as rendering above:

public class HelloWorldServlet extends HttpServlet {
    @Override
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
        throws ServletException, IOException {
        resp.setContentType("text/html");

        PrintWriter out = resp.getWriter();
        out.println("Hello World Sample");
        out.println("
Hello World Title
" +new Date().toLocaleString() + "
"); out.flush(); }}Copy the code

In theory, we could have started all the front-end development, but writing maintainable code in these early days requires a lot of prehistoric power. Writing the UI and business logic together is a very strong coupling that is not conducive to future expansion of the project. You can’t require everyone to write Java and a front end at the same time.

The back-end MVC

One of the problems with the above solution is that the logic is confusing, which most mobile developers experience at the beginning stage. The solution is simple: use MVC, pull the business logic out of the Controller, and let the View layer focus on displaying the UI.

Implementation of MVC scheme

In the field of front-end development, there are similar technologies, such as JSPS, which are compiled into servlets. When writing a JSP, we care more about the page style, so the code looks like HTML, but within the <% %=””> code block we can call Java functions:

JSP test page --HelloWorld! <% out.println("Hello World!" ); % >Copy the code

JSPS are equivalent to the View layer, which fetches data from the Model and, more specifically, uses a back-end language (such as Java) to access the interface provided by the Model layer.

As a module directly in contact with the client, Controller is responsible for parsing request, data verification, route distribution, result return and other logic. Route distribution refers to invoking different Models and Views to provide services depending on the request path.

Disadvantages and improvements of MVC

With MVC architecture (such as the well-known Struts), it seems that the responsibilities become clearer, with the front-end developer writing JSPS and the back-end developer writing controllers and models, but there are still a lot of problems in actual development.

First, business logic is still not strictly differentiated, and without good coding specifications, JSP will be mixed with a lot of business logic. The purpose of a framework is to allow new people to write decent code without a lot of training. In addition, front-end developers also need to have a general understanding of back-end logic and be familiar with the back-end programming language, so there are a lot of communication and learning costs.

The front end is just Demo

One solution is for the front-end developer to just write the Demo, that is, to provide static HTML effects to the back-end developer, who will do the view layer (such as JSP) development. Front-end developers don’t need to know anything about the back end.

Unfortunately, it’s a good idea, but there are problems with putting it into practice. First, backend developers rely on the front-end Demo, and only when they see the HTML file can they start implementing the View layer. The front-end relies on the back-end developers to complete the overall development and check the final effect through network access, otherwise they can’t get real data.

To make matters worse, once the requirements change, the process has to be reworked, and communication between the front and back ends is still inevitable. Generally speaking, the cost of front and rear end docking is too high.

For example, while developing an App, your colleague sends you a piece of code that is a locally written view and says, “The text for this button needs to be retrieved from the database, and the content for that image needs to be retrieved from the web. Change the code.” . So you spend half a day fixing the code, PM comes to tell you that the button text is dead, but the background color needs to be read from the database, and add a button. WTF?

Obviously, this development process is extremely inefficient and unacceptable.

HTML template

In fact, to a certain extent, JSP can be seen as the prototype of HTML templates. HTML basically does two things: frame the page and describe the content. An HTML template is a framework that uses a structured syntax to represent HTML, while isolating specific data.

Such as

111

Represents a paragraph with the content of “111”. If you use a template, you can write

or
p ContentAnd so on. Anyway, instead of obsessing over the syntax, just know:

Data + template = HTML source code

For example, at the Controller layer, it could be called like this:

Return res. View ({title: "111"});Copy the code

The code in the template is as follows:

<%= Content%=""/>
Copy the code

Readers familiar with front-end development will notice that this is actually losa.js + EJS. The former is a javascript-based server-side application, the latter is a template based on HTML syntax, and the other style is Jade, but the purpose of this article is not to focus on how to use these tools.

Going back to the concept of templates, it has an advantage over JSP in that it uses tools to forcibly prohibit front-end developers from writing business logic at the view layer. The front-end developer only needs to care about the UI implementation and determine the variables in the HTML. The back-end developer simply passes in arguments to get the STRING in HTML format.

Another benefit of template development is that the front and back ends can be developed simultaneously. The two parties agree on a data format, so that the front end can simulate fake data and use it for self-testing, and the back end can compare the generated data with fake data for testing. At the same time, the agreed data format plays the role of contract and document, standardizing the form of data communication between the two parties, thus saving the time cost of communication. Please refer to this link for more Mock Server topics.

Summary of back-end MVC architecture

Using the back-end MVC architecture plus template development is one of the prevailing development models, but it’s not perfect. Because the templates are done by the front-end developers, it is required that the front-end developers have some knowledge of the back-end environment (note that this is not an implementation detail).

As a simple example, the backend of a large application is divided into many folders, which requires the front end to understand the code structure, SSH, VIM, and dependency on the server environment when uploading files.

In general, with server-side MVC, HTML is rendered in the back end and the overall development process is based on the back end environment. So the front-end engineer inevitably needs to rely on the back end (although the situation has greatly improved with the use of templates).

AJAX versus front-end MVC

AJAX stands for Asynchronous Javascript And XML. It is not a framework, but a programming idea. It uses JavaScript to make requests asynchronously, the results are returned in XML format, and JavaScript can then locally manipulate the DOM based on the returned results.

The biggest advantage of AJAX is that instead of reloading the entire data, you can simply retrieve the changed content. This may seem natural in mobile programming, but front-end development is done exclusively with AJAX, and by default every minor change to a web page requires a reload of the entire web page.

Analog mobile application, AJAX is fit to be a single page updates, but not good at page jump, jump is just like your app page to create a new UIViewController/Activity rather than directly change the content of the current page.

Thanks to AJAX, HTML rendering in the front end became possible. You can download an empty shell HTML file and a JavaScript script, and then get the data in the JavaScript script to add nodes to the DOM.

There are lots of front-end MVC frameworks like backbene. js, AngularJS(let’s just say MVVM is a variant of MVC), and you can find their demos here. Take React, which I’m relatively familiar with:

  


Copy the code

This code doesn’t have to be completely readable, just realize that with the introduction of the React.js framework, we can move away from HTML programming. All the logic is written in