Live data from Hacker News

Firefox’s Fight for the Future of the Web

theguardian.com

71–80 of 296 posts

Re: Firefox’s Fight for the Future of the Web

#71

Earlier quoted context omitted.

How is it technically enforced though, I am curious. I mean, if I wrote an application that downloaded text files and rendered the text to the screen, I am sure that would be possible. If I wanted to add images to draw next to the text I am sure it is feasible. So how can one technically prohibit doing that? Implementation-wise, how is a web browser really that different from e.g. a video game? Or is it only policy-e…

One cannot have writeable executable memory on iOS (apple can, we cannot). Thus one cannot make a JIT compiler for js and thus pages are slow. Game engines such as Unity use il2cpp to go from the C# stuff into C++ that can be statically compiled as running the C# as bytecode would be too slow without a jitter.

> One cannot have writeable executable memory on iOS (apple can, we cannot).

Nitpick: you can but you cannot ship it via the App Store.

Re: Firefox’s Fight for the Future of the Web

#72
post #44

Earlier quoted context omitted.

One cannot have writeable executable memory on iOS (apple can, we cannot). Thus one cannot make a JIT compiler for js and thus pages are slow. Game engines such as Unity use il2cpp to go from the C# stuff into C++ that can be statically compiled as running the C# as bytecode would be too slow without a jitter.

> One cannot have writeable executable memory on iOS (apple can, we cannot). > Thus one cannot make a JIT compiler for js and thus pages are slow. Lack of JIT doesn't slow down pages much. I believe the difference is so small that it might even be possible to be faster without JIT for most pages, especially on low power devices, it's only computation heavy pages that are going to suffer and even then it's not like yo…

If I have understood correctly (I’m a C++ graphics programmer. So don’t know too much about what’s flashy in the web world) V8 only jits. As in it can only produce machine code and there is not even an option to run it as an interpreter.

Re: Firefox’s Fight for the Future of the Web

#73
post #26

Earlier quoted context omitted.

Right now my parent is getting downvoted but I think that there's a great truth in this comment: A lack of focus generally hurts an organizations legitimacy in the eyes of it's donors. Increasing the quality of a countries national elections isn't a goal I'd immediately assume to be part of Mozillas mission, so I'd be disappointed about such a project. They could go the more transparent route and create a second orga…

I've heard that you can't even donate any money for Firefox. All donated money are going to other projects.

AFAIK there does not seem to be a way to donate to rust development for the same reasons.

Maybe Mozilla should allow donors to specify the project they'd like to contribute to?

That would give them additional feedback on how the community evaluates their programmatic direction.

Re: Firefox’s Fight for the Future of the Web

#74
post #66

Earlier quoted context omitted.

Kivy bundles Python in iOS apps, and the apps are accepted on the App Store. Do you have a link for this policy?

That likely falls under the “educational” exemption: https://developer.apple.com/app-store/review/guidelines/#sof...

That's unlikely, Kivy is also used for commercial apps. Bundling interpreters is allowed, but you must not use them to execute arbitrary code, unless you do it for educational purposes. Kivy doesn't load remote code, so it's not affected by this policy.

Re: Firefox’s Fight for the Future of the Web

#75

Earlier quoted context omitted.

Ah, so it is all about the javascript engine? Ok I can see how that might put up some major technical barriers, but still it should be technically feasible to have the firefox rendering engine make use of the iOS javascript engine, no? Maybe it's not worth the effort of course. I am just trying to get a feel for what the barriers are.

I think that iOS JS engine is tied to WebView and it would be hard to re-use it with other rendering engine.

JavaScriptCore can be used can be used independently from the rest of WebKit, but I’d expect it to be slow.

Re: Firefox’s Fight for the Future of the Web

#76
post #44

Earlier quoted context omitted.

> One cannot have writeable executable memory on iOS (apple can, we cannot). > Thus one cannot make a JIT compiler for js and thus pages are slow. Lack of JIT doesn't slow down pages much. I believe the difference is so small that it might even be possible to be faster without JIT for most pages, especially on low power devices, it's only computation heavy pages that are going to suffer and even then it's not like yo…

If I have understood correctly (I’m a C++ graphics programmer. So don’t know too much about what’s flashy in the web world) V8 only jits. As in it can only produce machine code and there is not even an option to run it as an interpreter.

V8 has a high performance, JIT-less interpreter that disables TurboFan and relies exclusively on Ignition: https://v8.dev/blog/jitless

Re: Firefox’s Fight for the Future of the Web

#77

On a free and open platform like OpenBSD, Firefox isn't even really an option due to performance issues. More than anything else, being forced to use Chromium for a decent browsing experience turned me away from using OpenBSD on a daily driver laptop.

How's that? Firefox is way better nowadays than it was a few years ago. I have been using as my main work browser for some time and I don't face any performance issues with it.

Re: Firefox’s Fight for the Future of the Web

#78
post #74

Earlier quoted context omitted.

That likely falls under the “educational” exemption: https://developer.apple.com/app-store/review/guidelines/#sof...

That's unlikely, Kivy is also used for commercial apps. Bundling interpreters is allowed, but you must not use them to execute arbitrary code, unless you do it for educational purposes. Kivy doesn't load remote code, so it's not affected by this policy.

Then apps using it must ship all of their Python code in the app bundle to meet the App Store Review Guidelines.

Re: Firefox’s Fight for the Future of the Web

#79

Mozilla really has a big challenge. It is hard to compete with such powerful companies, creating a sustainable business with their mission without succumbing to ads or stopping to protect user privacy. It looks like an unfair game. I like the Brave business model. I wish to have the same with Firefox.

Too bad they built Brave on Chromium instead of Firefox. Which of course given that the company is run by Mozilla co-founder Brendan Eich is a bit of a shame. Firefox is showing that they are more than technically competent to keep up with Chromium and deliver great performance and functionality. With the work they are doing rewriting Firefox component by component in Rust, Google will have their work cut out keeping…

> With the work they are doing rewriting Firefox component by component in Rust, Google will have their work cut out keeping up in terms of performance using their C++ implementation.

I would expect Blink’s C++ implementation to perform comparably; wouldn’t the main benefits would be security-related?

Re: Firefox’s Fight for the Future of the Web

#80
post #9

Earlier quoted context omitted.

The point of opensource is to follow along with the leader?

It is to make synergies through code sharing. Let's fork the Linux kernel into a redundant implementation and take half kernel developers in order to slow down progress by a factor of two.

I suggest you take a look at Blink’s history ;)
Post reply on HN