Why is the web so complicated?

Discussion year results in the frontend suddenly became the 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 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 complicated, difficult, but reliable and not giving failures.
Why is the web so complicated?
source of the picture
generating layout .
And in the web itself appear monstrously complex solutions that previously could work exclusively in the desktop mode. I myself had 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 big enough, 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? 3r3174.
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, the development of potential audience and accessibility - web technologies are ahead of both mobile and desktop solutions. And now it has broken up into as many as three directions: 3r3323229.
3r3194. Development of completely static and near-static sites with partially dynamic content (galleries, pop-ups and so on)
3r3194. Development of "classic" web applications on server frameworks (django, rails)
3r3194. Developing client web applications 3-333199.  
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 they were replaced by tools that allow you to reuse code as efficiently as possible, statically detect errors, and build 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: reuse of the 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 work 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 for reusing code on native platforms appeared. 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: the use of 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 familiarize 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 the synchronization of 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 "coefficient", which tells how many juniors can simultaneously control the middle one and how many middle ones the leading developer can control. From the latest examples of such capabilities, es6 imports partially solve the problem of cyclic dependencies, and 3r3-300. prettier
allows 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 led to the majority of 3r3106. "jаvascript 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, we got on the one hand a completely adorable platform for reusable code everywhere, a syntax that allows you to work with large flat commands. But
3r3115. Everything became difficult and everyone got confused
And no one understood what to do. What is the problem? In those same three different categories.
3r3194. The development of fully static and near-static sites with partially dynamic content: for this type of application, HTML is characterized as an entry point, a maximum download speed and an optional JS 3r-33199.  
3r3194. 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), and partially you need to write yourself 3r3-3999.  
3r3194. 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. 3r-33199.  
What I mean by the entry point: this is an entity whose loading equals the minimum delivery to the product user. 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:
3r3145. Isomorphic applications 3r3174.
By "isomorphic" in web development, it usually means 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 3r3152. Nuxt
, eg.
Both tasks are relevant to them: the web application must 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 the content, the other for the 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 went to JS, but CSS still remains. And most importantly, we want to not deliver a single extra byte to the user. And then the 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.
3r3173. Now everything is in JS and it is good
It is worth making 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 applies to 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 ? 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 on knowledge, except 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 are enabled depending on the letter), Web IDE like Cloud9 or Internet bank .
But if a typesetter 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 fall for persuasion.
+ 0 -

Comments 10

huxewuj 15 May 2019 12:10
When somebody whines that the cutting edge web has turned out to be excessively confused, each time I need to remind this individual that he believes this advanced web with his cash in Internet banks and types of procurement, individual correspondence on informal organizations and web renditions of moment detachments, and individual documents in the mists. Also Can Someone Write My Essay - 24HWriteMyEssay.com, undoubtedly he truly needs the advancement procedure of these frameworks to be entangled, troublesome, however solid and not giving disappointments.
khan 17 June 2019 17:18
You have performed a great job on this article.  It’s very precise and highly qualitative. You have even managed to make it readable and easy to read. You have some real writing talent. Thank you so much. $500 loan online bad credit from UnitedFinances.com
Hassan1102 21 June 2019 20:37
I got what you mean  , thanks  for posting .Woh I am happy  to find this website through google. <a href="http://nursing.hu/mirapatches/">nursing</a>

I got what you mean  , thanks  for posting .Woh I am happy  to find this website through google. nursing
Shan 22 June 2019 22:49
I recently came across your blog and have been reading along. I thought I would leave my first comment. I don’t know what to say except that I have enjoyed reading. myshapeit
Farman 26 June 2019 12:49
If more people that write articles involved themselves with writing great content like you, more readers would be interested in their writings. I have learned too many things from your article. http://www.euronote.it/rivista/numero48.htm
Anna Sally
Anna Sally 30 June 2019 14:13
I appreciate this article for the well-researched content and excellent wording. I got so interested in this material that I couldn’t stop reading.  Your blog is really impressive. psicologifvg
Anna Sally
Anna Sally 30 June 2019 20:41
Wow, this is really interesting reading.  I am glad I found this and got to read it.  Great job on this content.  I like it. <a href="https://snapseedapks.com/">Snapseed Download</a>
Saqib 12
Saqib 12 23 July 2019 21:32
Thank you so much as you have been willing to share information with us. We will forever admire all you have done here because you have made my work as easy as ABC.Buy Automatic Instagram Followers

hassan 1102
hassan 1102 15 August 2019 11:55
Your blog is too much amazing. I have found with ease what I was looking. Moreover, the content quality is awesome. Thanks for the nudge! http://www.autoforum.be/forum/auto-algemeen/autosport/44887-superstars-series-o

hassan 17 August 2019 21:31
Took me time to read  all the comments, but I really enjoyed the article. It proved to be Very  helpful to me and I am sure to all the commenters here! It’s always nice when  you can not only be informed, but also entertained!  http://twoje-zycie-zdrowe-zycie.info

Add comment