5 ms·

> I think the ship has sailed and we won't have a new browser from scratch any time soon. I think the big mistake is that we let the HTML spec get so complicat

> I think the ship has sailed and we won't have a new browser from scratch any time soon. I think the big mistake is that we let the HTML spec get so complicated that it's essentially become Google's platform. Although it's technically open, it certainly looks and smells like a monopoly. How do we fix it? Maybe someone could make alternate rendering engines that use Canvas and WASM?

ilaksh 5y ago
https://github.com/runvnc/tersenet https://github.com/runvnc/tersenet
mike_hearn 5y ago
This is a topic dear to my heart. Actually, I'm working on a first-step project to help address this very issue. It's worth reflecting on a few important points. 1. "We" didn't "let" HTML5 become anything. HTML5 reflects whatever browser makers choose to ship, which is why it's un-versioned. The attempt at an industry wide consensus building effort around what HTML should be failed (W3C), largely because it spent most of its political capital on implementation-independent academic dreams rather than incremental improvements. But if you're shipping a browser then what you want is incremental improvemetns. 2. I think by alternative rendering engines you mean different approaches to rendering UI and documents, that aren't HTML. But then you describe something that would have to fit entirely within the constraints of whatever browser makers impose. You'd be trying to build a competitor to browsers on top of browsers. The industry has a history of that and it doesn't work - browser makers always find reasons to kill them off. Flash, Java, Shockwave, ActiveX. Some were more secure than others but in the end, browsers killed them all. They won't tolerate competing platforms that ride inside the browser. That means to make a competitor to HTML5 you need to go outside the browser and build new kinds of browser and document/app technology. 3. To do (2) it really helps to have a good, easy to use deployment technology. Watch this space.
- ilaksh 5y ago
  Seems really interesting so I have been Googling to try to figure out what you are talking about. Is the Hydraulic product a way to easily deploy GraalVM software? And maybe by adding some type of search and document browsing capability, it can become a new type of web browser? Could you take a look at my comment in this thread and also at https://github.com/runvnc/tersenet https://github.com/runvnc/tersenet I have not totally updated that but my current thinking is that we really want to finish deconstructing the overlay operating system that the "web browser" has become. For example, we should actually not bundle the information browsing program and application VM together, but rather have a simple standard for them to work together. Such as, the info browser can save the list of the application binaries to a file or directory that the VM system knows to watch. We also actually want to further decompose this into a multilevel window manager concept. On the first level, just a rule that applications save and reload window layouts when the user adjusts them. I really think it should be a goal to standardize on some web assembly extension with simple UI features like canvas or framebuffer and keyboard events.
  - mike_hearn 5y ago
    Yep, I saw your comment. You're definitely thinking along the right lines here. It's all about incremental decomposition and recombination. Hydraulic's first product is currently in private beta. If you like, email me and I'll add you so you can see what it is. Actually email me anyway, because I'm putting together a list of people who are interested in post-web technologies for perhaps a podcast/interview series. My address is in my profile.
- gwbas1c 5y ago
  > To do (2) it really helps to have a good, easy to use deployment technology. That's why I suggested "Canvas and WASM." It's very trivial to get a "Canvas and WASM" program running in the browser. All you need to do is plan the API inside of WASM very carefully, because... > That means to make a competitor to HTML5 you need to go outside the browser and build new kinds of browser and document/app technology. ... the next step is to remove the HTML & Javascript adaptors, and "build new kinds of browser"s that are compatible with the WASM API in the "Canvas and WASM" hack! In this case, the newer browser would probably perform much better than the "Canvas and WASM" hack. :) Edit: If you read this and want to talk further, my profile has a link to my web page. You can email me or track me down on LinkedIn.
  - mike_hearn 5y ago
    I can't email you because the email link on your website is broken unfortunately. But sure, would love to chat about this stuff. You can find my email in my profile if you want to say hello. I'm putting together a list of people who have some interest in the post-web space with the goal of starting a little community, or maybe a podcast series. Would be great to have you take part! Re: canvas+HTML5. Yeah, you can definitely go that way but there are some issues. My own analysis took me down a slightly different route. The issue with using WASM/Canvas is: 1. You need a UI toolkit that can draw into the canvas. Those are hard work. Making a simple one that gets abandoned after a year is easy, making one that's got a competitive feature set and which is maintained over the long term; much harder. Some do exist and it'd make sense to leverage them. 2. Of the toolkits that do exist, none are particularly well suited to wasm (maybe Qt could work?). In particular you normally want to write GUIs in high level GCd languages, but wasm doesn't support GC nor language-specific JITCs. 3. If you look at things developers are expressing a need for today when they go outside the limits of HTML5, it's often a combination of things like performance, OS integration, hardware integration, a wish or need to use other programming languages etc. HTML5 is a poor UI toolkit or really barely a UI toolkit at all, but that's not what's driving people currently. So the question is what would your offer be in the short term if you're restricted to wasm and canvas? 4. Finally, if you look at where HTML5 is weak and not innovating, or not even in the game at all, in my view there's lots of areas but they mostly require you to be outside the browser to fix them. So I think the way to go is to make being outside the browser a much more hospitable place and in that way encourage people to build competing neo-browsers. Let 1000 flowers bloom, if you see what I mean.
