> Web technology is designed for documents CSS/HTML have some pretty significant problems, but this hasn't been true for years. And in any case, 90% of the nat

> Web technology is designed for documents CSS/HTML have some pretty significant problems, but this hasn't been true for years. And in any case, 90% of the native apps I use are basically interactive documents anyway. Unless your definition of "non-toy" apps is primarily referring to apps like Blender or Photoshop, most of the native apps on my computer could be trivially represented in HTML. You should think of HTML as a render target, not as a document layout framework. HTML isn't where you lay out your application; HTML is where you present your application's data to the user. > in Web you either create all 1000 GUI elements[...] or you use a infinte scrolling like pattern, check Youtube as an example, go to a specific channel video list, you see only 2- 3 rows of videos, then you scroll and wait for next few rows, scroll and wait again, scroll and wait again The reason you wait on Youtube is because it's making network requests, not because the HTML is slow to insert. The way you would solve this problem if you weren't worried about network performance would be to use a virtual DOM, because the DOM is a rendering target, not a layout framework. "Native" controls on the browser do restrict you quite a bit, but that's at least partially on purpose, because the whole point is to use "native" browser conventions with those components. How many times on HN do we see people complaining about scrolljacking on a website? And you want people to be able to style scrollbar colors on top of that? There was significant debate on HN about a month ago about whether it was even a good idea for browsers to respect `autocomplete="off"` in input fields. A significant chunk of your users do not want you to do this kind of stuff. What the web does do is that it provides you mechanisms to avoid the native components if you have a really, really pressing need to do so -- while encouraging you that most of the time, using built-in browser behaviors will be better for both you and the user. If Twitter was using native components and not hijacking browser behavior, text input wouldn't insert extra spaces whenever you copy-pasted. If PayPal was using a regular numeric input instead of some custom-built monstrosity, it would respect the delete key and render more consistently with your browser theme. If Youtube wasn't forcing itself to be a single-page app, you wouldn't get bugs where videos failed to load on navigation. Seeking pixel-level control over every element is the opposite of how you get applications that look and feel native. Looking and feeling native means respecting platform settings and conventions.