Javascript-only: homogeneous web project architecture

The work of the front-end developer is filled with tasks to optimize the code, transfer the finished fragments between project versions, etc., the complexity of which is often determined by the historically established approach to the development itself. In his report at the HolyJS conference, which will be held on June 5 in St. Petersburg, front-end developer Alexey Ivanov will tell how the volume of these problems can be reduced by abandoning the usual approach, when an application consists of scattered parts, in favor of “all-in-JS” . On the eve of the conference, we talked with Alexei about what particular difficulties the ideas proposed by him save (the ideas themselves will be more fully disclosed in the report).



- Tell us briefly about yourself and your work.
')
- My name is Alexey Ivanov, I am a front-end developer at Evil Martians. This is a distributed development team that helps large companies, such as eBay or Groupon, as well as various startups in a short time and without any problems launching Internet projects with the expectation of rapid growth.
In Martians, I am currently engaged in a front-end service called eBay Social for the Russian office of eBay. This is a classic Ruby on Rails application with individual interactive parts written in React.
Before Martians, I made the first version of the SPA application for ridero.ru on Backbone, helped launch a couple of services for Yandex using bem-tools, and also developed other server and SPA applications of different sizes, which allowed me to touch a bunch of different tools and methodologies development. I like to study and compare different ways of organizing code, working with dependencies and resolving conflicts used in different methodologies and tools.

- Where did the idea of ​​a global change in the approach to development come from?

- Martian front-tenders work with two main types of projects.
First, we create classic projects on Ruby on Rails. In such projects, the rendering of templates occurs on the server inside Rails themselves, and the assembly of CSS and JavaScript lives separately in Node.js and Gulp or another assembler. We use pre- and postprocessors, collect individual files into common bundles and compress the code of Clean CSS and UglifyJS, but at the same time CSS and JavaScript know each other very little, but they don’t know anything about the HTML they work with.

Secondly, we create one-page applications (SPA) that build HTML, and often CSS right in the browser, and communicate with the server only at the data level.
In fact, these are two parallel worlds in the modern front end. At some point, the SPAs budgeted from the classic server applications into a separate evolutionary branch and went their own way with their own set of mutations and new ideas. As a result, the toolkit that is used on these two types of projects is very different.

The tools and approaches used in modern SPAs allow us to solve many classic front-end development problems with minimal effort: intersecting the names of variables and CSS classes in the global namespace, deleting unused code and styles, creating CSS and JavaScript assemblies for specific sections and pages. The most pleasant thing is that the main part of the work here is done for you by the machine with your minimum intervention.

Therefore, a return to classic server applications after working with SPA causes pain and suffering. Things that worked in the SPA out of the box, now either do not work, or require a lot of time and effort to implement.

As a normal person, I am looking for ways to get rid of pain and suffering. And my report represents the results of these searches. I want to talk about existing problems, how to solve them in the SPA, tools that appeared in the SPA, but which can also be used on the server, as well as concepts from the SPA, which are not yet implemented as server software for server applications (but in in case of software implementation, they would help solve many of the problems that are unresolved right now).

- Can you give examples of the mentioned problems inherent in the development of server applications?

- In large projects there are a number of tasks related to optimizing download speed and reducing the amount of code that is sent to the browser.

Suppose we send the user an HTML page, CSS, and JavaScript. CSS is written according to the BEM methodology. One of the ways to optimize is to shorten long names in CSS, which we wrote when developing for ourselves in order to avoid conflicts with other classes.

Suppose we have a class:

.block__element_modificator {} 

And these lines we have about a few thousand. I want to send something less long instead, let's say:

 .b1 {} 

How do we do this?
CSS classes are used in several places: firstly, in the CSS file itself, secondly, in HTML, and, thirdly, in JavaScript.
Let's start with the CSS file. The first thing to do is to combine the CSS files into one, because if we replace in different files, we cannot be sure that there are no conflicts (technically, you can shorten the names without merging into one file, but you will need an intermediate list replacements, which will have to be loaded during the processing of each new file; this option is more difficult and costly to implement in terms of the necessary resources - Ed . Next, we will go through the received file with some program and get two things at the output: a file with replaced names and a list of replacements in the form:

 { 'block__element_modificator': 'aBc' } 

So far, everything is simple. Go ahead.
Now we need to replace these classes in HTML. This is no longer so simple: classes can be assembled from separate pieces of strings, variables in templates can be part of classes, we can collect the name of a class from these parts not inside the class attribute, but somewhere separately, etc. Well, somewhere we can use one class on a tag, and somewhere - several. We need to identify all these points:

 <div class="block__element  block__element_{some_variable_name} {some_other_class_from_variable}"> 

If we miss at least one such place, the layout will break.

