Why is the web so complicated?
Discussion of the results of the year in the frontend suddenly became a subject of discussion . I will add my opinion, and I will be glad to hear the opinion of others.
It seems to me that it makes sense to talk about the fact that what is happening in the modern web is perceived outside and inside completely differently. Yes, and "inside" has several levels. Looking "again they complicate the layout" on the one hand is absolutely correct, but on the other - wrong and flawed, but the look "do not stop us from building abstractions" is also ineffective.
When someone complains that the modern web has become too complicated, every time I want to remind this person that he trusts this modern web with his money in Internet banks and forms of purchase, personal correspondence on social networks and web versions of instant messengers, and personal files in the clouds. And most likely he really wants the development process of these systems to be complex, difficult, but reliable and not giving failures.
By modern frontend and his friends they now understand much more than it seems from the outside. These are classic websites and SPA, applications on the electron, and mobile applications on cordova, NativeScript, React Native, and even Flutter. This is a complex infrastructure with CDNs, geocentralized services, these are chat bots on JS, and even machine learning tools for optimizing builds and even generating layout .
And in the web itself appear monstrously complex solutions that previously could work exclusively in the desktop mode. I myself managed a couple of years ago to touch the development of a full-fledged browser of the genome in the browser - I was engaged in providing performance and 60FPS, which was a fairly large, but solvable problem. Even 5 years ago, no one could have imagined that the genome browser could not be something installed on a powerful computer, and this solution allowed doctors and researchers to work with the genome even from a tablet or lightweight laptop.
Why?
At the moment, a bunch of HTML + CSS + JS is one of the most powerful in building interfaces - not only due to its capabilities, but also the number of solutions built on it - css-frameworks, libraries of visual components, interfaces to a huge number of services and SAAS . In terms of efficiency, in hours of development for potential audience and accessibility, web technologies are ahead of both mobile and desktop solutions. And now it has broken up into three areas:
- Development of completely static and near-static sites with partially dynamic content (galleries, pop-ups and so on)
- Development of "classic" web applications on server-side frameworks (django, rails)
- Development of client web applications
And each of them has a completely different specifics.
Development on JS was really painful, so solutions that solved this pain began to appear.
If you look at them, you can see something very interesting: first, solutions like jQuery and CoffeeScript began to appear, reducing the redundancy and verbosity of the language. But they quickly faded away, and in their place came the tools that allow for the most efficient reuse of the code, statically detecting errors, and building effective abstractions, “hiding” certain levels of complexity behind simple and well-described interfaces.
GraphQL appeared, solving problems with the complexity of describing, documenting and maintaining REST. Appeared TypeScript and Flow, which solved the problem of lack of typing. There are new entities of the language, allowing to work effectively with asynchronous operations, classes, data streams. There was WebAssembly, allowing to reuse code from other languages, and do it quickly.
All these solutions are aimed at the same thing: the reuse of code and the potential for building "flat" commands. They solve the problem in order to take someone else's code and start using it.
This is clear evidence that the web is developing in the direction of working in large teams, it has become a platform for "adult" solutions.
Even more clear evidence was a series of events that occurred further: React Native, NativeScript, Dart + Flutter and other solutions appeared for reusing code on native platforms. This is a very important point: in the absence of the ability to use other languages on the web, companies have begun to adjust their processes in search of a silver bullet, which will allow them to reduce far from small development costs and time to deliver the new functionality to all customers. It is important for any project to be fast, and high-level specialists began to unite in search of opportunities to work effectively on JS.
By the way, for the same reason, the template engines began to partially die away: using one more semantics proved to be less effective than using familiar HTML for all with small extensions on JS (Angular, Vue) or using just a language to describe the layout (React, Flutter). The inability to expand, the need to acquaint developers with a new language, the risk of the platform dying out, decentralization led to the fact that they began to prefer template frameworks of frameworks that tried to be as close as possible to HTML / DOM platforms.
However, in addition to efficiently writing code, there is also a "factor" for command synchronization. If the language allows you to work super-fast, but at the same time synchronizing a separate functional between the two developers creates tremendous pain, it most likely remains niche. Therefore, many language features and solutions are aimed precisely at reducing problems with synchronization and the absence of problems. They reduce this "factor", which tells how many juniors can simultaneously control the middle one, and how many middle ones the leading developer can control. From the last examples of such possibilities - es6 imports partially solve including the problem of cyclic dependencies, and prettierallows you to get the expected, well-giving merge-in git-e code regardless of how the developer writes. It should not be beautiful, it should be well synchronized.
And in the end, in just a few years, the web as a platform was captured by large companies and serious teams, which caused the majority to suffer from "javascript fatigue" . By the way, the main complaint about Google’s near-monopoly on the web in the face of Chromium lies in the fact that they push into the capabilities of the web platform and JS what they need (although this usually coincides with what most companies need).
As a result, on the one hand we got a completely adorable platform for reusable code everywhere, a syntax that allows working with large flat commands. But...
Everything became difficult and all confused
And no one understood what to do. What is the problem? In those same three different categories.
- Development of completely static and near-static sites with partially dynamic content: for this type of applications, HTML is typical as an entry point, maximum download speed and optional JS
- Development of "classic" web applications on server-side frameworks (django, rails): these solutions currently feature HTML loading as an entry point, but instead of maximum download speed, they are focused on reusing code, DRY, and backend integration. The JS code is partially generated by the framework (notifications, forms, turbo links, and so on), partially you need to write yourself
- Development of client web applications. This is where the unexpected happens: HTML instead of the entry point becomes both the application manifest and the rendering platform, and the “entry point” becomes JS.
What I mean by the entry point: this is an entity whose loading is equal to the minimum delivery to the user of the product. If the user needs to show information, then we need HTML + CSS, if you run the application - you need JS, which runs from HTML.
And in order to confuse everyone completely - a fourth category appeared:
Isomorphic applications
By "isomorphic" in web development, they usually mean something that works on both the server and the client. In this mode, applications can work on react, angular, vue.js, there are ready-made frameworks - Next and Nuxt , for example.
Both tasks are relevant for them: the web application must both deliver its initial state to the user as quickly as possible and act as an application. In other words, they should deliver both HTML and JS as two entry points, one for content and one for application. This creates two conflicting sections: on the one hand, the amount of data to be delivered should be minimal, on the other - the code should be reused. For JS, this is solved by webpack chunks, code splitting and dynamic code loading, the templates have gone to JS, but CSS still remains. And most importantly, we want to not deliver a single extra byte to the user. And then an idea came to someone after all: such applications really have two entry points. They can be treated as two autonomous entities.
From this, the concept of CSS-in-JS was born, focused on two separate processes: generating a CSS file for static content, and preserving styles next to components.
All left for JS.
Now, in JS, you can find styles, layout, and the actual code.
Now everything is in js and that's good
It is necessary to make another digression - now to the grocery side.
Any product in development or development is important to be able to "move" in the other direction. This is valid on any of the levels:
The ability to turn a visual component into a component with minimal logic by adding a line of code is very cool. The need to rewrite it from scratch is not cool.
Cheap transformation into a SPA or into an application with a server renderer is really cool, but it is very rarely possible. It is more reasonable, if it does not impose costs, to start from the very beginning with such a platform.
Therefore, almost any web project that has the risk that it will need to become rendered on the server, the risk that it will have to refactor components, move from one templating engine to another - tries to run away from risks.
When there is a single platform, within which some entities can turn into others rather cheaply, the development is carried out pretty darn fast.
In the case of an angular / react / vue application, this is exactly the case. They are difficult to understand. Not as complex as Angular 1, of course, but all the same - the path to their realization is long, and there are not enough semi-annual online courses to understand them. But they make it possible in a few hours to do what used to be done in a few weeks, and in a few days - something that used to take several months.
However, the opposite is also true - many do not need them, but they are used because they are “fashionable”.
When they talk about the infrastructure architect of a group of web and mobile apps and the coder, it will be damn hard for them. Now it is so different directions that they will have no intersections in knowledge, except for JS.
The next time you want to say "the web has become very complicated and bloated" - think about how difficult it is to design and build a google inbox-level email client (with intelligent entities that turn on depending on the letter), a Web IDE like Cloud9 or an Internet bank .
But if the coder comes to you and starts telling about the fact that he needs react, because he needs strong typing and decorators for the layout of the landing, do not be persuaded.