5 ms·

It was inevitable, what people generally want is to be able to interact with another node on the network in a visual way. The fact that browsers started as simp

It was inevitable, what people generally want is to be able to interact with another node on the network in a visual way. The fact that browsers started as simple HTML is only due to technology limitations. If the web was being made form scratch today, it would probably start with a repurposed game engine.

wmf 4y ago
The fact that browsers started as simple HTML is only due to technology limitations. It's not clear that this is true. Smalltalk and Hypercard existed before the Web. The Web started with static HTML because its vision was based on static documents, not apps.
- jandrese 4y ago
  This is exactly right. Hypercard and HTML started the problem from opposite ends. Hypercard being a GUI app development tool and HTML being a way of joining together text documents. That said, a network enabled Hypercard would have been a security nightmare. It was way too complex to secure given coding practices of the time. Heck, even "simple" web browsers had a reputation as a security weak point in the early days. There were no end to people who thought integrating the web browser with the OS was pure lunacy that was going to result in an endless string of compromised machines. Luckily "live desktop" and the like ended up being such weak features that they didn't have quite that much impact.
  - theGnuMe 4y ago
    Right but with "containerization" it could have been secured earlier.
    - jandrese 4y ago
      Containerization is easier said than done, especially with no hardware support. Ultimately you have to make compromises to keep it performant (remember this is on 386/68030 class hardware) and those compromises come back to bite you. Containerization also has a memory penalty, and memory was precious back in those days. Remember that early web browsers were heavy criticized for running poorly on less than 8MB of RAM.
      - musicale 4y ago
        This exactly. Isolation is a very hard problem, and it's even harder when you're running on top of hardware and operating systems that prioritized features and speed over security for decades - certainly due in part to users who had similar priorities and/or were unwilling to pay more for security and reliability.
  - musicale 4y ago
    > There were no end to people who thought integrating the web browser with the OS was pure lunacy that was going to result in an endless string of compromised machines Fortunately OS and web browser developers didn't really consider that to be a big problem so they did it anyway and implemented a system that downloaded random code from the internet and happily executed it in a non-secure sandbox on top of an OS filled with exploitable security flaws. See: Java, Flash, JavaScript, webasm, PDF, canvas, etc.. Not that it mattered too much anyway since media and HTML renderers were already exploitable.
ethbr0 4y ago
> If the web was being made form scratch today, it would probably start with a repurposed game engine. Doubtfully, for the same reason that VR is still looking for a general purpose problem. Visual metaphors are great when demonstrated visually (e.g. in futuristic movies), but their information bandwidth sucks compared to text et al. Or to put it another way, how many emojis would it take to convey the content of this post reliably?
- TuringTest 4y ago
  > Visual metaphors are great when demonstrated visually (e.g. in futuristic movies), but their information bandwidth sucks compared to text et al. Holy false dichotomy there, Batman! VR had some problems in the first batch of devices with low resolution, but as resolution improves there's no reason why it can't be integrated as first-class in it. There's no need for the structure of the text to be a long linear sequence. When you put together a sequence of more than a few paragraphs, it is convenient to group them into a text chunk under a headline; and in fact these chunks can be placed in non-linear structures such as trees and networks, which benefit from a visual representation. The 3D environment of VR would allow better manipulation of these structured text structures in space, compared to the limited 2D possibilities of minimaps and tables of contents.
  - deleted 4y ago
    [deleted]
devmunchies 4y ago
> it would probably start with a repurposed game engine. Like the html canvas or webgl/webgpu? I think it would be cool if you could encapsulate chunks of canvas drawings as components and have native dev tools for inspecting, debugging, etc. Or were you mostly implying that the web would have been more immersive (3D) from the start.
- still_grokking 4y ago
  > Like the html canvas or webgl/webgpu? I think more of a full flagged game engine. With all the bells and whistles. > I think it would be cool if you could encapsulate chunks of canvas drawings as components and have native dev tools for inspecting, debugging, etc. Have a look at how modern game engines with their editors work.
  - devmunchies 4y ago
    Yeah I work in the gaming industry. I was mostly daydreaming of that in the browser.
  - mch82 4y ago
    Unreal Engine can (or at least used to) compile games to WASM and render on canvas. There used to be an excellent demo based on Infinity Blade.
    - still_grokking 4y ago
      > Unreal Engine can (or at least used to) compile games to WASM and render on canvas. So does Unity and Godot.
