Comment by szastamasta
8 months ago
As much as I would love to see this succeeded, I simply cannot believe that you can sustain a browser development without millions of dollars. Web got so complicated. And it's perfect for all these huge ads companies owning browser engines. Nobody can catch up with this.
There's only one way we can make sure we can get really independent browsers:
SIMPLIFY THE WEB
- Limit the platform to absolute minimum - give way to render things, fetch stuff from the network, etc.
- Get rid of CSS - leave just some basic rendering primitives, so libraries can be created to paint on the canvas. We don't need 78 new animation primitives. We'll build them ourselves if we have a sensible canvas and execution platform.
- Move JS out of the browser to a WebAssembly compiler and make browsers run only WebAssembly
- Or keep JS in the browser but don't add any new features, features should be in libraries outside of the browser. Language should be as simple as possible.
- Get rid of all semantic html junk. We only need some basic blocks to move things around.
This way we can have simple browsers and move all complexity to client libraries, which you can pick and replace when needed. Just keep things as simple as possible and let people build on that.
(updated whitespace)
Any browser could do that tomorrow, and then their users will promptly abandon it when it doesn't work for websites they have to access. This will just never be a viable strategy because users want a web browser that works on the sites they want to visit, and site owners aren't going to rewrite their sites unless the browser has a big enough market share. But market share is going to be small for a browser that doesn't work. Rinse and repeat. It's a major chicken and egg problem.
Yes, we have done it to ourselves in the 90' when every browser had some custom extensions and small differences. And everyone was playing catch-up game. Then we got a bit of normality in 2000' when we standardised things. And now Google is playing like Microsoft - expanding web standards like crazy and nobody can catch up. I hope we stop this madness soon.
I agree with some of this (WWW is too complicated and messy, and has other problems with its design), but I do not agree with everything, and anyways in many cases it cannot be corrected this easily.
However, I should also think that documents should not need to execute JS or WebAssembly code; although there are uses for such things, it should perhaps be separately.
Also, some of the semantic HTML commands can be helpful, such as <ARTICLE>, <TIME>, etc. (However, the user agent should decide how to display them, according to the options selected by the user; this should not be decided by the author of the document.)
A completely new protocol and file format (or more than one) is another way. A few people have tried some things relating to this, including myself. One thing I had done is that, documents cannot contain scripts to be executed nor can they link to scripts to be executed as a part of the document; executable code can only be linked to from the conversion file (which does other things too, and is not only for executing programs; e.g. to specify how to transform a URL to download a file in a different format), and the user must explicitly tell it to execute; furthermore, it uses uxn and not JavaScript nor WebAssembly (since uxn is much simpler to implement); and, if the conversion file is implemented at all (for simplicity, it is not required), it is mandatory that the end user must be allowed to override it and specify their own conversion file instead (therefore, the end user decides what the client software does). Furthermore, I had also decided to use binary formats, to make them less complicated to parse special cases (to avoid needing so many escaping and stuff like that, which is necessary with HTML). And then, TLS is allowed but is optional; it does not have mandatory TLS (although it is recommended that servers and clients will accept both TLS and non-TLS connections; but a client or server that does not support TLS will still work even if the other does support TLS, if both TLS and non-TLS are implemented). There are many other things can be done too, to make improvement.
That all sounds great until you start considering what needs to be done for accessibility. For blind readers as well as many different screen resolutions.
I agree. That's actually one of few problems with having just canvas - accessibility. Most libraries would not have it, and it would be a disaster for disabled users, but... That's one of few things current state AI could solve. Why not make a neural net that would read or summarize page for blind people? Instead we use it to generate bulsh*t junk content and fake comments...
It might, but I think that isn't the best way. Accessibility is for everyone, not only for the blind people.
Better is if the document specifies the text (and any appropriate annotations, e.g. how to pronounce), and the blocks/sections/etc, and then the client software can display it according to the user's settings. Whether that means you want to display it on the screen, with your own formatting, or use a braille display, or text to speech, or whatever else it might be, you can use it.
It would also be a disaster for abled users. Accessibility empowers everyone.
We had this with plugins and it was a security, performance, and compatibility nightmare.
It wasn’t that long ago you needed QuickTime and RealPlayer for videos. Then Flash, Director, Silverlight, and Java for multimedia.
That isn't even slightly comparable as those plugins required the end user to install them, due to the inherent security concerns. Contrast that with today: you are constantly using websites which require giant libraries that entirely subvert the underlying semantics, such as React... it isn't at all crazy to just stop adding more BS to the browser and require more of it to end up in rendering layers such as React, or even to long for a web where React is merely built on top of something like canvas. (FWIW, Flutter is like this, and it is actually pretty damned good; it isn't great, but if we concentrated on only adding features required to fix Flutter's complaints, the web would be better for it, and we'd see a ton of web browsers as a handful of people can legitimately build an operating system kernel or a language compiler or a virtual machine monitor or a CPU emulator or a 3D engine, and yet implementing all of the current web stack requires some giant company, which is ridiculous.)
We needed them because platform was too high level, not because we had not enough web APIs. If we could have a canvas and means to render efficiently, there would be no plugins necessary. And they were nightmare because you had to install them yourself on your client, not because they were not JS and DOM.
>I simply cannot believe that you can sustain a browser development without millions of dollars. Web got so complicated.
You can build something good enough for vast majority of websites and people.
From a user experience, maintaining a large collection of “feature libraries” is about the last thing I want to do on top of web browsing. To me, this approach would doom the browser as needlessly nerdy and obtuse.
You already have this anyway. I’m not sure you have seen the size of average page js bundle. It’s many MBs of JS. All this while expanding browser APIs like crazy during last few years. Simplify the platform and let people brew.