4 ms·

I've thought about this a lot. I'd throw away HTML/CSS and start over with a client centric rendering protocol that is based on presentation first and semantics

by graiz 5y ago

I've thought about this a lot. I'd throw away HTML/CSS and start over with a client centric rendering protocol that is based on presentation first and semantics second. The language would be run-time compiled to describe exactly what needs to be rendered on the page and would be streamable to prevent rendering locks. Typical page size would go from 1M typical to 64K-128K being typical. Images would stream in after initial page renders but since most pages would fit in 1-3 packets, you'd see pages pop-in very quickly. This would also be very helpful for poor connection, mobile and the developing world. I'd fund a team to do this if I could figure out who would buy it.

hoten 5y ago
Could you explain how this is different from SVG?
- quickthrower2 5y ago
  That’s a cool side project! Build a modern site in svg. I guess you’d need JS to make it responsive
- graiz 5y ago
  SVG is still a markup language, not one that is compiled or streamable. It's also not relational. While you can design a page with SVG it's not parametric in that you can't modify the content or the page and have it re-flow, resize or act responsivly. I would also describe SVG as a very verbose instruction set rather than a reduced instruction set.
biztos 5y ago
How would this handle accessibility? 64-128K page size is perfectly doable in HTML today if anybody actually cares enough to do it. How much of the bloat in say an Amazon page is the JavaScript? Is there something about your protocol that would prevent the big players from re-normalizing 1M page size with it?
- graiz 5y ago
  Accessibility is easier because items have clear locations and sizes without computing cascading rules. This also allows for easier navigation (left/right) in addition to traditional logical / tab-stop order. If done right it would be harder to screw-up. Current HTML is very easy to inadvertently hurt accessibility. In my tests it would be very difficult to create a 1Mb page. You would need 10,000 text/image/nodes of actual content (not tags or containers). This just doesn't happen. Presentation is strictly separated from code execution so first load is never blocked by code. Code can dynamically change the page but does so by directly changing the DOM using limited server side-commands. In other words it's truly a thin client browser. You can bloat up the server with as much code as you want but the client side stays lean.
ketzu 5y ago
Would this really change page sizes significantly? Take amazon landing as an example: * HTML/CSS: 80 KB and 88 KB * Images: 3.2 MB * Font: 180 KB * JavaScript: 260 KB Reducing HTML/CSS to 1 Byte each, would make nearly no difference, because huge parts of pages are in images.
- graiz 5y ago
  This wouldn't help Amazon as much because they are obsessive about performance. An out-of-the-box wordpress site loads MB's for anything basic as do most of the top-visited sites on the web. In the developing world they are using the Internet at dial-up speed, only on mobile, and often charged per KB.

by graiz 5y ago

hoten 5y ago

Could you explain how this is different from SVG?

quickthrower2 5y ago
That’s a cool side project! Build a modern site in svg. I guess you’d need JS to make it responsive
graiz 5y ago
SVG is still a markup language, not one that is compiled or streamable. It's also not relational. While you can design a page with SVG it's not parametric in that you can't modify the content or the page and have it re-flow, resize or act responsivly. I would also describe SVG as a very verbose instruction set rather than a reduced instruction set.

biztos 5y ago

How would this handle accessibility? 64-128K page size is perfectly doable in HTML today if anybody actually cares enough to do it. How much of the bloat in say an Amazon page is the JavaScript? Is there something about your protocol that would prevent the big players from re-normalizing 1M page size with it?

graiz 5y ago
Accessibility is easier because items have clear locations and sizes without computing cascading rules. This also allows for easier navigation (left/right) in addition to traditional logical / tab-stop order. If done right it would be harder to screw-up. Current HTML is very easy to inadvertently hurt accessibility. In my tests it would be very difficult to create a 1Mb page. You would need 10,000 text/image/nodes of actual content (not tags or containers). This just doesn't happen. Presentation is strictly separated from code execution so first load is never blocked by code. Code can dynamically change the page but does so by directly changing the DOM using limited server side-commands. In other words it's truly a thin client browser. You can bloat up the server with as much code as you want but the client side stays lean.

ketzu 5y ago

Would this really change page sizes significantly? Take amazon landing as an example: * HTML/CSS: 80 KB and 88 KB * Images: 3.2 MB * Font: 180 KB * JavaScript: 260 KB Reducing HTML/CSS to 1 Byte each, would make nearly no difference, because huge parts of pages are in images.

graiz 5y ago
This wouldn't help Amazon as much because they are obsessive about performance. An out-of-the-box wordpress site loads MB's for anything basic as do most of the top-visited sites on the web. In the developing world they are using the Internet at dial-up speed, only on mobile, and often charged per KB.