Hacker News new | ask | show | jobs
by tardygrad 3142 days ago
Or just use Firefox, even if it is slightly slower than Chromium it's at least a browser that works for you not one that treats you as a pawn.

A Chrome monoculture is harmful, even if Google has the best intentions which I don't think they do - they definitely value their profits over an open web.

6 comments

>even if it is slightly slower than Chromium

Funny thing is Firefox Quantum is both faster and eats less memory compared with Chrome.

>not one that treats you as a pawn.

And sadly, Firefox is the only browser that doesn't treat you like a pawn. For MS, Google, Apple, that chinese company which owns Opera you are just a pawn.

(later edit : fixed the second remark).

>And sadly, Firefox is the only browser that does this.

Not any more, I recently discovered that my firefox at work got infected with Firefox Pioneer. I didn't install that, it just appeared on list of my addons, no warning or anything. I heard on Reddit about similar cases from a few months ago, people got Safe Browsing installed without their knowledge. Both are signed addons from Mozilla.

https://addons.mozilla.org/pl/firefox/addon/firefox-pioneer/

>at work

Is youre IT group policy doing this?

Small company, we don't have such policies, root account on my PC at work belongs to me. It's Ubuntu.

your

Safe browsing is now built in to Firefox (and Chrome) so I'm not sure what you're seeing there. It hasn't shipped as an addon for quite some time.
> Participation is voluntary, and you can remove yourself by disabling the add-on after you install it.

So it sounds like a bug or another case of non-malice. Tried reporting it at http://bugzilla.mozilla.org/?

Agreed 100%. I'd been using Firefox right since the early betas but at one point the scrolling performance grew so janky that I had to switch to Chrome. I hate the kind of bullshit chrome keeps pulling, specially the IE-like random standards that they keep inventing to make sure other browsers can't use certain features.

With quantum, Firefox is performing well. Even if chrome catches up I will not give up Firefox until it becomes so slow that I'm unable to use it normally. I don't care about the performance delta, just that it be good enough.

Go Firefox!

>> not one that treats you as a pawn.

> And sadly, Firefox is the only browser that does this.

Do you mean to say Firefox treats you as a pawn? How so?(Genuinely interested)

I read it as a typo, where the author intended to say: FireFox is the only browser that does [not do] this.
OK, makes sense.
Re: pawn

What about Safari? (May not be an option based on OS though)

You have a very narrow definition of "browser." Try xombrero, vimb, Luakit, uzbl or good old w3m.
Inspired by this post installed Quantum beta and used it for the last few hours. Stuttering videos and subtly laggy typing. In what sense it is faster?
Its an alpha/beta, your experience is clearly a bug rather than the expected behavior. Personally my experience has been bug free but unfortunately obviously not all bugs have been squished.

I'm running nightly which in theory ought to have more chance at issues but more chances of fixes for said issues faster too.

Linux?
Firefox is not slower, it's just that most websites are optimised and tested only or mainly under Chrome.

We are slowly getting back to the way things were with IE, but I hope that Mozilla won't give up and switch to blink or webkit like everybody else.

> Firefox is not slower, it's just that most websites are optimised and tested only or mainly under Chrome.

Anecdotally.. Firefox was always slower rendering pages compared to other browsers. On some sites that I visited regularly, using FF was depressing. Later on, it started to suffer from caching issues on my machine. This caused a massive system slowdown.

Tried Palemoon (non-blink\webkit, etc). It blazed through pages- even the heavy ones FF had problems with historically. The rendered results were spot on too. It was like getting a new machine.

What I'm saying is that we can't blame everything on pages being optimized for Browser X or Browser Y. Sometimes we need to call out our favorite browsing application and let them know this is an issue. Otherwise, they keep losing users based solely on performance.

Having said that, looking forward to Quantum.

I'd check out the Firefox nightly which now has all the Quantum stuff - it's a lot better.

I also switched to chrome back when Firefox was a lot slower, but now I'm tempted to switch to Firefox or Safari and I try to occasionally.

I've historically had to switch back partly because I (stupidly) rely a lot on chrome's omnibox autofill memory and also because we use the switchyomega plugin at work and I don't want to deal with having a non-standard setup.

I thought Palemoon was basically firefox?
With some ugly UI stuff pulled out and some extra compiler optimisation flags set.
That is definitely not true. Firefox 57 is about as fast as chrome, and Firefox 59 may well overtake, but chrome has genuinely been faster than Firefox for a long time.
I don't really care that much about how many ms of difference there is in page rendering between the two but blocking UI is a different thing. Still in 56 with no legacy extensions UI blocks from time to time, switching between tabs is slower than in Chrome and scrolling blocks more often.

But if I understood correctly that could be finally fixed in upcoming releases.

I'm curious as to how you can optimise a site to be faster specifically for Chrome?
Some ways it can happen:

1) Write browser-detection code and execute different code, with different performance characteristics, in different browsers. This happens, though less than it used to.

2) Write your code to hit the specific JIT heuristics in a Chrome particularly well, even if that requires contortions that slow it down in every other browser.

3) Write your code to effectively depend on Chrome bugs, where Chrome manages to be faster due to doing something that violates the standards.

4) Arrange the order in which you load your subresources/assets to play particularly well with Chrome's HTTP heuristics, even if it requires contortions that make the downloads slower in other browsers.

