What programmers must know about the evolution of the front-end

After carefully sorting out the front-end technologies I have come across in the past, I found that the evolution of the front-end is a particularly interesting history. People always make frameworks for the future in the past, and what is popular now is what was invented in the past. For example, one disadvantage of responsive design that must be mentioned is that it just puts the work that was originally done at the template layer into the style (CSS) layer to complete.

Complexity, like force, does not disappear or appear out of thin air; it is always transferred from one object to another or from one form to another.

If the mobile network speed six or seven years ago was as fast as it is today, the technology that would be directly used would be responsive design, and apps and SPAs would not have become so popular so quickly. Although we can foresee that these areas will get better in the future, what is more needed is to change the status quo. While changing the status quo, we also need to foresee future needs.

What is the front end?

Wikipedia says: Front-end and back-end are common terms for describing the beginning and end of a process. The front-end collects input information, and the back-end processes it. The interface style and visual presentation of a computer program belong to the front-end.

This statement gives people a very vague feeling, but he is right, it is responsible for visual display. In the MVC structure or MVP, the part responsible for visual display is only the View layer, but today most of the so-called View layers have surpassed the View layer. The front end is a very magical concept, but today's front end has changed a lot.

You introduced Backbone and Angluar, and your architecture became MVP and MVVM. Despite some architectural changes, the development of the project did not change. This involves some issues of responsibility. If there are too many responsibilities in a certain level, does it increase the burden on some people?

Front-end Evolution History

I have always wanted to write an article about the history of front-end development, but I thought that this history was already well known. Later I found that this was not the case. It was probably survivor bias - everyone who paid attention knew this history.

Data-Template-Style Mixin

In my limited front-end experience, I still went through the period of using Table for styling. During college, I helped some companies or individuals develop and maintain some CMS for a fee, and I came into contact with Table when I was helping a website update its style - ASP.Net (maybe). At that time, we started this CMS using a program called aspweb.exe. So, I found the following code in my mobile hard drive.

 <TABLE cellSpacing= 0 cellPadding= 0 width= 910 align=center border= 0 >
 <TBODY>
 <TR>
    <TD vAlign=top width= 188 ><TABLE cellSpacing= 0 cellPadding= 0 width= 184 align=center border= 0 >
 <TBODY>
 <TR>
 <TD>[Uploading external images...( 9 )]</TD></TR>
 <TR>
 <TD>
            <TABLE cellSpacing= 0 cellPadding= 0 width= 184 align=center
            background=Images/xxx.gif border= 0 >

Although I have found the modern prototype in HEAD - DIV + CSS, this is still the era of Table.

 <LINK href= "img/xxx.css" type=text/css rel=stylesheet>

People keep saying that front-end is hard, but the question is, have you ever learned it???

People keep saying that front-end is hard, but the question is, have you ever learned it???

People keep saying that front-end is hard, but the question is, have you ever learned it???

Maybe you have been saying that CSS is hard to write, but is it really hard to write CSS? People always say that JS is hard to use, but have you ever learned it? If you only learn it when you need it, it will definitely be hard. You have never spent time learning a language, but you can directly write working code, which means they are easy to get started. If you have seen the code written by some experienced Ruby, Scala, and Emacs Lisp developers, I think you will come to the same conclusion. There are some languages ​​that can make the programmer happy, but the reader may not be happy. There is more than one way to do things, but not everyone has to do it that way.

The programmers in the past were true full-stack programmers. These programmers not only did front-end work, but also did database work.

 Set rs = Server.CreateObject( "ADODB.Recordset" )
 sql = "select id,title,username,email,qq,adddate,content,Re_content,home,face,sex from Fl_Book where ispassed=1 order by id desc"  
 rs.open sql, Conn, 1 , 1  
 fl.SqlQueryNum = fl.SqlQueryNum + 1  

In this ASP file, it looks up the data from the database and then renders the HTML. If I could see the historical version, I think I would see that an author put the style="" code into the css file one by one.

There are also methods for dynamically generating JavaScript code in the code here:

 show_other = "<SCRIPT language=javascript>"  
 show_other = show_other & "function checkform()"  
 show_other = show_other & "{"  
 show_other = show_other & "if (document.add.title.value=='')"  
 show_other = show_other & "{"  

