I'm glad to see Darin working solely on the browser, and excited to see him in the SWE role!
When I was working on Chrome I had a strange leftover 1:1 with him (was a VP at that point.) He always impressed me with the deep understanding of the Chromium code stack and he did unblock my work as a SWE with that - An example: At at time I was struggling with an extra latency some callback incurred. He rightly pointed out that the other one (that backs the JS microtask) had smaller latency...and that was right! My problem was solved, by a VP, in the code!
Clearly he was wasting his time as a high-level manager, but I loved that fact. And that's why I cannot help but cheer this move.
/agreemsg. i had the privilege of giving a preso to mark russinovich ~6w ago, and came away from w/the exact reaction: a good tech leader should truly understand the deepest crevasses and be able to spin that back in to context when meeting w/technical people. and yes, shame this isn't the norm.
There is certainly more than one person who wants to reinvent browsers, even among web pioneers, I'm sure :-)
Some things I'd like to see in the next generation of browsers:
- Modular design. Many things like rendering engine, history/cookie/cache mechanism, configuration framework, UI, sync system, download manager, privacy enhancements, ad blocking/request filtering, extensions should be separate programs (with independent authorship) that follow some common, compatible interface. Advanced users can mix and match these components to assemble their own "browser", or even develop their own components. "Browser distributions" can be created for less technical users that are plug and play.
- Ad blocking, request filtering and cosmetic filters as core functionality, rather than some exotic thing for the adventurous that is best left to extension developers. These require low level access to the browser's internal workings, they don't work well as regular extensions because those usually have security restrictions. They also need a solid UX that can provide enough granularity to be useful. Probably a good system for crowdsourcing the filter rules as well.
- The browser shouldn't treat the server as incontrovertible gospel. It shouldn't necessarily run every script the server sends over, or provide a full inventory of capabilities (fonts, filetypes, etc.) unless there is a good reason for it. Rather than server as master and browser as worker, the connection should be treated as a contract where the browser is concerned with protecting the user's interest (privacy, usability) rather than slavishly obeying the server's whims.
so much this, i can't upvote you enough. i need very little of "core" browser functionality. i would use a browser that is mostly unable to fingerprint me for 90% of my browsing. what's left over I'd use Firefox for.
The last one - isn't that already the case? The browser treats the server as hostile and often overrides what it wants to do with extensions.
The issue with additional modularity would seem to be that things would become less hackable in general, because you'd have less insight into the internals of modules as there would be more variety and they might not be open source. How does ad blocking work if the core infrastructure doesn't know much about what's being rendered?
In terms of Modular design, Webkit is pretty much it.
The thing with modern browser is that we cant even Render an interactive HTML5 CRUD apps at 120fps at low latency with zero drop frames and jitter. Something many Simple Native Apps could do.
Reinventing the browser should be simplifying it to only what it needs to be: executing + rendering remote code in a sandboxed window.
Make a new browser that is just WebGPU + WebAssembly, no more DOM. Would already run the next wave of games that will come targeting that.
Then for regular websites, have them deliver a HTML rendering engine written in Webassembly for how they want to be rendered. No more need to test websites on a range of browsers
Great idea, every website should write its own WebGPU-based rendering engine from scratch.
But that will be way too much effort for every kind of project, so what can really happen is some large players write engines and define interfaces for them, and we can all use them for our sites.
But different engines rendering the same data differently is probably going to be confusing (what if I want to swap them to compare performance?), so we should also standardize on some rules for how they do that. Maybe define some kind of document model and styling language?
Also, downloading all these engines on every page load might be too wasteful, so we can pick a couple of the dominant ones and bundle them into the browser itself. That way sites just have to send over structured content and the browser can load them all without a problem.
If we can ever get to this it will be a great web experience!
You have definitely missed the entire point. Of course there are some advantages of just putting it all in the browser for rendering current standard web sites.
The point is to rethink the browser so it isn't just a single tech company setting what the web is with Chromium. A WebGPU+WebAssembly engine would be simple enough for there to be many.
Right but this misses the point that you’re not removing complexity by shuffling it down a layer. Is it really an advantage to have multiple “thin browsers” if there are only two or three “browser engines” anyway due to their complexity? Further by pushing the complexity down a layer you inevitably make it slower.
Aside from which from a market perspective most small browser projects already are a thin layer on top of Chromium. So really what’s gained here?
Particularly if you want to write a novel app using WASM and WebGPU/WebGL only you can already with the tiniest amount of glue to spin the handle. And this can be a useful approach but should it be the default?
It would definitely remove complexity from the browser.
By that logic should browsers just contain all the common Javascript frameworks?
No because that would slow down their rate of change, and sites couldn't control their exact version / configuration. Should be the same for the entire DOM
This doesn't really make sense the browser is complex because it needs to do a lot in order to meet web standards. Removing most of it's functionality and making it a VM with a cross-platform renderer is definitely a great idea for building cross-platform applications but it's no longer functionally a browser. You could build a browser engine on top but then that's just circuitous and most likely slower. The standards and complexity don't vanish in either case. Neither does the VM and renderer obviate the need to follow the version and configuration of that piece of software. And importantly you don't need to use the DOM right now if you don't want to in the browser as Figma and other applications clearly demonstrate.
If what you're trying to say is an application platform based on WASM and WebGPU that safely sandboxed userland applications ultimately delivered over the internet is a good idea then yes I'd agree it is. But it's not a browser.
Having a browser be just WebGPU+WebAssembly is basically just Flash and all the dog shit UX and terrible performance it forced on people. Responsiveness entirely up to the developer, giant binary blobs of content mixed with code, and 100% CPU usage all the time.
I don’t think this is a good idea. We’ll run into a situation with many different not-dom guis having the same set of problems that existing not-dom guis had for all these years. Think gnome-like drama for the half of the internet. Dom/css is no doubt a mountain of something stinky, but at least it is a slow moving standard and never had any politics or bdfl opinions involved. Also it has a set of features (e.g. accessibility, ad blocking) which would be hard to implement everywhere in the same way. Maybe something more low-level than dom but still integratable with higher-level apis and features could be built into a new browser paradigm.
"Oh, you're bored of a tenth of a gigabyte of React and TypeScript every time you load a web page? Here, we're going to ship you the entire browser every time you reload!"
Pushing all computations and interactions to the cloud has a number of downsides. Realistically, most sites would turn into a instant-rendering battery-saving untrackable privacy-respecting distraction-free ads for their own app.
> Then for regular websites, have them deliver a HTML rendering engine
I think this is a dealbreaker, that is simply too much data to have to send over every time you want to load a webpage. It kills mobile immediately since most users have data caps.
Having to store all the different versions of rendering engines out there doesn't really solve the problem, because space isn't unlimited either. Imagine: Facebook just upgraded to v1.3.2 of PopularEngine but Google still lags at v1.3.0, now you have to store both!
Yeah exactly. It's not great, because getting a website to work consistently across browsers is a bit of a pain, but it's gotten much better in recent years. Especially after IE was finally shut down.
>Make a new browser that is just WebGPU + WebAssembly, no more DOM.
At the very least you'll also need a WebAccessibility API for the HTML rendering engine to hook into so that the OS sees your rendered textboxes as textboxes.
I've been poking at doing something like this lately. I'm so sick of browsers and I agree with your thesis. It's a lot to think about putting together a browser project from first principles so I've only done a few tests and flowed some stuff out. WebGPU really is the future especially because you can pipe around remote rendering and data. Is there an existing open project moving in this direction? Do I have to start it? Would you like to help?
I think the net would become far less accessible. WebAssembly has its uses in certain applications. For high quality streaming or similar use cases it can really help to speed things up.
But for the average website? Not keen on having binary blobs executed for everything. That will at some point come with its own perils and in certain points would be a step back.
For this I have applications. For what would you need a browser then?
>"Make a new browser that is just WebGPU + WebAssembly, no more DOM."
I'm not familiar with WebGPU and WebAssembly, can you say is there something in that combination that replaces the DOM? I'd also be curious to hear what's the issue with the DOM.
Sounds like you're advocating turning browsers into something like a dumb terminal or television. Websites will soon do this anyway in an attempt to lock down content and avoid ad blocking.
I've been using a new WebKit-based browser called Orion. It is super snappy, has compatibility with Chrome and Firefox extensions, has power-user features built-in, is privacy focused (collects 0 telemetry as a tenet -- they are donation based), and continues to add features at super fast pace. I highly recommend giving it consideration if you are looking to move away from Chrome.
Some features I love: tree-style tabs. cross-window pinned tabs. low power mode which auto suspends tabs. in place editing of websites. profiles are their own application instance. extensions work on iOS. per-page user-agent. built in notes. preventing auto-playing videos. all this while retaining a native macOS UX.
Every Orion update makes the browser even better. With Safari and Firefox updates I'm always worried what they've made worse... Chrome is the absolute worst.
Interesting that their prototype looks a lot like my browser: which is Firefox using:
- Tabcenter Redux (last update 2018) https://github.com/eoger/tabcenter-redux-- creates a (searchable) left tab column including pinned tabs on top of the column, just like what they are showing. And
- Auto Tab Discard -- saves memory (but not perfectly) by writing out tab contents to disk if the tab is inactive for a settable amount of time, then seamlessly reloading the tab when it's clicked.
Should be titled "Why one web pioneer thinks it's time to bundle more apps with your browser and change the way it does tabs". I like Arc, but they aren't reinventing the browser.
Tried Arc, not my thing. Personally I want browsers to be developer originated, support massive amounts of protocols and playback formats, span over multiple layers of networks, debug tech stack issues as it should be. I don't bother tabs or bookmarks as I always choose to remember URLs with my head.
I am not against content creativity, but I really hope someone can re-invent Shockwave Flash, a container for streamable vector animation format. SVG and DOM canvas stuff are traumatic to work with and they always seem to burn my cpu0. Rich media should be so much richer & quicker instead of 20MB main.min.js barely movable <div> renders like shit on a browser. We had better content experience with .swf players on a Pentium-III.
Players should entertain us, they should be designed as consumer-oriented software. But browsers are for productivity, they were supposed to browse a broad range of documents hosted on networks of variety, with absolute control and input.
Now the world is confusing these two, we are browsing a world of popups, paywalls and infinite scrolls. Arc might never be able to solve the problem here.
I've been using "install this webpage as an app" in Edge for about a year now for the vast majority of sites I visit on a regular basis. The site doesn't need to have an app manifest or service worker to use the feature, you can just use it with any site. I also develop a Web-based VR app at work, have been doing WebXR and VR development for a while now.
The two experiences together have me about convinced that tabs in the browser were a mistake. The operating system already has a means of managing multiple documents/app views, and that is just windows.
It's disturbing that every browser has to implement most of their own media decoders, instead of relying on an OS level API and writing plugins for it. We have file systems for organizing our saved things. Bookmarks should just be links files on disk. You wouldn't need to have in-browser sync of your bookmarks, you'd just point it to your bookmarks directory and let Dropbox or OneDrive or whatever sync the files.
If what we think of as the "browser" used more of what is available in the operating system, and operating systems were more closely involved in web standardization (rather than treating it as a completely siloed project) I think we could have better standards for web apps that integrate seamlessly with the user's desktop.
We might be able to integrate different apps better, things like standardize an interface for image editors, let developers build to that interface, let users select their preferred editor, and have much more powerful image editing available in every app that wants to work with images. We might be able to have VR home environments where web apps represent objects within the user's environment, rather than exclusive mode, full "experiences".
And having this ecosystem on desktop would make users expect to have this functionality everywhere. Smartphone OS vendors might find it a hard time to try to make walled garden, only-place-you-can-do-any-business-so-we-get-our-vig stores.
But we don't. And now browsers are seen as "impossibly complex" (except the SerenityOS team seems to be killing it with Ladybird). All because browsers implemented their own multiple document interface and took over control from what should have been OS-level concerns.
It sounds great until I remember the experience with winhlp32.exe. Opening something in a new tab and bookmarking or pinning a location is a good idea on its own, web or not. And like the article suggests, if there were as many windows (apps?) as tabs my browsing session often has, I’d like to see a tab/side bar at least for all the apps which I have absolutely no intent to “install” or thread-navigate separately in their own window.
I mean, sure, we never had this to quickly jump to negative conclusions for your idea, but it is more related to execution contexts and system integration imo rather than to how the ui for it could work. Personally I would like to also try the opposite - push all the native apps into a tabbed or tree-like interfaces with a capability to middle-click e.g. a file, an mpeg or a project file and spawn even more [tree]tabs from there, instead of doing that in separate windows and/or apps and giving them full control of the input. E.g. by left-clicking a link to any ls’ed resource in a terminal or an IDE you could go to “that app” and rocker-gesture back when needed, rather than alt-tabbing back to the original window. Restyling “apps” and adding/removing features from them would also be nice. Native apps and desktops as they are now are a little behind in ui sense, imo.
Yeah, that's what I mean. OS vendors have almost completely stagnated on UI design for nearly 20 years now.
Mozilla popularized tabbed browsing back in 2003. OS X Leopard released stacks in the dock in 2007. I'm much more of a Windows user, but I had to look up that it had taskbar grouping all the way back to Windows XP in 2001, so I don't think it was enabled by default, because I really don't recall using it until Windows 7 in 2009.
What was it about tabbed browsing that was so much better than MDI? We've had MDI available for app developers since as long as I can remember. I don't know if it was in Win3.1, but I do know I used it in Win95. I think tabbed browsing is a key linchpin in this issue because I think it created an inflection point in how many open documents a user could expect to manage with ease. Before tabs, I don't think a lot of people tried to run more than a handful of apps with multiple windows at the same time, even with MDI. Nowadays, it's not unheard of to see someone completing about their browser crashing and taking it dozens, if not low-hundreds of tabs.
So there is a huge window here that feels like the two most popular desktop OSes couldn't be counted on by cross-platform app developers to provide a good means to manage dozens of documents in working space, because their vendors just kinda sat on their hands. "You want TDI? We have MDI at home." Ooooh, transparency effects on windows. That's really improving workflow /s
Honestly, stacks and taskbar groups aren't that good. Are they kind of junk because it's inherently impossible to do at the OS level? I don't think that makes sense; it's a pretty high level abstraction. It seems much more likely that folks at Microsoft and Apple just didn't feel any pressure to dramatically improve UX. We didn't get the first major, single-page-like web apps until round about 2005, but I don't think it really took off until 2008: smartphones giving people Internet access on the go, the popularity of the iPhone giving mindshare back to Apple so they might become a desktop contender again, and the desire by many developers to never have to ever ever ever touch Java Swing again. What real innovation and proliferation have we seen in desktop OS window managers since then?
So I'm imagining an alternate universe where OS vendors didn't cede control of UI R&D to browser vendors.
> If what we think of as the "browser" used more of what is available in the operating system, and operating systems were more closely involved in web standardization (rather than treating it as a completely siloed project) I think we could have better standards for web apps that integrate seamlessly with the user's desktop.
As a web developer, I do not want this. Currently, I can install Chrome and Firefox on my Linux machine and between the two I can test and get the same experience as 95% of my users. Safari is the only browser I can't directly install on my machine, but it's not hard to test that too, at which point 99% of users are covered.
If what you propose came about, all of the sudden OS (and OS version!) becomes a major variable that has to be accounted for in testing and troubleshooting, which eliminates one of the biggest advantages Web development has over Native.
The feature I most want in a browser is for them to enable client side ssl certificates for password free signin. The UI is actually quite trivial to implement and it would turn the entire internet into a single social network, sidestepping the awfulness [1] of existing solutions like openid-connect.
[1] It's awful because it gives a company's entire customer list to google, facebook, etc. That used to be called goodwill and it is/was the lifeblood of bricks and mortar companies.
I believe you are describing what is Webauthn. As more websites adopt this and more devices include things like Touch ID, Face ID, etc… what you want is maybe a few years from being normal
I’m working on reinventing a browser around reader mode. —Optimized for reading comprehension and the joy of discovery (instead of engagement / ad-metrics). This wouldn’t be the only browser you’d use, but hopefully, it’ll be the best way to read online. ama.
New rendering engine? Or yet-another-Chrom(e/ium)-clone with a different UI? Honestly, even the latter might be better if it's closer to what older browsers had, with a lot of options to configure and not the dumbed-down useless-UI trend that seems to be gradually infecting everything. That's one of the reasons I use Firefox, although it seems to be slowly going down the same path too.
I like Vivaldi and was seriously considering a switch away from Chrome as I'm a past Opera fan ... but it's still "just another" Chromium-based browser likely to be affected by the upcoming Manifest v3 changes that will limit adblocking browser extensions.
I'm running more and more with Firefox these days and trialing AdGuard Home, Blocky, Technitium in parallel in anticipation of having to recommend solutions to friends and family if the Chrome-o'verse dissolves into a ad strewn zombie landscape post full Mv3 rollout.
As someone in the " ~60, programming since 12, former usenet pre WWW " bracket I'm troubled(?) | perturbed by the convergance toward an all Chromium browser engine aspects here, Mv3 is but a single example of what can occur when there's a borg dominated domain.
The most striking, and maybe obvious statement, the design of chrome the goal being to drive people to search in google. But of course! I suppose an ancillary design and usage goal is usage tracking in some form as well.
Arc is a refreshing change after using Chrome, Brave, and Firefox.
My favorite feature which any of these browsers could copy though is the command palette and copying the current URL with cmd-shift-c.
I'm excited for the Boosts that they have, and think they could build a library of them that would be interesting to check out. But I'm not an expert with CSS so making my own is a struggle. Could be interesting if they were able to find a way to make the boost creation easier for non-css experts.
I also haven't used their internal notetaking tool as much, but the fact that the browser has it built in is interesting. I just get scared that the company will fold and I'll lose my notes. Would use it if it was like Obsidian and generated .md files based on my notes.
I would very much like to see someone move htmx-like hypermedia functionality into a browser.
While innovating around the chrome of the browser is certainly nice, it seems to me that hypermedia is just a few small tweaks away from being a viable alternative to the SPA approach for many applications, and it really wouldn't be much code at all to support.
> Arc, which has been in an invite-only beta for more than a year, is trying to rethink the whole browser UI
no one is ever going to dethrone chrome unless they start selling hardware filled with their crapware at a loss solely to suck ppl into the ecosystem and/or start giving away laptops as fast as possible for the same reasons
&
no one is ever going to compete with firefox or brave on UI alone, because the ppl that have the wherewithal to move away from the edge and chrome apps that are thrust upon them with every hardware purchase, care more about if your shit is secure and privacy respecting than if your 'tabs are on the left' :|
> he thinks browsers are due for a reinvention — and why he thinks a startup is the best place to do it
ah yes, a loss-leading category of software is best done at cash-strapped startups... wonder where the revenue will come from
Nobody thought anybody could dethrone IE when Firefox came around. I don't think the goal of Arc is to be the browser that everybody uses, so much to be a useful browser for a lot of power-users.
With the industry standardizing (for better or worse) on a handful of rendering engines, it's not a big stretch to imagine a world where you can choose between different browsers and still experience the same web as everybody else (as opposed to the days past where choosing a niche browser meant accepting a worse web).
I imagine they'll charge money. Mighty's $30/month is a bit out of my price range, but given that I spend ~70% of the workday in a browser, if one could improve my productivity the amount I'd pay for it isn't nothing.
I'd argue that IE6 got worse and didn't keep up with developments while Firefox got consistently better. Firefox' problem as "only" that is was really slow and that's what Chrome solved.
Yet, I also think that a new UI doesn't really change the browser experience much. It must be a completely different UX.
Firefox came at a time when the web was really annoying to use, and had features to make it better. I don't think IE had even shipped a pop-up blocker at the time. But FireFox's extensibility also made things like ad blockers and Grease Monkey scripts possible, which was the only way to stay sane as a power user in that era. And tabs! That was a big one.
I think the web has gotten annoying again, in different ways, because of the thousand things that nag you on every website to click to close them or otherwise obstruct your reading (cookie banners, too). If a browser can solve that reliably, I'd switch to it.
I can only speak for myself but I personally would switch to a fast, open source browser if it came within a set of built in and trusted features. Those include: adblock, Privacy features, fleshed out developer tools, better bookmark management, proper session management etc.
Chome/FF are fine and all but I wouldn't mind trying out a browser that rethinks the way things are done. Especially considering how much resources Chrome/FF currently eats up with the ~15 tabs I have open at any point.
> Chrome exists in large part to put a search engine front and center, which Fisher describes to me as like “a brick wall” for all kinds of browser innovation.
Chrome used to have this tab-to-search feature. When you visited a website like HN, it would use OpenSearch[1] to check whether it had a search engine, and then show "tab to search" in the address bar. That always seemed to me like a sign that the chrome team was working independently to make a great browser, even when that meant supporting other search engines. But today, you have to set this up manually in the settings.
I have been using tree tab since forever and it's really the best tab UI you can imagine. I wonder why it is not native to more browser. I can manage hundred of tabs with ease.
So this appears to be mostly an ad for Arc. To save everybody some time: Arc is a reskinned Chromium that's only available behind a signup wall right now.
If we have to rethink the browser is not because of the UI. We have to take the browser to the smartphones ecosystem and dethrone app platforms.
Maybe, an app-able solution that mimicks most or all of the stuff one can get from developing for app platforms — because it would provide crossplatform, it would create the necessary incentive to develop for it. Also, user privacy first and open source.
Is this actually a reinvention of the browser, or just another self-interested organization trying to grab a slice of the pie?
I download Arc and am immediately greeted with a mandatory account creation page (which asks for my name, even) with a footnote that says `tl;dr we don't spy on you`.
A web browser should be a purely clientside application; no logins required. Building a chromium riff that maintains serverside state about you as a user while saying "trust us :)" is in no way revolutionary, it's just another player in the nightmarish arena that is the modern web.
As someone who enjoys HTML with java, images and cookies turned off, with several blocklists in the browser on my main reading tablet, a text only protocol would suit me just fine as a modern browsing standard (privacy browser downloaded with aurorastore btw).
I still use other browsers on the tablet when needed, but have dropped websites that are incompatible with basic text webpage rendering.
I also use an ipad just to watch youtube and listen to podcasts on distrowatch (i always multitask).
And use a 5g phone just as a hotspot with an LTE travel router.
As an aside, I was visiting Washington state this year just south of Mount St Helens in the spring and with a verizon unlimited MVNO (and only one bar of signal), i was unable to open normal websites to view (and didn't have a VPN configured on my devices), but lo and behold, youtube loaded just fine and played videos the whole time.
Its 2022.. I don't think browsers are going to fix the faults/toxicity with tcp/ip
A text-only browsing standard (htxtp://justwords.com server and client side) would make < 56kbps useable though :p
When I was working on Chrome I had a strange leftover 1:1 with him (was a VP at that point.) He always impressed me with the deep understanding of the Chromium code stack and he did unblock my work as a SWE with that - An example: At at time I was struggling with an extra latency some callback incurred. He rightly pointed out that the other one (that backs the JS microtask) had smaller latency...and that was right! My problem was solved, by a VP, in the code!
Clearly he was wasting his time as a high-level manager, but I loved that fact. And that's why I cannot help but cheer this move.