TARS, make the level of frontend-routine 0%

Frontend is getting harder every day. Tasks are more voluminous, the user interface is richer, HTML, CSS and Javascript are larger, and the front-end sleep is shorter and more disturbed. It is necessary to structure the code correctly, perform many routine tasks (compiling css and js preprocessors, assembling sprites, preparing and optimizing images, minifying files, etc.). If you work in a team - this automatically increases the complexity of development. To solve these problems, I created TARS , a html layout builder based on gulpjs .

We at 2GIS know about frontend-rutin firsthand. The company creates many web projects of varying complexity: from portals and online maps, to various landing pages and promotional sites. We are tired of the boring copy-paste when working with html, preparing graphics for displays with high pixel density, minifying everything that can be minimized, etc. It seemed that all these things the machine can easily do for us. So I decided to develop a tool to automate the lion’s share of the frontend routine.

UPD: we released a lot of new products in TARS and even wrote an article about it!
')
What I wanted to get from this tool:

automate everything you can;
use existing practices, and therefore use the familiar programming language - JavaScript, the familiar ecosystem - Node.js and npm;
basic set of functions in one tool;
convenient API;
cross platform

Before writing ours, at first my colleagues and I looked for ready-made solutions. There were a lot of them. Here squeeze, as it seems to me, the most interesting projects:

Each of these tools is good in its own way: somewhere there is excellent documentation, somewhere the task storage system is well implemented. But all these solutions are either too complicated to modify, or too simple, that it is easier to write your own than to modify the existing one. At the same time, the functionality would have to be expanded precisely. For example, none of the solutions provided workflow graphics preparation for screens with high pixel density.

Then was born TARS, which has absorbed all the best of the already finished projects.

TARS is a set of gulp tasks for automating most frontend tasks + the ability to easily add new ones if something is missing. TARS can be called a gulp framework. Suitable for both individual developers and large teams. With TARS, it is easy to develop projects of any complexity: from landing to a huge portal. You don’t even need to know how gulp works, since everything that was possible was taken out in options, all the code and use cases are documented.

Key features of TARS.

Jade or Handlebars as an html template or plain html (when choosing Handlebars).
SCSS, Less, Stylus as a css-preprocessor or tube CSS (syntax is supported within any of the preprocessors). Recently appeared fmp project, in which it is also available.
The ability to separate data from the view, transferring the data in the form of a js-object in the templates. So we use the same template many times, but with different data, without copy-paste, libraries and frameworks. More on this will be discussed below.
Here is the chokidar .
Truly smart image manipulation. Maximally simplifies the development of screens with high pixel density. This will be discussed below.
Easy to expand your task. Modular structure.
Excellent documentation.
Creating an archive of the finished assembly. Trifle, but nice.

And, of course, concatenation, minification and optimization of everything that is possible, several assembly modes, etc.

TARS has an impressive set of options, each of which is described in detail in the documentation.

We have already used TARS in developing a website about technology, products and design.
2GIS, various landings ( 2GIS promo for Windows Phone , 2GIS franchise for Kazakhstan , 2GIS internal developer conference site), 5pm website, etc.

How it all works

You will need:

Node.js (maybe soon on IO.js, working on this);
Globally installed gulp;
Archive with TARS .

After we have downloaded the archive, we execute the gulp init command. It will connect the selected html template and css-preprocessor (specified in the config), it will create the basic file structure. Everything, you can sausage. TARS runs on all desktop platforms.

In the near future I will make a yeoman-generator.

Before you start working with the collector, I recommend to read the documentation .

Basic build commands

In total there are two main commands:

gulp build (or just gulp);
gulp dev.

The first team makes a ready build of the project, and the second runs TARS in development mode. In dev-mode, the project is built without minifikatsiy and with running votcherami behind the files.

Commands are diluted with a small number of flags:

gulp build (or just gulp) (--min, --release, --ie8);
gulp dev (--lr, --tunnel, --ie8).

With gulp build, you can use the –min key, and then miniated js and css files will be connected to html. When using the --release key in html, all the same minified files will be connected, in the name of which there is a random hash.

