5 ms·

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

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.

lamnk 17y ago
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
- blasdel 17y ago
  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!
  - __david__ 17y ago
    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.
    - lallysingh 17y ago
      But users still pay the runtime startup costs for not using the native libs.
    - blasdel 17y ago
      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.
- andrewtj 17y ago
  Whilst that sounds reasonable on my VM Safari loads faster than Firefox on Windows.
- DrJokepu 17y ago
  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.
  - rbanffy 17y ago
    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)
    - DrJokepu 17y ago
      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.
      - rbanffy 17y ago
        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.
blasdel 17y ago
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!"
- weavejester 17y ago
  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.
  - blasdel 17y ago
    The web's ideology is to not give a shit -- no baseline content types were ever specified for <img> or <object> or <embed>
    - slater 17y ago
      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.
      - blasdel 17y ago
        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.
blasdel 17y ago
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.
voidpointer 17y ago
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.

lamnk 17y ago

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

blasdel 17y ago
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!
- __david__ 17y ago
  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.
  - lallysingh 17y ago
    But users still pay the runtime startup costs for not using the native libs.
  - blasdel 17y ago
    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.
andrewtj 17y ago
Whilst that sounds reasonable on my VM Safari loads faster than Firefox on Windows.
DrJokepu 17y ago
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.
- rbanffy 17y ago
  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)
  - DrJokepu 17y ago
    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.
    - rbanffy 17y ago
      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.

blasdel 17y ago

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!"

weavejester 17y ago
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.
- blasdel 17y ago
  The web's ideology is to not give a shit -- no baseline content types were ever specified for <img> or <object> or <embed>
  - slater 17y ago
    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.
    - blasdel 17y ago
      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.

blasdel 17y ago

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.

voidpointer 17y ago

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.