Laugh as much as you like, then look at this code:

 import React from "react" ;
 import { getData } from "../../common/request" ;
 import styles from "./style.css" ; 
 
 
 export default   class HomePage extends React.Component {
 componentWillMount() {
    console.log( "[HomePage] will mount with server response: " , this .props.data.home);
 } 
 
 render() {
    let { title } = this .props.data.home; 
 
 return (
      <div className={styles.content}>
 <h1>{title}</h1>
        <p className={styles.welcomeText}>Thanks for joining!</p>
 </div>
 );
 } 
 
 static fetchData = function(params) {
 return getData( "/home" );
 }
 }

The code 10 years ago and 10 years later doesn't seem to have changed much. The difference is that the data layer has been separated. If your component also mixes the data layer, that is, directly querying the database instead of calling the data layer interface, then you need to think about this issue carefully. Are you just following the trend, or are you changing? What's the point of replacing a View layer with a View layer, and replacing a Router with a Router?

Model-View-Controller

People are constantly reflecting on this complex process and have compiled some good architecture patterns. Among them, we have to mention Martin Folwer's "Enterprise Application Architecture Patterns". The Chinese translation of this book was published in 2004. At that time, the system layering was

The incarnation of the then popular Spring is MVC. People have data persistence layer frameworks such as iBatis, that is, ORM, object-relational mapping. So, your package will have several folders like this:

 |____mappers
 |____model
 |____service
 |____utils
 |____controller

At the mappers layer, all we do is make database-related queries like the following:

 @Insert (
 "INSERT INTO users(username, password, enabled) " +
 "VALUES (#{userName}, #{passwordHash}, #{enabled})"  
 )
 @Options (keyProperty = "id" , keyColumn = "id" , useGeneratedKeys = true )
 void insert(User user);

The model folder and the mappers folder are both part of the data layer, but their responsibilities are different, such as:

 public String getUserName() {
 return userName;
 } 
 
 public   void setUserName(String userName) {
 this .userName = userName;
 }

And they all need to be processed in the Controller, or ModelAndView:

 @RequestMapping (value = { "/disableUser" }, method = RequestMethod.POST)
 public ModelAndView processUserDisable(HttpServletRequest request, ModelMap model) {
    String userName = request.getParameter( "userName" );
    User user = userService.getByUsername(userName);
    userService.disable(user);
    Map<String,User> map = new HashMap<String,User>();
    Map <User,String> usersWithRoles= userService.getAllUsersWithRole();
    model.put( "usersWithRoles" ,usersWithRoles);
 return   new ModelAndView( "redirect:users" ,map);
 }

In most cases, the Controller should not be directly connected to the data layer, and it is a mistake to put the business logic in the Controller layer. This is when the Service layer comes into being, as shown below:

Service MVC

However, there are always different opinions on which layer the Domain-related Services should be placed:

MVC Player

MS MVC

Domain (business) is a rather complex level, and this is the core of the business. A reasonable Controller should only do what it should do, and it should not handle business-related code:

 if (isNewnameEmpty == false && newuser == null ){
    user.setUserName(newUsername);
    List<Post> myPosts = postService.findMainPostByAuthorNameSortedByCreateTime(principal.getName()); 
 
 for ( int k = 0 ;k < myPosts.size();k++){
        Post post = myPosts.get(k);
        post.setAuthorName(newUsername);
        postService.save(post);
 }
 userService.update(user);
    Authentication oldAuthentication = SecurityContextHolder.getContext().getAuthentication();
    Authentication authentication = null ;
 if (oldAuthentication == null ){
        authentication = new UsernamePasswordAuthenticationToken(newUsername,user.getPasswordHash());
 } else {
        authentication = new UsernamePasswordAuthenticationToken(newUsername,user.getPasswordHash(),oldAuthentication.getAuthorities());
 }
    SecurityContextHolder.getContext().setAuthentication(authentication);
 map.clear();
 map.put( "user" ,user);
    model.addAttribute( "myPosts" , myPosts);
    model.addAttribute( "namesuccess" , "User Profile updated successfully" );
 return   new ModelAndView( "user/profile" , map);
 }

What we should do in the Controller layer is:

1. Processing request parameters
2. Rendering and redirection
3. Choosing Model and Service
4. Handling Sessions and Cookies

Business is fickle. Yesterday we might have been competing with our competitors to launch new features first, but today we may have merged. It is difficult for us to foresee business changes, but we should be able to foresee that the Controller is not easy to change. In some designs, this mode is the Command mode.

The View layer is a layer that is constantly changing. People's tastes are constantly changing, and sometimes they may even change because of competitors. When a certain market has been achieved, Model-Service-Controller is usually unlikely to change, or even dare not change. Enterprises are aware of the two sides of innovation, either leading to death or occupying a larger market. However, competitors are usually smarter than you think, so it is a better choice to start a new business at this time.