- bogomipz 5y ago
  >"The attempt at an industry wide consensus building effort around what HTML should be failed (W3C), largely because it spent most of its political capital on implementation-independent academic dreams rather than incremental improvements." Interesting. Can you elaborate on what some of those academic dreams are/were that derailed things? Did they end up in the spec or were they just bikeshedded to death?
  - mike_hearn 5y ago
    What I meant here was the combination of X[HTML] and RDF. During the era when the W3C was firmly in charge, their tech output was all oriented around making the web stack more rigorous and - as they saw it - better suited for training AI. HTML itself was more or less abandoned and everyone told to move to XHTML, the benefits of which would be the ability to embed new DSLs like SVG, app-specific markup, and the ability to express abstracted "knowledge" in the form of RDF triples. All these specs still exist of course and they were all implemented in browsers, but hardly anyone uses them. There were several big problems: 1. XML has strict validation rules. Much, much easier to build a parser and tools for, but, not compatible with most web content which is full of markup errors. For a brief period some people heroically tried to fix all the errors in their markup and make it fully validating, but the effort involved was high especially for big sites and the reward was ... well, there was no reward really. The only tool most people care about is the browser and browsers had complicated hacky HTML parsers nobody understood. But, pixels got to the screen and they got their reliably. Especially consider how important that is given the prevalence of HTML-by-string-concatenation. In XHTML if you made a tiny error in that process then the browser would stop and render an error page, meaning a site outage that doesn't show up in your server logs. HTML has the opposite philosophy: keep on trucking no matter what. Your page might render a bit garbled at worst, but users can tolerate that occasionally. 2. RDF/XML/Tim Berners-Lee turned out to have the wrong idea about AI. Or, well, maybe. I suspect the jury is still out on that one given that stuff like GPT-3 doesn't really meet people's prior expectations of what AI will be like, but still. The idea of expressing human knowledge in the form of an abstracted graph of nodes, in which all the nodes and edges are labelled with URIs, and then serializing that to XML and embedding it into XHTML web pages. Yeah, no. Big, big specs. No tools that actually used any of it to do anything useful. Meanwhile in all of this HTML4 was stagnant, missing lots of small quality of life fixes that ordinary webmasters and browser makers really wanted. So you can't blame browser makers for killing off the W3C. It wasn't meeting the world's needs. On the other hand, once unleashed from any kind of broad consensus or standards process, HTML more or less ceased to be a spec you could actually implement. You can't even say you're compliant with it because a week after your statement it might have had another 100 pages added to it.

ilaksh 5y ago

https://github.com/runvnc/tersenet https://github.com/runvnc/tersenet

mike_hearn 5y ago

This is a topic dear to my heart. Actually, I'm working on a first-step project to help address this very issue. It's worth reflecting on a few important points. 1. "We" didn't "let" HTML5 become anything. HTML5 reflects whatever browser makers choose to ship, which is why it's un-versioned. The attempt at an industry wide consensus building effort around what HTML should be failed (W3C), largely because it spent most of its political capital on implementation-independent academic dreams rather than incremental improvements. But if you're shipping a browser then what you want is incremental improvemetns. 2. I think by alternative rendering engines you mean different approaches to rendering UI and documents, that aren't HTML. But then you describe something that would have to fit entirely within the constraints of whatever browser makers impose. You'd be trying to build a competitor to browsers on top of browsers. The industry has a history of that and it doesn't work - browser makers always find reasons to kill them off. Flash, Java, Shockwave, ActiveX. Some were more secure than others but in the end, browsers killed them all. They won't tolerate competing platforms that ride inside the browser. That means to make a competitor to HTML5 you need to go outside the browser and build new kinds of browser and document/app technology. 3. To do (2) it really helps to have a good, easy to use deployment technology. Watch this space.

ilaksh 5y ago
Seems really interesting so I have been Googling to try to figure out what you are talking about. Is the Hydraulic product a way to easily deploy GraalVM software? And maybe by adding some type of search and document browsing capability, it can become a new type of web browser? Could you take a look at my comment in this thread and also at https://github.com/runvnc/tersenet https://github.com/runvnc/tersenet I have not totally updated that but my current thinking is that we really want to finish deconstructing the overlay operating system that the "web browser" has become. For example, we should actually not bundle the information browsing program and application VM together, but rather have a simple standard for them to work together. Such as, the info browser can save the list of the application binaries to a file or directory that the VM system knows to watch. We also actually want to further decompose this into a multilevel window manager concept. On the first level, just a rule that applications save and reload window layouts when the user adjusts them. I really think it should be a goal to standardize on some web assembly extension with simple UI features like canvas or framebuffer and keyboard events.
- mike_hearn 5y ago
  Yep, I saw your comment. You're definitely thinking along the right lines here. It's all about incremental decomposition and recombination. Hydraulic's first product is currently in private beta. If you like, email me and I'll add you so you can see what it is. Actually email me anyway, because I'm putting together a list of people who are interested in post-web technologies for perhaps a podcast/interview series. My address is in my profile.
