241–250 of 349 posts
Earlier quoted context omitted.
The biggest problem IMO with using C++ when I tried the browser is that it crash, it crash a lot and I would imagine they are segmentation fault.
Can you recommend a language that doesn't crash?
Earlier quoted context omitted.
Big problem is the constant feature churn in the web space. Getting from zero to browser is probably doable. Staying at the mark with the ever shifting CSS standards and the constant deluge of web extensions is hard and expensive.
I don't think that's true at all. We get only a handful new CSS features every year, and features introduced today are much more carefully defined than the ad-hoc features of yesteryear. Implementing them is pretty straightforward. Certainly not more difficult than any of the million other things you have to do when building an OS from scratch. The difficulty of building a state-of-the-art browser is almost entirely…
Many of them are just as ad-hoc, even if they are better defined, and meant to cover some holes in previous ad-hoc specifications. For example, the entire `subgrid` spec is patching one specific hole which actually has a proper general definition: "These however are independent of the parent and of each other, meaning that they do not take their track sizing from the parent. " [1]
So instead of solving that general problem, we have a hyper-specific patch for a single feature. Which will definitely clash with something else in the future.
I mean, the entire web components saga is browser developers patching one hole after another that exist only because the original implementation was just so appalling.
> The difficulty of building a state-of-the-art browser is almost entirely about performance.
But that performance is directly affected by the numbe rof specs and features.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...
Earlier quoted context omitted.
https://meiert.com/en/blog/valid-html-2021/ Most sites still don't have valid HTML. EDIT: my link is old. 98% of the top 100 sites had invalid HTML in 2021, in 2022 we've managed to hit 100%, great job everyone! https://meiert.com/en/blog/valid-html-2022/
This does not surprise me at all, with all the "must be a web app", still treating HTML mostly as a string in many web frameworks and semantically inappropriately using tags. It is exactly as I thought, the ratio of invalid HTML has become even worse. Probably most web devs these days do not even check their websites for HTML validity, because achieving it with the frameworks they chose is hard or impossible.
It’s not that difficult to build a browser, but it’s very difficult to build your own browser engine, and kudos to Ladybird devs for that undertaking!
Browser = browser engine. Without it it's just a collection of extensions.
Earlier 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.
This is a fact that Microsoft understood and pushed when they tried to get people to build pages for IE instead of working across both Navigator and IE.
Earlier quoted context omitted.
Son what i'm hearing is that you're looking forward to browser-in-a-browser as if that's somehow not the most depressing trend I didn't know about
As an industry we’ve taken a long and windy path to delivering full applications (with a local cache) on every load to a sandboxed environment that is mostly compatible across environments. While it’s easy to take shots at the current state, I find it hard to imagine another path to delivering a cross platform application over the network. What we have now is actually pretty rad. We built it stone by stone, increment…
If we spent all the effort we used up on making JavaScript work on Java instead, I’d be typing this from my Moon habitat.
But we instead chose a pig, buried it under layers of lipstick, and strapped a jet engine onto it. Sure, it’s airworthy, but was it the best way to allocate resources?
Earlier quoted context omitted.
Could you elaborate your point? I made a comment about why browser is hard in general. I don't in anyway suggest or imply this team would struggle with performance, so not sure why their (amazing) background would be relevant.
Please re-read your own comment. You describe two hard things, performance and long-tail compatibility, and literally state that “the team” will have a nightmare left after an initial cruise.
And I mention these two things because the article itself said they're going to "[f]ocus on vertical slices" first and "[d]eferring on performance work". So I was pointing out that it basically means they started with easy part (nothing wrong with it).
I still failed to see what point I said you didn't agree with, other than argumentum ad verecundiam.
Earlier quoted context omitted.
I don't think that's true at all. We get only a handful new CSS features every year, and features introduced today are much more carefully defined than the ad-hoc features of yesteryear. Implementing them is pretty straightforward. Certainly not more difficult than any of the million other things you have to do when building an OS from scratch. The difficulty of building a state-of-the-art browser is almost entirely…
> features introduced today are much more carefully defined than the ad-hoc features of yesteryear. Many of them are just as ad-hoc, even if they are better defined, and meant to cover some holes in previous ad-hoc specifications. For example, the entire `subgrid` spec is patching one specific hole which actually has a proper general definition: "These however are independent of the parent and of each other, meaning…
The former is 100x harder than the latter, and the prior statement that new CSS/JS features are a burden to keep up with is patently absurd. Because it's a tiny amount of work relative to the total work required to make a browser. (But still hard in the absolute sense, because browser engines are among the most complicated software projects.)
Earlier quoted context omitted.
The main reason it's difficult is because the output criteria seem properly defined but they actually aren't at all. Yeah it's "just" building some parsers and figuring out live updates, but you have to keep in mind that this is ~the internet~. People have been uploading broken, against spec, webpages since forever. Coding a web browser as a serious project (so not as a flight of fancy) borders on the impossible most…
This comment gets some pretty important fundamentals wrong. > The real bugbear here is JS though, HTML and CSS are complex but workable. JS is an ever-moving target What you characterize as "JS" is, in reality, more HTML and CSS than JS. JS is a language. The fact that all the behavioral details of the HTML and CSS objects and related host objects have bindings available to JS programs does not make those things "JS"…
> Deferring on performance work I'll be curious to see how this plays out. History seems to show that boosting performance later is a monumental challenge. Early Chrome showed that Firefox was leaving a lot of performance on the table, and it took Firefox a long time to catch up.
But their product survived and they ended up being wildly successful. In a lot of projects, early optimization hurt the development speed and maintainability, sometimes killing the product. It is easier to see performance bottlenecks once a product is wildly used than adding optimizations everywhere we suspect it might become a problem later.