josephg 4y ago
> If the web was being made form scratch today, it would probably start with a repurposed game engine. I still hold that reinventing the underlying operating systems' text rendering and text input is almost always a bad idea. Some things this "game engine" would need to work with the underlying operating system to solve: - Accessibility (screen readers, etc) - OS-specific text kerning behaviour - Ligatures (including for Arabic and Korean text) - IME for Korean / Chinese / Japanese / etc. - Right-to-left and left-to-right language support. - Input events on every platform. There's about 20 keyboard shortcuts to interact with text on windows, macos and linux. They're different on every platform. iOS / Android are different again. - Native scrolling There's probably more. Its an obscene amount of work to reimplement this stuff correctly on top of a game engine-like API like Canvas. The browser already does almost all of this work and despite that its still a ridiculous hassle to implement web-native rich text editor components. (Though we may disagree on why). As a developer, there are a lot of advantages to having your application behave in an identical way on every platform. But as a user, I don't actually want that. I want your application to fit in with the rest of my operating system. (Be it windows / macos / linux+GTK / iOS / Android). Mind you, Raph Levien is smart and as I understand it, he disagrees with me on this. Here's a video of him talking about it: https://www.youtube.com/watch?v=zVUTZlNCb8U https://www.youtube.com/watch?v=zVUTZlNCb8U
- raphlinus 4y ago
  These things are hard, and I don't want to discount any of it. But three observations. First, browser engines do reimplement most of this stuff, though that's been an evolution, it used to be they relied a lot more on platform text layout, for example. And for the stuff that's not completely reinvented (accessibility), they have a put in a lot of work to make cross-platform abstractions. In many cases (interfacing with the compositor comes to mind), browsers are the only viable open source code bases you can read. Second, to a large extent OS platforms are stagnating. UWP was going to be a big advance over the old WinAPI ways of doing things, but it ended up being a dud. SwiftUI has performance problems for a number of reasons, including the fact they're still using software rendering for a lot of stuff, and their compositor model requires allocating huge amounts of memory for intermediate textures for all their UI elements. Third, the business structure around platforms requires them to each do things differently, which creates gratuitous incompatibility. You really only need one high quality library to do, say, text layout, rather than having slightly different and slightly incompatible versions on each platform. (And very few places are gratuitous incompatibilities more frustrating than GPU infrastructure) So for these reasons, I do believe it's worth exploring a new cross-platform GUI toolkit. It is pretty speculative, though; there are lots of ways it could fail. Game engines are decent at a lot of this stuff, of which of course GPU infrastructure (and graphics rendering in general) is quite good. Most of them could use work in the text department though :)
deleted 4y ago
[deleted]
jimmySixDOF 4y ago
Alan Kay has been thinking & talking [1] about a game engine based web for more than 20 years called Croquet and they are just now launching into the open WebXR world because, like James Cameron waiting decades for the film tech to catch up with his vision of Avatar, the delivery of open 3D Immersive experience is becoming possible. And that will affect all the old underlying design assumptions for things like the Dynabook required by real world physical constraints. [1] https://www.youtube.com/watch?v=uQTeWJNkylI https://www.youtube.com/watch?v=uQTeWJNkylI [2] https://www.croquet.io https://www.croquet.io
- still_grokking 4y ago
  First I thought this would be super cool. But than I read "Metaverse" on the front page. So it's something like Web3, I guess.
  - jimmySixDOF 4y ago
    More Web3D than Web3. They are building an Immersive PaaS and you can do with it what you want. Please don't let crypto own that word but maybe that ship has sailed for now.
    - still_grokking 4y ago
      The point is: I'm quite skeptical about this new Second Life fad. It's a little bit off-putting when someone jumps on the "Metaverse" train. But OK, maybe I should have a second look despite this marketing stunt.
- dragonwriter 4y ago
  The Smalltalk based OpenCroquet was interesting. This might be too, but if so it is hidden well under the buzzword bingo marketing.