Compared with enterprises in the early stages of development, enterprises in the rapid development stage need more front-end developers. When the user base is not large enough and the business is pending, the View only needs to be usable and beautiful. At this time, a large amount of business code may be placed in the View layer:

 <c:choose>
    <c:when test= "${ hasError }" >
    <p class = "prompt-error" >
        ${errors.username} ${errors.password}
 </p>
 </c:when>
 <c:otherwise>
 <p class = "prompt" >
        Woohoo, User <span class = "username" >${user.userName}</span> has been created successfully!
 </p>
 </c:otherwise>
 </c:choose>

In different situations, people will have disputes about this, but as long as it is in line with the current business, it is the best choice. As a front-end developer, I need to modify JSP and PHP files in the past, during which I need to understand these Templates:

 {foreach $lists as $v}
 <li itemprop= "breadcrumb" ><span{ if (newest($v[ 'addtime' ], 24 ))} style= "color:red" {/ if }>[{fun date( 'Ym-d' ,$v[ 'addtime' ])}]</span> <a href= "{$v['url']}" style= "{$v['style']}" target= "_blank" > {$v[ 'title' ]}</a></li>
 {/foreach}

Sometimes frameworks like Django, which call themselves Model-Template-View, make it easier to understand their intentions:

 {% for blog_post in blog_posts.object_list %}
 {% block blog_post_list_post_title %}
 <section class = "section--center mdl-grid mdl-grid--no-spacing mdl-shadow--2dp mdl-cell--11-col blog-list" >
 {% editable blog_post.title %}
 <div class = "mdl-card__title mdl-card--border mdl-card--expand" >
    <h2 class = "mdl-card__title-text" >
        <a href= "{{ blog_post.get_absolute_url }}" itemprop= "headline" > {{ blog_post.title }} › </a>
 </h2>
 </div>
 {% endeditable %}
 {% endblock %}

As a front-end person, what we are actually dealing with is the View layer and the Template layer, but MVC does not explain these.

From desktop to mobile

Wap came along and brought more challenges. Then the resolution went from 1024x768 to 176×208 and developers had to face these challenges. All that was needed was to modify the View layer, which changed again with the iPhone.

WAP website

This is a short history. What kind of website does PO need to make for mobile users? So they moved the desktop version of the website to the mobile version. Due to network reasons, the page needs to be reloaded every time, which brings a poor user experience.

Fortunately, people soon realized this problem, and SPA was born. If the mobile network speed at that time could be faster, I think many SPA frameworks would not exist.

Let's talk about jQuery Mobile first. Before that, let's take a look at two different versions of the code. Here is a mobile version of the blog details page:

 <ul data-role= "listview" data-inset= "true" data-splittheme= "a" >
    {% for blog_post in blog_posts.object_list %}
 <li>
        {% editable blog_post.title blog_post.publish_date %}
        <h2 class = "blog-post-title" > <a href= "{% url " blog_post_detail " blog_post.slug %}" > {{ blog_post.title }}</a></h2>
        <em class = "since" >{% blocktrans with sometime=blog_post.publish_date|timesince %}{{ sometime }} ago{% endblocktrans %}</em>
 {% endeditable %}
 </li>
 {% endfor %}
 </ul>

And here is a snippet of the desktop version:

 {% for blog_post in blog_posts.object_list %}
 {% block blog_post_list_post_title %}
 {% editable blog_post.title %}
 <h2>
    <a href= "{{ blog_post.get_absolute_url }}" > {{ blog_post.title }}</a>
 </h2>
 {% endeditable %}
 {% endblock %}
 {% block blog_post_list_post_metainfo %}
 {% editable blog_post.publish_date %}
 <h6 class = "post-meta" >
 {% trans "Posted by" %}:
    {% with blog_post.user as author %}
    <a href= "{% url " blog_post_list_author " author %}" > {{ author.get_full_name| default :author.username }}</a>
 {% endwith %}
    {% with blog_post.categories.all as categories %}
 {% if categories %}
 {% trans "in" %}
    {% for category in categories %}
    <a href= "{% url " blog_post_list_category " category.slug %}" > {{ category }}</a>{% if not forloop.last %}, {% endif %}
 {% endfor %}
 {% endif %}
 {% endwith %}
    {% blocktrans with sometime=blog_post.publish_date|timesince %}{{ sometime }} ago{% endblocktrans %}
 </h6>
 {% endeditable %}
 {% endblock %}

