I'm pretty sure today's web is going at least two different directions that can't be easily merged together. On one side we have textual and basic graphical dat

I'm pretty sure today's web is going at least two different directions that can't be easily merged together. On one side we have textual and basic graphical data that is supposed to be controlled by user, like resizing, scaling, copying, bookmarking, drag and drop, and so on. On the other side we have interactive applications supposed to work strictly as-designed with complex handling of internal state, like Adobe Flash or HyperCard did. When you merge those completely together you get a frankenstein, when you kinda have the content controllability until you don't, when the content is displayed as designed if you are lucky enough. I would like to remind you the whole reason for creation of Angular/React/Vue/Polymer/etc — that is because you have this overbloated DOM which is slow despite being implemented in fast low-level compiled languages. The main reason is complexity of calculation of inline elements (text and images with wrapping) and two-way propagation of size (parent to child and child to parent). At the same time the whole idea of CSS as a customizable style description (similar to LaTex/MS Office/OpenOffice styles) is completely forgotten while becoming inseparable from the rest of the content e.g. visibility styles, inability to show the content in different sizes, etc. And now we need workarounds like Webpack and HTTP/2 for putting together separate files that are not so separate by their functions. Because, in fact, a simple textual HTML is separate, its CSS is separate, but dynamic application within this page is a single entity composed of html+styles+js+images — similar to adobe flash swf blob. I've been writing native GUI apps for like seven years, but now I write web SPA, and the more I write them, the more I feel like today's HTML is not a good platform for true GUI application, because within DOM simple GUI things have to be implemented as complex entities. Yes, we got a flexbox which makes positioning much simplier than float blocks or scripted positioning. However, we also got "display: grid" and "column-width" which also implement flexbox-like behavior, but slightly different. In the end it doesn't matter how many layout mechanism we are going to have — it will never be enough. Recently we got HTML5 canvas, including WebGL, but we got no good language to write the program for this canvas. Actually, WebGL is the closest to the double-world model of web browser I'm trying to suggest, because WebGL uses a separate high-performance shader language to describe the WebGL-canvas logic which is uncoupled from the main web page's logic. We can also render from a webworker into WebGL canvas, and chromium supports OffscreenCanvas capable of webworker rendering. However, both 2D canvas and WebGL lack one important thing — two-way composability i.e. include html page into canvas. Just like native GUI apps struggle with including native elements into internal browser, canvas struggles with including web browser into 2D or WebGL context. Actually, Microsoft once solved this problem by implementing support of custom elements in the IE browser, thus bringing a two-way composability. However, due to windows-only nature of the solution it had not achieved wide acceptance. Some cross-platform execution environment is required for success, like JVM or CLR — WebAssembly being the most relevant today, but the composability problem has to be solved. Until then, the developers would still prefer to keep the composability by avoiding HTML5 <canvas> and clinging on the old DOM as long as they can. And by the way, speaking about cross-platform runtime. JVM, CLR, optimized JS, WebAssembly, and non-native-architecture VM have similar performance, so it's really not the fundamental execution speed that killed Java applets, but a failed GUI model "every pixel is drawn by JVM bytecode". WPF, UWP, JavaFX tried to fix the issue, until "everything is web" came. Now about a second small idea I have and I've been struggling with for many years of web surfing. Bookmarks, history, and tabs are not separate things. The gap between them is closing but closing very slowly. We are getting web services that live between pages, we are getting frequently visited pages as a kind of bookmarks, we are getting cheap tabs that are loaded only when user switches to them, but nobody is brave enough to erase the separation and create a single visited-tab-bookmark entity. Today's computational resources clearly allow us to save some amount of data about every visit without forcing the user to be a bookmark keeper, especially when the user has no convenient tools for managing current tabs he's working with, and as for me I work with 50-300 tabs daily, so it's really a pain to manage them with this "ten tabs on the screen"-oriented tool modern browsers have. I know tree-like tabs exist, but usually they have their own issues. I'd prefer to open the tabs in a full-screen view, preferably with preview. Some people in the older days would save onto HDD every page they visit — they had a struggle sorting all the crap they've got.