With gulp dev, the --lr keys are used to start livereload in the browser, which opens automatically (you can select the browser in the config file). The key - tunnel will share the layout from your local computer to the external web. You will receive a link in the console, on which the layout will be available on the web.

Also, with any command, you can use the --ie8 key, which will launch additional tasks for assembling with support for Internet Explorer 8. The browser is special, and that's what makes the workflow special.

All installation instructions are in the documentation.

Project structure

In the "tars" folder are all the files of the collector (built-in and user task with vocher, various helper) and a folder with the source of the project (markup). At the root is the collector config, the dependency lists for the project, the config for checking js code style and the main gulpfile.js.

├── gulpfile.js # gulpfile  ├── tars-config.js #   ├── package.json #  TARS ├── user-package.json #   └── tars/ #     gulp └── helpers/ #  └── tasks/ #   └── user-tasks/ #   └── watchers/ #   └── user-watchers/ #   └── markup/ #     └── modules/ #  └── pages/ #   └── static/ #   (css, js  ..) └── docs/ #

A project is a set of pages (pages folder), a set of modules (modules folder) and a folder with various statics (static, by default. The name can be changed in the config).

Pages are the simplest templates in which modules are connected. The simplest example of a module is menu or footer. To make it clearer, in terms of BEM, a module is a block. And if without BEM, then the module is any independent entity on the page.

 exampleModule/ #   └── assets/ #      └── ie/ #   ie8  ie9 (ie9/ie8.scss|less|styl) └── data/ #       ├── data.js #      js- ├── exampleModule.html # Html|Jade-  ├── exampleModule.scss|less|styl # Scss|Less|Stylus-  ├── exampleModule.js # Js-

Each module has its own html-, css- and js-presentation, a folder for various files for the module (images, video files, etc.), a folder for browser styles IE8 and IE9, a folder with a data file for modules. All listed files and folders are optional for the module. Any module can include other modules.

It is not necessary that the module is a separate entity. You can use modules as you like.

A folder with statics can contain subdirectories for storing images, js-files of libraries and plug-ins, files of the selected css-preprocessor + various files that should end up in the root of the project, for example, favicon or robots.txt

Be sure to read how JavaScript and CSS are glued together - it depends on how you need to use the files of the collector.

The file structure is created automatically when the project is initialized. It is generally unchangeable, but there are a number of optional directories, plus a number of options for changing the name of already existing collector folders. The file structure is described in detail in the documentation.

For JavaScript, separate options have been created in which you can specify where else you need to take js for gluing. Thus, you do not need to go into the collector files if you want to use any framework in which there is not only such an entity as a module (or a view, or a directive, or something else there).

Work with templates

Suppose that we have a page that has a top, side, and bottom menu. Something like this:

The menus are very similar to each other, but have different links, small differences in styles. Further we will speak in terms of BEM. Each menu is a block. Sketch a little html to implement the menu, which we will eventually put in the modules folder (modules / menu / menu.html):

 <nav class=”menu”> <ul class=”menu__list”> <li class=”menu__listItem”> <a href=”url” class=”menu__listItemLink”>title</a> </li> ... </ul> </nav>

I will not give all the code, but it is obvious that the footwoman turns out quite solid. Now we will put all the data for this menu (links and menu item names) into a separate file (data / data.js in the module folder):

 menu: { header: { mod: 'header', list: [ { url: firstLinkUrl, title: firstLinkTitle } ... ] }, side: { mod: side, list: [ { url: firstLinkUrl, title: firstLinkTitle } ... ] }, footer: { mod: footer, list: [ { url: firstLinkUrl, title: firstLinkTitle } ... ] } }

