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.
Maintaining an Independent Browser Is Expensive
261–270 of 310 posts
Re: Maintaining an Independent Browser Is Expensive
#262Earlier 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.
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
#263Earlier 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…
Re: Maintaining an Independent Browser Is Expensive
#264Earlier 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)
Re: Maintaining an Independent Browser Is Expensive
#265Earlier 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...
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
#266Earlier 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.
Re: Maintaining an Independent Browser Is Expensive
#267Earlier 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.
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
#268Earlier 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?
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
#269Earlier 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.
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
#270Earlier 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.