At this point in market concentration, any sufficiently brave or delusional soul that ventures into even the most rudimentary web browser development is a hero to me !
I think what's been achieved in a little over a year with the Ladybird Browser from the SerenityOS project shows that it's quite possible to build a new browser from scratch. And yes, they are absolute heroes for doing it!
It's definitely impressive, and it shows it is possible to build a new browser. I don't think it shows it is possible to build a new browser that ordinary people will use though. That requires implementing a gazillion niche features that Chrome supports, and compatibility with a gazillion broken websites.
Probably with web browsers the last 0.1% is 99.9% of the work.
A lot of us would be happy to have a browser that doesn't try to support the gazillion features of chrome and Firefox, if it instead gave us the ability to browse the web on our own terms instead of one company's vision of what the web should be.
I share the sentiment. Reality is often physical businesses now require visiting their website, sometimes even in person, and they just don't work unless the browser is Chromium based.
Literally today I had to upload a drivers license in person yet on my phone to rent a truck. Of course Firefox failed, and even Chrome glitched, yet Chrome could be made to work with it's alternate uploader.
Amen to that --- and those who do will quickly lament the state of the "Modern Web"; fuckings to CloudFlare and the like for gatekeeping and calling everyone who doesn't use even slightly non-mainstream browsers or configurations (no JS? Filtering proxy?) a bot. A disappointingly large percentage of sites are behind such walls, and another large number of them are otherwise static content that requires JS to display.
But not giving up is the first step to success. I probably wouldn't use a browser in Go either, but as someone who has also been working on one of my own intermittently and knows how much opposition there is, I certainly encourage any attempts at increasing actual browser diversity.
as others mentioned, some people don't care about market share. the browsers I use day to day (Firefox, Chrome) are honestly pretty bloated and terrible, so I think others would agree that quality wise, users are starving for something better.
Even though Go is unlikely to be an ideal choice for a web browser, I had definitely wanted to venture into it just as a toy project. Unfortunately, it's obviously an enormous project, so I am absolutely nowhere on it.
The truth is, I'd like to still work on this and even see if it's plausible to build a decent JIT without going too far into the weeds (I wouldn't tolerate a requirement on Cgo personally) but given that I never even pushed up an interpreter (I had an AST-based interpreter, but it was so ugly that I scrapped it :) I doubt I'll get anywhere near Opossum. Oh well.
It'd still be fun to at least get some pages rendering. Probably no chance in hell I'd ever get over to milestones I'd actually like to (like booting GMail for example.)
I would say the browser ecosystem as a whole is thriving, there's all sorts of browsers for different needs, but most of them are based on the same couple web engines.
This looks like an implementation from scratch which is fantastic.
I fully acknowledge that Plan9 had a cool vision, maybe a superior one to the world we’ve got. But is it practical as an operating system for day to day use, particularly when working with other people using conventional Linux/Mac/Windows?
> But is it practical as an operating system for day to day use [...]?
It was never meant to be. Just like UNIX initially, it was a research operating system. UNIX turned out to be an accidental runaway success, and many of Plan9's greatest ideas (like synthetic filesystems, bind/union mounts, its threading library, the 9p protocol, etc) found their way to more "practical" systems.
It also did have a commercial counterpart in Inferno (mostly finding use in products like telephone switches). But nowadays both remain mostly as toys for enthusiasts. You can get work done, if you're patient enough, and have the freedom to ignore things like Zoom calls or Excel files.
I have witnessed dozens of people making vague statements about how awestruck they are with plan9's vision, and I've always wondered what exactly they mean.
My take is that plan 9 is basically a "pure" rewrite of a unix/posix OS, that takes many underlying principles of unix to their logical conclusions, without the taint of the incremental evolution of the existing systems, yet nevertheless informed by the lessons learned operating real OS systems. The incompatibility is why it hasn't moved forward, though many of the good ideas that are compatible with systems like bsd/linux have since been ported over.
It is really useful exercise to consider, in hindsight, how could we have built a better unix? And a bunch of really smart people participated and came up with some great ideas.
It's difficult to encapsulate specifics because it's a large amount of small details in the design decisions that end up adding up to a lot. You don't need Docker, you don't need Nix, you don't need NFS or SSHFS or Samba. The world doesn't need web browsers to do as much as they already do. So much tooling is made totally redundant by the emergent properties of the system. A monumental amount of engineering cruft, tacked onto *nix by the necessity of outdated system design, is simply cut away. How? It's little things like namespaces not requiring a tasteless amount of systems bureaucracy boilerplate. The amount of power that can be leveraged by shell scripts rather than dozens of low level API calls in C is not to be scoffed at. It's more than this, so much more. But it's not something you're going to "get" by reading about it.
As with everything else, it depends on who you are and what you do. Email, typesetting, remote shells are all well within the bounds of what workflows work great out of the box.
Typesetting? the linux-centric FOSS world has failed to produce a serious type-setting application for going on 30 years now, what's the offering here?
Johannes Gutenberg produced the primary, and, by far, the most serious, application for type setting 575 years ago, long before the era of the Linux desktop. It's called The Book. Read one some time, and maybe you'll learn what a comma is for.
Sure, but that doesn't seem to really be using Plan9, at least to me. Networked access seems so fundamental to Plan9 that running it in a sandbox seems like trying out a car with all the tires removed.
I'm interested in hearing what it's like to use it more seriously; my biggest doubts are around collaborating with people on conventional OSes.
I've used it as my "main driver" for around 6 months last year and I can assure you it's definitely practical, you can also easily interact with the other OSes with ssh and vnc, that way I could even do some remote video calls from plan9 with the help of another linux computer for instance.
Maybe I misunderstood Plan9, but I figured that if remote services aren't speaking 9P then everything would be a bit kludgey. Like, using Acme on local files which you push up to Github seems to be somehow against the spirit of Plan9. I suppose you could just use it like any other Unix-like OS, but what's the point?
I think I'm convincing myself in this thread that it's not for me - but of course I think it's great that others are using it, I don't want to sound too negative.
There is an image for raspberry pi. I guess that can be a good way to force yourself into it. Just make sure to have vnc access to a linux, mac or windows computer if you need it for work too.
That question makes no sense really. It’s like asking whether camping can be as practical as living in a proper house - maybe for some people, but generally, that’s just not the point.
If that's the analogy, then I think the question is certainly answered for me! "Practical isn't the point" seems pretty similar to "no, it's not generally practical."
I think there’s an interesting clue in the fact that the entire 9front has less lines of code than Go, which this browser depends on. And that includes two web browsers already shipped with the system! Yes, there are ways to force Plan 9 into something it isn’t, but fundamentally starting from the assumption that you want it replace your daily driver is not going to work out.
If you’re interested in it, set it up on a Raspberry Pi, connect to it with drawterm from your daily driver. Experiment with adding a second machine, netbooting it as a CPU server etc. That way you’ll look at Plan 9 from the point of its strengths, not weaknesses.
Nice! I'm glad to see more people are interested in creating browser from scratch. Tho like the "OS from scratch" trend, most of those browsers won't be as nearly as performant or complete as those market-leading browsers without ton of work put into it. Making a browser is not a one man job.
But it's certainly fun to make a browser! I happen to keep track of the open-source browser projects & resources here if anyone is interested:
Huh, interesting that you implemented flow (block/inline) layout but not Flexbox or CSS Grid. I've been working on a library has the opposite! (it support Flexbox and CSS Grid, but not flow layout). Here if you're interested:
Woah, that's so cool. Maybe I'll use your library for flexbox support in my browser!
I implemented the flow layout first mainly because I didn't know how difficult it would be to support flexbox. The flow layout just seems like an easy entry point back then.
If you don't care about JS and just want a good hypertext document viewer with decent HTML and CSS support, I think it shouldn't be too hard to beat mainstream browsers on performance.
yeah that's true. A hypertext document viewer with decent HTML & CSS support is basically a stripped-off browser so it will almost always have a better performance.
Wow, I didn't realize so many people were interested in this. I've been wanting to make a hobby browser for a couple of years now but haven't gotten past some basic steps, but seeing this really does make me want to go deeper. If only I had more time.
At least I will enjoy checking out other projects in the meantime.
Yeah I think you should definitely go for it. I was hesitated for a long time as well but decided to just throw myself into it & use it as a learning experience. After about two years, I got myself a very basic browser & ton of useful knowledge about browsers & their quirks.
What difference does that really make? In Go, all files in a directory share a namespace. I think the only impacts of splitting a file are build tags and shortening the import list, and neither really applies here.
Those components you listed could be in separate packages, but in a program this small that seems merely different, not better or worse.
Why do you believe it is impossible to display a web page of text on screen without a 3D graphics accelerator adapter card? Haven't you ever used a computer without a Nvidia in it before? A young kid like you might be surprised to learn that there was a time not so long ago when most computers didn't have 3D accelerator cards, and that they were still more than capable of rendering a page of information and driving their displays.
Sure it is possible to display the page with text, it is matter of what compatibility level one wants to achieve in regards to modern Web platform in pages that might have 3D and media content into them, which includes some forms of CSS styles as well.
Ultimately everything can be done via software rendering as well, depending on how much one is willing to wait.
OpenGL already has a client/server model (i remember a friend of mine once showing me running some OpenGL stuff from his SGI to his Linux machine... or the other way around, it has been years :-P) and i can't think of anything in WebGL that couldn't work in the same way (though i only used WebGL very little). Sending commands and data over a file handle fits this fine.
You aren't going to be sending vertices through the pipe every frame.
You are going to be sending commands to create the vertex buffers and upload textures (with the relevant data) and then most of your commands will be referencing those. Which is basically exactly what discrete GPUs already do anyway.
IIRC, unlike OpenGL, WebGL doesn't even allow you to do things in another way.
What X Windows did isn't very relevant because the use is very different. It'd only be somewhat comparable if the WebGL programs would treat WebGL as a way to stream new frame data for every frame (e.g. video). Also all X Windows communication with clients is done via commands sent through unix sockets which have similar performance to pipes.
I also run https://shithub.us, which is hosted from plan 9, and more or less needs plan 9 for push access. It uses the hjgit:// protocol for push access, which requires plan9 auth to establish the channel. The fact that there are so many repos up should give a hint at how active the community is.
This isn’t meant to come off as judgmental, but a real question. Plan 9 looks pretty neat but I would think that the lack of driver support alone would make it pretty difficult to run for anything.
Fair enough! I've played a bit with Inferno and Plan 9 inside VMs, but never tried to run it full time. Maybe I should give it a go on one of my spare laptops.
What's the problem with GC? Between C and Go (and maybe Scheme) there's not much choice of languages on plan 9 today.
So not having to think about memory management in a browser pet project is surely the best choice when it comes to a relatively ambitious project as this.
Also of note, Limbo (the language the successor was written is) is also garbage collected, so it's not like it's against the spirit of plan 9.
The predecessor language, Alef, supposedly was abandoned in part because it didn't have GC.
I wonder how much ad-hoc GC popular browsers have and what the tradeoffs are in comparison to using a runtime with a GC and avoiding allocations where necessary.
