These years, the front end has undergone a disruptive change, which has greatly changed the front end ecology, from an insignificant role many years ago to an indispensable existence.

The technology of the front end is not only in front end development itself, it extends its tentacles into mobile development, back end development. If you’re going to pick an all-stack technology, the back end, some of the technology on the mobile end itself is not going to compete with the front end.

The front end is not what it used to be!

However, having been personally involved in back-end and mobile development for many years, AFTER comparing the current situation of the front end to back-end mobile and so on, I still feel that there are some dilemmas in the front end that it needs to overcome.

This week, I continue my thoughts and analysis on the front end in the seventh of a series of articles on the front End:

  1. Change of the front end (I) : change and invariance of technology
  2. Front end change (2) : “unchanged” front end
  3. Front end change (3) : change and breakthrough
  4. Front end change (4) : attack front end
  5. Change at the front (5) : The return of the king
  6. Change of the front end (6) : Leading the change from imperative UI to declarative UI

Write it at the very beginning

Since I’m talking about front-end dilemmas, I’d like to make a brief statement:

  • The development of front-end technology is very fast, itself is very good, this article said that the problem is not my personal negation of it, just based on my personal full stack technology background some thinking

  • These are just personal thoughts, which of course have a high probability of being wrong or biased, but there is value in expressing one’s opinion.

  • In the next post, I’ll talk about the opposite side, which is some thoughts on the future of the front end, where I’ll analyze the advantages of the front end and some predictions about the future of the front end technology

Three dimensions

In thinking and sorting out the front-end problems, I summarized it into three dimensions, which I think the front-end technology needs to focus on improving. Once these improvements are made, the future of the front-end can not be underestimated

I analyzed and summarized the difficulties faced by the front end, which can be summarized as follows:

  • The language of the trapped
  • The struggle to ecological
  • Developer’s Dilemma

Next, I will elaborate on my thoughts one by one

The language of the trapped

JavaScript

The core of the front-end language is JavaScript, which is fine with everyone.

Based on my experience with Java,OC,Kotlin, and TypeScript on the front end, it’s easy to make the following conclusion when comparing JavaScript to these languages:

JavaScript is far from being a good language

JavaScript was designed and developed in 10 days. Netscape’s initial goal was to “design a language that was similar enough to Java to be simpler,” but JavaScript designers were not very comfortable with Java, preferring a more functional design style, so in this case, JavaScript was born.

It combines some of the function-oriented styles that designers like, but has had to conform to the company’s requirements to make it a bit like Java, with some of the object-oriented styles. Its designers didn’t like it enough to say, “I hate Javascript more than I love it. It’s a one-night stand between C and Self.”

There is a lot of discussion about the language design flaws of JavaScript in the book JavaScript Language Essentials. I won’t elaborate on that in this article.

As you can imagine, no matter how widely javascript is used today, this doesn’t change one obvious fact.

A good language makes it easier to produce good maintainable code, while a bad language makes it much harder.

Almost the entire front-end ecosystem is built on JavaScript.

This is a big dilemma for the front end, and even after TypeScript came along and a lot of well-known frameworks moved to TypeScript, JavaScript’s influence on the front end will always be there.

TypeScript

With JavaScript out of the way, I have to talk about the other front-end language: TypeScript

Microsoft’s desire to design another language has a lot to do with JavaScript’s own problems. However, TypeScript has emerged as a new front-end language to replace JavaScript.

TypeScript is more similar to Java than JavaScript.

Here I post a snippet of my Java code and Typescript code for comparison.

TypeScript

public async fetchUnconfirm(): Promise<number> { const fetchUrl = Config.getInstance().api + "/bings/" + BingMessage.tagString(BingTag.Unconfirm) + "? skip=0&limit=0"; const response: BaseResponse = await this.request.requestForGet(fetchUrl); if (response.resultSuccess()) { return response.result.total_count; } return -1; }Copy the code

Java

    public Goods addGoods(a){
        this.created = System.currentTimeMillis();
        Goods goods =  getGoodsRepository().addGoods(this);
        getItemRepository().createInventoryItemFromGoods(goods.getId());
        return goods;
    }
Copy the code

As you can see, TypeScript is more similar to Java in that it is an object-oriented language.

