5 ms·

I think part of this deal must involve radically simplifying the web and reflect on the EU's sponsorship of W3C via ERCIM. We've seen web tech becoming more com

I think part of this deal must involve radically simplifying the web and reflect on the EU's sponsorship of W3C via ERCIM. We've seen web tech becoming more complicated all the time, with self-acclaimed "standardization bodies" (WHATWG) acting as fig leaf for Google's take-over of the web. Now with Firefox on the brink to drop out, like all other "browser vendors" (Opera, MS) except Google before, and failing to create a new browser engine in about 10 years of development (!) with highly competent developers, it must be clear to everyone there's something very wrong with trusting the web as the universal digital medium for accessing nearly every piece of information. It's also becoming extremely hard to find pages that used to be ubiquitous only 2 years ago, so we're heading into an information crisis (on top of information warfare). W3C may have acted in good faith, but in the end contributed to irresponsible CSS complexity (which, in turn, is the result of having no standing/statue and no representation but rather a "pay-as-you-go" sponsorship model). WHATWG have consistently denied including HTML/CSS profiles for simplified subsets (as eg suggested by MS). Time to stop playing this naive web march of progress game only benefitting very few US companies, at the expense of everybody else.

goto11 6y ago
How would you "radically simplify" the web without causing breakage?
- tannhaeuser 6y ago
  Couple 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 ago
      Don'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 ago
  Start with a markdown-optimized browser that makes it easier to publish new static content with minimal attack surface.
- c-smile 6y ago
  Let'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 ago
    Not 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 ago
    What 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.
foolmeonce 6y ago
I don't think it's fair to make Google particularly responsible for WHATWG and the over complicated web. The other vendors were on board and used the sentiment against XHTML from those who directly did write-once HTML, right before the web out grew their manual skill level and became capable of offering tooling. The results have naturally been a hodge-podge since WHATWG was about using the sentiments of everyone against a standard, and the results are everything in every direction except the track the W3C standard was on.

goto11 6y ago

How would you "radically simplify" the web without causing breakage?

tannhaeuser 6y ago
Couple 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 ago
    Don'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 ago
Start with a markdown-optimized browser that makes it easier to publish new static content with minimal attack surface.
c-smile 6y ago
Let'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 ago
  Not 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 ago
  What 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.

foolmeonce 6y ago

I don't think it's fair to make Google particularly responsible for WHATWG and the over complicated web. The other vendors were on board and used the sentiment against XHTML from those who directly did write-once HTML, right before the web out grew their manual skill level and became capable of offering tooling. The results have naturally been a hodge-podge since WHATWG was about using the sentiments of everyone against a standard, and the results are everything in every direction except the track the W3C standard was on.