Live data from Hacker News

Maintaining an Independent Browser Is Expensive

robert.ocallahan.org

261–270 of 310 posts

Re: Maintaining an Independent Browser Is Expensive

#261
post #244

Earlier quoted context omitted.

> What has become quite obvious to me within the past few years is that the whole "move the Web forward" thing seems to be really about coming up with and implementing as many complex features as possible (and advocating for their use in new sites), making it harder over time for smaller efforts at creating independent browsers to produce anything useful. Yeah, it's enough to be infuriating. I've recently been thinki…

The alternative to a "living document" is "we have a bunch of updates and errata, and you're going to have to piece together the current version yourself from many sources". If you really need an unchanging version, download some version and use that.

No, the alternative is a versioned document.

Re: Maintaining an Independent Browser Is Expensive

#262

Earlier quoted context omitted.

As far as I can tell, anything Javascript heavy performs significantly worse on Quantum than on Chrome. The benchmarks I've looked at seem to indicate that this shouldn't be the case, but I'm thinking maybe Google has put in some "real life application" optimizations for certain configurations that can't be measured easily with benchmarks? Maybe they've learned some lessons from Angular? Just spitballin' here. Kinda…

There was an article some time ago by someone from Chrome/google in which you could read that they optimized for benchmarks before but benchmarks are not real world usage so they stopped and started to optimize for real world usage. They did it because they optimized for some benchmarks while making real world average usage less efficient. Benchmarks do not show real browser performance.

Ah, thanks for that, it seems you are spot on.

https://blog.chromium.org/2017/04/real-world-javascript-perf...

