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
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 :)
The amount of work to do this well is high. Probably (easily) measured in engineer-years. All to reimplement something that - janky as it may be - already exists in some form in web browsers. But as you say, worth it if we can pull it off. But it’s a common good. The hardest part in my mind would be figuring out how to fund a project like this.
My ideal application platform isn’t a video game engine. It’s probably something like electron, but with most of the browser stuff stripped out. (Dump javascript, the game pad api, midi, usb, Bluetooth, tab isolation, and probably the DOM. And use Houdini or something instead of CSS). And then I’d happily swap the rendering for pietgpu or whatever will perform the best on modern platforms.
Basic desirada: Small and light, fast, cross platform and platform-native look and feel everywhere. Accessibility, IME, localisation, rtl- and ltr- language support, and so on.
Mobile is still a big question. But solvable if sufficient engineer time was poured into it. It’s just a big project.
Now, I freely admit that many applications don't need that much performance. But I think having a toolkit that is optimized along those lines could be a good basis for doing work on the other things (developer experience) that make a toolkit great.
I think the Jetpack Compose guys have plans to multi-thread composition, and they already do it incrementally.
JavaFX has a reactive/observable properties framework where you can build chains of lazy computations which update only the part of the UI that needs to be changed, this is then propagated to a parallel render thread that runs concurrently with the app logic. They originally wanted to further parallelize the render thread via tiling, but never did so.
Performance problems obviously still occur, usually when trying to do complex layouts with lots of measurement.
Depends on the users I guess. Mine are really adamant that they want the exact same app no matter the OS. The OS is just a tool to launch actual productivity apps.
But than I read "Metaverse" on the front page. So it's something like Web3, I guess.
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.
[1] https://www.youtube.com/watch?v=1s9ldlqhVkM
[2] https://scholar.google.nl/scholar?hl=nl&as_sdt=0%2C5&q=alan+...
[3] morphle at ziggo dot nl
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.
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.
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.
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-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.
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.
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.
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?
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.
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.
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.
So does Unity and Godot.
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.
(Besides the insanity that correct parsing would need network access, it's mostly very sound).
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.
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.