What people do is just reload the View layer. This is also an effective SEO strategy. The above code is the code of my blog in the past. There are different templates and different JS and CSS for desktop and mobile versions.

Mobile version

During this period, the code for the desktop and mobile versions may be in the same code base. They use the same code and call the same logic, but the View layer is different. However, we have to maintain two copies of the code every time we make a change.

Later, people discovered a more friendly mobile version of the application - APP.

APP and Transition API

This is a difficult time. In the past, many of our APIs were built in the original code base, that is, the desktop and mobile versions together. We have developed more and more features in this code base, and the system development has become bloated. As said in "Linux/Unix Design Thinking", it is a great system, but it is bloated and slow.

Should we choose to redevelop a third system that combines the best features of the first and second systems, or continue to be bloated? I think you already have the answer. Then we had the APP API and built a blog APP.

application

At first, people liked to use APP more and more because it was faster and smoother than the mobile version of the website. It was also a good thing for the server because there were fewer requests.

But not all people will download the app - sometimes they just want to see if there is anything they need. For apps that are not in strong demand, people will not download them, but will only visit the website.

With the APP API, we can provide API to the web page, and we began to imagine having a good mobile version.

Transitional SPA

Backbone was born in 2010, the same era as responsive design, but they seem to have become popular in the same era. If CSS3 had become popular earlier, Backbone would have been out of the question. However, mobile networks still limit the popularity of responsiveness, but today all this has changed.

We use Ajax to request the API from the backend, and then Mustache Renders it. Because JavaScript has shortcomings in modularization, we use Require.JS for modularization.

The following code is what I used when I tried to design a SPA for my blog:

 define([
 'zepto' ,
 'underscore' ,
 'mustache' ,
 'js/ProductsView' ,
 'json!/configure.json' ,
 'text!/templates/blog_details.html' ,
 'js/renderBlog'  
 ],function($, _, Mustache, ProductsView, configure, blogDetailsTemplate, GetBlog){ 
 
    var BlogDetailsView = Backbone.View.extend ({
 el: $( "#content" ), 
 
        initialize: function () {
 this .params = '#content' ;
 }, 
 
        getBlog: function(slug) {
            var getblog = new GetBlog( this .params, configure[ 'blogPostUrl' ] + slug, blogDetailsTemplate);
            getblog.renderBlog();
 }
 }); 
 
 return BlogDetailsView;
 });

Get data from API and render the page with Template. But this cannot change the need for two rendering methods: Client Side Rendering and Server Side Rendering, unless we can be like Taobao without considering SEO - because it does not rely so much on search engines to bring traffic.

At this time, we are still based on the MVC-like model. The only difference is that the data acquisition method has changed to Ajax. We have made a mistake - putting a lot of business logic on the front end. At this time, we can no longer directly access the Model layer from the View layer, which is a bit dangerous from a security perspective.

If your View layer can directly access the Model layer, then your architecture is still in the MVC mode. When I built a Side Project on Github, I used the View layer to access the Model layer directly. Since the Model layer is an ElasticSearch search engine, it provides a JSON API, which requires me to process data in the View layer, that is, business logic. Although putting the above JSON API into the Controller will increase the complexity of this layer, the business logic is no longer placed in the View layer.

If you always have an interface between your View layer and the Model layer, then you are using the MVP pattern, a derivative of the MVC pattern (PS: In order to distinguish other things, someone will always give it a meaningful name).

Overnight, we went back to the past. We left JSP and changed the View layer to Template and Controller. The original Services layer no longer only assumed its original responsibilities, but began to change to ViewModel.

Some teams extract services into multiple services, calling them microservices.

API Gateway

It becomes a microservice that is called directly:

Micro Services

This is a great thing for backend developers, but it is not the case for the application/frontend. There are more services to call, functional testing on the application side becomes more complicated, and more APIs need to be mocked.

Hybird and ViewModel

At this time, the problems were not only on the front end, but also on the App end. Small teams could no longer afford the development costs. People paid more attention to the Hybird application. The Hybird application solved some problems encountered by small teams in the early stages of development, and this part of the application was handed over to the front-end developers.

Front-end developers first became familiar with pure JS + CSS + HTML, and then with the structure of Router + PageView + API. Now they need to make mobile apps. At this time, they have to use the familiar jQuery Mobile + Cordova.

Later, people first changed from Cordova + jQuery Mobile to Ionic of Cordova + Angular. Before that, some teams may have replaced Backbone with Angular. They need better interaction and data binding.