TypeScript is far better than JavaScript and more of a modern language, but TypeScript faces some problems on the front end today

  • It is, after all, dependent on JavaScript, and it cannot replace or eliminate JavaScript, only coexist
  • It is only suitable for some scenarios that use the Node environment, if you are not using NPM and Node front-end, such as using pure JS or JQuery, you have no choice but JavaScript
  • Many front-end programmers think of TypeScript as JavaScript with Type, and I’ve seen Flow more than once compared to TypeScrip because Flow also provides Type support for JavaScript. Most people on the front end either don’t understand or ignore the object-oriented programming thinking TypeScript brings.

The struggle to ecological

In the “post-” front-end era, NPM package management has also emerged on the front end, mirroring the Maven dependencies of back-end Java.

There were so many packages on NPM that I didn’t realize there was a problem until I used the awesome-typescript-Loader dependency that I slowly realized there was something wrong with the front-end ecology.

The origin of

When I did PCX in 2020, I used typescript 3+ Webpack 4+ React 16+mbox 5. The plugin webpack uses to transform TS is awesome-typescript-loader. There is also TS-Loader, and Babel can convert TS code.

Ts-loader is recommended in the official WebPack documentation.

The reason I use awesome-typescript-loader is because I read the official typescript blog and other (less impressive) blogs that recommend awesome-typescript-loader, I also listed some reasons why awesome-typescript-loader is better than TS-Loader. For this reason, I chose awesome-typescript-loader in my project.

It’s a normal thing to do, and in fact, it always works.

Until…

The problem

In 2021, I was working on myDDD-Electron to upgrade PCX’s core dependencies to WebPack 5 + typescript 4 + Mbox 6 + Electron 12. After the upgrade, everything else was fine. But awesome-typescript-loader ran into problems.

I was wondering if I needed to upgrade to a new version. Then I went to the NPM website to check and upgrade to the latest version of typescript 4 and WebPack 5.

Here’s what I see:

The framework stopped updating three years ago.

Of course, this problem was solved by me switching to the TS-Loader.

I glanced at the problem and found that it wasn’t isolated, the ioc framework I used, typescript IOC, stopped updating and I had to switch to Microsoft Tsyringe to fix it.

I was surprised, because I had never seen anything like this in Java, and it might not be clear to a lot of front-end programmers, but I could tell front-end developers clearly:

In the mainstream dependencies of Java, there is no framework that has not been updated for long periods of time, and this is hardly the case

Investigation and Reflection

Based on this situation, I slightly investigated the ecology of the lower front end, and compared with the ecology of Java, I found that there are many obvious problems in the ecology of the front end, which are as follows:

Ecology is based on personal development

The mainstream Java ecosystem, be it Spring, Hibernate, vert. x or any of the major frameworks or libraries used by programmers, is almost always backed by a company or foundation, most of which are also open source.

However, many front-end ecosystems are basically dominated by individual developers. For example, the famous Webpack was almost made by one developer at the beginning, and later, when it became famous, many individual developers added plug-ins to form the current situation. But it’s still dominated by the same developer, until now. Awesome typescript-loader, TS-loader, etc., are almost the product of individual developers.

I not criticize the personal development of ecology, it is to some extent the front-end ecology can quickly develop an advantage, but I want to say, with the back end an obvious difference is that: after the ecological use of mainstream technology, basically is the company’s support behind them, their quality and reliability, updated timely, is far superior to individual developers.

Personal development is fine, but is the natural progression to a company or open source foundation? This is one of the challenges that front-end ecology has to face.

On the other hand, typescript and React are open source projects led by big companies, so they are updated and reliable. I suppose programmers using typescript or React are less likely to suspect that they will have a lot of problems or that one day no one will update them?

Frameworks are self-contained and do not form standards

When I was doing PCX, I was looking for the right framework to handle it in terms of ioc and database.

Many front-end programmers probably don’t have a clue what IOC is, which I’ll talk about later in developer’s Dilemma.

Inversion of Control, or IoC, is a design principle in object-oriented programming that reduces coupling between computer code. One of the most common is called Dependency Injection (DI) and another is called Dependency Lookup.

In the back-end Java ecosystem, both IOC and database ORM started out as different frameworks, but soon, due to their importance and popularity, standards were born. In ORM database was born JPA standard, and in IOC, Java added IOC standard Annotaion, and some specific framework, followed by comply with this standard, is the implementation of this standard.

However, it is a pity that in the front end, no matter IOC or ORM database, each framework has its own set of standards and concepts, which do not communicate with each other.

I looked into typescript-IOC, inversifyJS, and then found Microsoft Tsyringe after typescript-IOC didn’t work with typescript4, and I used it without hesitation, given that it’s Microsoft and it’s got some quality. They have nothing in common.

