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.
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?
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.
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."
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.
Readit News
https://awesomekling.github.io/Ladybird-a-new-cross-platform...
https://linus.dev/posts/ladybird-browser-year-in-review-2022...
Probably with web browsers the last 0.1% is 99.9% of the work.
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.
That said, shameless plug: if anyone wants a reasonably complete but immature ECMA262 parser in Go, I did do that. You can see how (un)finished it is here, with the wasm build: https://cleansheets.io/parser/ - source here. https://github.com/jchv/cleansheets
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.)
Did the author express that his intent was to capture browser marketshare? If not, he may not be delusional :)
This looks like an implementation from scratch which is fantastic.
Deleted Comment
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.
Plan 9 was also available commercially for some time.
[1] https://man.9front.org/1/doc2txt
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.
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.
Dead Comment
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:
https://github.com/ZeroX-DG/awesome-browser
https://github.com/DioxusLabs/taffy
I'll definitely take a look at your browser when I get some time.
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.
At least I will enjoy checking out other projects in the meantime.
It wasn't an easy journey but I really enjoy it.
Good luck to them - we need more actual engines rather than the modern “new browser” model where it’s just whatever Google want in chrome.
and all of that inside single go file?
I think you'd make your life 10 times easier by splitting it better
Those components you listed could be in separate packages, but in a program this small that seems merely different, not better or worse.
Depends if you want to continue developing this (or any) project
If you want, then it makes huge difference, the faster you refactor it, then the easier the development will be.
If you want to stop putting effort into it, then there'll be no difference.
One file doing everything is almost always more annoying than stuff splitted correctly.
no, did you even visit the link?
I've seen them and point is still valid.
https://marc.info/?l=9fans&m=111558695515839&w=2
Ultimately everything can be done via software rendering as well, depending on how much one is willing to wait.
Note sure about WebGPU though.
X Windows did not come up with shared memory communication and hardware mapping extensions just for fun.
Dead Comment