Next, we can move our Angular code directly from the front end to the APP, such as the following blog APP code:

 .controller( 'BlogCtrl' , function ($scope, Blog) {
 $scope.blogs = null ;
 $scope.blogOffset = 0 ;
 //  
   $scope.doRefresh = function () {
     Blog.async( 'https://www.phodal.com/api/v1/app/?format=json' ).then(function (results) {
       $scope.blogs = results.objects;
 });
     $scope.$broadcast( 'scroll.refreshComplete' );
 $scope.$apply()
 }; 
 
   Blog.async( 'https://www.phodal.com/api/v1/app/?format=json' ).then(function (results) {
     $scope.blogs = results.objects;
 }); 
 
   $scope.loadMore = function() {
     $scope.blogOffset = $scope.blogOffset + 1 ;
     Blog.async( 'https://www.phodal.com/api/v1/app/?limit=10&offset=' + $scope.blogOffset * 20 + '&format=json' ).then(function (results) {
       Array.prototype.push.apply($scope.blogs, results.objects);
       $scope.$broadcast( 'scroll.infiniteScrollComplete' );
 })
 };
 })

As a result, the timeline was wrong again. People always made the wrong decision one period ahead of time, which was the right decision in the future. People encountered the user authorization problem of the web version, so they invented JWT - Json Web Token.

However, due to performance issues with WebView on some early Android phones, people began to consider alternatives. Two different solutions emerged:

1. React Native
2. New WebView——Crosswalk

Developers began to cheer for frameworks like React Native. However, they did not foresee that people were getting sick of apps, which were updated in our iterations, maybe one week, maybe two weeks, or maybe one month. Who says that self-updates in apps are not a bad thing? But the reminders of apps are constantly interfering with people's lives, and the noise is getting more and more. Don't compete with users for the right to use their phones.

Build once, run across platforms

When we needed to learn C language, GCC had such cross-platform compilation.

When we develop desktop applications, QT has such cross-platform capabilities.

When we build web applications, Java has such cross-platform capabilities.

When we need to develop cross-platform applications, Cordova has such cross-platform capabilities.

Now, cross-platform frameworks like React have emerged, and responsive design is also a cross-platform design.

One drawback of responsive design that must be mentioned is that it just moves what was originally done at the template level to the style (CSS) level. You are still designing for different devices, and there is not much difference between the two. Complexity does not disappear or appear out of thin air, it just moves from one object to another or one form to another.

React leaves a small part of the complexity to humans, and leaves the other part to React itself. Before using Spring MVC, we might still be using CGI programming, and Spring reduces this part of the complexity, but like React, it only reduces the complexity for novices. When we cannot write related code in a certain language, it will cause a lot of trouble.

RePractise

If you are a hard-working bee, I think you should have played with the above technologies. Are you practicing front-end technology or re-practicing? If you don't take some time to sort out the past and predict the future, then you are in vain.

The evolution of the front-end was particularly fast this year, and Ruby on Rails also appeared in the right era and became popular very quickly in that era. The advantage of RoR's high development efficiency is no longer prominent. The side effect of its flexible syntax is that its operating efficiency is reduced, and it is difficult to maintain in the future - everyone metaprograms themselves.

If we cannot turn Controller and Model Mapper into ViewModel, or decouple them with Micro Services, then ES6 + React only brings higher development efficiency now. The so-called high efficiency is just a fantasy in comparison, because it is only a View layer. Add Model and Controller back to the View layer and then separate them later?

The existing structure only makes the View layer do what the View layer should do.

First, you should consider a way to decouple the View layer from the Domain or Service layer. Today, desktops, tablets, and mobile phones are not the only user devices. Although you may unify these three platforms next year, the emergence of new devices now divides devices into two types - desktop and mobile. At first, the desktop and mobile versions are different versions, and later you need to merge these two devices.

Secondly, you can consider using Monolithic Service that combines the advantages of Micro Services to decompose the business. If you can give a successful example, it is Linux, a "Service" with a hybrid kernel.

***, Keep Learning. We always need to make changes at the right time. Although we think it would be great to have a web application code base with desktop and mobile versions, changes need to be made at that time.

For complex applications, the architecture is definitely not as simple as pure MVP or pure MVVM. If an application mixes MVVM, MVP and MVC, then it also becomes MVC - because it directly accesses the Model layer. But if you look at it in detail, only the part that accesses the Model layer is the MVC pattern.

A pattern is a description of a solution. There may be various design patterns in a piece of code, not to mention the architecture.