5) Write your code to rely on specific behavior in Chrome's HTML prescan, even if it requires contortions that break HTML prescans in other browsers.

That sort of thing.

Basically, if you just write some code, chances are it will run in times X, Y, Z in three different browsers, with the times closer or further apart depending on what features you're using and how the browsers optimized them, etc. But if you then set out to make it faster in X at the expense of any other considerations, you can get it to look like 0.9X, 2Y, 2Z. Or in some pathological cases 0.5X, 10Y, 10Z...

A trivial example is that a 'for' loop vs. 'while' loop can be faster on one browser compared to another.

These differences are even starker if you use newer features without polyfills. For example, 'forEach' implementations as of a year ago varied by orders of magnitude.

Native array sorting is another obvious one. Chrome, Firefox and especially Safari use quite different algorithms each based on array size with varying results.

If you add up all those little changes and always go with the option that's fastest in Chromium, in a reasonably complex SPA you could easily generate noticeable differences.

If 'for' and 'while' loops vary in speed that much between browsers, isn't that a defect in the browser? If one way is faster in chrome than firefox, why doesn't firefox change how it is doing the slower version?
Because that would likely mean slowing down a different scenario. It's usually a trade-off, not a "defect".

The array sorting is a great example where the length of the array chosen or the pre-sort ordering can affect which browser is faster. No single browser may be able to claim the fastest for every scenario.

I don't write JS-heavy websites these days so I don't have a technical example to give, but for instance I've opened the Vue cinema website recently on Firefox mobile. The thing was unusable - when I typed my postcode, nothing would show up on screen, the whole website seemed frozen while waiting to load something. I had to press several times certain buttons for something to happen.

On Chrome however everything worked fine right away. Overall it was just a few images, some text and a search bar, so no matter the performances of the browser that should work everywhere, but since it was probably only tested on Chrome and Safari, it only worked in these browsers.

Optimize for the v8 engine and/or browser-specific errata like the way chrome handles composition or svg etc.
If most websites are faster on chrome than on firefox, why does it matter that the reason is people optimize for chrome? An end user doesn't care WHY chrome is faster, just that it is for their usage.
From a users standpoint - no it doesn't matter.

From a developers standpoint it does. From a "health of the web" standpoint it does also.

FWIW, at this point, the Firefox 57 betas are more responsive than Chromium for me. Not planning on looking back any time soon.
Same for me, I've also enabled all the experimental webrender flags on both private and work machines and have had basically no issues at all for the last weeks.

It's actually almost slightly uncanny how well it's working.

>It's actually almost slightly uncanny how well it's working.

Indeed, I've caught myself thinking "it's not supposed to render this fast" a few times myself. Really am enjoying the nightlies.

This might be a placebo effect, because last I heard enabling WebRender would leave the usual renderer enabled as well in order to paper over yet-unimplemented features, which should often result in double the work and, one would assume, worse performance. But if it doesn't feel slower, then, well, that might be some kind of triumph. :P
I'm still on chrome, because of pepper flash.. :/ and because debugging angular sucks on firefox.

Edit: still checking out if it might be possible. i've just seen that the newer firefox has also some kind of flash player integrated. just the debugging is now strange.

Flash also works in Firefox, what do you need pepper flash for?
Firefox is not immune to this behavior. Please look up the preference "experiments.enabled" before recommending blindly.

In fact, Firefox has increased in the amount of unwarranted telemetry and "experiments" a lot in the last years, a direction I'm really not happy with.

The main difference is that Firefox still gives you pretty liberal access to most internal settings, while Chromium is abysmal, if not ridiculous.

>In fact, Firefox has increased in the amount of unwarranted telemetry and "experiments" a lot in the last years

I can understand "experiments" (Pocket comes to mind), but what are you referring to wrt "unwarranted telemetry"?

I'm not talking about Pocket.

I'm talking about A/B testing internal features exactly like Chrome, such as ip v4/v6 path preference, pipelining support, TLS faststart (and so on) according to a random cohort selection.

While you can certainly turn off these sorts of features, I just want to emphasize that these are intended to make the product better, and Mozilla abides by a fairly strict privacy policy (when comparing to most tech companies at least):

https://www.mozilla.org/en-US/privacy/firefox/

The intention is to ship features that people actually want, and to ensure that Firefox is actually working for people (not everyone can/will file bug reports or post on twitter or hackernews etc)

Exactly like Chrome. I do not argue about the good intention behind.
can we set experiments.enabled to false? if so that's a severe difference, albeit a questionable default, there should be a popup on install, or at least a message on install
Firefox just broke the bulk of their extensions, and I'm sitting and praying the APIs needed for non-broken gestures get implemented...

I'm not being treated as a pawn, but it's still pretty rough.

The extension API change has been widely available information for ages now, with a significant migration period. If an extension developer chooses to not update their extensions, that's their choice.
It is impossible to update a gesture extension into something that works properly. The APIs don't exist. The workaround is to inject scripts into the page to track gestures, which means gestures don't work until the DOM is parsed, and don't work on about:newtab or other about pages.

Multiprocess had a significant migration period. Webextensions had "Well here's some APIs, we'll try to get you more before the day we switch. Some of the important ones are coming the version after, oops. And some are still missing but suck it up."

Brendan Eich's Brave browser - https://brave.com/

Chrome without the tracking