0, the introduction

A good front-end product must be a product with excellent user experience, smooth use, accurate data and friendly interface. In order to achieve this goal, the selection of technology needs to be very careful at the very beginning, and the cost of maintenance and upgrading in the later period should not be increased exponentially by trying to be quick, nor should we ignore the technical evolution of the team and the requirements of the boss for product positioning.

PS. Technology selection is in the eye of the beholder, this article only talk about experience, to provide a selection of ideas, rather than to give you a specific program

Purpose of selection

As the name implies, it is a trade-off between product requirements and technology costs in order to maximize revenue.

1, from the perspective of the enterprise to consider the selection

The survival purpose of the enterprise is to create as much enterprise benefit as possible with the least labor cost. From this starting point, we can get the requirements of the enterprise for a product selection.

Ensuring product quality is the foundation

The quality of products must pass the basic barrier. It is not required to have an amazing effect, but it must meet the requirements of customers, web pages can not be blank for a long time, or dislocation is not stuck, normal operation, accurate data. Going further, it may require some interaction and visual experience, and may include accessibility effects.

If you want to add compatible Arabic site layout, the existing architecture may not work at all, need to double the work of writing a separate -_-

Cost reduction is a necessary condition

The cost includes the manpower input of early development and the manpower input of late maintenance. The more manpower invested in the premise, the development cycle may be shorter, but the corresponding management cost of team collaboration will be higher; If people invest less in the early stage, there may be loopholes in the selection of technology or lack of scalability. If people are replaced for maintenance in the later stage, it may be difficult and have to be reconstructed.

2, from the technical form of the product to consider the selection

The technical form of the product refers to its technical mode, which is divided into pure front-end development, front-end and back-end separation and back-end driven development.

Pure front-end page

Pure front-end is generally some static pages, such as personal blog, some activity pages, promotional websites and so on. One person is usually enough, and you don’t need to worry about architecture at this point, just use your best technology stack and mature generation tools to stack pages quickly.

Front end separation

This product form should be the development mode of most products on the market at present, such as large ToB projects, mature APP web client, web shopping, etc. In this product, page rendering is basically the work of the front end, and the back end only needs to provide THE API documentation. This product is recommended as a single page application developed by the Web side rendering framework, or as a straight out template rendering using Node.js. If the project has a lot of business, consider deploying front-end microservices.

The back end leads development

A back-end led product team usually does not have a separate front-end team, but one team with one or two front-end teams to support back-end development. As the front end, you don’t need to have too many ideas of your own, just keep things simple. For example, with the front-end preprocessor Sass, you might need to be more cautious. At the same time, don’t break new ground. Use a front-end framework that the team hasn’t used before and just follow the technology stack. At this point, you may find it painful to maintain a mess of code written by your ex while failing to use your own expertise. The author was lucky enough to have made such a product. At that time, the requirement of the back end was that the API interface mapping name should not be written into the code, and the front end should be configurable; The back end was reluctant to modify the returned JSON, and I had to parse a bottomless pit of JSON data layer by layer. In this case, active communication with the team is one thing, and the other is to find their own positioning to use the technology. This is the basic culture of a good programmer, after all, this program you can not take out a person to sell.

3, from the user group to consider the selection

Front-end products for different user groups, the form of display will be different, modern Internet development for the same user group and divided into PC terminal and mobile terminal products. The main categories are as follows: external user PC, external user mobile, internal user PC, internal user mobile; At the same time, the use habits of domestic and foreign users will also have slight differences.

External user PC

For external users, visual experience is the first, SSR on PC is also very necessary. You’ll probably need a decent framework that supports SSR configuration and UI animation libraries, and research whether you want to support IE users (or even IE8). JQuery(or Zepto.js) can be useful sometimes.

External user mobile terminal

1. Mobile page Access: Use a mobile browser to access the Web page. Page switching is also a traditional link jump, belonging to the traditional Web page, the front and back end of separate development, page rendering, and PC terminal architecture is basically the same, just to do some adaptation work.

2. At present, React Native applications on mobile terminals use a large number of technology stacks for front-end development. The author has made advertising pages and activity details pages in the APP. If your product has Native requirements, React should be the best choice for the entire product stack. After all, React Native should be compatible with React Native.

Internal system user

