
Ask HN: If you could reinvent the web browser, what would you do differently? - osrec
Given that the web is becoming more of an application delivery platform, rather than a collection of documents, as it was probably first envisaged, what would you do differently if you were to reinvent the browser, given the key use cases of today?<p>I&#x27;m very interested to hear your thoughts :)
======
pizza
Basically we should both maximize the potential for creative developers to
create revolutionary tools, and also protect users who know next to nothing
about problems with the web.

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.

------
alcinnz
I'm actively exploring/implementing this, which has shaped my thoughts on the
topic.

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?

~~~
byko3y
>7\. Drop support for CSS `position:`, there's better alternatives now & it
does more visual harm than good

Tell me an alternative to flexbox scrolling with "position: absolute; left: 0;
top: 0; bottom: 0; right: 0".

I do agree "position: sticky" and "position: fixed" are harmful though.

~~~
alcinnz
I'm not clear what you're describing with "flexbox scrolling"?

My reasoning is that I want to prevent elements from overlapping and obscuring
important information. CSS is generally designed to avoid that, which is what
the "CSS is awesome" memes like to illustrate.

~~~
byko3y
>I'm not clear what you're describing with "flexbox scrolling"?

"position: absolute" can be used to disrupt the two-way size propogation.
Without it you either get shrinked content on y, flexbox wrapping problem on
x, scroll appearing on a wrong element in some cases (or cropping for
"overflow: hidden"), or you have to set width and height of the block with
scroll using css "calc()" — all these solutions are ugly.

>My reasoning is that I want to prevent elements from overlapping and
obscuring important information

The most simple example of overlapping elements is a background/border. You
can look around this page and find a lot of overlapping graphical elements —
it's not the problem, but overlapping text (and other content) is.

"CSS is awesome" example formally has no overlapping DOM elements, no
"position" attributes. It's just a block with "border" style and "width" set
to some fixed amount. Often this problem happens without border on the block
and remains invisible, unless two such blocks are really close together and
the text begins to overlap. Still no "position" involved though.

------
krapp
Remove the JS runtime, replace it with a WASM runtime (assuming a future
version of WASM with native, non JS DOM support) and relegate Javascript to a
language module that just happens to ship with the browser for legacy reasons,
along with other popular languages like Rust and Lua.

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.

------
BjoernKW
While Tim Berners-Lee was indeed mostly concerned with (scientific) documents,
with form support HTML 2 already introduced application-like features.
HyperCard, one of HTML's spiritual precursors also was very much about
applications.

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.

~~~
troycarlson
Interesting concept. I imagine web pages which behave like a shared Google
doc.

------
jwinnie
XHTML, WebAssembly, and CSS.