Now let's improve our menu template a bit (use handlebars):

 <nav class=”menu {{#if mod}} _{{mod}} {{/if}}”> <ul class=”menu__list”> {{#each list}} <li class=”menu__listItem”> <a href=”{{ur}}” class=”menu__listItemLink”>{{title}}</a> </li> {{/each}} </ul> </nav>

In this case, a certain mod was added, with the help of which we can customize CSS for the menu depending on its position.
It remains only to connect these menus on the page:

 <html> <head></head> <body> <header> {{> menu/menu menu.header}} </header> <aside> {{> menu/menu menu.side}} </aside> <footer> {{> menu/menu menu.footer}} </footer> </body> </html>

With the help of the handlebars helper ">" we connect the menu module with the menu view (each module can have several views) to the page and transfer certain data to it.

Total we have 1 template + 1 data file for the menu, which is used in two different places. Thus, you can implement a module that is very convenient to reuse. It remains only to add that the same functionality is implemented for jade.

Preparation and storage of graphics

Today there are many screens with high pixel density. Let's figure out what that means.

As an example, consider the IPhone 3GS and IPhone 4 smartphones. In 3GS, the screen resolution is 320x480, and in 4-ki - 640x960. As we can see, the resolution has increased exactly twice with the same diagonal, which means the pixel has become smaller. In order to level this difference between pixel sizes (and we are managing the pixels in CSS), the device-pixel-ratio (or dppx) parameter appeared, which shows how many real screen pixels are contained in a logical pixel, which we operate in css. For example, for an IPhone 4 display, this parameter is 2. You can read more on the W3C website .

Suppose we have a sprite PNG image. Such pictures have fixed sizes. If we place such a sprite on the IPhone 4 screen, then each pixel of the sprite will be blurred into two screens, and if you smear such a picture by the number of pixels 2 times larger than the size of the picture, the image will look awful.

To get rid of this problem, you can use an image 2 times larger, while setting the size of the image in CSS based on the size of the original image (the background-size property).

At the moment there are screens with dppx from 1 to 4 (they will soon be higher). Cooking sprites for four screen sizes is a lot of work.

Rescues SVG. Vector, does not depend on the dppx-screen, perfectly rendered in modern (and not only) browsers. Only one size can be made, and this image will look the same on all screens.

Unfortunately, SVG has several drawbacks:

SVG poorly displays radial and other complex gradients (linear displays are excellent);
complex shadows are poorly displayed;
not displayed in IE8.

Total we have two approaches: SVG for all that we can. For the rest we prepare PNG images. For IE8, we will simply rasterize SVG images and prepare a sprite of them.

To easily manage these approaches, two remarkable mixins were written (SCSS syntax):

  @include bg-svg($svg-image-name);  SVG ; @include bg($png-image-name);  PNG .

At the same time, for IE8, everything will be generated and connected automatically; for png-images, media requests will be generated that connect certain png-pictures depending on the type of screen. In general, separate css files are generated for IE8 and IE9. Files for IE8 are created only if we run the build with the --ie8 key.
An example of the use of mixins:

You can imagine the volume of the generated code, how much work was done automatically.

More details about the assembly of graphics can be found in the documentation, and the approach itself is perfectly described in the presentation of web developer Timofey Chaptykov.

Custom Tasks

TARS already has everything you need to develop projects of any complexity, but you cannot please everyone. Everyone can have some kind of specificity, some additional tasks. To solve this problem, a custom task template was created (tars / user-tasks / example-task.js). On this basis, you can make your task, which is easily integrated into the existing infrastructure of the collector.

Each default task can issue a notification of an error or successful completion, launch a page reload in the browser and connect other tasks if you need to make dependencies between them.

Since the main package.json (the file in which the dependencies of the collector are located) can be changed by the assembler itself (for example, when executing the gulp update-deps command), user dependencies should be stored in a separate place. For this there is user-package.json. The syntax for declaring dependencies is the same as for package.json.

There is also an example of a user posted in the tars / user-watchers directory.

Future plans

There are plans to add new features:

move to Gulp version 4;
add template engines;
add pre- and post-processors for CSS;
add support for ES6;
Use Browserify or webpack.

In the near future, we will release version 1.3.0 and translate the documentation into English (literally next week it will be ready). Plans for new versions can be viewed on GitHub .

I forgot to mention that it is open source, so I’m waiting for your pull requests, questions on expanding the functionality of the collector in the issue . Duplicate direct link to the repository of the project.

PS: March 28–29, Novosibirsk will host the largest IT conference in the Urals - odeFest . At this conference, TARS will have a separate booth. If you come to CodeFest - come and ask questions.

Source: https://habr.com/ru/post/254105/

All Articles