3 ms·
How would you "radically simplify" the web without causing breakage?
by goto11 6y ago
How would you "radically simplify" the web without causing breakage?
- tannhaeuser 6y agoCouple ideas: - specify profiles that can be targetted by web developers and browser developers; demand web assets to be delivered in sane and portable formats (rather than a mish-mash of JSON configs and plugins) - in public tenders, demand that web sites for public information don't become apps: announce sites requiring JavaScript as application/html - promote, invest into new web frameworks for apps (not sites) that abstract/isolate from HTML+CSS as underlying rendering mechanisms such that these can run stand-alone (like applets used to); I kindof like React, but unfortunately it ties apps to browser runtimes which isn't adequate for apps most of the time IMO - transfer specs to standardization bodies with fair representation and transparency - push for energy-efficiency; require that sites with not that great information density can render on easily-produced devices before the end of times - push distributed web tech Going for complete backward-compat is impossible, but humans used to do just fine without today's web of shit. HTML is rooted in markup technology which had highly organized content representations since the late 1960s.
- goto11 6y ago> announce sites requiring JavaScript as application/html You assume sites would deliberately make their sites stop working in browsers because you don't like JS? This is not going to happen. What would be the incentive?
- tannhaeuser 6y agoDon't know; a noscript browser that doesn't suck?
- jhoechtl 6y ago> - in public tenders, demand that web sites for public information don't become apps: announce sites requiring JavaScript as application/html That would be bold. Unfortunately I dont see any lobbyist being motivated to inform policy makers accordingly and no politican himself having the knowledge and cochones for this step.
- walterbell 6y agoStart with a markdown-optimized browser that makes it easier to publish new static content with minimal attack surface.
- c-smile 6y agoLet's imagine a browser (UA) that supports basics of HTML (language portion of HTML5) and CSS (e.g. v 2.1). Yet it has WebVM instead of JS. WebVM is a virtual machine similar to JavaVM but with DOM, CSSOM and layout APIs exposed in it as a runtime. So if some site needs flexbox in its CSS then it can be included as: <link href=".../css-flexbox.bytecodes" rel="extension"> If JS then <link href=".../es6-compiler.bytecodes" rel="extension"> and so on. This would allow a) keep browser small and maintainable and b) open room for innovations in Web technology beyond browser vendors and comities. As an example: TypeScript can be compiled to WebVM bytecodes instead of JS.
- tannhaeuser 6y agoNot bad an idea at all! Hadn't considered bytecodes for layout algorithms, though I guess it would work with regular js as well, and I AFAICS Project Houdini is about providing the necessary core rendering API.
- c-smile 6y ago> would work with regular js as well In principle JS may work but it is too slow for that. Function calls are too pricey, no integer arithmetic, etc. At least in my Sciter (https://sciter.com https://sciter.com) element's layout controller must have three methods: void calc_min_maxes() // calculates min-content and max-content int layout_width(int px_new_width); int layout_height(int px_new_height); so it is quite easy to add new layout modes. This way I've added () flow:grid(...); // a la display:grid flow:horizontal; // a la display:flexbox flow:stack; // no alternatives in standard CSS etc. Modern Java (and C# for that matter) are almost ideal for such things, especially considering modern effective JITs and VMs.
- zzo38computer 6y agoWhat is needed in some ability to identify the extension, so that the user may substitute their own, or may want to cache it instead. This would also improve speed, since it can avoid download it for each separate web page, and can also substitute a native code implementation.