I'm very interested to hear your thoughts :)
More vim-split like capabilities - native multiple tabs within a tab would be great imo
More programming languages (not just confined to Javascript)
More hackable (like emacs level hackable maybe)
The current plugins system is good, but maybe there are more creative ways to push the envelope.
Better native ABI support, maybe.. suppose I wanted to collaborate my Ableton jam session into someone else's Firefox tab, or I wanted to pair program in Sublime Text with somebody else via a Firefox plugin, etc
So kind of like how Netflix Party improves Netflix, but instead with any app
Maybe some good built in (opt in) tools that allow people who have a problem with surfing the net for too long every day. E.g. browsing screen time, etc. Of course private data, not to be shared.
Maybe a browser fingerprint-intercepting layer that just returns useless data to browser fingerprinting tools, unless the user would like to be fingerprinted. I really like Firefox's Facebook container plugin, which helps protect me from Facebook across the web.
1. I'd have the browser recommend apps to install to open otherwise unsupported MIMEtypes & URI schemes. I think most desktops support this now (certainly FreeDesktop.Org-compatible Linux & BSD ones do via "AppStream"), it'll free webdevs from compatibility worries, & allow low-cohesian features like videoconferencing & (like brimstedt & osrec discussed) apps to be entirely independant codepaths.
2. For the sake of markettability & accessability (unlikely bedfellows) I like to target unusual human interface devices, e.g. voice, "smart" TVs. It should be a goal to work well absolutely anywhere!
3. I was kind of surprised to find that the next biggest simplification after dropping JavaScript is to move forms out-of-line from the webpage into their own codepaths. This allows me to better reuse OS code whilst simplifying hypertext event handling, avoid webdevs complaining that native widgets clash with their designs, & design a better UX for more devices.
4. There seems to be plenty of precedence suggesting it'd be a good idea to allow links to partially update a webpage, or open modal dialogs/popovers. hey.com is a prominant example.
5. The DOM needs to be replaced, it's an overengineered OO monster straight out of the 90's that can be largely replaced with about 10 lines of code in any language. It's expensive for the browser to construct, for JavaScript to optimize away, and for webdevs to deal with directly.
6. I've got almost no complaint against CSS (I found it easy enough to implement), but sometimes author styles actively make websites worse. So support for user & alternate styles should be emphasized to the user, and websites should still look good if they don't provide CSS.
7. Drop support for CSS `position:`, there's better alternatives now & it does more visual harm than good.
8. I prefer XHTML over HTML as it's easier to parse, but there's a better compromise to be reached between the two camps than the one WHATWG prescribes: handle self-closing tags and close any intermediate tags between the current one & the explicitly closed ones. This routine seems to work well enough on the modern Web, even if it'd break some CSS selectors.
That covers the main points, I'm curious to hear other thoughts?
I would also re-introduce the type attribute to the HTML script tag and extend the tag to allow downloading WASM language runtimes as necessary. If the browser already has it cached, it would use the cached version like any other asset.
The end goal is for all software to be universally accessible and executable from a URL or some similar identifier. It's possible there may need to be another protocol for streaming applications rather than HTTP, I don't know.
This is a vaguely sketched out pie in the sky idea i've had for a while. I have no idea if it's even feasible, but I'd like to see it happen.
That said, I'd like one feature of the original web browser to be much more prominent (or in fact to be available at all): In-place editing and instant publication of changes, alongside with version control.
That'd of course require infrastructure for those publications to run on. So, it'd not just be a different browser UX but an entirely different way of publishing on the web.
If you want to use an interpreted language you can compile the interpreter to WebAssembly (https://github.com/iodide-project/pyodide and https://github.com/RustPython/RustPython are examples).
I.e. publishing documents for reading and making applications for interactions.
I think the browser is a pretty good tool for browsing information (think wikis, blogs, news, etc) but we are shoehorning applications (think project management tools, calendars, mail..) into them.
I would like to have them separated so one tool can be optimised for documents and one for making applications.
- built-in collaboration
- offline storage, data cache
- internet-archive's client, permanent web
I would like to remind you the whole reason for creation of Angular/React/Vue/Polymer/etc — that is because you have this overbloated DOM which is slow despite being implemented in fast low-level compiled languages. The main reason is complexity of calculation of inline elements (text and images with wrapping) and two-way propagation of size (parent to child and child to parent). At the same time the whole idea of CSS as a customizable style description (similar to LaTex/MS Office/OpenOffice styles) is completely forgotten while becoming inseparable from the rest of the content e.g. visibility styles, inability to show the content in different sizes, etc. And now we need workarounds like Webpack and HTTP/2 for putting together separate files that are not so separate by their functions. Because, in fact, a simple textual HTML is separate, its CSS is separate, but dynamic application within this page is a single entity composed of html+styles+js+images — similar to adobe flash swf blob.
I've been writing native GUI apps for like seven years, but now I write web SPA, and the more I write them, the more I feel like today's HTML is not a good platform for true GUI application, because within DOM simple GUI things have to be implemented as complex entities. Yes, we got a flexbox which makes positioning much simplier than float blocks or scripted positioning. However, we also got "display: grid" and "column-width" which also implement flexbox-like behavior, but slightly different. In the end it doesn't matter how many layout mechanism we are going to have — it will never be enough.
Recently we got HTML5 canvas, including WebGL, but we got no good language to write the program for this canvas. Actually, WebGL is the closest to the double-world model of web browser I'm trying to suggest, because WebGL uses a separate high-performance shader language to describe the WebGL-canvas logic which is uncoupled from the main web page's logic. We can also render from a webworker into WebGL canvas, and chromium supports OffscreenCanvas capable of webworker rendering. However, both 2D canvas and WebGL lack one important thing — two-way composability i.e. include html page into canvas. Just like native GUI apps struggle with including native elements into internal browser, canvas struggles with including web browser into 2D or WebGL context.
Actually, Microsoft once solved this problem by implementing support of custom elements in the IE browser, thus bringing a two-way composability. However, due to windows-only nature of the solution it had not achieved wide acceptance. Some cross-platform execution environment is required for success, like JVM or CLR — WebAssembly being the most relevant today, but the composability problem has to be solved. Until then, the developers would still prefer to keep the composability by avoiding HTML5