- morphle 4y ago
  There is much better documentation on Croquet [2] and its many forks (Open Cobalt, Teleplace, OpenQwaq, 3DICC) and I have many more video demonstrations of what this massively scalable collaboration environment and virtual unlimited desktop GUI could do [1]. It is still alive and being worked on. You can contact us and get involved [3] [1] https://www.youtube.com/watch?v=1s9ldlqhVkM https://www.youtube.com/watch?v=1s9ldlqhVkM [2] https://scholar.google.nl/scholar?hl=nl&as_sdt=0%2C5&q=alan+kay+croquet&btnG= https://scholar.google.nl/scholar?hl=nl&as_sdt=0%2C5&q=alan+... [3] morphle at ziggo dot nl
still_grokking 4y ago
> If the web was being made form scratch today, it would probably start with a repurposed game engine. I came to the exact same conclusion. Modern browser work anyway like a game engine as that's the only way to be fast with rich interactive content. https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/ https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f... We would just need to get rid of all the HTML / HTTP baggage (JS as such is OK-isch as scripting engine, but could be any other VM also of course; and CSS has great utility everywhere, so it's not web specific). Than switch to some sane RPC protocol for networking (as all the "RESTfull" stuff today is anyway only badly made RPC in disguise). Such client-server protocols are actually also already available in game engines because a lot of online games need super efficient real time communication. Efficient content distribution and client self-updates are also part of game engines. I start to consider Godot as an application framework, to be honest. A usual (completely self contained) GUI app with networking is only a few MiB, is supper snappy, and does not need much resources at runtime. The engine and it's editor is really nice to work with. You can finally again click together an UI with the editor. Like in the good old days.
- rswail 4y ago
  > Than switch to some sane RPC protocol for networking (as all the "RESTfull" stuff today is anyway only badly made RPC in disguise). RPC is a dumb protocol because it tries to abstract away the necessary aspects of "remote" as if they don't exist. REST APIs done correctly are great because they expose the possibility of network failures and partitions, allow for idempotency (GET doesn't change stuff), caching and all of the other things that the architectural style offers. RPC doesn't have that.
  - dragonwriter 4y ago
    > RPC is a dumb protocol RPC is a broad concept, even farther from a protocol than REST, which is an architectural style. > because it tries to abstract away the necessary aspects of "remote" as if they don't exist. Generally, it does not. There are some languages/frameworks/other technologies that have been promoted on the basis of transparent RPC or distribution across machines, but that’s not the normal case of RPC. > REST APIs done correctly are great because they expose the possibility of network failures and partitions, allow for idempotency (GET doesn't change stuff), caching and all of the other things that the architectural style offers. More accurately HTTP has all that, and REST layered over HTTP gets it for free from HTTP, while many RPC approaches (though this is not inherent on “RPC”) over HTTP would, e.g., tunnel all actions over POST and reinvent distinctions between safe/idempotent/neither operations if handled at all, within the RPC protocol, and would require specialized caching mechanism for things that are cachable, not HTTP caches. Or, worse, do the same thing but tunnel over GET.
