Brad, I'm surprised we didn't get a rant from you about how great OmniWeb is and will be and how Chimera is doomed cause it's based on 1.5 million lines of cross-platform code (not that I disagree with you.)
Well, I do have to agree with the original poster. When compared to Internet Explorer, Chimera *is* much faster and more responsive.
Of course, OmniWeb kicks the crap out of Internet Explorer too.
I don't at all think Chimera is doomed based solely on its Mozilla heritage. As Mozilla improves, so will Chimera (provided the Chimera developers ever decide to use something newer than the decrepit 1.0 release of Mozilla). I just see that OmniWeb has a *more* promising future because of its native design. From beginning to end, OmniWeb is designed strictly for Mac OS X. Mozilla, on the other hand, is moreso designed for Windows and Linux first.
<strong>And isn't some of the code from OmniWeb ported oover from OS 9?</strong><hr></blockquote>The Omni Group has *never* developed for Classic Mac OS. OmniWeb was first designed and run on NeXTSTEP. In fact, I believe it was included with the distro at some time.
In any case, Mac OS X is the evolution of NeXTSTEP. So, essentially, OmniWeb has been developed on the same OS since its start.
I think the big thing to watch is OmniWeb 5. If it delivers on its promises, that's going to be the web browser to beat.
For the moment, though, Chimera is the winner on my machine. Tabbed browsing, good standards compliance, speed, ease of use... it's still got room to grow, but I'm not touching IE anymore.
Well, OMNIweb is also doomed unless it switches to a better rendering engine very quickly. They claim they're developing their own, better-than-Gecko engine - well, Opera also did, and Opera 7 Beta 1 is, just as I expected, not much better in rendering than Opera 6.
<strong>Well, OMNIweb is also doomed unless it switches to a better rendering engine very quickly. They claim they're developing their own, better-than-Gecko engine - well, Opera also did, and Opera 7 Beta 1 is, just as I expected, not much better in rendering than Opera 6.</strong><hr></blockquote>
OmniWeb is far from doomed; it has a large base of users who appreciate the spell checking and good looks, and ad blocking, pop-up blocking, etc.
Just because one company failed at something doesn't mean that every other company that tries it will fail at it too...witness Apple.
<strong>Well, OMNIweb is also doomed unless it switches to a better rendering engine very quickly.</strong><hr></blockquote>The same can be said for Internet Explorer and its poor threading, but you don't see it going anywhere, do you?
OmniWeb excels at a low level that IE, Opera, Mozilla, and Chimera don't. For one, it has FAR better support for SMP. The latter browsers are barely threaded at all whereas OmniWeb is very much so. Since dual-processor Macs aren't going away for quite a while, this helps OmniWeb a great deal. Also, OmniWeb uses native classes for practically everything it does. That means things like the interface behave like a true Mac app should. No funky toolbar like Mozilla and IE. No funky text editing like in Mozilla and Chimera. No funky preferences window like IE and Mozilla.
The interface *alone* is the biggest reason that people use OmniWeb. Beyond that, the rendering really isn't so bad.
I've posted these quotes before and now seems like a fine to to post them again:
[quote]Originally posted by Rickster:
Why not just throw in the towel and make OmniWeb just another UI for Mozilla? Maybe it's pride, as Fotek suggests. Or maybe we think we can do better. I'll try explaining again why that might we worth our effort...
In the spirit of those Mac OS X architecture diagrams we've all seen a million times by now, here's a quick picture of what goes on in a web browser:
None of these parts of a web browser's "engine" is trivial: we (and the makers of other browsers) have invested much engineering effort into each.
Now, the state of affairs in OmniWeb 1.x-4.x is that the layout & display component (the green part in the diagram) is based on an architecture that made sense back in the earlier days of the web, but that turns out to be a major performance liability on modern pages. (It also makes compatibility with some web standards such as CSS-P near impossible.)
The other parts of the OmniWeb "engine", however, are based on a modular, multithreaded architecture that's unique among web browsers. That's why OmniWeb totals around 300,000 lines of code while Mozilla is somewhere on the order of 1.5 million lines. It's also why, despite taking a massive performance hit on layout & display, our performance is still competitive enough with the other guys that users are continually arguing over whether OmniWeb is faster or slower than Mozilla/IE/etc.
So, how do we resolve this issue where one component of our architecture doesn't work too great, but the rest are at the top of their game? If we used Cocoazilla, we'd get the entire Netscape engine, all the way down -- not only would we lose high-level features like best-of-breed Unicode support, we'd also be taking a step backward in terms of lower-level architecture. We could attempt to use the upper layers of Gecko in tandem with our lower-level code, but trying to interface the two completely different architectures in the middle would be a massive project. It'd take far more time and effort than rewriting our own layout & display component from scratch, and we'd still be taking steps backward in certain areas (like Unicode support).
We think we can do it better, so we're going to try -- we're already rewriting our layout & display engine for 5.0. If nobody thought things could be improved upon, there would be no such thing as progress.<hr></blockquote>
[quote]Originally posted by gregomni:
I want to follow up even more on what Rick was saying...
The different layers in Rick's architectural diagram all run in independent threads, with potentially multiple copies of each type of thread if (for instance) we are loading multiple pages at once or loading multiple images on a single page, et cetera.
This all funnels together into a single 'main' thread which runs both the user interface and view layout and display. As well as all the problems already mentioned with the view layout and display piece, that 'funnel' is a pretty major bottleneck to the speed up we get for our multi-threaded architecture.
We'll be fixing this when we replace that component in OW 5. The 'funnel' will essentially move up one level higher to be right below the user interface layer. Meaning, view layout and display will no longer be competing in the same thread with user interface, which should make OW more responsive.
Anyway, what I originally wanted to get at, is that even today with our outdated view layout layer, OmniWeb is very speedy compared to other browsers if you have a dual processor machine and a fast network connection. Our multi-threading architecture lets us get more done simultaneously, if your hardware and network can support it.
I see this as a bet on the future. I think cable and DSL are going to get more common, and I think multiprocessor Macs are going to get more common (including, perhaps, quad processors on the high end). OmniWeb is architected in such a way that we can continue to benefit from additional processors and additional bandwidth -- we have a lot of headroom to grow.
The other browser architectures (at least as far as we've investigated them) are concentrating on single-threaded performance, and don't appreciably benefit from multiple processors. They also don't tend to do as much network processing in parallel, so they don't take advantage of increasing network bandwidth as much as we can.
I admit it's a little hard to imagine a world in which average people do all their web browsing with a quad processor box hooked up to a megabit per second net connection, and it's even harder to imagine those people still complaining about slow web browsing in such a world. But if they did complain, it wouldn't be about our browser. :-)<hr></blockquote>
Comments
Moving to software.
Of course, OmniWeb kicks the crap out of Internet Explorer too.
I don't at all think Chimera is doomed based solely on its Mozilla heritage. As Mozilla improves, so will Chimera (provided the Chimera developers ever decide to use something newer than the decrepit 1.0 release of Mozilla). I just see that OmniWeb has a *more* promising future because of its native design. From beginning to end, OmniWeb is designed strictly for Mac OS X. Mozilla, on the other hand, is moreso designed for Windows and Linux first.
[ 11-17-2002: Message edited by: Brad ]</p>
And isn't some of the code from OmniWeb ported over from OS 9?
[ 11-17-2002: Message edited by: Spart ]</p>
<strong>And isn't some of the code from OmniWeb ported oover from OS 9?</strong><hr></blockquote>The Omni Group has *never* developed for Classic Mac OS. OmniWeb was first designed and run on NeXTSTEP. In fact, I believe it was included with the distro at some time.
In any case, Mac OS X is the evolution of NeXTSTEP. So, essentially, OmniWeb has been developed on the same OS since its start.
I knew it didn't begin its life on OS X though...just assumed it started on OS 9.
For the moment, though, Chimera is the winner on my machine. Tabbed browsing, good standards compliance, speed, ease of use... it's still got room to grow, but I'm not touching IE anymore.
Why doesn't Chimera use Mozilla 1.2?
<strong>Chimera's interface needs work. Why doesn't Command-down go to the bottom of a page? And then there's that Text Entry Bug!
Why doesn't Chimera use Mozilla 1.2?</strong><hr></blockquote>
Yup, the text entry bug is pretty annoying
No major annoying bugs in OmniWeb, and Explorer displays everything fine.
Also, rendering speed matters little when you are on a 56k.
<strong>Well, OMNIweb is also doomed unless it switches to a better rendering engine very quickly. They claim they're developing their own, better-than-Gecko engine - well, Opera also did, and Opera 7 Beta 1 is, just as I expected, not much better in rendering than Opera 6.</strong><hr></blockquote>
OmniWeb is far from doomed; it has a large base of users who appreciate the spell checking and good looks, and ad blocking, pop-up blocking, etc.
Just because one company failed at something doesn't mean that every other company that tries it will fail at it too...witness Apple.
<strong>Well, OMNIweb is also doomed unless it switches to a better rendering engine very quickly.</strong><hr></blockquote>The same can be said for Internet Explorer and its poor threading, but you don't see it going anywhere, do you?
OmniWeb excels at a low level that IE, Opera, Mozilla, and Chimera don't. For one, it has FAR better support for SMP. The latter browsers are barely threaded at all whereas OmniWeb is very much so. Since dual-processor Macs aren't going away for quite a while, this helps OmniWeb a great deal. Also, OmniWeb uses native classes for practically everything it does. That means things like the interface behave like a true Mac app should. No funky toolbar like Mozilla and IE. No funky text editing like in Mozilla and Chimera. No funky preferences window like IE and Mozilla.
The interface *alone* is the biggest reason that people use OmniWeb. Beyond that, the rendering really isn't so bad.
I've posted these quotes before and now seems like a fine to to post them again:
[quote]Originally posted by Rickster:
Why not just throw in the towel and make OmniWeb just another UI for Mozilla? Maybe it's pride, as Fotek suggests. Or maybe we think we can do better. I'll try explaining again why that might we worth our effort...
In the spirit of those Mac OS X architecture diagrams we've all seen a million times by now, here's a quick picture of what goes on in a web browser:
None of these parts of a web browser's "engine" is trivial: we (and the makers of other browsers) have invested much engineering effort into each.
Now, the state of affairs in OmniWeb 1.x-4.x is that the layout & display component (the green part in the diagram) is based on an architecture that made sense back in the earlier days of the web, but that turns out to be a major performance liability on modern pages. (It also makes compatibility with some web standards such as CSS-P near impossible.)
The other parts of the OmniWeb "engine", however, are based on a modular, multithreaded architecture that's unique among web browsers. That's why OmniWeb totals around 300,000 lines of code while Mozilla is somewhere on the order of 1.5 million lines. It's also why, despite taking a massive performance hit on layout & display, our performance is still competitive enough with the other guys that users are continually arguing over whether OmniWeb is faster or slower than Mozilla/IE/etc.
So, how do we resolve this issue where one component of our architecture doesn't work too great, but the rest are at the top of their game? If we used Cocoazilla, we'd get the entire Netscape engine, all the way down -- not only would we lose high-level features like best-of-breed Unicode support, we'd also be taking a step backward in terms of lower-level architecture. We could attempt to use the upper layers of Gecko in tandem with our lower-level code, but trying to interface the two completely different architectures in the middle would be a massive project. It'd take far more time and effort than rewriting our own layout & display component from scratch, and we'd still be taking steps backward in certain areas (like Unicode support).
We think we can do it better, so we're going to try -- we're already rewriting our layout & display engine for 5.0. If nobody thought things could be improved upon, there would be no such thing as progress.<hr></blockquote>
[quote]Originally posted by gregomni:
I want to follow up even more on what Rick was saying...
The different layers in Rick's architectural diagram all run in independent threads, with potentially multiple copies of each type of thread if (for instance) we are loading multiple pages at once or loading multiple images on a single page, et cetera.
This all funnels together into a single 'main' thread which runs both the user interface and view layout and display. As well as all the problems already mentioned with the view layout and display piece, that 'funnel' is a pretty major bottleneck to the speed up we get for our multi-threaded architecture.
We'll be fixing this when we replace that component in OW 5. The 'funnel' will essentially move up one level higher to be right below the user interface layer. Meaning, view layout and display will no longer be competing in the same thread with user interface, which should make OW more responsive.
Anyway, what I originally wanted to get at, is that even today with our outdated view layout layer, OmniWeb is very speedy compared to other browsers if you have a dual processor machine and a fast network connection. Our multi-threading architecture lets us get more done simultaneously, if your hardware and network can support it.
I see this as a bet on the future. I think cable and DSL are going to get more common, and I think multiprocessor Macs are going to get more common (including, perhaps, quad processors on the high end). OmniWeb is architected in such a way that we can continue to benefit from additional processors and additional bandwidth -- we have a lot of headroom to grow.
The other browser architectures (at least as far as we've investigated them) are concentrating on single-threaded performance, and don't appreciably benefit from multiple processors. They also don't tend to do as much network processing in parallel, so they don't take advantage of increasing network bandwidth as much as we can.
I admit it's a little hard to imagine a world in which average people do all their web browsing with a quad processor box hooked up to a megabit per second net connection, and it's even harder to imagine those people still complaining about slow web browsing in such a world. But if they did complain, it wouldn't be about our browser. :-)<hr></blockquote>
More information <a href="http://forums.macnn.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=37;t=003527"; target="_blank">here</a>
[ 11-18-2002: Message edited by: Brad ]</p>
user_pref("network.http.pipelining", true);
user_pref("network.http.proxy.pipelining", true);
<strong>
More information <a href="http://forums.macnn.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=37;t=003527"; target="_blank">here</a></strong><hr></blockquote>
They aren't on UBB anymore, man.
<a href="http://forums.macnn.com/showthread.php?s=&threadid=88706"; target="_blank">Good linky</a>