4 ms·

> 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

> 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.
- gwbas1c 5y ago
  Thanks, I'll follow up. (And fix the email link) FYI: You can do GC in WASM. I'm actively working in Blazor right now, which is C# compiled to WASM. Even though it's GC, it still relies on the Dispose pattern. (IE, if an object has a resource or needs explicit cleanup, it can't rely on the garbage collector to know when to release its resource or otherwise do its cleanup.) But I'd be careful about being too opinionated about forcing a language onto the consumers of an API. I believe WinForms (the first C# UI API) was a thin wrapper around the Windows UI API, but I never did a Windows UI in Win32 directly to fully validate my assumption.

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.

gwbas1c 5y ago
Thanks, I'll follow up. (And fix the email link) FYI: You can do GC in WASM. I'm actively working in Blazor right now, which is C# compiled to WASM. Even though it's GC, it still relies on the Dispose pattern. (IE, if an object has a resource or needs explicit cleanup, it can't rely on the garbage collector to know when to release its resource or otherwise do its cleanup.) But I'd be careful about being too opinionated about forcing a language onto the consumers of an API. I believe WinForms (the first C# UI API) was a thin wrapper around the Windows UI API, but I never did a Windows UI in Win32 directly to fully validate my assumption.