drewcoo 4y ago
I thought most of us just wanted to do the cool new thing, like Wargaming!
LeonB 4y ago
> If the web was being made from scratch today, This is a brilliant prompt, for discussion / thought provocation. My answer is: start with a reliable system for exchanging CSV files. Add a few extensions and boom, everything’s possible.
- still_grokking 4y ago
  Please no, not CSV. A strictly specified format would be in need instead.
  - pasc1878 4y ago
    And isn't this on reason why XML was invented?
    - still_grokking 4y ago
      Sure. XML is a great tech. Much underrated today. (Besides the insanity that correct parsing would need network access, it's mostly very sound).
- blippage 4y ago
  > This is a brilliant prompt, for discussion / thought provocation. The web is such a complicated mess right now that I wish we would revert to it being just a document-based format. That's why I'm interested in things like gopher. Gopher pages can look surprisingly good. I ye olden days there were BBSs (Bulletin Board Systems). It is stateful and all the heavy lifting is done server-side.
tomrod 4y ago
Would that be WASM?
bazoom42 4y ago
> If the web was being made form scratch today, it would probably start with a repurposed game engine. Possibly. But I dont think such a “web” would be anywhere near as successful. It was critical for the success of the early web that anyone would write a webpage in notepad and link to other pages.

wmf 4y ago

The fact that browsers started as simple HTML is only due to technology limitations. It's not clear that this is true. Smalltalk and Hypercard existed before the Web. The Web started with static HTML because its vision was based on static documents, not apps.

jandrese 4y ago
This is exactly right. Hypercard and HTML started the problem from opposite ends. Hypercard being a GUI app development tool and HTML being a way of joining together text documents. That said, a network enabled Hypercard would have been a security nightmare. It was way too complex to secure given coding practices of the time. Heck, even "simple" web browsers had a reputation as a security weak point in the early days. There were no end to people who thought integrating the web browser with the OS was pure lunacy that was going to result in an endless string of compromised machines. Luckily "live desktop" and the like ended up being such weak features that they didn't have quite that much impact.
- theGnuMe 4y ago
  Right but with "containerization" it could have been secured earlier.
  - jandrese 4y ago
    Containerization is easier said than done, especially with no hardware support. Ultimately you have to make compromises to keep it performant (remember this is on 386/68030 class hardware) and those compromises come back to bite you. Containerization also has a memory penalty, and memory was precious back in those days. Remember that early web browsers were heavy criticized for running poorly on less than 8MB of RAM.
    - musicale 4y ago
      This exactly. Isolation is a very hard problem, and it's even harder when you're running on top of hardware and operating systems that prioritized features and speed over security for decades - certainly due in part to users who had similar priorities and/or were unwilling to pay more for security and reliability.
- musicale 4y ago
  > There were no end to people who thought integrating the web browser with the OS was pure lunacy that was going to result in an endless string of compromised machines Fortunately OS and web browser developers didn't really consider that to be a big problem so they did it anyway and implemented a system that downloaded random code from the internet and happily executed it in a non-secure sandbox on top of an OS filled with exploitable security flaws. See: Java, Flash, JavaScript, webasm, PDF, canvas, etc.. Not that it mattered too much anyway since media and HTML renderers were already exploitable.

ethbr0 4y ago

> If the web was being made form scratch today, it would probably start with a repurposed game engine. Doubtfully, for the same reason that VR is still looking for a general purpose problem. Visual metaphors are great when demonstrated visually (e.g. in futuristic movies), but their information bandwidth sucks compared to text et al. Or to put it another way, how many emojis would it take to convey the content of this post reliably?

TuringTest 4y ago
> Visual metaphors are great when demonstrated visually (e.g. in futuristic movies), but their information bandwidth sucks compared to text et al. Holy false dichotomy there, Batman! VR had some problems in the first batch of devices with low resolution, but as resolution improves there's no reason why it can't be integrated as first-class in it. There's no need for the structure of the text to be a long linear sequence. When you put together a sequence of more than a few paragraphs, it is convenient to group them into a text chunk under a headline; and in fact these chunks can be placed in non-linear structures such as trees and networks, which benefit from a visual representation. The 3D environment of VR would allow better manipulation of these structured text structures in space, compared to the limited 2D possibilities of minimaps and tables of contents.
- deleted 4y ago
  [deleted]

devmunchies 4y ago

> it would probably start with a repurposed game engine. Like the html canvas or webgl/webgpu? I think it would be cool if you could encapsulate chunks of canvas drawings as components and have native dev tools for inspecting, debugging, etc. Or were you mostly implying that the web would have been more immersive (3D) from the start.

still_grokking 4y ago
> Like the html canvas or webgl/webgpu? I think more of a full flagged game engine. With all the bells and whistles. > I think it would be cool if you could encapsulate chunks of canvas drawings as components and have native dev tools for inspecting, debugging, etc. Have a look at how modern game engines with their editors work.
- devmunchies 4y ago
  Yeah I work in the gaming industry. I was mostly daydreaming of that in the browser.
- mch82 4y ago
  Unreal Engine can (or at least used to) compile games to WASM and render on canvas. There used to be an excellent demo based on Infinity Blade.
  - still_grokking 4y ago
    > Unreal Engine can (or at least used to) compile games to WASM and render on canvas. So does Unity and Godot.

josephg 4y ago

> If the web was being made form scratch today, it would probably start with a repurposed game engine. I still hold that reinventing the underlying operating systems' text rendering and text input is almost always a bad idea. Some things this "game engine" would need to work with the underlying operating system to solve: - Accessibility (screen readers, etc) - OS-specific text kerning behaviour - Ligatures (including for Arabic and Korean text) - IME for Korean / Chinese / Japanese / etc. - Right-to-left and left-to-right language support. - Input events on every platform. There's about 20 keyboard shortcuts to interact with text on windows, macos and linux. They're different on every platform. iOS / Android are different again. - Native scrolling There's probably more. Its an obscene amount of work to reimplement this stuff correctly on top of a game engine-like API like Canvas. The browser already does almost all of this work and despite that its still a ridiculous hassle to implement web-native rich text editor components. (Though we may disagree on why). As a developer, there are a lot of advantages to having your application behave in an identical way on every platform. But as a user, I don't actually want that. I want your application to fit in with the rest of my operating system. (Be it windows / macos / linux+GTK / iOS / Android). Mind you, Raph Levien is smart and as I understand it, he disagrees with me on this. Here's a video of him talking about it: https://www.youtube.com/watch?v=zVUTZlNCb8U https://www.youtube.com/watch?v=zVUTZlNCb8U

raphlinus 4y ago
These things are hard, and I don't want to discount any of it. But three observations. First, browser engines do reimplement most of this stuff, though that's been an evolution, it used to be they relied a lot more on platform text layout, for example. And for the stuff that's not completely reinvented (accessibility), they have a put in a lot of work to make cross-platform abstractions. In many cases (interfacing with the compositor comes to mind), browsers are the only viable open source code bases you can read. Second, to a large extent OS platforms are stagnating. UWP was going to be a big advance over the old WinAPI ways of doing things, but it ended up being a dud. SwiftUI has performance problems for a number of reasons, including the fact they're still using software rendering for a lot of stuff, and their compositor model requires allocating huge amounts of memory for intermediate textures for all their UI elements. Third, the business structure around platforms requires them to each do things differently, which creates gratuitous incompatibility. You really only need one high quality library to do, say, text layout, rather than having slightly different and slightly incompatible versions on each platform. (And very few places are gratuitous incompatibilities more frustrating than GPU infrastructure) So for these reasons, I do believe it's worth exploring a new cross-platform GUI toolkit. It is pretty speculative, though; there are lots of ways it could fail. Game engines are decent at a lot of this stuff, of which of course GPU infrastructure (and graphics rendering in general) is quite good. Most of them could use work in the text department though :)

deleted 4y ago

[deleted]

jimmySixDOF 4y ago

Alan Kay has been thinking & talking [1] about a game engine based web for more than 20 years called Croquet and they are just now launching into the open WebXR world because, like James Cameron waiting decades for the film tech to catch up with his vision of Avatar, the delivery of open 3D Immersive experience is becoming possible. And that will affect all the old underlying design assumptions for things like the Dynabook required by real world physical constraints. [1] https://www.youtube.com/watch?v=uQTeWJNkylI https://www.youtube.com/watch?v=uQTeWJNkylI [2] https://www.croquet.io https://www.croquet.io

still_grokking 4y ago
First I thought this would be super cool. But than I read "Metaverse" on the front page. So it's something like Web3, I guess.
- jimmySixDOF 4y ago
  More Web3D than Web3. They are building an Immersive PaaS and you can do with it what you want. Please don't let crypto own that word but maybe that ship has sailed for now.
  - still_grokking 4y ago
    The point is: I'm quite skeptical about this new Second Life fad. It's a little bit off-putting when someone jumps on the "Metaverse" train. But OK, maybe I should have a second look despite this marketing stunt.
dragonwriter 4y ago
The Smalltalk based OpenCroquet was interesting. This might be too, but if so it is hidden well under the buzzword bingo marketing.
morphle 4y ago
There is much better documentation on Croquet [2] and its many forks (Open Cobalt, Teleplace, OpenQwaq, 3DICC) and I have many more video demonstrations of what this massively scalable collaboration environment and virtual unlimited desktop GUI could do [1]. It is still alive and being worked on. You can contact us and get involved [3] [1] https://www.youtube.com/watch?v=1s9ldlqhVkM https://www.youtube.com/watch?v=1s9ldlqhVkM [2] https://scholar.google.nl/scholar?hl=nl&as_sdt=0%2C5&q=alan+kay+croquet&btnG= https://scholar.google.nl/scholar?hl=nl&as_sdt=0%2C5&q=alan+... [3] morphle at ziggo dot nl

still_grokking 4y ago

> If the web was being made form scratch today, it would probably start with a repurposed game engine. I came to the exact same conclusion. Modern browser work anyway like a game engine as that's the only way to be fast with rich interactive content. https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/ https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f... We would just need to get rid of all the HTML / HTTP baggage (JS as such is OK-isch as scripting engine, but could be any other VM also of course; and CSS has great utility everywhere, so it's not web specific). Than switch to some sane RPC protocol for networking (as all the "RESTfull" stuff today is anyway only badly made RPC in disguise). Such client-server protocols are actually also already available in game engines because a lot of online games need super efficient real time communication. Efficient content distribution and client self-updates are also part of game engines. I start to consider Godot as an application framework, to be honest. A usual (completely self contained) GUI app with networking is only a few MiB, is supper snappy, and does not need much resources at runtime. The engine and it's editor is really nice to work with. You can finally again click together an UI with the editor. Like in the good old days.