gwbas1c 5y ago
> To do (2) it really helps to have a good, easy to use deployment technology. That's why I suggested "Canvas and WASM." It's very trivial to get a "Canvas and WASM" program running in the browser. All you need to do is plan the API inside of WASM very carefully, because... > That means to make a competitor to HTML5 you need to go outside the browser and build new kinds of browser and document/app technology. ... the next step is to remove the HTML & Javascript adaptors, and "build new kinds of browser"s that are compatible with the WASM API in the "Canvas and WASM" hack! In this case, the newer browser would probably perform much better than the "Canvas and WASM" hack. :) Edit: If you read this and want to talk further, my profile has a link to my web page. You can email me or track me down on LinkedIn.
- mike_hearn 5y ago
  I can't email you because the email link on your website is broken unfortunately. But sure, would love to chat about this stuff. You can find my email in my profile if you want to say hello. I'm putting together a list of people who have some interest in the post-web space with the goal of starting a little community, or maybe a podcast series. Would be great to have you take part! Re: canvas+HTML5. Yeah, you can definitely go that way but there are some issues. My own analysis took me down a slightly different route. The issue with using WASM/Canvas is: 1. You need a UI toolkit that can draw into the canvas. Those are hard work. Making a simple one that gets abandoned after a year is easy, making one that's got a competitive feature set and which is maintained over the long term; much harder. Some do exist and it'd make sense to leverage them. 2. Of the toolkits that do exist, none are particularly well suited to wasm (maybe Qt could work?). In particular you normally want to write GUIs in high level GCd languages, but wasm doesn't support GC nor language-specific JITCs. 3. If you look at things developers are expressing a need for today when they go outside the limits of HTML5, it's often a combination of things like performance, OS integration, hardware integration, a wish or need to use other programming languages etc. HTML5 is a poor UI toolkit or really barely a UI toolkit at all, but that's not what's driving people currently. So the question is what would your offer be in the short term if you're restricted to wasm and canvas? 4. Finally, if you look at where HTML5 is weak and not innovating, or not even in the game at all, in my view there's lots of areas but they mostly require you to be outside the browser to fix them. So I think the way to go is to make being outside the browser a much more hospitable place and in that way encourage people to build competing neo-browsers. Let 1000 flowers bloom, if you see what I mean.
bogomipz 5y ago
>"The attempt at an industry wide consensus building effort around what HTML should be failed (W3C), largely because it spent most of its political capital on implementation-independent academic dreams rather than incremental improvements." Interesting. Can you elaborate on what some of those academic dreams are/were that derailed things? Did they end up in the spec or were they just bikeshedded to death?
- mike_hearn 5y ago
  What I meant here was the combination of X[HTML] and RDF. During the era when the W3C was firmly in charge, their tech output was all oriented around making the web stack more rigorous and - as they saw it - better suited for training AI. HTML itself was more or less abandoned and everyone told to move to XHTML, the benefits of which would be the ability to embed new DSLs like SVG, app-specific markup, and the ability to express abstracted "knowledge" in the form of RDF triples. All these specs still exist of course and they were all implemented in browsers, but hardly anyone uses them. There were several big problems: 1. XML has strict validation rules. Much, much easier to build a parser and tools for, but, not compatible with most web content which is full of markup errors. For a brief period some people heroically tried to fix all the errors in their markup and make it fully validating, but the effort involved was high especially for big sites and the reward was ... well, there was no reward really. The only tool most people care about is the browser and browsers had complicated hacky HTML parsers nobody understood. But, pixels got to the screen and they got their reliably. Especially consider how important that is given the prevalence of HTML-by-string-concatenation. In XHTML if you made a tiny error in that process then the browser would stop and render an error page, meaning a site outage that doesn't show up in your server logs. HTML has the opposite philosophy: keep on trucking no matter what. Your page might render a bit garbled at worst, but users can tolerate that occasionally. 2. RDF/XML/Tim Berners-Lee turned out to have the wrong idea about AI. Or, well, maybe. I suspect the jury is still out on that one given that stuff like GPT-3 doesn't really meet people's prior expectations of what AI will be like, but still. The idea of expressing human knowledge in the form of an abstracted graph of nodes, in which all the nodes and edges are labelled with URIs, and then serializing that to XML and embedding it into XHTML web pages. Yeah, no. Big, big specs. No tools that actually used any of it to do anything useful. Meanwhile in all of this HTML4 was stagnant, missing lots of small quality of life fixes that ordinary webmasters and browser makers really wanted. So you can't blame browser makers for killing off the W3C. It wasn't meeting the world's needs. On the other hand, once unleashed from any kind of broad consensus or standards process, HTML more or less ceased to be a spec you could actually implement. You can't even say you're compliant with it because a week after your statement it might have had another 100 pages added to it.