Comment by codyrobbins | Hacker News Reader

Comment by codyrobbins | Hacker News Reader

Parent Full thread

This is exactly the reason, as a general rule of thumb, why I don't like end-user software packages that are designed to be cross-platform. While I find Firefox 3.5 on OS X to be way faster than Firefox 3.0, it still doesn't hold a candle to Safari. It may as well be written in Java. For something as fundamental as a web browser, which I'm using all day long, it can't take 30 seconds to open a new window, freeze up and start thrashing halfway through rendering a page, or crash twice a day. (All of which Firefox 3.0 did, and which made me decide to move to Safari.) On top of the performance, the fact that Firefox uses a fake skinned XUL look-alike interface on each platform is the straw that breaks the camel's back, at least for me.

Port the renderer cross-platform, and write separate native apps for each target platform. The amount of complication and cruft that must be in the codebase for making a massively complex software package like Firefox work cross-platform, and the amount of basic OS-level functionality that must have to be reimplemented from scratch because it isn't available on some particular target platform, is probably no small contributor to its performance woes.

It gets worse: sometimes they won't use platform libraries because it conflicts with the ideology they're trying to force on the web.

"Of course we won't use DirectShow / QT / GStreamer as an alternate backend for <video> -- that would make it actually useful in the real world, and our Theora evangelism comes first!"

I wouldn't have said they're forcing their ideology onto the web; it's more that they're forcing the web's ideology onto their users.

The web's ideology is to not give a shit -- no baseline content types were ever specified for <img> or <object> or <embed>

Yes, and "not giving a shit" gave us the fun we had with GIF89 (Will Compuserve shut down the web?!?), various incompatible video formats (Real, AVI, etc.), so this time around, giving a shit might save us from having to go thru all that again.

The LZW GIF patent trolling was from Unisys (It was a submarine patent for Compuserve), and it only affected encoders -- it didn't threaten the web in any way.

The video wars were because [Apple, MS, Real, Macromedia, Sun] were all trying to compete with each other using crap products that conflated [Branding, Plugin, Container Format, Codec] in a mash of uselessness.

Flash won not because it had the same codecs on all platforms, the plugin was customizable the same way on all platforms, and the end-user branding was all yours to theme.

The most interesting part of <video> is not codecs or containers, but the full + uniform control and customizability via its Javascript API. The only reason there is any problem at all is because Mozilla is refusing to expose access to QT / DirectShow / GStreamer.

This is true, but I wonder whether this would have been the case had more image formats been patent-encumbered. The web is a product of open standards and formats, and Firefox is attempting to apply that ideology to HTML5 video formats as well.

As usual, there's no conspiracy. They're working on a GStreamer backend for Firefox but it wasn't finished in time for 3.5. It will probably go in next time around; the current version is a functional stopgap until then.

Gecko used to be used directly by a number of consumers for implementing native applications, but Camino on OS X is the only one left. All others are long-dead or switching to Webkit.

Mozilla threw all of their weight behind XULRunner years ago. It probably wasn't that bad of a decision, given how much of a headache it is to use Gecko directly.

I think you made a good point there about the drawbacks of cross-platform end-user apps. The problem is that the idea of developing a single code-base for all the different platforms are so damn compelling to both managers (from a business perspective) and also lots of engineers who've learned to accept code re-use as the holy grail of our craft.

Even doing the core rendering part cross-platform has a lot of technical issues as the platforms provide a lot of functionality that can be leveraged by the rendering engine (typesetting, drawing, animation etc...). Consequently, the more you want to integrate with the native facilities of the platforms, the more interfaces and glue components you need in order to hook the platform independent part up to the native facilities. This leads to a loads and loads of ceremonial code and interfaces that introduce additional layers of complexity.

Of course Safari loads faster than Firefox on OS X, as IE loads faster in Windows. Their libraries are preloaded by OS ...

Native apps for each platform may give performance boost, but maintaining a consistent UI will be a lot harder

That's the point: we don't want consistent UI

If we want native UI, it's obviously going to have major inconsistencies between platforms!

Well that's not 100% true because the main interface for Firefox on Mac OS X looks more like Safari than it does Firefox on Linux.

I think they've actually done a really good job making it look like a native app instead of just a port from some other OS.

But users still pay the runtime startup costs for not using the native libs.

It's not about looks, but about behavior.

Fun Fact: In Safari since version 3, the <input> elements aren't actually native widgets anymore, as NSButton et. al. couldn't support a bunch of the CSS attributes. They are now rigorous behavior-level reimplementations!

A widget that looks native but behaves differently is terrible! At least when it looks alien you don't expect it to behave natively.

Whilst that sounds reasonable on my VM Safari loads faster than Firefox on Windows.

You know, I remember the times when Firefox was called Firebird and Phoenix and I adored it for loading way much faster than IE. It's surprising how much FF changed since then.

It would be unfair to say it's all due to Firefox and nothing due to improvements on IE (like pre-loading stuff on startup)

The old Mozilla Suite had a start-up preloading tool as well if I remember correctly. Still, Google Chrome loads up way much faster than either IE or FF without preloading anything at all.

I think Chrome has something that preloads stuff. Starting it right after login takes a lot more time than if you start it a couple minutes later. I don't think it's all due to the heavy activity a Windows login takes.

Reply on news.ycombinator.com