rswail 4y ago
> Than switch to some sane RPC protocol for networking (as all the "RESTfull" stuff today is anyway only badly made RPC in disguise). RPC is a dumb protocol because it tries to abstract away the necessary aspects of "remote" as if they don't exist. REST APIs done correctly are great because they expose the possibility of network failures and partitions, allow for idempotency (GET doesn't change stuff), caching and all of the other things that the architectural style offers. RPC doesn't have that.
- dragonwriter 4y ago
  > RPC is a dumb protocol RPC is a broad concept, even farther from a protocol than REST, which is an architectural style. > because it tries to abstract away the necessary aspects of "remote" as if they don't exist. Generally, it does not. There are some languages/frameworks/other technologies that have been promoted on the basis of transparent RPC or distribution across machines, but that’s not the normal case of RPC. > REST APIs done correctly are great because they expose the possibility of network failures and partitions, allow for idempotency (GET doesn't change stuff), caching and all of the other things that the architectural style offers. More accurately HTTP has all that, and REST layered over HTTP gets it for free from HTTP, while many RPC approaches (though this is not inherent on “RPC”) over HTTP would, e.g., tunnel all actions over POST and reinvent distinctions between safe/idempotent/neither operations if handled at all, within the RPC protocol, and would require specialized caching mechanism for things that are cachable, not HTTP caches. Or, worse, do the same thing but tunnel over GET.

drewcoo 4y ago

I thought most of us just wanted to do the cool new thing, like Wargaming!

LeonB 4y ago

> If the web was being made from scratch today, This is a brilliant prompt, for discussion / thought provocation. My answer is: start with a reliable system for exchanging CSV files. Add a few extensions and boom, everything’s possible.

still_grokking 4y ago
Please no, not CSV. A strictly specified format would be in need instead.
- pasc1878 4y ago
  And isn't this on reason why XML was invented?
  - still_grokking 4y ago
    Sure. XML is a great tech. Much underrated today. (Besides the insanity that correct parsing would need network access, it's mostly very sound).
blippage 4y ago
> This is a brilliant prompt, for discussion / thought provocation. The web is such a complicated mess right now that I wish we would revert to it being just a document-based format. That's why I'm interested in things like gopher. Gopher pages can look surprisingly good. I ye olden days there were BBSs (Bulletin Board Systems). It is stateful and all the heavy lifting is done server-side.

tomrod 4y ago

Would that be WASM?

bazoom42 4y ago

> If the web was being made form scratch today, it would probably start with a repurposed game engine. Possibly. But I dont think such a “web” would be anywhere near as successful. It was critical for the success of the early web that anyone would write a webpage in notepad and link to other pages.