In addition, the class names we use in JavaScript. There it is even more difficult to determine what exactly our class name is:

 var className = "block__element_modificator"; $elem.addClass(className); 

but do not edit anything extra:

 var block = ...; 

It is worth noting that a class in JavaScript can be stored simply as a variable, by which it will not be clear that this is a class. Again, any logic can be used in the construction of class names, or the variable can be called as a class, i.e. just a regular expression will not be able to replace.

As a result, a simple task - the abbreviation of class names - is transformed into something non-trivial.

With all this, the compression of class names gives us not a very big gain in size. There are more effective ways to optimize the size of styles - for example, cleaning files from unused rules. When using libraries like Bootstrap or icon fonts like Font Awesome, hundreds of unused rules fall into the assembly. Likewise, the weight is added by the rules omitted and uncleaned when refactored. If we could send only really used rules to the browser, this would give us a much larger gain in size.

- Is it also difficult to remove unused elements from an assembly? And does this “historical tail” really give a big boost to the size of the assembly?

- If the project develops for several years, then tons of garbage can accumulate in it. And I’m talking not only about individual class names, but also about complex nesting selectors. For example, the rule:

 .news .title {} 

On our site, both the news class and the title class can be used separately. In this case, in such a combination, as in the rule, they may never occur. In this situation, the rule can also be safely removed. As a result, to remove unused code, we need to understand the page structure, and not only in the current state, but in all possible (the page can be for an authorized or unauthorized user, with popup, personal advertising or a selection of records of a certain type in the friends feed). It is worth considering that for understanding the structure of the page, HTML alone is not enough for us, since we have javascript that can change all that. In an amicable way, after we built a tree of possible states for a page, we need to understand how our JavaScript can change this tree.

And only after we understand this, we can, with a clear conscience, delete the rules from CSS.

The same goes for the JavaScript abbreviation. We can automatically remove unused variables and functions. But we can’t delete the code for working with HTML, because without knowing the structure of the page, we cannot understand what we really need from it and what will never be used.

- Is it possible to just use some other approach when optimizing?

- We can try to go on the other side. For example, breaking a common CSS and JavaScript bundle into separate bundles for different pages, so that the user is sent only what is needed for the current page. Suppose he came to the main page - let's send him only what is necessary for the main one, so that it would appear faster, and load the rest later. For simplicity, we can even do not build pages, but according to the user's state - for authorized or unauthorized (i.e., add a part after authorization).

Just to do this quickly, we again need to know which page is on, and how HTML, CSS, and JavaScript affect each other. Of course, we can prescribe all this with our hands, but this work is very long and ungrateful.

And we have so far discussed only reducing the size of files sent to the browser. And there are also problems of name conflicts, dependency resolution, transferring code from a project to a project so that nothing is forgotten, deleting unnecessary things from the source in the editor and many others.

- Is there really no tool for solving these problems? How, then, to get out of this "vicious circle"?

- At the beginning of the interview I just said that there are now two parallel worlds in the front end: the world of server applications and the world of SPA. In the SPA world, many of the problems described above have been successfully solved, and no one remembers them, but in the world of server applications they are still relevant.

At the same time, we cannot just take everything and start writing SPA, because there are still a large number of areas where the dynamics on the pages are few, and search engine indexing and accessibility from the maximum number of devices is relevant: these are online stores, directories, government websites with high requirements for accessibility and other.

Unfortunately, simply taking the existing tools from the SPA is also impossible. They were created under a different environment with different requirements. But the ideas and approaches that are used in these tools are wonderfully transferred and used anywhere. It is about these ideas, approaches, features and problems of their application in different environments, as well as about what can now be used both there and there, and there will be my report on HolyJS .

- The idea seems to be on the surface. Why does she not go to the masses?

- The idea is still going to the masses. There are isomorphic applications and attempts to cross React with Django and Rails . There are bem-tools, the reason for the creation of which were many of the problems that I will talk about in my report. There are attempts to make friends with HTML and CSS on the server through pstcss-modules , which was written by my colleague Sasha Madyankin. That is, there are many approaches to the problem from various angles, although there is not one common popular, generally accepted solution.

One of the main reasons why this decision has not yet appeared, in my opinion, is that the number of SPA developers is much less than the number of developers of server applications. And even among the last those who came across and worked with all the tools and concepts that I will talk about in the report are not very many.

Just so that as many people as possible learn about these concepts and start thinking in these terms and, I hope, write tools for working with them on the server, I prepare my report.

Thank you for the conversation!

As part of the conversation, we briefly described the problems that frontend developers face every day. About how exactly the “everything in JS” approach can simplify the situation, listen to Alexey Ivanov's report on HolyJS. In addition, the conference will be several other reports related to the architecture of web applications. Well, of course, our today's interlocutor will be able to ask you questions in the same place, without departing from the cash register.