According to many front-end developers, the web is getting better and better every year. And this is good. The bad news is that we can simply not live to a good condition at such a rate of improvement. That the bottom from which we rise is so deep that it doesn’t come up at all. However, a lot has been written about how bad everything is in the HTML-CSS-JS bundle. So today we will dispense with woeful lamentations and dream about what can be done and why it will be done.
Right start
When you create a web page, component, or write an API, you are somehow faced with the solutions laid down 25 years ago. What seemed logical and correct in the days of the creation of the first graphical browsers still harks at us every day. It is unlikely that the creator of Javascript had the concept of creating something similar to modern web applications in his head. There were no mobile devices that today create most of the Internet traffic. CSS was seen as a way of styling a document, and not as a turing-complete language for creating presentations. Etc.
And year after year, as the world around us changed, the web tried to adapt. The changes layered on top of one another, but the old features did not disappear anywhere. And they determined how new features will be added, pre-determining the radius of curvature of the latter. This led to enormous specifications, to the actual monopolism of one engine in the browser market, to rather clever programming and assembly techniques. And for programmers, this all translates into an endless memorization of new crutches, because the web is now wholly and completely determined by a layering of specifications, and not by common sense or thought-out architecture.
Moreover, these specifications are written in the hope of pleasing everyone and, as a result, are completely unsuitable for anyone. Worse, they introduce a fairly high-level API that can not always be bypassed to solve the problem. So at the concept level we are limited by the DOM, the available security approach, and the data transfer protocols used.
More than one web
From the very beginning it must be recognized that the web as a single platform does not exist today. There are different classes of applications, sites, call it what you want, for example:
- text sites like blogs and wikipedia
- CRM / ERP applications
- multimedia applications
- games
- communication applications
- SHKAR selling landings
- social networks
- API. . CSS, . 90% . API . CRM/ERP , , , . ..
, API, . . - , Java, , . , . — , .
API . , . CDN (Press Ctrl+f5 to fix). ( ) . , , . , , .
, DOM, ? ? , ? CSS ? - ?
— ? , JVM? legacy , — .
«»
, «». - . ( ) , . - , . . . , , . IE6, .
, , , . . - . - . , . , , , , , . , . , .
. . DOM, V8 ( - JS ).
. Google -, , . , , , . . , .
App Browser, , . «» , -, . , - . , . - .
. , . , by design.
? . , Delphi/QT/WPF/WinForms .. , - GUI . . , — , 10 .
, , . — . - . - , .
, 15 . , , , . .
, . 10, , App Browser 100% . , , () . , . .
. , .
?
- , . - CMS, -, - , -. . , . , , - . , . -. , , .
-, , . , , . ? , -? , 4- - ? JS? Firefox Chromium-based .
. . . . , accessability . , , . . , -.
« ». , 100% . . DOM , . -. , , ? , , , .