Five years of front-end, still small white, to sum up, welcome to exchange.

The road to growth

After graduation in 2015, I started to do front-end business. At the very beginning, IT was the mall. The experience from 0 to 1 was very painful, but also grew rapidly, and I got familiar with the whole link of r&d. Juqery started with Requirejs, SeaJS, fix, and the concept of modules. Later, I started learning about frameworks, starting with Angular, then React, then Vue, and finally various derivative frameworks. Later, I learned TS, Graphql, Mico Frontend, Serverless…

A little thought

There are more things to focus on at the front end, and new technologies are emerging all the time. If you want to use it in the old business line, the cost is extremely high. The reconstruction project requires complex framework and configuration upgrade. One project can be changed slowly, but there are many, so the cost can be imagined. Can use CLI automatic upgrade, but different projects can ensure stable operation without missing hidden bugs? Especially when the infrastructure is not perfect, there is no testing, there is no scenario verification, how to ensure that the project refactoring is not introducing new bugs. So, as a front-end, what do I do?

Some frameworks

Here is the study and application of some frameworks, without any comment. The formation of frameworks depends on the actual business line, so it is not suitable for comments without understanding the actual situation. Teams with enough manpower can maintain scaffolding, component libraries, CLI, and even develop systems themselves, but for a small front-end team, these costs are obviously too high, so using off-the-shelf is the norm. The first is NextJS, which has been tested by many people and is very convenient, saves unnecessary time to study WebPack configuration, Babel, TS, etc., meets all business needs, supports Serverless, and can be implemented for microservices (though just like nginx forwarding). But there are always restrictions on some uses, for example:

  • Nextjs 9.0 has mandatory tsconfig requirements, mudule is esNext, but I had a headache when I implemented the Server layer for Node in the same project, so I had to give the server a separate TSconfig configuration.
  • For example, when I move Pages to another directory, the static file cannot be accessed anywhere.
  • Nextjs has a default meta configuration that allows mobile to be zoomable, so it doesn’t matter what I do in _document

All in all, it gave me more traversal than it bothered me, making development smoother.

After talk about Umijs, this is a framework I am very optimistic about, although not used much, but I like his out-of-the-box block and UMI UI concept, so that the development environment is very convenient to build and modify, but also let template sharing is very smooth, for the middle class development is a magic tool. Of course, there is also a disadvantage, the documentation is not systematic, some default configurations may not be found in the documentation, because there are too many conventions that are not well retrieved. Overall, this direction is great, and if you need an out-of-the-box framework for ANTD Pro, umiJS is the way to go.

Look at uni-App. As cross-platform becomes mainstream, mobile applets are being developed everywhere and everyone wants to get out of their applets and light apps. It’s a nightmare for developers, just like when Microsoft pulled out of IE, everyone customized standards, along with catering to these different standards, it must be developers. I have used Wepy, Taro, Electron and uni-App. In the end, I may prefer uni-App. It is very convenient and saves a lot of work.

I have also used other derivative frameworks, mainly vUE and React, but the real quality of the framework depends on the business needs.

Some tools

When the front end is a person, you can build as much as you want. When there is a group of people, how to better collaboration, first of all, there should be a specification, and then use a series of tools to make the collaboration more smooth.

The first is the specification, the front end is definitely ESLint, through a series of configurations to restrict the way code is written, developing good programming habits is essential. We started with fecs, but it turned out that it didn’t work very well, you know, formatting gibbers a lot, but there were some weird constraints. So when I switched to ESLint, development was much smoother, but there was still a problem, that is, similar code, ESLint could not guarantee a uniform style. When prettier was introduced, it was easy to format code the same way when writing warning rules with ESLint. This, combined with ghook pre-commit validation, makes the code submitted to the REPO almost formatting free.

Then there is the document, the document is the basis of communication, with a good document, communication twice the result with half the effort. Communication between the front and background has always been a pain point. I have experienced many API document tools, such as Wiki, Eolinker, Swagger and YAPI. Finally, I decided on YAPI, privatized it, developed it again and then promoted it to the company. Although yAPI has many scenarios that cannot be satisfied, at least it has found a set of effective documentation solutions that greatly improve the efficiency of development communication. Of course, in addition to API documents, there are project documents, framework documents, use documents and so on, which is convenient for new people to learn and communicate, but also to make personal summary and improvement.

Then, framework, CLI, yes, these are standard, regardless of the size of the team is expected to have their own scaffolding, CLI, just to adapt to different business needs have their own focus, there is no need to show up. I want to talk about how to implement cross-project component/page sharing and build your own development system.

Bit. dev is a convenient way to export existing components/pages in the project to the repository, which can be easily introduced in other projects. By default, dependency statistics will be counted when exporting, so as to facilitate the output of compiler. You just share the source code of the component through ignore-package-json. At the very least, this is a very feasible solution that allows me to easily update the same component/page code in different projects for cross-project sharing. Of course, bit offers much more than that, with a range of support for component sharing, rendering, and testing. I haven’t tried it yet, but it’s a great way to manage components and will continue to explore it.

Again, piral is the prototype of my ideal development system, for the project dimension of the central management, for the component/page dimension of the Feed Service, so that microservices, Serverless out of the box is not far away. Personally, rather than managing maintenance iterations separately for the project, it would be better to do more focused development test iterations for components/pages. Let the framework disappear invisible, for components can have more room to play, can be different frameworks, languages, code, but all have to run in the same environment (that is, the project environment). This, not mature practice, just exploration stage, sharing is just to express ideas.

Some ideas

As for the front end, technical iteration is relatively fast, the project is getting bigger and bigger, it is more and more difficult to reconstruct and upgrade, and overturning and redoing may not be realistic. If it is convenient to have a research and development system, move in, for components/pages to do smaller granularity of reconstruction and upgrade, will it be more smooth. I am a front end and hope to bring some change to the profession.

The original link