A new CEO for Mozilla
A new CEO for Mozilla
Posted Feb 8, 2024 22:53 UTC (Thu) by roc (subscriber, #30627)In reply to: A new CEO for Mozilla by donbarry
Parent article: A new CEO for Mozilla
Posted Feb 8, 2024 23:15 UTC (Thu)
by milesrout (subscriber, #126894)
[Link] (11 responses)
What costs money is *constantly* adding new ill-designed user-hostile and useless Javascript "features" because Google added them to their browser first. Stuff like "CSS relative colour". This is pure bloat pushed into the specifications purely because Google knows they can churn out new "features" faster than other vendors can. The more features, the bigger their advantage. The fewer new features, the easier it is to "catch up".
None of this is actually necessary, and it wouldn't be happening if the major governments of the world actually held Google to account for their anticompetitive behaviour.
Posted Feb 9, 2024 3:02 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Far less than a thousand, and yes, you need a lot of developers. Google definitely has more than a thousand.
Keep in mind, that a browser also needs a JavaScript engine (with JIT), needs to support multiple OSes, and it needs to stay on top of security issues.
Posted Feb 9, 2024 7:29 UTC (Fri)
by josh (subscriber, #17465)
[Link] (9 responses)
They really, really can't. Forget adding new features, three programmers could barely keep the lights on, or respond to bug reports, or fix issues as they arise.
As for the rest of your argument, this is the same refrain commonly heard in retrocomputing everywhere: "We don't need all those new features from systemd/wayland/Linux/etc, if you stopped adding those new features software wouldn't depend on them and we could keep using sysvinit/x11/OpenBSD/etc forever!" The world moves on, and users and web developers *want* new features for the web platform. The net effect of digging in your heels and choosing to not add support for new web standards is a dead browser in which websites slowly stop working and people switch away to a working browser.
And it's also not the case that web browsers *as a group* could stop adding new features if they all agreed to do so, either. The net effect of *that* would be that native applications have features browsers can't match, more sites throw features into their native app and not into their web version, and all the people saying "stop telling me to download your app, I just want to use your website!" lose out. The better the web gets, the less weight the mobile app ecosystem has, and the more it's possible for users to remain in control of their experience.
Now, it's *absolutely* valid that not all things should be in web standards. But Mozilla *does* have a voice in web standards too, as does Apple, as do others. Things do not get *unilaterally* added because one vendor wants them. And frankly, in order for Mozilla to have a larger voice in web standards, they need to have more market share. If they have 50% of the market and say they're not going to implement something, it doesn't become a standard; if they have 3% of the market they don't have that power.
Posted Feb 9, 2024 7:46 UTC (Fri)
by milesrout (subscriber, #126894)
[Link] (8 responses)
With the current complexity? Sure. But I said *a* browser engine. A browser engine doesn't need to be as complex as they have made them. Plus you're forgetting that most of the work is done by a few highly productive individuals.
>As for the rest of your argument, this is the same refrain commonly heard in retrocomputing everywhere: "We don't need all those new features from systemd/wayland/Linux/etc, if you stopped adding those new features software wouldn't depend on them and we could keep using sysvinit/x11/OpenBSD/etc forever!"
Not at all. They aren't even adding new features in the traditional sense. The things they add to the browser engine aren't being used by users. They're being used by developers. Users just want websites and basic web apps. No user ever asks "please make this website use CSS relative colours" or "hey mister webmaster your site should really be using this new Javascript API to do date manipulation instead of the old one". Much of the new things that get added to these browsers are actually bad for users for god's sake, like tracking features.
There aren't even any new user-facing features that come out of all of this. What can websites do today they couldn't do 10 years ago? 10 years ago we had responsive web map applications, we had websites (~30 years ago we had those, even, but modern ones we had 10 years ago). Nothing about the way we use the web is actually any different today than it was 10 years ago. What has the last 10 year of browser engine development actually done for users? Basically NOTHING. The user experience hasn't changed for the better at all. Websites have just become more bloated. And for what? The typography still sucks, the layouts still don't scale properly down to phones or up to bigger screens. It all still sucks. It's just sucks while using gigabytes of RAM instead of megabytes.
>And it's also not the case that web browsers *as a group* could stop adding new features if they all agreed to do so, either. The net effect of *that* would be that native applications have features browsers can't match, more sites throw features into their native app and not into their web version, and all the people saying "stop telling me to download your app, I just want to use your website!" lose out. The better the web gets, the less weight the mobile app ecosystem has, and the more it's possible for users to remain in control of their experience.
Native applications will always have features websites can't match, because browsers are native applications. It's the same reason manual optimisation always beats a compiler: I can use a compiler, and the compiler can't use me. So at the very worst, I can match a compiler by just using one. Similarly, you can always match what a browser does with a native application, by just doing the same thing.
> Now, it's *absolutely* valid that not all things should be in web standards. But Mozilla *does* have a voice in web standards too, as does Apple, as do others. Things do not get *unilaterally* added because one vendor wants them. And frankly, in order for Mozilla to have a larger voice in web standards, they need to have more market share. If they have 50% of the market and say they're not going to implement something, it doesn't become a standard; if they have 3% of the market they don't have that power.
The standard is whatever Chrome does in practice, realistically. Go to HN and read any thread about browsers: they basically all admit they only test on Chrome and only care whether it works on Chrome.
Posted Feb 9, 2024 9:34 UTC (Fri)
by josh (subscriber, #17465)
[Link] (4 responses)
It does if you want users. If you want users, you need to support 99.99% of websites.
And even with a simpler browser engine, you're still going to get bug reports and support requests. The only way you're going to support a browser engine with three developers is by not handling much of the web *and* not having many users.
> The things they add to the browser engine aren't being used by users. They're being used by developers.
Who develop things used by users; that's always how it works when providing a platform. Some of those features *are* quite user-visible. And while some of them are primarily for developers, they help replace developer hacks with better solutions, or put the user more in control, or otherwise do things that developers are seeking a way to do.
It used to be much hackier to produce certain types of page layouts; now it's easy, in any modern browser. There are a lot of features that used to require JavaScript that can now be done with pure CSS or HTML. Web developers don't tend to say "I can't do that", they say "it's going to be harder to do that", and then they make it happen, whatever that takes; browsers can make hard things easier and simpler. Browsers can reduce the size that webpages need to be, or improve page compression and load time, or improve security...
By way of an example: I'm not a fan of webpage-specified fonts, but the world *before* they existed often had sites render key text as *images*, making it harder to scale, worse quality, larger, less accessible, and unselectable. Now, in a modern site, you don't see people put text in an image just so they can use a particular font, and that's a good thing. It'd be an even *better* world if websites didn't do *either* and just used browser fonts, but 1) nobody has succeeded or is likely to succeed in telling web developers what they *shouldn't* do, and 2) you can configure your browser to ignore webpage-specified fonts, which is one way browsers keep you in control, and they can't do that with the text in an image.
> Users just want websites and basic web apps.
You may want to examine substantially more broadly than the bubble of users you are in. Users want games (both casual and fancy), high-quality videoconferencing with screen sharing, sites that load quickly and securely, sites that work on mobile devices with limited/unreliable bandwidth while providing nice features, sites that include real-time communication with other users, and many many many other things. Pretty much any functionality you could want a computer to do, users want to be able to do on the web.
> Much of the new things that get added to these browsers are actually bad for users for god's sake, like tracking features.
Tracking features are absolutely a bad thing that have no place on the web. The vast majority of new features are not inherently bad in the way that tracking is.
In fact, some of the new functionality being added to web browsers is to *improve* privacy, such as locking down third-party cookies and similar tracking mechanisms, and otherwise locking down bits of the web platform to put users more in control.
One of the oldest features on the web is showing visited links in a different color than unvisited links. There's a huge amount of infrastructure that has gone into preserving that functionality in browsers while not allowing that to let pages track whether you've visited a page or not. Firefox has a whole mechanism to limit what sites can change between visited/unvisited links, so that there's no way for a site to *infer* that you've visited or not visited any given link.
Posted Feb 12, 2024 8:37 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (3 responses)
All of this was available 10 years ago. That was his point.
Posted Feb 12, 2024 11:09 UTC (Mon)
by ojeda (subscriber, #143370)
[Link] (2 responses)
Posted Feb 12, 2024 14:04 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
Posted Feb 12, 2024 14:08 UTC (Mon)
by ojeda (subscriber, #143370)
[Link]
Posted Feb 9, 2024 17:42 UTC (Fri)
by dilinger (subscriber, #2867)
[Link] (2 responses)
Here's an example. I have a few Bafang mid-drive motors on my cargo bikes. There are a bunch of useful settings that you can change, and much like a customizable linux desktop, I usually don't like the stock settings that the vendor programmed. It used to be that you needed some (free as in beer) windows program to update the settings, but someone reverse-engineered the protocol and people have written various (free as in freedom) programs to update settings (eg, https://github.com/horga83/bdac). That's all fine and good, but I really didn't want to have to build/install random software that I'll only use once every 5-10 years when I get a new motor. Turns out someone wrote *a website* that can update the motor settings. Which is amazing. As simple as just plugging my laptop into the bike, going to a website, turning on the motor, and punching in the new settings that I want. I don't have to mess around with containers and host permission to ttyS*, or pulling down 50 python dependencies and realizing that something was written in python2 but never updated for python3 and debian no longer supports python3, and and and.. I just go to https://devnotes.kymatica.com/BafangWebConfig/BafangWebCf... and do the thing.
But that website works in chromium but not firefox, because it "requires a browser with support for Web Serial API, and should work on any recent version of Chrome, Opera or Edge." https://developer.mozilla.org/en-US/docs/Web/API/Web_Seri... says that it was added with chrome 89, which would've been mid-2021.
Posted Feb 10, 2024 3:54 UTC (Sat)
by pj (subscriber, #4506)
[Link] (1 responses)
https://addons.mozilla.org/en-US/firefox/addon/webserial-...
Posted Feb 10, 2024 4:32 UTC (Sat)
by dilinger (subscriber, #2867)
[Link]
I honestly don't mind using chromium for the webserial stuff; might as well since I maintain it. I use firefox for most things, and then chromium for a few other things that work better there.
A new CEO for Mozilla
A new CEO for Mozilla
A new CEO for Mozilla
A new CEO for Mozilla
A new CEO for Mozilla
A new CEO for Mozilla
A new CEO for Mozilla
A new CEO for Mozilla
A new CEO for Mozilla
A new CEO for Mozilla
WebSerial for Firefox
WebSerial for Firefox
