Live data from Hacker News

Engineering code quality in Firefox

hacks.mozilla.org

151–155 of 155 posts

Re: Engineering code quality in Firefox

#151
post #149

Earlier quoted context omitted.

There is this 6 year old and open report here: https://bugzilla.mozilla.org/show_bug.cgi?id=1065894 Chrome has improved DataView 2 years ago: https://v8.dev/blog/dataview A rather basic jsperf is here: https://jsperf.com/dataview-float-int The results are that the u8 hack is equally slow in firefox and chrome (~90ops/sec), the DataView version is 10x faster in chrome(945ops/sec) but almost 4x slower in firefox(25ops/…

Thanks.

Thanks for bringing it up in the firefox issue tracker.

Re: Engineering code quality in Firefox

#152
post #118

Earlier quoted context omitted.

Those are all very different levels of difficulty IMO: Linux is almost trivially easy, only slightly harder than the usual configure && make and has very few dependencies. Firefox is pretty painful but it's doable with a decent amount of care and bandwidth. Chromium is a fairly typical google project where the recommended first step to building it is to become a google employee but some alternative workarounds are al…

Nah building is fine, just follow the steps from Debian/Ubuntu/whateverdistro . But trying to contribute is fun. By the time you've danced all the hoops to allow you to contribute, some Google employee has already refactored the code around the bug. Then you have to be fast enough to get your updated patch applied before someone else has reorganized the code again... At some point I started wondering if indeed I'd ge…

> ...some Google employee has already refactored the code around the bug. Then you have to be fast enough to get your updated patch applied before someone else has reorganized the code again...

For what it's worth, this is how it work's if you're a Google employee too.

Re: Engineering code quality in Firefox

#153
post #47

Earlier quoted context omitted.

> Presto wouldn't be so memory efficient on today's web; I disagree. (I continued to use the last version of Opera Presto for a few year even after it was abandoned, and it continued to outperform other browsers on both platforms - Windows and macOS, though the macOS version was a bit more buggy). Let's not forget that Presto already supported a lot of HTML5 features(1) before it was abandoned. (Even today, it works…

> But let's not forget that Opera browser earned its reputation for being blazing fast, its tiny size and its low memory consumption on the desktop platforms long before it became a popular browser on the mobile platform. Just about all of the major browsers earned their reputation for being blazing fast, tiny, and using little memory. And those attributes are well-deserved at their launches. Then real-world pressure…

> And yes, it was a deliberate decision, but not for the profit motivations you're suggesting. It was based on maintainability and developer velocity, when we realized we were not going to out-compete Google with engineer headcount. We had to simplify and reduce our nonessential complexity overhead.

How naive to think that copying your competitor makes you gain many users!

Edit (references):

1. https://www.dedoimedo.com/computers/firefox-addons-future.ht...

2. https://www.dedoimedo.com/computers/firefox-29-sucks.html

3. https://www.dedoimedo.com/computers/firefox-suckfest.html

4. https://www.dedoimedo.com/computers/firefox-disable-australi...

Re: Engineering code quality in Firefox

#154
post #47

Earlier quoted context omitted.

> But let's not forget that Opera browser earned its reputation for being blazing fast, its tiny size and its low memory consumption on the desktop platforms long before it became a popular browser on the mobile platform. Just about all of the major browsers earned their reputation for being blazing fast, tiny, and using little memory. And those attributes are well-deserved at their launches. Then real-world pressure…

> Just about all of the major browsers earned their reputation for being blazing fast, tiny, and using little memory. Not like Opera though who made performance and small size (and power optimizations) as their core philosophy. (This was the browser whose popularity even frightened Microsoft, whose infamous Internet Explorer had I think nearly 80% market share at the time. So much that they deliberately ensured that…

> Just look at Goanna / Pale Moon struggling to maintain quality and feature parity now. (Ofcourse they are also struggling because of the design decisions they made

What design choices? If they would ride on Firefox release cycle, Pale Moon would lose its advantages.

Re: Engineering code quality in Firefox

#155

Earlier quoted context omitted.

> Just about all of the major browsers earned their reputation for being blazing fast, tiny, and using little memory. Not like Opera though who made performance and small size (and power optimizations) as their core philosophy. (This was the browser whose popularity even frightened Microsoft, whose infamous Internet Explorer had I think nearly 80% market share at the time. So much that they deliberately ensured that…

> Just look at Goanna / Pale Moon struggling to maintain quality and feature parity now. (Ofcourse they are also struggling because of the design decisions they made What design choices? If they would ride on Firefox release cycle, Pale Moon would lose its advantages.

True. I meant that some of the struggles that they are facing in keeping parity with current Gecko development is because of the goals they have. I use Pale Moon sometime but it's performance on mac leaves a lot to be desired. I also worry about security issues on it ...
Post reply on HN