I actually just ran their "real-world" test (http://browserbench.org/Speedometer/), and the results were:

  Chrome 62: 39.6 ± 3.4 rpm
  Firefox 59: 27.0 ± 5.6 rpm
So there may definitely be something to this theory. Would be good to have a larger sample size though.

Re: Maintaining an Independent Browser Is Expensive

#263

Earlier quoted context omitted.

...and ideally, we should also encourage the use of the "lesser" browsers like Dillo, NetSurf, and all the text-based ones. They can't really run "web apps" and the like, but will be fine for viewing the "long tail" of content-focused sites out there (including this one.) What has become quite obvious to me within the past few years is that the whole "move the Web forward" thing seems to be really about coming up wit…

> we should also encourage the use of the "lesser" browsers like Dillo, NetSurf, and all the text-based ones. They can't really run "web apps" and the like, but will be fine for viewing the "long tail" of content-focused sites out there Perhaps this is a knee-jerk reaction on my part, but I'm against initiatives that resist technological progress, including those that rail against modern web applications. Not only do…

I had bosses argue pretty much exactly this when I resisted proposals to remake entire websites in Flash... "It's _obviously_ the future!" they said...

Re: Maintaining an Independent Browser Is Expensive

#264
post #43

Earlier quoted context omitted.

You had a running css engine in a few minutes?

Heh, bad wording; I should say that I had performance problems within a few minutes. I did eventually get something that kind of worked, but that took about a day, and still suffered performance issues, probably because I had no idea what the hell I was doing (and still don't, really)

You had a running CSS engine within a day?

Re: Maintaining an Independent Browser Is Expensive

#265
post #41
post #32

Earlier quoted context omitted.

Would you rather have people in standards groups to act more like competitors instead of coworkers? Cause that seems like a really bad idea. As for: > For anyone who believes money to be some kind of motivating thing, it isn't hard to come to the conclusion that Mozilla is Google-by-proxy > edit: And apparently I have to have "hits" to my name to state that getting 85% of your revenue from Google puts your independen…

Citations for "cutting how much they were going to pay"? Mozilla revenue is up, they're making a LOT of profit, and the Yahoo deal was supposed to be 5 years so they're not likely to be losing money by switching to Google: https://www.cnet.com/news/mozilla-revenue-jump-fuels-its-fir...

Well in all fairness the deal with Yahoo kind of went side wise. But yeah I would agree its probably around equal.

As for the source, I can't seem to find a source for this. I may have been mistaken, but it was something I heard several years ago on a google related podcast.

Re: Maintaining an Independent Browser Is Expensive

#266

Earlier quoted context omitted.

20k USD/month is in the range that Google/FB/Microsoft pays for direct managers of ~10 person teams: basically that would be the level of credentials that you would be competing for in that pay area.

That’s low for a manager. Many individual contributors make more than that at large companies.

What do they contribute that no one else could for this „low“ amount?

Re: Maintaining an Independent Browser Is Expensive

#267
post #244

Earlier quoted context omitted.

The alternative to a "living document" is "we have a bunch of updates and errata, and you're going to have to piece together the current version yourself from many sources". If you really need an unchanging version, download some version and use that.

No, the alternative is a versioned document.

These documents are versioned in VCS. The core issue is that either you update the master document every time you have a fix, or you don't.

If you do, it's a living standard.

If you don't, then people have to cobble together the latest version from various sources.

Re: Maintaining an Independent Browser Is Expensive

#268
post #43

Earlier quoted context omitted.

Heh, bad wording; I should say that I had performance problems within a few minutes. I did eventually get something that kind of worked, but that took about a day, and still suffered performance issues, probably because I had no idea what the hell I was doing (and still don't, really)

You had a running CSS engine within a day?

Yeah, a really crappy one that parsed a CSS file using Bison, and could change text colors, background colors, and position things based on pixels (no em or %).

I never got around to implementing class support, but I did allow targeting an element via ID.

I did this in C++ for some reason, and used Xerces to parse the XML, and I used Allegro to render everything. If I were to try and make this now, I probably would not use a rendering system designed for games, but I was naive back then.

I'll have to look to see if I can find the old files on my NAS; if I can I'll put it on Github.

Re: Maintaining an Independent Browser Is Expensive

#269
post #126

Earlier quoted context omitted.

>I would view it as a guideline or a best practice, rather than a restriction. >I would definitely offer scripting, but just not all features. That's a restriction. If site authors have to abide by that or else not have their content render in your browser, you're restricting their freedom to publish the content they want or make their own decisions about what code they choose to write. But if you still have a "backu…

> > Why can ads inject arbitrary javascript into my website?! > Because that's what the site authors decided to publish. Like it or not, that's the way the web is intended to work I'd argue that the web wasn't intended to involve executing code, but rather it was originally envisioned to be a means of viewing documents.

>I'd argue that the web wasn't intended to involve executing code, but rather it was originally envisioned to be a means of viewing documents.

That's fair - but it doesn't imply that it was intended to not execute code, so much as that it wasn't feasible to consider at the time. The web wasn't originally intended to display images either, but it evolved over time. Certainly, in either case, javascript was never intended to carry the burdens it's been made to, but people found it useful to have a Turing capable language as part of the web, and here we are for better or worse.

And the web in the near future when WebAssembly takes off is going to execute binaries compiled from arbitrary languages, of which javascript will be only one option. That's going to be awesome in both senses of the word. Not what the web was originally intended for, and certainly not the best of all possible worlds, but I would argue that it's still better than static documents alone, in terms of the possibilities it provides to publishers and users.

And maybe the pendulum will swing the other way at some point. Maybe people will choose to write lighter pages and not use unnecessary code. But if they don't, that's still their choice to make, not yours or a browsers to make on their behalf. And unlike with C, C++, Java, etc, you can turn javascript off if you want and still use some of the web.

Re: Maintaining an Independent Browser Is Expensive

#270

Earlier quoted context omitted.

> I don't think this is hostile to developers at all, unless AMP is already hostile. I think the prevailing opinion on Hacker News is exactly that.

I don't see how a subset of HTML could be hostile. AMP is not Google Search.

A subset of HTML isn't hostile. A browser that defaults to only rendering that subset is hostile, because it relegates any content which doesn't conform to that proprietary spec to second-class status.
Post reply on HN