As for ORM databases, there are Sequelize, TypeORM, etc., but they also have almost nothing in common. Each framework has its own style and pattern.

Lack of top open source foundations

You can’t be a Java programmer without knowing the Apache Foundation.

Apache Foundation represents the highest ecology of quality control of open source framework. It is a top open source foundation. Only open source frameworks with extremely reliable quality and guarantee can be included in APAHE open source foundations, such as The Dubbo open source framework of Ali in China a few years ago, because relying on the strong technical strength of Ali, This framework has long been widely used by small and medium-sized enterprises in China, but even so, it was not until many years after it was popular that it was applied and approved to enter the Apache Foundation.

Unfortunately, there is no similar foundation on the front end. It’s still a mix of a few big company-led frameworks like React and a lot of open source work from individual developers.

With the support and control of companies and foundations, it is almost impossible for the back-end mainstream framework not to be updated. I have rarely encountered similar situations.

Compared with the front end, there is indeed a gap in ecology, Java’s ecological operation is worth learning from the front end.

Developer’s Dilemma

When I talked about IOC earlier, I made an assertion that many front-end programmers probably don’t know what IOC is.

This brings me to my third dilemma: the developer’s dilemma

I think it’s obvious that front-end programmers have a much weaker understanding of object-oriented coding than back-end programmers

Of course, this is not the problem of the front-end programmers, because the front-end started with JavaScript, which is by no means an object-oriented language, and it is natural that the front-end programmers do not know much about the concept of object-oriented coding.

Unlike front-end programmers, back-end programmers encounter object-oriented ideas almost at the beginning of their coding careers, whether intentionally or not, such as:

  • Object – oriented basic features: encapsulation, inheritance, polymorphism
  • The key approach to decoupling: IOC dependency injection
  • Programming for interfaces, not for implementations
  • MVC pattern, layering, etc

, etc.

The point is that the frameworks used by back-end programs have been advocated since the beginning. For example, when I first graduated, the popular backend architecture was SSH, which is a technical combination of Spring+Struts+Hibernate.

In this collocation, there are some ideas in itself

  • SSH is an implementation of the MVC pattern
  • Spring is responsible for IOC, also known as dependency injection

The following concepts are most familiar to back-end programmers, though I think front-end programmers may understand them less well:

  1. Basic features of object-oriented language: encapsulation, inheritance, polymorphism
  2. Five basic principles of object orientation: single responsibility principle, open and close principle, Richter substitution principle, interface isolation principle, dependency reversal principle
  3. There are more than twenty common design patterns: singleton, observation, factory, adapter, template, and so on
  4. Common architectural styles: MVC pattern, layered pattern, domain-driven design style, hexagonal architecture, etc
  5. Test driven philosophy, refactoring philosophy, agile software development philosophy, etc

These are the basic principles and ideas that determine the quality and maintainability of code, and front-end programmers are probably the least familiar with them of the three, essentially because the front-end is driven by JavaScript.

JavaScript is not an object-oriented language.

So much so that even after TypeScript came along, many front-end programmers still thought of it as just another Flow, JavaScript with Type,

TypeScript does more than just bring Type to the front end. Many front-end programmers fail to understand that TypeScript brings a great set of object-oriented concepts and patterns to the front end, enabling the front end to finally enter the object-oriented world.

These are still the best ideas in our programming world today, and despite the growing popularity of functions in recent years, object-oriented concepts are still the best ideas that lead to good, maintainable code.

This is why almost every language in every technical direction today is dominated by object-oriented languages. Java on the back end, Kotlin on the mobile end,Swift,OC, TypeScript on the front end, they are almost invariably object-oriented languages.

We programmers on the front end have to learn and understand these great ideas.

The future of the front-end

Although I said these difficulties, but the front-end changes are still a flaw, today only the front-end technology, the closest to the possibility of full-stack coding. People like me, who have done back-end, mobile and front-end, are in the minority.

Many years ago, a programmer said:

Atwood’s Law: Any application that can be written in JavaScript, will eventually be written in JavaScript.

Any application that can be written in JavaScript will eventually be written in JavaScript.

Is that the truth? Is it the future of the front end? Is it the future of programming?

Next, the end of the Change of the front End: The Future of the front End. Describe some of my personal thoughts on the future development of the front end.

Visit taoofcode.cc – Spreading the taoof coding with our little power

Visit myDDD – Full stack Domain Driver website: myddd.org