Many teams incorporate scaffolding modules when developing front-end engineering solutions. Although the understanding and implementation of engineering varies from team to team, the positioning of scaffolding is basically the same: create initial project documentation. This is a seemingly simple rule, but it is not so simple how it should be understood and implemented.
Before exploring the depth of this guideline, let’s look at similar mature solutions, such as Eclipse. This well-known IDE software is used by many Java and Android developers. When you create a new project through Eclipse, it provides a wealth of configuration items that can be summarized as follows: Select project type -> Select project catalog -> Configure project details -> Final confirmation -> Done. This is the most basic and must have scaffolding process. The essence of scaffolding can be summarized from this process: encapsulation of the solution.
From this, we have a clear definition of scaffolding: scaffolding is to create the initial files of the project, and is essentially the encapsulation of the solution.
Of course, there are many details involved in the scaffolding creation project process, and the variety and complexity of front-end projects makes it even more difficult to implement. This article briefly expounds some of the author’s shallow views, hoping to give you some inspiration.
1. The role of scaffolding in front-end engineering
1.1 “disposable” scaffolding
I wrote one beforeAnalysis of front-end engineering, briefly introduces the front-end workflow model, which can be summarized as the following figure after simplification:
Scaffolding is responsible for creating initial files during the project initiation phase in the front-end workflow. Unlike other functional modules, scaffolding is a completely “start-down” module, with no pre-dependencies. Once the initial project documentation has been created, scaffolding is useless.
The “use and discard” working mode makes the implementation of scaffolding a great leap. Scaffolding can be done with the simplest copy-and-paste, but a full-fledged scaffold with a rich set of interactive configurations is “just” creating a bunch of initial project files. Why spend time and manpower developing complex scaffolding schemes when the result is the same?
A transition is a quantum mechanical term for a process by which states change by leaps and bounds. The term is used here because highly complete scaffolding provides a qualitative leap over the lower form.
This is a very real problem. With the rapid pace of Internet product iterations, the input/output ratio is what the development team focuses on most, and scaffolding “seems” to be the lowest. If you look at the front-end tool ecosystem today, it’s mostly build tools, and of course we can’t deny that build is the most complex feature. Scaffolding tools are minimal, and discussion of scaffolding in the front-end community is rare. You may have heard of the famous Yeoman, but it’s hard to think of a second scaffold tool.
Scaffolding may not be very “cost effective” on its own, but if your team has a complete front-end engineering system in place, scaffolding will be much more useful. Front-end engineering system has a wide range of functions, many types of packages, and the corresponding configuration items are also very complex. Also, most front-end engineering architecture developers are not front-line business developers. The engineering system is a black box for business developers, who don’t need to understand the intricacies of it, just how to configure it. Therefore, the requirement of business developers is to develop fast configuration and generate configuration items corresponding to the project, which not only meets the functional requirements of the project, but also does not have “confusing” redundant functions.
The front-end engineering system is not a development framework such as Vue and React. The engineering system is only a “service” and an auxiliary one. The learning curve should be flat, and business developers should not be required to spend time learning details, even if the documentation is clear and understandable. This is the scaffolding to solve the real problem, to put it simply:
- Quick build configuration;
- Reduce the cost of framework learning.
As front-end engineering systems become more complex, scaffolding will play an increasingly important role.
1.2 Elements required for scaffolding
1.2.1 Execution Environment Only local
Before discussing the elements that go into implementing a scaffold, let’s take a look at the scaffolding execution environment. Reviewing the simple front-end workflow mentioned earlier, the simplest scenario is that the framework provides a complete set of local toolchains, and scaffolding, development, development server, build, and deployment testing are performed locally, as shown below:
Further teams will build CI (continuous integration) platforms to move build and deployment functions to the cloud for easy workflow control and uniform code management. The diagram below:
Regardless of the workflow, scaffolding is always executed locally.
1.2.2 Mode is not fixed
The reason why there is no fixed model of front-end scaffolding is that the positioning of front-end engineers is not fixed by different companies. For example, the front end of some companies is still “Chetuzai”; In some companies the front end is responsible for all the logic development on the browser side but the HTML template layer is still maintained by the server engineer; Some of the more advanced teams advocate the “big front end,” which takes care of the browser layer and the middle layer (which hosts HTML rendering). The unfixed positioning of front-end engineers leads to the unfixed model of front-end projects, and scaffolding naturally has diversity.
Regardless of the working mode, a good front-end scaffold should have the following elements:
- Rich but not tedious configuration items;
- Linkage with other function modules to generate corresponding basic configuration items;
- Automatic installation dependency;
- High scalability of the underlying layer;
- Support for multiple runtime environments, such as the command line and the Node.js API.
How to understand “rich but not fussy”? For example, assuming that the build function supports automatic generation of CSS sprites, there are two configuration items:
- Whether to enable CSS sprites;
- Specify the hash icon directory.
Should scaffolding implement configuration items for CSS Sprites with both configurations open to user configuration? Obviously not necessary, scaffolding as long as open whether to enable CSS sprites configuration items, because this is the most important point affecting this function, hash icon directory even if the user does not configure, using the default scheme will not cause any inconvenience.
In addition, scaffolding should be implemented not only with current requirements in mind, but also with changes and additions to subsequent requirements. Therefore, a good scaffold should be highly scalable and easy to customize for different types of solutions. In that sense, Yeoman has done the best so far.
2. Open source front-end scaffolding scheme analysis
Clear the basic working mode of scaffolding, we might as well look at the current industry can learn from the case. Here we introduce three types of scaffolding:
- Sails is a Node.js fullstack framework that uses sails to generate scaffolding designed primarily for server-side code;
- Youku PHP middle layer framework is the development framework used by the author’s former team, which is not open source at present. The simpler sails were used to create a complete WebApp, complete with Controller layer and browser layer code;
- Yeoman is widely known as an open source scaffolding tool, which does not provide any direct file creation capabilities on its own, but is a scaffolding underlayer framework that allows you to customize your own scaffolding implementation.
Two of them are open source projects, available on Github.
2.1 Losa-node. js fullstack framework
Sails are a Node.js full-stack framework that uses MVC architecture on the server side. Sails generate is the scaffolding module that can create initial code for the following modules by default:
- App-create a new sails project;
- API – Create a pair of models and controllers;
- Model – Create a model;
- Controller – Create a controller;
- Adapter – Creates an adapter;
- Generator – Creates a scaffold template.
The Adapter in the Sails framework is simply a mapping Adapter that simplifies the Model operation API.
Notice the last type: generator. Sails added a custom scaffolding template API to the default scaffolding.
The default sails are mostly server-side scaffolding, which can only be added manually to browser-side code (JavaScript/CSS/Views) without using other scaffolding templates.
2.2 Youku – PHP middle layer framework
Youku PHP middle layer framework is not open source, so a rough introduction to it.
The mid-tier framework does not involve the Model layer, does not involve database operations, only includes the Controller and View layers. The idea of this framework is that every module is treated as a WebApp, and every WebApp is a SPA, such as the login/registration module Passport, the subscription module Subscribe, etc. Scaffolding can create only one file type: a full WebApp. These include Controller files, Resource files (browser layer), and routing configuration files.
Since each module webApp is a SPA and contains a Controller file, a View entry file, an entry JS file, and a CSS file, the initial scaffold creation file is sufficient, and the developer only needs to manually add the submodule files. At the same time, the technology stack is unified, build function is fully packaged, no additional configuration is required. This form of scaffolding basically meets the needs of youku PHP middle layer framework.
2.3 Yeoman – Probably the best open source scaffolding framework
You can’t mention scaffolding without mentioning Yeoman, a veteran. Yeoman has been around five years since it was first announced on Google I/O in 2012. For the front-end tech community, five years is enough to make most technologies obsolete, and Yeoman has held on to this day without fading. If we take a quick look at the front-end technologies of five years ago, Knockout and Backbone might come to mind, YUI 3 might come to mind, and even the horror of being dominated by ExtJS. Then look at the current state of the market for these technologies that were so hot at the time. Yeoman has survived for so long thanks to its clear positioning.
Yeoman’s slogan is “THE WEB’s SCAFFOLDING TOOL FOR MODERN WEBAPPS” – SCAFFOLDING, but I personally think it’s more appropriate to call it SCAFFOLDING. Instead of creating project files directly, Yeoman provides a complete set of development scaffolding apis that you can use to customize any scaffold solution that fits your business needs. In other words, Yeoman doesn’t encapsulate any solution, it’s completely open and highly extensible.
Yeoman’s API has all the elements you need for a scaffold listed above, so if you need to develop your own scaffold, Yeoman is your best choice. Future posts will detail how to use yeoman’s Node.js API to integrate it into the engineering framework.
3. Summary
Although there is no fixed form of front-end scaffolding, there are essential elements. From the point of view of function realization, it is necessary to consider highly matching with business; From the perspective of the underlying framework, it is necessary to have a high degree of scalability and implementation environment diversity support.
This is probably the most crap ever written about the concept of front-end scaffolding, lol. The content is the author of some shallow experience, I hope to give you some inspiration.
PS: MADE a simple video sharing, you can use wechat to scan the TWO-DIMENSIONAL code to watch.