If you want to use an interpreted language you can compile the interpreter to
WebAssembly ([https://github.com/iodide-
project/pyodide](https://github.com/iodide-project/pyodide) and
[https://github.com/RustPython/RustPython](https://github.com/RustPython/RustPython)
are examples).

------
jokethrowaway
Every page is written in markdown (without html), extended to support forms
and embed videos and images. You can just look at content, click links, send
form data. Websites can only provide content, the style is specified by the
user. Clicking a button won't run untrusted code on your machine.

------
anigbrowl
Graph centric. Everything is a graph, I'd prefer to start off with semantic
web endpoints and pluggable modules. Sorta like nestable pinboard,
prioritizing the simplest mime types and deprioritizing anything which too
much code unless it's providing specific functionality.

------
maps7
I'd have web widgets. No reason every website needs to take up the full window

~~~
osrec
So the ability to tile windows into a single screen, without them sharing the
same context? Perhaps, like a bunch of iframes containing their own "web
page", but with the control over how the frames are arranged given to the
user?

~~~
d--b
This is what the new portals api is about

~~~
maps7
Is that this
[https://wicg.github.io/portals/](https://wicg.github.io/portals/)?

------
samdwilson
Get rid of HTML and CSS. Have everything done more programatically like React.

------
FELDO
Disallow foreign code execution in the browser, allow spawn of non-native code
only in a separate process. No JavaScript, no Java, etc.

~~~
osrec
Ok, so you would allow foreign code execution, but only in a separate process?

If not JavaScript, then what would you prefer to write the foreign code in?
Should it be some sort of interpreted script or do you feel all foreign code
should be compiled?

Would you allow access to the file system, if permitted by the user? What
about other native APIs, like networking, Bluetooth etc?

------
brimstedt
I think one of the problems of the web imo is that we are trying to solve two
quite different problems with one tool.

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.

~~~
osrec
I agree with this sentiment, but I'd take it a step further.

I personally think, the fact that we're shoehorning so much app-like stuff
into the web highlights the need for a good web-based app delivery mechanism.
If we provide a solid app delivery mechanism, then people can create their own
document publishing apps/mechanisms using that.

I know this might lead to fragmentation of document formats, but hopefully
there'll be one clear winner in terms of popularity and ubiquity (similar to
WhatsApp or PDFs).

~~~
brimstedt
Well, PDFs are yet another issue. It's preformatted documents made
specifically for a certain size paper.

This is not optimal for documents to be read on screen/mobile devices since
they handle zooming, changing text sizes etc poorly.

In a way I can agree with you that application delivery would allow document
distribution as well, but I think the benefits of a unified standard for this
that focuses on content rather than presentation is a key feature of the web
that we should not loose.

------
potta_coffee
A better programming language than Javascript, and a better CSS. CSS is not
intuitive IMO.

------
joddystreet
\- robotic process automation

\- built-in collaboration

\- offline storage, data cache

\- internet-archive's client, permanent web

------
vimy
Support for micropayments.

~~~
digitalsushi
That could be as amazing an improvement as experiencing television shows
without commercials was for the first time.

------
byko3y
I'm pretty sure today's web is going at least two different directions that
can't be easily merged together. On one side we have textual and basic
graphical data that is supposed to be controlled by user, like resizing,
scaling, copying, bookmarking, drag and drop, and so on. On the other side we
have interactive applications supposed to work strictly as-designed with
complex handling of internal state, like Adobe Flash or HyperCard did. When
you merge those completely together you get a frankenstein, when you kinda
have the content controllability until you don't, when the content is
displayed as designed if you are lucky enough.

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 <canvas> and clinging on
the old DOM as long as they can.

And by the way, speaking about cross-platform runtime. JVM, CLR, optimized JS,
WebAssembly, and non-native-architecture VM have similar performance, so it's
really not the fundamental execution speed that killed Java applets, but a
failed GUI model "every pixel is drawn by JVM bytecode". WPF, UWP, JavaFX
tried to fix the issue, until "everything is web" came.

Now about a second small idea I have and I've been struggling with for many
years of web surfing. Bookmarks, history, and tabs are not separate things.
The gap between them is closing but closing very slowly. We are getting web
services that live between pages, we are getting frequently visited pages as a
kind of bookmarks, we are getting cheap tabs that are loaded only when user
switches to them, but nobody is brave enough to erase the separation and
create a single visited-tab-bookmark entity. Today's computational resources
clearly allow us to save some amount of data about every visit without forcing
the user to be a bookmark keeper, especially when the user has no convenient
tools for managing current tabs he's working with, and as for me I work with
50-300 tabs daily, so it's really a pain to manage them with this "ten tabs on
the screen"-oriented tool modern browsers have. I know tree-like tabs exist,
but usually they have their own issues. I'd prefer to open the tabs in a full-
screen view, preferably with preview. Some people in the older days would save
onto HDD every page they visit — they had a struggle sorting all the crap
they've got.

~~~
osrec
Thank you for this incredibly detailed answer. I too am an SPA guy,
specifically because I like the clean separation between data and presentation
they allow, which HTML simply doesn't.

This was exactly the kind of answer I was looking for when I asked my
question, so thanks again!

~~~
byko3y
>I too am an SPA guy, specifically because I like the clean separation between
data and presentation they allow, which HTML simply doesn't

HTML was never intended to separate data and presentation. That's what PHP and
other server-side languages (ColdFusion, Perl, etc) were used for, because
HTML specifically is a presentation. Moreover, DOM, as HTML representation, is
also a presentation. Considering high availability of network bandwidth, I'd
say there's no more need to squeeze data into client-server channel, that's
where server-side rendering comes into play with thin client just doing
presentation thing.

~~~
osrec
I disagree. I think HTML was originally a structured document format. And CSS
was another layer on top of HTML, specifically for presentation.

Today, we see a mish-mash of HTML + CSS (+JS) being used for presentation,
since neither HTML, nor CSS can successfully solve every problem on their own.
They often also need to rely on JS.

Regarding bandwidth and SSR, I disagree also. I think we should do things more
efficiently where possible, not less. In my current SaaS product, if we were
doing SSR instead of client side rendering, our hosting costs would be through
the roof right now. As it stands, we have one large-ish download at the start,
followed by very small JSON payloads thereafter. Plus, using service workers,
it can work offline, which is not really possible with SSR.

~~~
byko3y
First of all, I just want to empasize there exist kinda three layers: data ->
presentation -> decoration. HTML still acting as a presentation, but in SPA it
also acts as a decoration together with CSS. Secondly, we need to find what
the data is. Because often the data is on the server database, while
everything else is transmitting and caching the original data.

>In my current SaaS product, if we were doing SSR instead of client side
rendering, our hosting costs would be through the roof right now

It's good you mentioned your product instead of generalizing implicitly.
Because SSR in some cases allows you to prerender pages and host them
statically, thus significantly reducing server CPU and RAM load, and also
making page loading time very fast.

>Plus, using service workers, it can work offline, which is not really
possible with SSR

Similar scenario is possible with SSR, allowing for completely offline
operation. SSR implementations usually require scripts to be run on the client
side, and also allow for defining explicitly server-side-only and client-side-
only scripts, including full transition into kind of SPA for specific pages,
as well as a full SSR prerendering with dead-static content on both server and
client. And gzip can help to reduce the bandwidth required.

------
UhDev
javascript

------
poiuytrewqa
Use standards, that's enough. And avoid that a random Corp create the next
unaccessible thing and force it down to everybody and avoid support for not
standardized / proprietary technologies

~~~
osrec
So, you feel the web should be more simplified? Or is it more that you want to
keep the complexity, but also want good standards to be followed across all
browser vendors (e.g. banish CSS prefixes and Chrome-only JS APIs etc)?

What about the wide range of web apps the new APIs enable? Do you think they
should be catered for somehow?

~~~
poiuytrewqa
Having standards does not imply no more new APIs. But creating them only for
one browser doesn't bring progress on the web but rather lead to monopoly and
at the end inaccessibility.

Consider that with chrome (and chromium based browser) we're close to the
situation we had back in the days with IE.

So I'd say open standard definition for web API should come first, later each
browser will have their own release process to include them inside but at
least behavior and aspect are defined upfront and this will avoid lots of
issue

As of today for example and I'm using both Firefox and Chrome daily. You'd be
surprised on how many website have been tested only in Chrome and some stuff
do not work in Firefox at all

~~~
byko3y
>Consider that with chrome (and chromium based browser) we're close to the
situation we had back in the days with IE. >So I'd say open standard
definition for web API should come first, later each browser will have their
own release process to include them inside but at least behavior and aspect
are defined upfront and this will avoid lots of issue

Just a sheer complexity of the layers being deposited during the current and
the previous century makes it impossible for a single person to understand all
the possible interactions. So today's situation with chromium-based browsers
differ from IE in that the latter deliberately went against existing standards
while creating many non-standard features.

In the last years google set a course for putting more and more features into
browser so no other browser can catch up quickly enough. And despite the fact
google actually tries to be standard-complaint and to create standards for
their new feature, but only a large corporation is able to implement those
features e.g. Mozilla.

