Why not just fork Firefox?
I agree. Can someone explain why this is not a good solution?
We're building a browser when it's supposed to be impossible
161–170 of 349 posts
Re: We're building a browser when it's supposed to be impossible
#162The fact there are better specs doesn’t help if a large part of the work is handling things that are outside the spec. You better show every “buggy” page similar to how the major browsers show them or the new browser will be considered defective. That’s the unfortunate reality of web tech (I wish every page with an js error or incorrectky closed tag would be a big fat error message but it isn’t). And that’s still a l…
> You better show every “buggy” page similar to how the major browsers show them or the new browser will be considered defective.
Used to be true, I doubt that it is anymore.
There are too few (I could find exactly none, to be honest) sites are around these days that are unreadable when rendered strictly according to a newish (say, 2019) HTML/Javascript spec.
The proliferation of front-end frameworks means that almost no site is going out of spec, and because any site that doesn't meet a large portion of the spec is invisible to search engines, having the site be broken when sticking to the various specs is no issue.
In short:
1. With practically all large-traffic sites using a framwork, a browser that strictly sticks to the specs and the specs alone is not at a disadvantage.
2. With important on SEO, a site that is unreadable on a recent spec is not going to be found anyway by the large body of traffic.
Conclusion: a browser that sticks to the spec and the spec alone has a fighting chance.
It's the complexity and edge-cases of an exceptionally large, complicated and self-contradictory spec with thousands of edge-case when different parts of the spec are combined that's the problem.
Re: We're building a browser when it's supposed to be impossible
#163Earlier quoted context omitted.
Depends on if your actual goal was getting twitter to work. If Twitter rendered fine, chances are some other site render fine today. The same it was with Wine.
Sure but Wine is a tool where if 90% of the stuff user wants to run in it works, it's still great. Say if you use it for gaming you can play most of the games and only boot into windows every few months once you hit one you can't. But that's not how you use web. If 90% of the pages worked in browser I wouldn't use that browser, ever, because chances are I'd hit one that didn't at least once every few days.
It depends on the types of bugs and inconsistencies that show up in practice. If a page (or worse, the whole browser) crashes, that's a problem. If a column of ads doesn't scale right and gets bumped down to become its own lonely row below the main content, that's kind of ugly but almost a feature.
Re: We're building a browser when it's supposed to be impossible
#164Earlier quoted context omitted.
It’s neither. There’s no management or promotions or really any incentive to do this other than it’s fun. It’s also not an architectural decision, just how they as a team decide what to work on.
But how does developing a half-baked browser that targets some websites for fun refute that building a browser is impossible? Doesn’t it provide another example that it is impossible, at least for this team?
Doesn't that depend on whether or not they end up making a browser in the end?
Re: We're building a browser when it's supposed to be impossible
#165I would suggest to design the browser's core for being able to natively support features homologous to:
· uMatrix : A version with even more extended filtering characteristics. With special attention to javascript calls/loads control.
· uBlockOrigin.
· DecentralEyes.
· CookieAutodelete: Special attention to cached content deletion after leave an specific site and to add previous write permissions.
These are essential and needed features within any browser.
Re: We're building a browser when it's supposed to be impossible
#166Earlier quoted context omitted.
Firefox has tons and tons of C++ to this day.
Yes, but they are replacing it bit by bit - I mean, they even started Rust for exactly that purpose. So (without being a huge fan of Rust) the decision to start a "greenfield" browser project in a memory-unsafe language is questionable IMHO...
> Yes, but they are replacing it bit by bit - I mean, they even started Rust for exactly that purpose. So (without being a huge fan of Rust) the decision to start a "greenfield" browser project in a memory-unsafe language is questionable IMHO...
Maybe, but the speed with which SerenityOS, its programs and the browser has been implemented, with so few man-hours thrown at it kinda displays why C++ was chosen over Rust.
There is no comparable project in Rust that demonstrates just how quick you can go from "nothing" to Full-Fledged OS, with applications, with a browser.
Just from the Serenity project (if you've been following it), it looks like C++ is about 10x faster to write performant and safe code in than Rust.
Re: We're building a browser when it's supposed to be impossible
#167Earlier quoted context omitted.
Depends on if your actual goal was getting twitter to work. If Twitter rendered fine, chances are some other site render fine today. The same it was with Wine.
Sure but Wine is a tool where if 90% of the stuff user wants to run in it works, it's still great. Say if you use it for gaming you can play most of the games and only boot into windows every few months once you hit one you can't. But that's not how you use web. If 90% of the pages worked in browser I wouldn't use that browser, ever, because chances are I'd hit one that didn't at least once every few days.
Web browsers tend to degrade a webpage rather than fail to load it. Given that every day using Chrome I'll come across a website that is having issues with rendering, it should be acceptable.
Re: We're building a browser when it's supposed to be impossible
#168I would suggest to design the browser's core for being able to natively support features homologous to: · uMatrix : A version with even more extended filtering characteristics. With special attention to javascript calls/loads control. · uBlockOrigin. · DecentralEyes. · CookieAutodelete: Special attention to cached content deletion after leave an specific site and to add previous write permissions. These are essential…
I think they have bigger fishes to fry right now, as most of the web still doesn't work there
Re: We're building a browser when it's supposed to be impossible
#169I know that this is more of an "can we do it?" experiment, so I feel kind of bad for ciriticising. It's a great feat to get this far.
But I was disappointed that it just crashes on any github page... and SerenityOS github is literally the first link on the Ladybird default homepage :)
edit: oh it doesn't crash on github page, it crashes on the github issues page.
Re: We're building a browser when it's supposed to be impossible
#170Why not just fork Firefox?
Why learn to play an instrument when you can just buy a CD?
The goal is not to have a browser, but to build one. This browser is affiliated with the SerenityOS project, which is reimplementing an entire desktop OS and all applications from scratch.