1. Management system used by internal users on the page accessed by the PC. Such as OA, project management system, etc. You don’t even need to use an in-house component library. An open source framework + UI + diagram library will do the job.

2. Pages accessed by mobile terminal Most mobile terminal products used by enterprises are attached to apps such as enterprise wechat. Take the enterprise wechat for example, workbench open API, support secondary development. Such embedded H5 pages are also mostly single-page applications, which can be independently deployed and configured with wechat authentication.

Overseas customers

For overseas users, configuring PWA or AMP should be a mandatory architectural choice. PWA is also widely supported by all three frameworks.

4, from the expected effect of the product to consider the selection

Short life cycle

Products with a short life cycle often require a fast start: low barriers to entry, freedom to write, no mandatory adherence to best practices, and then scrap after use. This is where you need to use a simple, non-over-encapsulated architecture that doesn’t use ESLint and Typescript. There is even no need to arrange code review, since there is no consideration for post-maintenance.

Products for a long time

For long – term products, post – maintenance is important. Choose an architecture with a complete ecology that can be upgraded smoothly, encapsulates business components with modularity, does not require hard coding, and controls the number of lines of code per file. There are too many products on the same product line, such as the architecture of Ali Cloud, and micro services are also necessary.

Exploratory product

Exploration products are often short cycle products, which require more radical exploration of new frontier technology. If successful, there may be a transition to long-cycle products. This requires the ability of the architect to do a good job of portability.

General advice

Framework to choose

React OR Vue OR Angular ?

Brief introduction:

  1. Vue is the least difficult to get started, it is not easy to learn well,2.0to3.0Migration is not non-invasive. It starts graduallyTSSupport, but not natural support, you need to configure a little bit.
  2. React performs well, but it’s also hard to learn. It’s getting a lot of updatesHooksA lot of people can’t adapt. The counterpoint to complexity is its flexibility, and ecology is also doing well and supportingTS.
  3. Angular Natural SupportTSWith built-inRxjs, can be embedded, injected, and own unit tests. usedJavaStudents should be easier to accept. At present, the utilization rate is relatively low in China.

The authors suggest that,Use what your team uses! This is the main thing, my previous company evolved from the original front-end MVC architecture and retained a lot of itAngular 1.xThat upgrade is naturally to2.x Migration (two frameworks entirely, but not entirely); In addition, your team has accumulated a lot of expertise in the previous framework and has packaged a lot of tool-libraries and diagram-libraries to support it. Switching architectures may require repeating the wheel and increasing learning costs unless your client asks you to use them.

Depends on the smoothness of the upgrade

The dependencies in your package.json should be upgraded smoothly when the project is updating the framework. Before you reference dependencies, look at the supported versions of the framework described on their home page and see if they will support the new version in the future. Some instrumental dependencies are fine, but some dependencies, like moment.js saying it doesn’t support React18 (just kidding), will cost you a lot of refactoring.

The authors’ advice is that small projects with mature open source UI libraries and toolsets are fine, future refactoring costs are acceptable, and frequent updates to major releases are not likely to be involved. If it is an important project for long-term maintenance, it is recommended that major dependencies, such as the UI library, be used in-house, so that when the framework is upgraded, the UI can be synchronized with the upgrade, rather than the face of a third party library.

TS or JS

Don’t rush to use TS if you haven’t used it before, use it if you’ve been using it all along. JS is used for fast projects and TS is used for large projects.

UI/ chart library selection

I have the ability to use open source libraries, such as UI libraries such as ANTD, elementUI, MaterialUI, etc., and chart libraries such as D3.js, Apache ECharts, g2plot after secondary encapsulation.

The author’s common technology stack

The following is the author’s commonly used technology stack, after the company repeatedly polished, there is a certain reference value, but do not blindly believe.

  1. Angular9+ + ng-zorro(or build your own component library) +lodash-es + echarts + jsplumb.
  2. React17 + antd(or self-built component library) + self-built API Service library + self-built micro-service architecture +moment.js + Typescript + webpackFor state managementmobx.
  3. Vue2 + Vuex + elementUI + echarts + axios.

conclusion

There is no best architecture choice, only one that is right for you. Do not blindly trust the experience of others, or based on their own products and team research, according to the reality of the strategy.

Welcome comments and exchanges! If found inadequate place, I hope you great god not stingy give advice!