Why Mozilla Is Committed To Using Gecko

Ars Technica has published an article about Mozilla's commitment to use the Gecko rendering engine instead of using Webkit, which was adopted by Apple and Google for use in the Safari and Chrome browsers. I have been using Chrome on my work PC and find many of its features compelling, and wonder how soon we will see its best innovations in Firefox. Why is Gecko worth keeping if it is outdated and bloated?

Comments

Why use Gecko?

[suck_burners_rice]

Because it has a cooler name than the boring sounding WebKit. Besides, it'll save you 15% on car insurance.

Re:Why use Gecko?

[sexconker]

Really? I thought it was so we could render GameCube games. (And Wii games if you have some duct tape and a dual core CPU?)

Re:Why use Gecko?

[smittyoneeach]

Thought it was so easy, even a caveman could code it.

Re:Why use Gecko?

[martin-boundary]

Because it has a cooler name than the boring sounding WebKit.

So boring, and yet so close to mass appeal! All they had to do was name it WebK.I.T.T., and bring out the 'Hoff (*shakes head*)

Re:Why use Gecko?

[causality]

Because it has a cooler name than the boring sounding WebKit. Besides, it'll save you 15% on car insurance.

Yeah, their commercials often say that a 15 minute call will save me 15% on my car insurance. So what happens if I give them a 100 minute call?

Re:Why use Gecko?

[davester666]

It's just to make sure XPCOM continues to get used. Otherwise, it would just fade into history.

And that would be bad.

Re:Why use Gecko?

[TheNetAvenger]

McCain/Palin '08. Now THAT's hope and change!

Rove would be proud of you, still partially in charge of a campaign ran by lobbyists, and they have convinced people they will change things.

Maybe start by firing Rove and the Lobbyists running the campaign, and I might believe McCain, until then, the change argument is about as accurate as being 'against' the bridge to nowhere, from one of the people that pushed Stevens for it. ;)

Re:Why use Gecko?

[aliquis]

But then you'd have to replace it after every crash, and predict them in advance so the user never notice that there was one.

Re:Why use Gecko?

[aliquis]

Over here in Sweden Synoptik lets you buy glasses with your age in years as rabatte on a pair of glasses, so if you are 45% old you'll get 45% off and so on. Great for 100+ year olds.

(I wonder if 500 pairs / day at 120 year old works, will someone please think of the grandchildren?)

Re:Why use Gecko?

[eam]

How do you know you are 45% old? Don't you have to know when you are going to die in order to know you are 45% old?

Let's see....

If I'm 45% old now, that means I'll live to be 84... ;-)

Re:Why use Gecko?

[aliquis]

bwah, don't ask me why I typed % ;/

If you decide to do suicide within the same day you can be pretty sure, but not really sure, when your life end ;D

lite

[TheSHAD0W]

Why is Gecko worth keeping if it is outdated and bloated?

Because it's bloated as a single app, but less bloated then opening up a new process (or more than one!) for every single web page loaded. Until every computer in use has multi-gigabyte memory, including handheld devices, there will be a need for something lighter than webkit

Re:lite

[Just Some Guy]

You're confusing Firefox-the-browser with Gecko-the-renderer. There's no reason Firefox couldn't have one process per tab, and most Webkit/KHTML implementations currently use one process per browser window (like Firefox).

In short, pick something else to distinguish them. You're way off this time around.

Re:lite

[Anonymous Coward]

Webkit doesn't specify that you have to use a separate process for each page. That's a Google Chrome feature.

Re:lite

[kestasjk]

Isn't Chrome the only browser out there which does this? And doesn't it actually just do it with separate processes and not individual threads?

Maybe I'm missing something, but it doesn't seem incredibly shameful to me.

Re:lite

[bigstrat2003]

IE 8 has threaded tabs. Now, granted, that's in beta, but that means that the biggest browser has picked up this feature. Chrome also has it, albeit with processes instead of threads. Note I'm not picky about the technical details of threads vs processes, I just want the browser to not completely hang (or worse, crash) based on one tab's misbehavior.

Like I said, given that IE 8 is implementing threaded tabs, there's no excuse for Firefox not to have it. It just brings too much to the table in terms of reliability to not have.

Re:lite

[stephanruby]

Why is Gecko worth keeping if it is outdated and bloated?

Because Gecko is actually less outdated than Webkit. When Webkit can run extensions/plugins without crashing, then may be -- then Webkit could be a serious contender.

Re:lite

[jorgevillalobos]

There is no excuse for a modern browser to not have this, especially in light of the fact that their main competitor (IE) is developing it.

Here's one excuse: complications when trying to have multiple processes render content on a single window in Mac OS X (mentioned near the end of the tab process isolation section).

It's not clear to me if this is impossible or really difficult to achieve, but I think it'll be interesting to see what Chrome does for Mac OS X.

Re:lite

[Moridineas]

Opening a new process per rendering window is a property of google chrome NOT webkit. Try Safari if you want to see what Webkits looks like in a more established browser.

Additionally, I don't know about you, but I haven't bought a computer in several years that hasn't had 2gb, and 1gb seems to be the absolute floor. Memory isn't doing any good if it's not being used!

Re:lite

[multipartmixed]

Really? You think threaded tabs bring stability to the browser. WHAT? How the HELL do you figure that?

Re:lite

[bigstrat2003]

...it's trivial to figure that out. Let me explain it to you: you have tab A, and tab B. If tab A and B share the same thread, they will hang each other if one of them hangs. By putting them in separate threads, tab A and B can hang, but not affect each other.

How is that hard to see? It's not exactly a great insight.

Re:lite

[et764]

IE 8 actually a process-per-tab (almost) model, like Chrome does. The logic of how to split tabs and stuff into different processes is different, but the general idea is the same. One thing Chrome does that IE doesn't, as far as I know, is that Chrome runs plugins like Flash in a separate process, while IE still keeps them in the tab's process.

The threads vs process distinction is very important, actually. Processes each get their own address space, while threads share an address space. This means processes can't write to each other's memory (except through things like shared memory segments), whereas threads can trample all over the other threads. A thread per tab model does protect you from a rogue Javascript freezing the browser's UI, but it doesn't protect you from a poorly written plugin that does something stupid like dereference a NULL pointer. If you really want reliability, you want processes instead. The downside is that processes are a lot heavier than threads.

Re:lite

[chromatic]

... unless there's thread contention, or memory corruption, or a deadlock, or they use a non-thread-safe library with a global lock, or one thread has to handle a signal, or there's a segfault, or....

Re:lite

[multipartmixed]

> How is that hard to see? It's not exactly a great insight.

Haven't done much multi-threaded programming, have you?

Say, one thread locks a mutex and hangs.

Whoops! Now all the other threads that want that mutex will wait forever!

How's THAT for great insight?

Repeat after me:
1. Threads are Hard
2. Threads are not magic bullets
3. Threads introduce WHOLE NEW CLASSES of bugs

Re:lite

[Jarjarthejedi]

Lol. You have a grossly inflated view of process-specific tabs IMHO.

To take your points one by one,

"Stable over Lightweight" - Firefox 3 has never crashed on me. Not once in the time I've been using it, which has been over a month now. And I use it daily, for at least an hour a day, with flash games being a near daily diversion. Chrome, on the other hand, is far lighter weight (at least ram wise, CPU wise it's too much of a hog for me) but has crashed twice, and I've used it for, perhaps, 3 hours. Ergo, by your logic, FF3 is the better browser for me.

"Lack of threaded tabs is shameful" - Why? Is it really that big of a deal? Don't open a tab that's going to lock up your browser.

"IE developing it" - Oh noes! We need this now, if IE has it then FF needs it! Guess we should go ahead and make FF IE5 complient then, since IE is as well. Forget that standards nonsense, IE has it so we need it.

If you're encountering enough lock-ups to cause you to need to be able to end a single tab's process regularly (which is pretty hard to do in Chrome with all the tabs having the same process name mind you) then have fun with your threaded tabs. Me, I'm just not going to open sites that are likely to lock up my browser. There aren't many out there, I haven't seen a single one in a couple of months.

Re:lite

[TheUser0x58]

Note I'm not picky about the technical details of threads vs processes, I just want the browser to not completely hang (or worse, crash) based on one tab's misbehavior.

The details are important. If a crash occurs in one thread, the whole process (i.e. application) will go down. IE8's one thread per tab model will not improve resilience against crashes.

Re:lite

[qualidafial]

Let me explain it to you: you have tab A, and tab B.

Sorry, I was distracted by something shiny.

Could you restate your scenario in terms of tab A and slot B?

Re:lite

[BenoitRen]

Even if Firefox used threaded tabs, it wouldn't stop the browser from crashing if one tab screwed up. If one thread in a process crashes, the entire process crashes.

Re:lite

[bigstrat2003]

I never said it was trivial to implement, just necessary. One doesn't imply the other.

Re:lite

[Sancho]

And because people confuse that, they tend to post misinformation.

IE8's tabs will be in separate processes despite what the grandparent said. This adds stability.

Re:lite

[Just Some Guy]

When Webkit can run extensions/plugins without crashing

Is it Webkit that actually runs the plugins? In Chrome, plugins run in their own child processes, so it seems like it would be Chrome and not Webkit that manages them.

Re:lite

[lysergic.acid]

that's not an argument for having a memory-hogging web browser.

yes, CPU clock speeds are going up, and memory prices are going down, but a web browser should still be a relatively lightweight application by itself.

there are much better uses for the increase in standard memory size in desktop computers. with computers as advanced as they are today, i should be able to have a web browser running in the background while i'm working in Photoshop, Illustrator, or other memory-intensive applications. even if you're not multi-tasking, the extra memory should go towards opening more tabs, running java applets, rendering flash applications, or streaming media.

there seems to be a negative trend of basic office applications becoming increasingly resource-intensive at a pace that negates simultaneous increases in computer processing power. that's not technological progress, that's just inefficient software development.

there's no reason that an office secretary should require a dual-core CPU and 2 GB of RAM when all she really needs to use her computer for is checking e-mail, word processing, web browsing, and possibly edit spreadsheets or run slide show presentations like PowerPoint.

i mean, what good is increased CPU efficiency and cheaper memory when all of that is offset by increased hardware requirements for basic software applications? with the current energy-crisis, we ought to consider whether or not the average person should need to keep pace with Moore's law for simple computing tasks like web surfing or word processing. given the huge strides made in CPU efficiency, a modern web browser should be lean enough in its most basic configuration to be capable of running on a modern low-power PC.

it doesn't make sense to constantly upgrade one's computer just so all applications run just as slow as they did before.

Re:lite

[fuzzylollipop]

Note I'm not picky about the technical details of threads vs processes, I just want the browser to not completely hang (or worse, crash) based on one tab's misbehavior.

If you aren't picky about the details then you don't understand the problem, and thus the solutions and why Threads don't give you protection from misbehaving browser windows/tabs and processes do.

Re:lite

[fuzzylollipop]

...it's trivial to figure that out. Let me explain it to you: you have tab A, and tab B. If tab A and B share the same thread, they will hang each other if one of them hangs. By putting them in separate threads, tab A and B can hang, but not affect each other.

How is that hard to see? It's not exactly a great insight.

Wrong, a misbehaving Thread can and will hang the entire process. If anything Threads will INCREASE the chance of hanging the entire browser, because correct Thread programming is HARD!

Re:lite

[im_thatoneguy]

Why? Is it really that big of a deal? Don't open a tab that's going to lock up your browser.

Oh that's why all those links were labeled "will crash your browser if clicked"! It makes so much more sense now. I kept expecting my browser to fail gracefully and continue operating and didn't realize I just wasn't supposed to click all those links listed as such.

In other news I would like everybody to stop running executables which crash. The OS shouldn't need to keep them isolated since you shouldn't be running applications which crash in the first place. /sarcasm

You must be a gymnast because you really had to bend over backwards pretty far to justify yourself.

Re:lite

[bigstrat2003]

I'm perfectly clear on the difference between threads and processes, but I was, indeed, misinformed, and had read that IE 8 uses threads, not separate processes. Thank you for the correction.

Re:lite

[Moridineas]

yes, CPU clock speeds are going up, and memory prices are going down, but a web browser should still be a relatively lightweight application by itself.

Why? I spend more time in the web browser--by far--than any other application. Email? 10 years ago I used a standalone email app, now I mostly use webmail. 5 years ago I used AIM. Now I use web chat. Picasa? Google documents? Between javascript advances, DOM, rich media, plugins, TABS, etc etc etc, today's browser does things not even imaged in 10 years ago.

Chrome's very purpose is to make the browser a more generalized application development platform. Heck, WEBKIT is used in the same way (and XUL, etc for Firefox). The web browser ain't just for HTML circa '97 anymore. The web browser is probably the single most important application for most users.

there seems to be a negative trend of basic office applications becoming increasingly resource-intensive at a pace that negates simultaneous increases in computer processing power. that's not technological progress, that's just inefficient software development.

Exactly right. MS Office is a great example of this. The average user utilizes a very small percent of the functionality of Office, and yet everyone suffers the bloat. Can you honestly say that most people don't get anything out of a more rich browsing experience?

Re:lite

[hairyfeet]

It is also quite easy to customize,both with extensions and full bore rebuilds. Firefox by itself is okay, but with Noscript,Adblock Plus,Forecastfox,and FEBE to ensure backups it makes Firefox a must have in my book,even so far as keeping a copy of Firefox Portable(another nice customization) on my flash for out in the field.

And then if Firefox isn't to your liking there is always Flock,and Kmeleon for older Windows machines(also works with Noscript and Adblock with a little tinkering) and of course there is Songbird which is going for an Open Source iTunes kind of thing and is actually a pretty nice media player IMHO. To me that is what is nice about Gecko,it has enough features built in that a good coder can use it as the basis for all sorts of applications and it is trivial to add functionality through extensions to make the browser YOUR way,instead of what some company thinks is best. This is why despite the buzz around Chrome I'll still be installing Gecko based browsers(Firefox,Seamonkey,or Kmeleon depending on the client/machine) on every machine I service or sell. But as always this is my 02c,YMMV

Re:lite

[cecil_turtle]

The only word that suffices to describe Firefox's lack of threaded tabs is "shameful". There is no excuse for a modern browser to not have this,

You do know that there are not currently any stable browsers with threaded tabs, don't you? There are exactly two browsers attempting this that are both in early betas. You speak as if it's been common for years and Fx is way behind the game.

Re:lite

[cecil_turtle]

Correcting my own post, of course I'm assuming the parent meant "tabs in separate processes" rather than "threaded tabs". Hopefully the latter doesn't become common slang for the former.

Re:lite

[Sancho]

You probably got your information from someone who was unclear on the distinction :)

Re:lite

[MidnightBrewer]

You're confusing the browser with the render engine. WebKit doesn't dictate how many threads are used, it just parses the web pages. That's how both Chrome and Safari can both use WebKit and have entirely different approaches to their tab implementation.

Since WebKit is in fact ten times lighter than Gecko in memory (an admission made by one of the developers in TFA), that is a Good Thing(tm). However, Firefox scrapping Gecko would also mean losing XUL and extensions along with it, which would be less than good for those of us who like that functionality.

Re:lite

[Undead NDR]

Because it's bloated as a single app, but less bloated then opening up a new process (or more than one!) for every single web page loaded.

Rendering engine choice has nothing to do with multi-process tabs. Chrome does its thing by spawning multiple instances of WebKit, so it's not like the "separate processes" philosophy is somehow built into the renderer. Firefox could do the exact same thing with Gecko.

Re:lite

[Trogre]

4. Threads are necessary

Re:lite

[naasking]

and most Webkit/KHTML implementations currently use one process per browser window (like Firefox).

Firefox does not use one process per browser window. Firefox uses one process per user profile.

Re:lite

[StrategicIrony]

Given infinite resources to code and debug applications, that may be the case.

On the other hand, given realistic design specifications, given the current level of compilers and code verification, the advantage to spawning new threads all the time for processes that aren't super I/O intensive is quite often far overshadowed by the complexity introduced by doing that.

Obviously, it's a design decision, but threaded tabs simply put more onus on the developers to sit around troubleshooting race conditions and inter-thread communications, rather than actually focusing on user-oriented features and performance enhancements.

6 in one, half dozen in the other.

But you don't do yourself any service by dogmatically insisting on it, like it's a magic bullet.

You sig is funny btw

But I want to eat cookies all the time! I want to do it!!.

Yes... and threads too. :-)

Re:lite

[rs79]

"Haven't done much multi-threaded programming, have you?"

Aww hell. I've used Opera since about version 4 or so and I was there the day they foisted tabs on is. Neat idea but it sure makes browsers crash a lot.

It's mostly better these days. Mostly. I still open things in new windows which seems to be a bit safer.

So it aint just an unfamiliarity with threaded code, one has to wonder about the whole, uh "tabbing experience" factor here.

But carry on.

Re:lite

[bluephone]

The downside is that processes are a lot heavier than threads.

Kinda like yarn!

Re:lite

[aztracker1]

Funny, just tracked down a bug earlier today related to a similar issue... A static instance of Class A is instantiated, and called by multiple processes... Class A had a class level instance of Class B... Class B had a class level variable that method X used. Method X would modify Class B's variable while running... On occasion the wrong information was shown to the user... Why, a static instance where a child object's methods weren't threadsafe... even though they weren't really designed to be, but because of being called from a static instance, used by multiple threads... just a major issue about 1/100,000th of the time.

Building anything that is multi-threaded, even if un-intentional can cause issues... in this case, making the Class A's instance inside the method was the solution... in other cases locking is. Just depends.. it's just amazing how many people don't understand, or realize how these issues pop up.

Re:lite

[sir fer]

I don't know about you, but I'll take stable over lightweight any day. The only word that suffices to describe Firefox's lack of threaded tabs is "shameful". There is no excuse for a modern browser to not have this, especially in light of the fact that their main competitor (IE) is developing it.

Well why don't you fucking write some code so it does? Either that or STFU.

Re:lite

[Firehed]

I don't see why this was modded troll - it's a very accurate statement, even if it shows !Mozilla in a good light (even MS, *gasp*). I haven't used a computer with less than a gig of RAM in about five years, and a lightweight app is no good to anyone if it crashes every hour. Firefox has been relatively stable for me all things considered (except for some rogue JS at digg which I abandoned a while ago, I rarely have issues), but Chrome's approach of sandboxing tabs so they don't kill each other probably should have come around tabbed browsing 1.1.

It would be one thing if this approach bloated up Photoshop or something (as if PS wouldn't burst if it got any more bloated), but I spend ALL DAY with my browser open - dozens of tabs often spread across a couple windows. Firefox taking 400MB of my 4GB doesn't bother me considering how much of my time it gets (though since 3.0 and disabling Firebug, it's not usually near that bad), so taking a little more of my system's memory in order to significantly enhance stability is more than worth it.

Hell, even in my pre-Firefox days (actually, I think this was everyone's pre-firefox days, as I'd made the switch around the time of the old mozilla naming fights), I could almost emulate this by digging for that old setting somewhere in the bowels of explorer preference to make each IE6 window run it its own explorer.exe process. And as you might expect, the system as a whole became fantastically more stable upon doing so. IE6 was (and still is) as crash-prone as ever, but it wouldn't take out my other browser windows nor the main GUI process when one took a nosedive (the decision to make the browser and the desktop run in the same process by default has always been well outside the grasp of my understanding). In any case, that should have been a tip-off that each tab should have its own process. To be fair, that setting is so buried that I'm probably one of about five people in the world to have used it (hell if I still know where it is), but there was still an important lesson there.

Re:lite

[bigstrat2003]

Ah yes, the worthless comeback of any fanboy of an OSS project. "Write some code". Well, that might be necessary if no one else was meeting my needs, but two other browsers are, so I'm gonna go ahead and go with "no" on this one. Even ignoring that fact, suggesting you need to help write the browser in order to comment is laughable.

Re:lite

[aztracker1]

In the case of Chrome, there's one process for the main application, and others pre tab (rendere'd view) and plugin. The overhead for the view itself is far larger than the shared content that multiple tabs/view may have.

Re:lite

[wc_paladin]

Processes are better than threads for stability purposes. If a page in a thread causes the browser to crash, the whole thing crashes. If a page in a process crashes, that tab is all that is affected.

Re:lite

[Firehed]

Slot B is visible in tabs A, C, D, E, F, and G. You're currently in tab B, slashdot.org. Very inappropriate multitasking, especially given that out of seven tabs, you're currently browsing the one that's not porn. You need to learn to prioritize.

Re:lite

[mweather]

WebKit can run in a single thread.

Re:lite

[lysergic.acid]

i understand that the web has evolved quite a bit over the years--trust me, i know.

but when you discuss the relative importance of the browser compared to other applications, you still need to look at things in context:

one of the main benefits of the web as an application platform is that you can start accomplishing previous desktop computing tasks using a thin client. why is that? because with software as a service, all of the data processing is done server-side. all your browser needs to do is render the presentation, everything else is run on the web server.

but you're absolutely right, even web UIs have become much more involved; today's web apps/interfaces are a lot more interactive, and significantly more responsive. some of this is due to increased capabilities/complexity of the desktop browser. however, much of this is also because the actual content to be rendered by the browser's layout engine is much more complex and resource-intensive.

it's like watching a QuickTime video in your browser, or playing a Flash game. the actual content is much more resource intensive, just as a Web 2.0 interface with lots of div layers, images, event-tracking, JavaScript libraries, and not to mention all the CSS style rules that are loaded with each site. but these are resource requirements in addition to the actual browser application. if a browser with a single blank page loaded eats up 1 GB of memory, then how is it going to deal with 10-15 tabs, each loaded with rich web content.

i've also become quite dependent on a lot of Firefox extensions that help me check my mail and even develop/debug web applications. but these are all superstructures that are loaded on top of the basic browser application. my Firefox installation takes significantly longer to load than a standard installation. if Firefox were to become more of a resource hog, then how would i even run these plugins that i use daily?

Re:lite

[spitzak]

A thread per tab model does protect you from a rogue Javascript freezing the browser's UI, but it doesn't protect you from a poorly written plugin that does something stupid like dereference a NULL pointer.

Actually threads would protect against a null pointer because it would cause an exception that could then kill only that thread. What threads can't protect against is random memory being used as pointers, if the memory contains a pointer to allocated pages it will write over that memory and nothing can catch it.

Separate processes would be better because of this, but it does slow down communication between the threads. And in reality most of the failures of flash/java/layout appear to be them just screwing up their own logic, not due to accessing random memory locations. So I can see why threads were preferred.

One surprise is that Microsoft's solution is multiple processes, while the Unix solution is threads. This is pretty much the reverse of previous tendencies.

Re:lite

[Anonymous Coward]

slashdot would suck without multiple threads.

Re:lite

[Z34107]

but less bloated then opening up a new process (or more than one!) for every single web page loaded

Well, as others have said, that's a feature of Chrome, not Webkit.

But, multiple processes makes things less bloated, not more so. The obvious case is on multicore processors - each core can render a tab, and multiple tabs can be rendered simultaneously. It's faster, and makes better use of your CPU.

Less obvious is how multiple processes fare better even on a single core. Depending on how the browser is written, a bloated^W "Web 2.0" page laden with graphics and animation can be death to a slow processor. But, if the lagging tab is in its own process, it doesn't affect the rendering of your other tabs. By taking advantage of how your operating system schedules processes, you've kept your browser responsive and made better use of your single core.

Now, it's not like there aren't other ways to do this - multiple processes is just a very elegant way. (It would have been better if Google did multiple threads, but that probably would've made it harder to port to operating systems that don't support them. *Squinty eyes*).

It's also not like multiple processes don't have overhead - context switching is expensive in a multitasking operating system, and multiple processes (but not so much multiple threads) will eat memory quicker.

But, I doubt they're trying to put Google Chrome on embedded devices anyways. And, it's not like the memory difference is that astronomical - I've had 3 tabs open, and 3 chrome.exe processes. They totaled 68MB of memory used, but one process released most of it's memory as I was writing this rant (!) and those same 3 tabs now only occupy 50 MB of memory. The same three tabs in Internet Explorer are using 57MB, and those tabs in Firefox are using 55MB. Not that that's a scientific measurement, and it's not like the memory used isn't fluctuating by several megabytes even as the other browsers sit, but the "bloat" just isn't there.

It's a better programming method, it has negligible memory overhead when done right, and it's much, much faster. I was happily using a combination of Firefox 3 and Internet Explorer 7 (and recently IE8 beta 2), but Chrome was just so much faster than even Firefox that it made me switch.

Join the dark side?!

Re:lite

[Anonymous Coward]

Sir, you've hit the nail with thumb intact.

I often wonder how software (particularly office or basic internet applications) can somehow manage to demand the same proportion of computing power today as they did fifteen years ago, almost rendering the increase in computational power worthless for so many "simple" tasks. My current computer is about 850 times faster than one I had in the early '90s (on paper, anyway), and yet it takes about the same about of time to load Windows, open Word, write a short document, save it, and then shut down.

I know it's because the current version of Word offers a vast array of features that I could only dream about through most of the last decade, but most of the time, I'm not going to use it. I don't even want it to load into memory until I specifically tell the application that I'm about to do some graphing, or translating, or whatever. Can't these apps open in a kind of "thin mode", and stand ready to load additional features as I express desire to use them?

As fast as breakthroughs are made in hardware, software is always able to keep pace, demanding more and more of it. This is fine for games, or other applications that offer a better experience with the additional resources (and which are not designed to be run alongside other apps), but for basic office work or internet browsing? Those applications should be lightning fast by now.

Re:lite

[gutter]

Sounds like somebody doesn't understand how shared libraries and forks with copy-on-write work. Operating systems these days are very smart. With shared libraries, there is only one copy of WebKit across every process that uses it.

Also, I'm sure that Google is smart enough to use fork() to create new processes. When you fork a new process, it doesn't actually allocate new memory - the new thread points at the same copy in memory until something changes. When that happens, the OS will allocate new memory for just the changed part, and continue to share the parts that haven't changed.

This means that each new process which will not actually use any extra memory until it modifies a data structure, and even then only the memory for the changed data structure will need to be allocated by the OS. Since it needed to be different for the new tab, it would have had to have been a separate variable in the new thread anyway, so the actual memory overhead of a new process should be surprisingly low.

Re:lite

[supernova_hq]

My head hurts... Where are foo, bar, and family guy references?

Re:lite

[Anonymous Coward]

You, personally, are the reason I can't convince managers to use open source products.

I hope you're proud of your own stupidity.

Re:lite

[TheSHAD0W]

Looks like I'm going to have to reply to myself, since pretty much everyone responding misread my point.

I am actually very fond of the idea of using independent processes to perform a task; it reduces code complexity enormously, making tasks more elegant and less prone to bugs - and also significantly raises the resources required. Multithreading raises resource use, though less so than multiprocessing, but often causes complications that surpass even single-threaded coding. I like Google Chrome's model (and only uninstalled it because of its obnoxious updater).

Someday, soon I hope, we will have machines with dozens of processors and terabytes of memory that will blow the hell out of the single-thread paradigm. Until EVERY general-purpose computer has reached that level, however, there will still be room for more efficient codebases. I just bought a computer with "only" a gigabyte of RAM (Eee PC), and I doubt handhelds will routinely reach past a gig for years yet. Until then Firefox should hang around.

Re:lite

[reddburn]

Until every computer in use has multi-gigabyte memory, including handheld devices, there will be a need for something lighter than webkit

Except that webkit browsers never leaked memory like a New Orleans levee, while Firefox has only recently gotten the problem within some reasonable boundary. On older machines, WebKit browsers would run for far longer without depleting my available memory.

Re:lite

[veskoteque]

Really, come on! I tired of 'thread bashing'.

1. If you insinuate that multi-process programming is easier than multi-threaded programming any time that resources need to be shared, than you are plain wrong.

2. In a non-threaded program you are running essentially a single thread. If that thread hangs, your whole program hangs anyway. Mutex or no mutex.

3. True - but they also solve a whole new class of problems. So they are not a universal bullet, I would not multi-thread hello world. But when the time comes to when you need them - it sure feels like a magic bullet.

Anyway. SOMEONE POST SOMETHING ON TOPIC! I am more than half way through this, and I still don't know why WebKit is cool, and why Mozilla won't use it! (And multi-threaded vs. multi-process is not that reason)

Re:lite

[Moridineas]

i understand that the web has evolved quite a bit over the years--trust me, i know.

Ok, I trust you! ;-)

one of the main benefits of the web as an application platform is that you can start accomplishing previous desktop computing tasks using a thin client.

That WAS one of the biggest benefits of web apps, and IS still an advantage. But again, look at the goals of Chrome..of the Webkit library..of the gecko library, etc. These XML/DOM/Javascript engines are becoming strong application development platforms in their own right. Google gears. It's very clear that this is the direction that both browsers and application development is heading in. (at least for now)

if a browser with a single blank page loaded eats up 1 GB of memory

Well, that's hyperbole to be sure.

Win2k3 server, FF3, according to task manager.

1 tab, our company intranet (XHTML+CSS+1 image+javascript) -- 30mb
+1 blank tab ... 30mb
+2nd blank tab ... 30mb
+3rd blank tab ... 30mb
(etc)
+5th tab -- google -- 31mb

How can you complain about 31mb?

--

Chrome, default 1st tab -- 22mb
1st tab -- google
2nd tab -- intranet
3rd tab -- microsoft.com
4th tab -- slashdot
5th,6th,6th tab -- blank

memory usage is ~60mb total.

So basically, not only is your complaint completely invalid, but I would question whether you've looked at Chrome's (or Firefox's for that matter) memory usage at all? I mean, 1gb for a single blank page is orders of magnitude off :p

As I argued before, there's no longer any point to additional computing power except to improve the user experience. Office is bad. Web browsers good.

Re:lite

[AmberBlackCat]

I'm thinking they want to keep using Gecko because they made it and want to justify its existence.

Re:lite

[Jarjarthejedi]

"Gee, why didn't I think of that? Develop a magical foresight that allows me to know what actions will cause my applications to crash! Brilliant!"

Well let's see. Is is javascript or flash based? Does it come from a less than reputable site? What else would cause a browser crash I ask? I have little experience with them, despite visiting probably 100 web pages per day.

I have used Chrome, fairly extensively (as I said, about 3 hours worth thus far). Haven't found that process manager yet, it's either well hidden or poorly shown.

I developed that insight through simple application of common sense. 99% of reputable webpages will not crash your browser, period. If they do, then there's something wrong with your computer besides your browser. Ergo, if you don't want to crash, don't visit irreputable websites. And if you can't tell the good from the bad on the internet then you haven't spent enough time on it.

"I never said anything resembling your idiotic "IE has it, so everyone else must have it" mockery."

Yes, you did.

"especially in light of the fact that their main competitor (IE) is developing it."

Tell me, how do you read that statement to not mean "Since IE is developing it, Firefox needs it"? That's pretty much exactly what you said, perhaps not what you mean, but what you said.

Re:lite

[lysergic.acid]

i think you misunderstood me. i was simply responding to the statement "since, the memory is there, you might as well use it." the hyperbole was intentional, not to criticize any existing browser (hence the word "if"), but to illustrate where resources could be better spent. so everything you wrote about actual memory usage is moot. it's a good thing that modern desktop browsers use very little resources by themselves.

regarding the web as an application development platform, i think you're neglecting the other part of the picture, which is the expansion of the web beyond desktop computing towards smart devices/portables--such as cell phones, portable entertainment devices, internet tablets, etc.

right now we're moving away from WAP browsers for portable devices as we develop more powerful smart devices with full-fledged web browsers capable of rendering most sites just as well as a desktop or laptop can. if the portable web experience is converging with the desktop experience, then clearly a fat client isn't the future direction of the web browser.

Re:lite

[xant]

You don't understand programming with processes.

Re:lite

[Arterion]

The web browser is VERY lightweight. Open a browser and point it to about:blank.

The problem is that the browser is a platform upon which to execute code. Without any javascript, the web would be super fast and lightweight.

For an analogy, it's really easy to completely bog down something as simple as a Word doc by adding a little VBA code to do something really intense. If people were to do this commonly, would we really have a right to complain about the huge resource consumption of Word? Substitute OpenOffice/StarBasic if you prefer.

The bottom line is, the browser is just a platform that, by itself, is very lightweight. But once you start to utilize the platform, you start using more resources.

What you're asking for is a free lunch. You want rich, graphical applications that consume the resources of a simple document viewer. We can improve efficiency, but from what I understand, we're fast approaching the speed of "native" apps with some of the new JS engines (Tamarin -> TraceMonkey, V8, etc). We can try to improve efficiency, but we can't get free cycles.

As for the secretary. The dual core/2GB RAM system is entry level anymore. It's only marginally cheaper than a single core system with less memory, so why not get it?

Re:lite

[BZ]

IE8 betas have process-per-tab as well.

Re:lite

[Icyfire0573]

"Lack of threaded tabs is shameful" - Why? Is it really that big of a deal? Don't open a tab that's going to lock up your browser.

Man your pretty good, do you pre-download every page you are about to view in a web-browser with curl and then parse everything in your head to make sure it won't lock up your browser?

PS: your pretty brave, trusting your brain not to lock up over your web-browser, at least you can kill the browser, i'm sure you'd be unhappy about killing yourself to get running again, i hear re-incarnation takes a while to get back to where you used to be.~

Re:lite

[sir fer]

3. Threads introduce WHOLE NEW CLASSES of bugs

ah, so that's why MS is so keen on adopting multi-threaded programs.

1.Introduce new buggy software

2.Offer paid support for said software

3.Eventually fix old bugs but introduce new ones

4.Profit

Re:lite

[e2d2]

Yes programming with multiple threads can be tricky, but there is a reason more apps are using more threads. It's to take advantage of the new hardware coming down the pike. IMO it gives webkit more longevity.

Multi-threading is not some "new fangled gadget" and this attitude, "The monolith is king because it's simple", is just nonsense. Some things require more complex code to take all the advantages it can get. A browser is one of those applications.

Re:lite

[sir fer]

Necessary for who?

Re:lite

[Pfhorrest]

Because it's bloated as a single app, but less bloated then opening up a new process (or more than one!) for every single web page loaded. Until every computer in use has multi-gigabyte memory, including handheld devices, there will be a need for something lighter than webkit

I know the singular of data is not anecdote, but having been using both Safari and Firefox since their respective inceptions (all on Macs of various vintages with various OS X versions), Safari pretty much always seems significantly faster than Firefox. Maybe the experience is different on other platforms, but on the Mac side at least it certainly feels like Webkit is much lighter than Gecko.

Re:lite

[jfengel]

If there's a need for a mutex in a multi-threaded app, how do they get around it in the multi-process app? Couldn't they just do the same thing in the multi-thread app?

I understand how a multi-process design provides a better level of isolation for the application, but I don't see how it helps with any of the other vast complexities of parallel programming. If anything, it should make some kinds of communication harder.

Re:lite

[TedRiot]

My Firefox 3 doesn't start a new process when I open a new window at least according to Task Manager in Windows.

Re:lite

[spongman]

chrome runs the plugins in a separate, sandboxed process. IE8 runs the whole page (including plugins) in a separate, sandboxed process.

Re:lite

[dgatwood]

Most of the problems I've had stem from Flash, which is buggy and unreliable in any brower, not just Safari. Besides, the plug-in model most commonly used by WebKit plug-ins came from Netscape. It is probably not a good idea to try to blame WebKit for that.... :-)

Oh, the other plug-ins that I've seen cause people problems are the haxies. That would be because they aren't using an actual plug-in model and are instead scribbling across arbitrary parts of the process address space hoping that they're looking in the right place. Also not a good idea to blame WebKit for that mess....

Re:lite

[hatchet]

Shameful is your understanding of threads. Firefox tabs ARE threaded. Open process manager check column "threads" in options and see for yourself. Opening new tab will spawn additional thread. But an unmanaged application error in any thread will crash whole process. The solution is to either switch to managed architecture (.NET for example) or to do what chrome and IE8 do - spawn tabs in totally separate processes.

Re:lite

[TheLink]

"Until then Firefox should hang around"

In my experience too much of it hangs around.

The last time I used Firefox it regularly used more than 1GB of RAM and leaked memory.

And because Firefox used one process, you could not get rid of the "offending" browser instance and still keep the other tabs and windows around. In order to free up the leaked memory you had to close ALL browser windows.

Ironically unlike IE, you cannot easily launch separate instances of firefox - it insists on running in a single process (you'll have to create multiple accounts etc).

With IE, if your facebook instance is sucking up huge amounts of memory, just close it, and you get the memory back. The other IE instances do not have to be closed.

The firefox devs should have been humble enough to admit they can't manage memory, and so design their browser to allow separate processes to run.

Re:lite

[Sentry21]

"Lack of threaded tabs is shameful" - Why? Is it really that big of a deal? Don't open a tab that's going to lock up your browser.

Other good advice: don't get on a plane that's going to crash. Don't get on a boat that's going to sink. Don't work for a company that's going to go bankrupt.

"IE developing it" - Oh noes! We need this now, if IE has it then FF needs it! Guess we should go ahead and make FF IE5 complient then, since IE is as well. Forget that standards nonsense, IE has it so we need it.

When Internet Explorer, of all things, has new, useful, and (dare I say) innovative features that make people's lives easier and more productive, far ahead of Firefox, then either it's time for FF to stop resting on its laurels, or it's time to start giving the IE team some well-deserved kudos. Either way, attention must be paid.

If you're encountering enough lock-ups to cause you to need to be able to end a single tab's process regularly (which is pretty hard to do in Chrome with all the tabs having the same process name mind you) then have fun with your threaded tabs. Me, I'm just not going to open sites that are likely to lock up my browser. There aren't many out there, I haven't seen a single one in a couple of months.

Good thing Chrome itself includes a process manager that will let you end a specific process based on what the name of the tab is, how much memory it's using, how much bandwidth it's using, and so on. Pretty keen.

Your post reads like so much 'LA LA LA I CAN'T HEAR YOU!' that I'm forced to wonder why your emotional attachment to Firefox is so deep. Seriously, it's just a browser, lighten up.

Re:lite

[The Master Control P]

A lot of FOSS projects fall into the closed-community trap and get ossified in place. "Write your own patch" is code for "this is our perfect little gem and we have no interest in changing it." They will never achieve an audience outside a very narrow niche, let alone contribute to what Linus called FOSS's "completely unintentional side effect" of toppling closed-source software, and they're perfectly happy with it. Here's an example:

I've played bzflag on and off since about version 1.7. It's somewhere between 10 and 15 years old. In and of itself, a remarkable acheivement in a world where computer games are flashes in a pan. It still has some heritage from it's ancient past as a game for Silicon Graphics workstations, such as support (buried in the manual) for hardware stereo screens and anaglyph mode*. But it's stuck in the past. It's played by about the same one thousand people worldwide. The exact same two dozen or so out of nearly 400 servers receive 99% of the traffic, and 2/3 of those have a distinct group that plays there for the most part.

Now, as far as I know, version 2.0 was the first to add support for graphics more complex than pre-textured boxes and pyramids. Everyone was cont significant audience, or for that matter an audience outside their existing niche.ent jumping around on boxes and would've been happy to keep doing it forever I bet.

There have been physics problems since before I started playing that still stand, and you can't complain because that's just how the game works. It's my fault when my tank gets stuck in a crevice, or on a pyramid, or between meshes, and I should stop whining. Apparently, there are no plans to use something like ODE to give BZflag actual physics. It has options for momentum and basic friction, but they're nigh-always off; Everyone is happy to just drive their inertialess tanks around and jump in parabolic arcs, because that's how the game works.

There is no armor or even hitpoints. It's "too complex" to play with apparently. I suggested it, and was met with people not understanding why I'd even want the option or even scorn. It's a bad sign that I honestly wondered whether it was a joke when someone claimed he truly didn't understand why hitpoints might be a desired feature in a FPS game. But hey, that's the game. When playing "capture the flag," I've often said that hitpoints would open up deeper strategies than lone-hero and zerg-rush, but no one cares... They're perfectly content to sit there playing sniper & thief, or on rare occasions trade waves of tanks. That's the way the game has been since time immemorial (equivalent to between one and two centuries in meatspace by most estimates), and by God that's the way it'll always be.

Have I mentioned the cheater problem? The server does no sanity checking what so ever. Cheaters can zoom across the map, hover, be shot at point blank range with area-affect and tracking weapons, to no effect. I've asked several times if the server couldn't at least run basic checks for hovering or impossible movement. But bzfs is a very lightweight server, and adding collision checking would unduly burden it - that's what I was told, in all seriousness. While 5-10 megabytes is indeed an impressively small memory footprint, how in God's name can "the client does everything and the server implicitly trusts it" have been considered a viable model unless it were being implemented with a closed, unchanging community?

At any rate, the game plods along, with a closed, ossified community happy with nothing at all changing ever. It'll never be accepted for wide playing, but no one cares, because it's our perfect little gem. Our precious, to cherish and polish forever and ever.

And you want to change it? Well bugger off... go write your own code, or fork the project.

*Actually any OpenGL program supports stereo buffers if the hardware does, but good luck finding any references to GL_BACK_RIGHT in the wild with games

Re:lite

[amdpox]

Just because one WebKit browser spawns a new process for each tab doesn't mean all do. In my experience, WebKit is a tad faster and just as light as Gecko when implemented in similar applications (eg Epiphany).

Re:lite

[Darth Android]

If you're encountering enough lock-ups to cause you to need to be able to end a single tab's process regularly (which is pretty hard to do in Chrome with all the tabs having the same process name mind you) then have fun with your threaded tabs.

See, the beauty of multi-process (or multi-threaded, even) is when one tab locks up, the rest of the browser doesn't. Open Chrome's process manager (Shift+Esc) and kill the tab. And I don't know anyone that goes around trying to open tabs that will lock up the browser. That's done on accident, and it's nice to be able to do something about it when that occurs.

Re:lite

[imrehg]

Firefox 3 has never crashed on me. Not once in the time I've been using it, which has been over a month now. And I use it daily, for at least an hour a day, with flash games being a near daily diversion.

Well, then you are damn lucky... I use FF3 since the stable version came out, both on Windows and on Linux. I love it, but it certainly crashes all the time - well, on the "right" sites. Java and Flash (one of the news sites I check regularly and Youtube, among others) can crash more often than not.... It's not that FF3 is bad, but it cannot isolate itself from problems of the apps it depends on to display some pages.

Used Chrome as well, and liked it a lot, but what I'd really give my bucket for, is FF3 where only the tab crashes if anything happens... Or ideally nothing crashes, but that's probably a bit too much to ask :)

Re:lite

[tyrione]

When Webkit can run extensions/plugins without crashing

Is it Webkit that actually runs the plugins? In Chrome, plugins run in their own child processes, so it seems like it would be Chrome and not Webkit that manages them.

Sorry, but Debian Sid running Iceweasel or Epiphany Gecko or Epiphany-WebKit, to Opera 9.52, to Konqueror 4.1.1 all have Flashitis and force one to kill them all.

Re:lite

[drsquare]

If anything Threads will INCREASE the chance of hanging the entire browser, because correct Thread programming is HARD!

It's hard, but then I'd guess that when making Chrome, Google hired programmers capable of doing hard things. When I load a 600-post Slashdot thread in a Firefox tab and see my whole browser freeze up for many seconds, I think I'll take multi-threading any day of the week.

Re:lite

[rrohbeck]

Here's one excuse: complications when trying to have multiple processes render content on a single window in Mac OS X (mentioned near the end of the tab process isolation section).

Why? Only the active tab needs to render anything.

Re:lite

[tyrione]

yes, CPU clock speeds are going up, and memory prices are going down, but a web browser should still be a relatively lightweight application by itself.

Why? I spend more time in the web browser--by far--than any other application. Email? 10 years ago I used a standalone email app, now I mostly use webmail. 5 years ago I used AIM. Now I use web chat. Picasa? Google documents? Between javascript advances, DOM, rich media, plugins, TABS, etc etc etc, today's browser does things not even imaged in 10 years ago.

Chrome's very purpose is to make the browser a more generalized application development platform. Heck, WEBKIT is used in the same way (and XUL, etc for Firefox). The web browser ain't just for HTML circa '97 anymore. The web browser is probably the single most important application for most users.

there seems to be a negative trend of basic office applications becoming increasingly resource-intensive at a pace that negates simultaneous increases in computer processing power. that's not technological progress, that's just inefficient software development.

Exactly right. MS Office is a great example of this. The average user utilizes a very small percent of the functionality of Office, and yet everyone suffers the bloat. Can you honestly say that most people don't get anything out of a more rich browsing experience?

You sound like you work for Google. I use as many browsers as are on OS X and Linux.

However, I sure as hell am not spending my time in GMail [I have it but rarely use it], when I can use KMail, Mail.app, Thunderbird, Evolution, et al. for email.

I'm not interested in Web Suite Apps. When I want a spreadsheet I'm not headin' over to Google. I've got plenty of locally installed options from basic to advanced Numerical Analysis needs.

I could go on regarding Inkscape, Gimp, Photoshop, Xara Xtreme, Krita, OpenOffice Draw, Xfig, et al., but you get the idea.

Re:lite

[rrohbeck]

Firefox 3 has never crashed on me. Not once in the time I've been using it, which has been over a month now.

Then you're probably not using JVMs and othe rplugins. FF is relatively stable, but once you use multiple tabs that load plugins, the fun starts.
Running each tab and each plugin in a separate process would be a huge improvement for FF.

Re:lite

[rishistar]

"Opera developing it" - Oh noes! We need this now, if Opera has it then FF needs it!

There, fixed that for you.

Re:lite

[anothy]

threads needn't be hard, it's just that most of the popular models for working with them suck. check out C. A. R. Hoare's work with CSP and some of the modern languages influenced by, or modeled on, it. my personal favorite's Limbo, but there's a good library for C using the model, and it shows up in places like Occam and Erlang's process model. the right concurrency model just makes a world of difference.

you're still right that they're not magic bullets and they have a host of new issues to consider (although they make a whole host of other ones go away, and can be much friendlier in the right model).

Re:lite

[Tim C]

Is it really that big of a deal? Don't open a tab that's going to lock up your browser.

And how exactly do you know ahead of time what page is going to lock your browser up?

Re:lite

[godrik]

yes, CPU clock speeds are going up, and memory prices are going down, but a web browser should still be a relatively lightweight application by itself.

Why? I spend more time in the web browser--by far--than any other application. Email? 10 years ago I used a standalone email app, now I mostly use webmail. 5 years ago I used AIM. Now I use web chat. Picasa? Google documents? Between javascript advances, DOM, rich media, plugins, TABS, etc etc etc, today's browser does things not even imaged in 10 years ago.

Chrome's very purpose is to make the browser a more generalized application development platform. Heck, WEBKIT is used in the same way (and XUL, etc for Firefox). The web browser ain't just for HTML circa '97 anymore. The web browser is probably the single most important application for most users.

People using web application != people should use web application. Web application are pain in the ass. Everthing, i mean EVERYTING people do with there 2.7Ghz dual core 2 GB memory computer today, i did it in 1997. I checked my mail using outlook. Browse the web for informations on IE. Streaming musics. Streaming videos (not that much considering the bandwidth). Reading to forums and newsgroups. Well, basically, people do the same thing today. They uses at least ten time more ressource but do the same thing ? Why should we say. Because everything is done one the web, because "It's so cool". Don't tell me it is because web applications are easier to use. They are not. Look at yahoo mail, then look at outlook express. It is the same application. Why use flashplayers to stream some videos ? mplayer can do that. There is no interest in this so called web 2.0. No interest at all unless you want to use more and more ressources.

Re:lite

[tuomoks]

Wrong - thread programming is not hard and nothing new. Designing threaded system is a little harder but nothing new. Same complains I got in 70's when teaching design and development for multitasking systems! Learn to think a system - who cares of one thread, program, process, whatever. If the system is designed for threading it is easy, especially in modern languages, we are not talking assembler or are we? And even in assembler it is just a discipline. And remember to write re-entrant code, oops, thread safe code for your DLLs, libraries, whatever.. Or doesn't your "clever, managed" language do that for you?

Re:lite

[h4rm0ny]

I'm thinking monoculture is bad so I'm all for a variety of different rendering engines. Though I have no informed opinion on the relevant merits of either. When I use Firefox 3 (quite often), it has performed well. Though that said, I also use Konqueror quite a lot which has the original engine that WebKIT was forked from (KHTML) and I like it.

But basically this whole "story" is a meaningless attempt to generate hype for Google's browser and troll for post-high arguments.

Re:lite

[tuomoks]

Wrong - a crashing thread doesn't kill the main or any other threads. Now - you can code that way if you want but why would you? It is very common to restart crashed threads in 24x7 systems, of course controlling the restarts not going to die / restart loops. Any decent system does that, all the time.

Re:lite

[Your.Master]

"'Lack of threaded tabs is shameful' - Why? Is it really that big of a deal? Don't open a tab that's going to lock up your browser."

Err...the big deal is that
a) a tab shouldn't lock up your browser.
b) ignoring a, you shouldn't have to be bothered by thinking about such things.
c) ignoring a and b, you shouldn't have to have psychic powers to divine which tabs will do this.
d) you are not representative of the Universe.

FF pretty much is IE5 compliant via "quirks mode". IE5 in turn is netscape compliant, which is after all the ancestor to Firefox itself.

I'm actually amazed FF3 has never crashed on you. For me, it crashes all the time on gmail or any other Ajax-y site. It perma-hangs all the time on youtube and other flash video sites. FF2 didn't have these problems for me (however, FF2 was a memory fiend beyond any other browser ever, and FF3, I admit, seems to finally have fixed that).

Re:lite

[umghhh]

reliability - you are not seriously proposing that ie8 is reliable? Chrome is too new to have a coherent opinion so this falls out of equation too.
besides if you are so happy with ie8&chrome than go use them not whine about how badly ff needs this feature.

Re:lite

[discord5]

... unless there's thread contention, or memory corruption, or a deadlock, or they use a non-thread-safe library with a global lock, or one thread has to handle a signal, or there's a segfault, or....

Let's not forget my all-time favourite: hardware failure due to repeated pummeling with a blunt object.

Let's see browser tabs solve that one

Re:lite

[dargaud]

Thread programming is HARD!

Unless you do it in a real programming language like Ada or Erlang, running on a real message-passing OS like BeOS, Plan9 or QNX...

Re:lite

[paulatz]

also, I like the layout produced by gecko/firefox much more than the one produced by webkit/konqueror, maybe it's better no googlechrome, but it does not run on linux

Re:lite

[Eunuchswear]

Uh, webkit != process per window.

And process per window != bloat. (Learn how VM works).

Re:lite

[Yer Mum]

It might be more practical to make each plug-in run in its own process and each tab in its own thread if necessary.

As plug-ins work through APIs there's fewer problems when it comes to accessing data if you put them in their own process (basically you don't need to).

Tabs can be put in other threads and if a JavaScript script goes off the rails it can still be killed. What you gain: it's far less work to overhaul the browser (you still have access to shared memory) and it uses fewer resources.

It might not be popular with the digg crowd who want each tab to have its own process, but then again software architecture is not their strong point.

Re:lite

[Yer Mum]

There's more than one way to stop a tab locking up a browser. A dedicated process is not the only way, contrary to the current hype.

Unlike plug-ins which cannot be controlled and really should be given their own process, tabs (web pages) have basically two components; a render and a script engine, and the browser has control of both.

At most you should need a new thread to stop a tab locking up the rest of the browser.

Re:lite

[something_wicked_thi]

Actually threads would protect against a null pointer because it would cause an exception that could then kill only that thread. What threads can't protect against is random memory being used as pointers, if the memory contains a pointer to allocated pages it will write over that memory and nothing can catch it.

That's a pretty naive view of threads. First, if you have a segfault, the process dies, not just the thread. If you catch the fault (you can do this only on Windows, not Unix) and kill the thread, the process is in an undefined state because it is always unsafe to kill a thread that didn't voluntarily die, for pretty obvious reasons. It is unsafe to continue the process after such an event, threads or no.

Re:lite

[DjDanny]

FYI, Chrome has its own 'task manager' built in which DOES show you the tab name next to each process so you can easily end the process you want to. Also, if one locks up, it tends to notice anyway and asks you if you want to kill it.

As for your comment "Don't open a tab that's going to lock up your browser.", well, you don't know what it's going to do til you open it, do you? And if you're a developer, sometimes you do stuff which gets you stuck in loops or whatever and need to kill the process.

So far I've found this feature one of the most useful ones in Chrome. IE7 frequently locks up and then you're shafted because you have to kill the whole browser, rather than just the one tab.

Re:lite

[aldousd666]

In Chrome, they're not threads. They're processes. It's like launching each as a separate app. There won't be any locks, deadlocks, contention, etc, any more than there is for your copy of Firefox and IE running at the same time. And when you kill one process, all it's memory space goes back onto the free pile, and wont' become fragmented.

Re:lite

[multipartmixed]

Hey, thanks for the links.

The CSP page was like revisiting Formal Methods all over again (ugh ;), but that plan-9-derived C lib actually looks interesting. And it may solve some problems I have been mentally muddling with for some time.

Now I have to go think about this. In a few weeks, when I have time. *grumble*

Re:lite

[walshy007]

Apparently, there are no plans to use something like ODE [ode.org] to give BZflag actual physics. It has options for momentum and basic friction, but they're nigh-always off; Everyone is happy to just drive their inertialess tanks around and jump in parabolic arcs, because that's how the game works.

well it IS how the game works, if you give the ultra fast quake 3 the physics system and settings of serious sam, it changes the game, sure a small minority may like the change, but the point is it is no longer quake3

same with bzflag, it is a fun completely non-realistic tank game, and that's the way the majority of players like it, why should the minority mess up the game for the majority?

If the majority want the changes then indeed fork it and you'll get the new playerbase and developers etc etc. But essentially, your complaining that you can't screw up a perfectly functioning game for the people who maintain it just because you want the game to go in direction x.

take another oss thing, example wesnoth, the turn based strategy, and you want it to go in real-time because that would be cooler for multiplayer, if those drastic changes were introduced, you would have destroyed the game for all the players that liked the game the way it was,

I believe the best reason for projects to fork is differing design goals, if someone just wants an efficient toaster, and you want to design a kiln for smelting things, while they both generate heat, you may wish to split the project

Re:lite

[ckaminski]

Which is why I have always wanted to work at Microsoft. I wanted to be the guy who brought fork() to Win32.

sigh.

All the power of threading, with all the memory protection of a full process context... sigh.

Re:lite

[LWATCDR]

Umm what the heck are you doing in that mutex!
Unless you have some big honking data structure that is very state sensitive that should never happen.
Ideally you should mutex copy the data to a local var, free the mutex do what you need with the data, and then mutex and update the data structure.
Just keep the mutexs as short as possible and write your code for threads from the start.
Theads are hard and can produce some interesting bugs but they are just not that bad.

Re:lite

[encoderer]

Allow me to return the favor..

1. FF3 Has never crashed on you and Chrome has. You said you've used FF3 for "over a month." That means you weren't using it in Beta. Chrome is still Beta. Apples meet Oranges.

2. "Don't open a tab that's going to lock up your browser." Wow. You know, you're right. No reason for modern OS's to use protected memory. Lets all go back in time 20 years and use shared memory. After all, don't run an app that's going to lock your OS.

3. "Guess we should go ahead and make FF IE5 complient then" You can just read about this one on wikipedia.

4. "pretty hard to do in Chrome with all the tabs having the same process name mind you" ... huh? The chrome task manager uses the page title as the process name. Click on the page title you want to kill, press "end process" and you're done.

5. "There aren't many out there" You're on one right now. The new discussion system here has locked up FF2 on my system dozens of times. It doesn't happen as much anymore, but it still does when there's >500 comments and I'm reading at +1.

6. The truth is, having one process per web application makes sense. 20 years ago OS's transitioned from cooperative multi-tasking and shared memory space to preemptive multi-tasking and protected memory space. That change allows us to do everything we take for granted now, although it probably wasn't NECESSARY to meet the needs of the time.

Google is correct: Most of the "websites" we love and use every day are actually web applications. And when you're running 5 applications in one process, you're right back into the 1980s world of cooperative multi-tasking. And in FF3 if one tab decides to throw a JS alert() box, that thread is no longer "cooperative" and all JS execution on the other 4 tabs has stopped.

And no, today's applications aren't yet at the point where they NEED their own process. But who knows how web app development could be retarded by not giving developers the kind of environment that has proven successful for Win32 development.

The truth is that you'll probably see this in FF4. It IS the next major leap in browser tech. Tabs took us from dos-era one-page-at-a-time browsing into a Win3.1 era of "almost multitasking."

Now we're about to enter the "NT era." No use fighting it.

Re:lite

[amn108]

So, basically it comes down to WHAT you use threads for. Obviously, using threads to process tab page content wont speed up your 600-post Slashdot discussion, because only a single thread will be doing the job. Or a process with a single thread. Threads are not magic, but I am sure you know that.

There are multiple ways to optimize such scenarios with threads. There are multipple ways to optimize multi-page browsers too, with the one-process/thread-per-tab/page being the most known obviously.

Alternatively, you might want to use a single process, and dedicate one thread for page rendering, another for plugins (including updating all those pesky Flash animations for those who dont use NoScript/AdBlock+), and another for JavaScript processing.

My point is there are many ways to use processes and threads, and dedicating execution threads on a per-page/tab basis is just one of them, and I am not sure it is the wisest. Microsoft recommends themselves that any process uses 2 x CPU_core_count threads, and even though they are sometimes coming up with pretty weird recommendations, it is still a hardware bound feature, and too many threads, especially if waiting on locks of diff. kinds will have the OS spend more time on the whole thread scheduling than doing useful work for the user. I am sure Intel would NOT recommend either to load more than 6-8 threads in a GUI application process. Sometimes the whole threading can be "emulated" with benefits in speed and resource usage by faking it all. The way overlapping I/O is done f.e.

I did create a TCP/IP server once, creating a thread for every client connection it receives, and I noticed client would be waiting for the server OS scheduling their connection threads, so that they could receive some data already after 10 threads. That was on P4 NetBurst arch back in 2004, but I doubt the picture is much better now.

Re:lite

[tbannist]

Actually, Chrome uses processes instead of threads. It's Microsoft's programmers who need to handle threads in Internet Explorer 8...

I know some of the people that got hired out of university and went to work there. They have trouble with single-threaded single-process applications.

Re:lite

[WuphonsReach]

You do know that there are not currently any stable browsers with threaded tabs, don't you? There are exactly two browsers attempting this that are both in early betas. You speak as if it's been common for years and Fx is way behind the game.

Firefox is way behind the game.

One of the things that users (who drive adoption) have wanted for quite a few years now is to get rid of the problem where one slow-responding tab slows down the other tabs. It drove me up the wall starting back in the FF 1.x days, where you'd tell a link to load in the background - and it would freeze the foreground tab until it was done processing.

Which really, really, really annoys me. If I had wanted to wait on the new tab to load, I'd have loaded it in a foreground tab. Part of the whole point of being able to open links into new background tabs is so that you can keep working with the foreground tab without interruption.

So, if we were asking for this since the FF 1.x days... why are the developers still putting their heads in the sands on this issue in FF 3.1 days?

(Yes I know it's hard - but now there are 2 competitors who are trying to make it work. So it must not be impossible. And it's not like FF 2.x wasn't already a bit bloated.)

Re:lite

[amn108]

The whole thing crashes because pretty much nobody can be bothered to process the exceptions that rise and cause the OS to abort the process and clean up the mess. But when we were kids we did learn to clean up our own mess, and not let our parents or computer operating systems slave for us. Jokes aside, if your thread screws up, the process should tidy up, and not let the OS remove the process altogether.

Then again, it is something that is not achievable today, and few if any programmers think about salvaging the processes they design. So you are essentially on spot here.

Re:lite

[gr8scot]

Bottom line: multiprocessed and multithreaded programming are strictly equivalent.

Not close. Operating system control is a crucial difference. I can close one process without affecting another. The only way to control a specific thread is to have written the app that spawned it. A multithreaded browser is not nearly equivalent to one that starts a separate process for each tab.

Whereas single-process browsers such as Firefox aim for lean, efficient browsing experiences, Chrome and IE 8 are all about delivering a robust platform for reliably running multiple Web apps in a tabbed format in answer to the Web's evolving needs. To do this, Chrome takes a 'purist' approach, launching multiple, discrete processes to isolate and protect each tab's contents. IE 8, on the other hand, goes hybrid, creating multiple instances of the iexplore.exe process without specifically assigning each tab to its own instance. 'Google's purist approach will ultimately prove more robust,' Kennedy argues, 'but at a cost in terms of resource consumption.'

As another Slashdot reader already observed in this or another recent 'Chrome' discussion, 'consumption' is an inappropriately derogatory term. We should be talking about memory use or resource use , not 'consumption' because (1) memory is released when the program closes, not destroyed or converted to a different, unusable form (such as food post-digestion or gasoline post-combustion), and (2) although the 200MB - 400MB used by browsers is a significant fraction of system memory for low-end computers with just 1GB of memory, these browsers do not exceed available RAM, except for very old computers which should probably be de-commissioned anyway. So, the 'cost in terms of resource consumption' for a multiprocess app is well worth paying, because it is only relevant on systems that are terribly underpowered, as defined by the industry's pace car; they would certainly not be rated 'Vista Ready' or 'Vista Capable.'

Re:lite

[amn108]

This is at least OS-specific. Crashing implying a segmentation fault WILL cause Windows NT kernel to abort the process that owns the thread and clean up the mess. You may however trap the segfaul exception signal and thus prevent the process from being bailed out by the OS.

The most common crash scenario on Windows is when the single thread that is part of any process misbehaves by accessing memory it does not have right to access, the CPU signals a segfault, Windows kernel catches the uncaught exception and decides, for the lack of capability and capacity to salvage a corrupt process, to "eject" it - aborting the process, freeing up memory, and restoring the system the best it can. So whatever you wrote in your post above, does not apply at least to Windows NT derivatives. I am pretty sure it is a pretty common default scenario action and reaction in Linux too.

Re:lite

[hobbit]

Well let's see. Is is javascript or flash based? Does it come from a less than reputable site?
[...]
I developed that insight through simple application of common sense. 99% of reputable webpages will not crash your browser, period. If they do, then there's something wrong with your computer besides your browser. Ergo, if you don't want to crash, don't visit irreputable websites. And if you can't tell the good from the bad on the internet then you haven't spent enough time on it.

Wow, browsing the web must be really fun for you. "Hmm, that link looks interesting. Ah, but I've never visited that domain before. Ah well, back to Wikipedia."

Re:lite

[agentultra]

It's because Gecko has XUL and has an open development model.

Webkit has a nice lean code-base, but gives up flexibility. It's "open sourceness" is somewhat closed on the Apple side -- bugs will disappear into their proprietary tracker and patches will be released without community discussion.

XUL is IMO, the best reason to keep Gecko. I loves my extensions and refuse to use a browser that doesn't implement the features they give me in some way.

Re:lite

[nabsltd]

There's no reason Firefox couldn't have one process per tab, and most Webkit/KHTML implementations currently use one process per browser window (like Firefox).

I don't know anything about Webkit, but Firefox on Windows spawns only one process regardless of the number of browser windows or tabs.

You might be thinking of IE, which does have an option to start a new process for every browser window.

Re:lite

[agentultra]

I feel much the same way.

It really hit home a number of years ago just after the 1Ghz mark was broken and was trickling down to the low-end price range. I was still on a 333mhz laptop and happy. My mother bought a shiny new 1ghz computer with 512mb of RAM and I was shocked! Who needed so much processing power just to chat on the Internet, play solitaire, and read webmail?

I was doing far more with my ancient and conservative machine by comparison.

Some 5 or 6 years later the only thing that has changed is that the software requirements continue to grow and so does that hardware. What I actually use them both for has remained much the same. Aside from 3D applications, graphics processing, and real-time DSP; what benefits do these huge powerful machines really provide to users like my mom or the office secretary or joe account manager?

Re:lite

[Moridineas]

You sound like you work for Google. I use as many browsers as are on OS X and Linux.

I don't work for google. I do occasionally develop webapps as part of my job, but it's not my main "thing"

However, I sure as hell am not spending my time in GMail [I have it but rarely use it], when I can use KMail, Mail.app, Thunderbird, Evolution, et al. for email.

When I went to college, every incoming student just about installed Mulberry as their email program. By the time I graduated, the IT services didnt even distribute Mulberry anymore because MOST PEOPLE preferred the univ webmail or gmail, etc. I was a holdout. Still am to some degree. MOST people preferred the web apps.

I actually fought this argument long and hard when I worked for the govt and they wanted to move off some very powerful legacy apps (Lotus Notes and TONS of programsi ncluded) to go to flashy web 2.0 junk. I'm basically conceding the fight though, IMHO, it's over.

I'm not interested in Web Suite Apps. When I want a spreadsheet I'm not headin' over to Google. I've got plenty of locally installed options from basic to advanced Numerical Analysis needs.

As I said in my post--"the average user utilizies a very small percentage of the functionality of Office." You are clearly not an average user, neither are most people on slashdot. I would not expect--at this point in time--most slashdot users and tech-savy users to switch from powerful desktop apps. For the secretary doing email and typing memos that the OP mentioned, does it matter?

Re:lite

[Moridineas]

People using web application != people should use web application

I don't necessarily disagree, however, my point is somewhat greater. My point is that XML+Javascript/etc is becoming a very powerful development platform in its own right. For both local AND web apps.

Don't tell me it is because web applications are easier to use.

Well, sometimes they ARE easier to use. More importantly, you don't have to download, install, update, make sure you're not installing a virus/spyware, you don't have to know what things like POP servers or SSL or SMTP are to check your email. You just have to be able to type "www.yahoo.com" etc. For many users, this is a BIG deal.

Why should we say. Because everything is done one the web, because "It's so cool".

There are many advantages (and disadvantages as well). Just a few--easy to roll out bugfxies, updates, security fixes, etc. Users don't have to download and install binary blobs. Users can have the same desktop experience on their work computer, their home laptop, and their smartphone. If a user's computer dies, they don't lose all their data.

Re:lite

[Moridineas]

I'm not arguing for OR against anything you're saying here!

Let me put my belief another way. You could make an operating system that had no user configurable elements, no ability to install applications, and only one application--a web browser--and for many users, it would be perfectly acceptable as a primary computer.

Re:lite

[jhol13]

There won't be any locks

The difference of threads v.s. processes has nothing to do whether there are locks or not.

If you have a shared resource you must use locks - no matter if you use processes or threads.

I do not know about Chrome but I'd imagine it does not use shared resources (separate windows, sockets, etc.) which may or may not be a good thing (share cookies of several tabs?). Or maybe it locks only for a (provably) short time ("getGlobalCookie")?

Re:lite

[aldousd666]

I hadn't thought about sharing cookies and things. good point. it probably does use some shared structures.

Re:lite

[Hatta]

I don't understand. Why should separate processes take more memory than a single process? I'm no expert, so I'm expecting someone to correct me here. But as I see it, there are 2 things that take up memory, the pages you're viewing, and the firefox binary itself. If you're viewing two pages in the same process, or in separate processes, those pages are going to be the same size, so that shouldn't affect the amount of memory that's used.

So what's left is the firefox binary. Since that binary doesn't change, why copy it into memory twice for two processes? Is there no way to share that memory?

Re:lite

[edalytical]

I'm not convinced it would be difficult on a Mac. You seem to be drawing that conclusion on one person's blog in which there happens to contain one small piece of pure speculation:

I hear there's also some problem where the MacOS Core Graphics APIs make it harder to implement multiple processes for one browser window than it is on Windows.

There was exactly zero technical details about why it would be tricky on a Mac. So that wasn't an excuse at all.

Re:lite

[Hatta]

I just bought a computer with 256MB RAM. With LXDE and Firefox 3 it's snappy as hell. Why do you want to make my computer less useful?

Re:lite

[booch]

I'm thinking they want to keep using Gecko because they made it and want to justify its existence.

I think that may be part of the reason has not seriously considered switching to WebKit/KHTML. But I think there are a few other reasons they will likely continue using Gecko:

1) The work required to replace Gecko with WebKit in Firefox would be quite substantial. It'd probably take just as much effort as improving Gecko.

2) It's good to have competing renderers out there, to stir competition and prevent a mono-culture.

3) They've got a lot of developers familiar with Gecko. If they moved to WebKit, they would not have a lot of experience with it, so would have trouble improving it to meet their own needs. In some ways, this overlaps with my reason #1. But it could also be considered a part of controlling their own destiny.

Re:lite

[Moridineas]

You're running the latest and greatest browser revision--what's your problem?

Re:lite

[jorgevillalobos]

There was exactly zero technical details about why it would be tricky on a Mac. So that wasn't an excuse at all.

I'd say that's exactly why it constitutes an excuse and not a fact. I apologize for the poor reference, this problem has been mentioned in several posts by Mozilla employees, but nobody has really delved into the technical specifics. I don't know much about Mac OS myself, so I can't comment on it.

All I'm saying is that there is something that may make it difficult to implement cross-platform process separation in tabs.

Re:lite

[tuomoks]

It's weird then - just about three years ago I designed and coded the guts to a decent size switch which has been running over an year now in Windows XP and 2003. Many threads have crashed, by bad data, by coding errors, by whatever but the system keeps running and restarting the threads, either automatically or by command, depending on the configuration. The nice thing is that in case of coding errors, because the code is in separate DLLs by function, the DLL can be changed and the threads can be restarted with new code, meanwhile the system just keeps processing other transactions which don't need that specific functionality. I'm missing something?

It was designed based on what I did for Unix 12 years ago (adapted to Linux 3 years ago), up in some places about 5 years now. Both systems use external libraries, mostly Imagemagic, MySQL, Postgres or MSSQL depending on customer and some of our own compression, security, SNMP and communications (mainly for HTTP(S) traffic, pure IP(TCP/UDP) just keeps working) have had some problems but their libraries can be changed in flight and the (thread) code using them can be terminated, changed if needs to and restarted - SQL used for auditing, not processing on switch level so it is queued while fixing the auditing problems or even changing the audit formats, no need to stop the system itself. I'm really missing something?

Of course you have to do your own memory management but you would do that anyway in any fast, secure, 24x7 SMP and multi-node system, not difficult even on the top there are .NET applications? So - I don't like so much Windows but it doesn't mean that you can't build such systems on it, it just takes a little more effort than in Unix / Linux. Give me back the MVS or Tandem - excluding hardware errors it is easy to make recovering systems and even single hardware failures are just a small glitch which can be take care easily.

Re:lite

[lysergic.acid]

i'm not asking for a free lunch or complaining about the current state of web browsers. i was simply arguing against the idea that just because we have more memory a basic web browser (by itself, not including the memory cost of actual content) ought to use as much memory as it can. after all, like you said, it takes a lot more resources to render many modern web apps and their responsive interfaces.

i'm not arguing that a web app that works like a desktop application should take up as little resources as a plain html document; quite the opposite actually.

in regards to the dual core system, it's less about cost and more to do with efficiency and finding the appropriate system for the task (or the right tool for the job). i guess i brought it up partly because there was an earlier article about IT energy-conservation. that really got me thinking about whether we still need the full processing power of a desktop computer just for the typical office computing work.

it seems to me like wouldn't need a full ATX desktop system with a 500-600 Watt power supply when there are so many sub-ATX solutions available. i mean, in theory most tasks that the average person uses their computer for shouldn't require anything more than an 800 MHz VIA C7 running on a micro-ATX motherboard. less power consumption equals less heat, less heat equals less cooling, which in turn reduces noise and also conserves energy.

of course, in practice things are quite different. VIA's Eden chipsets have little to no driver support. and i'm also not sure if the C7 processor is supported by Windows XP. but the point remains, perhaps there needs to be a range of low-power desktop computers for the average person who doesn't need to run the latest 3D games or do CPU-intensive computational modeling or do digital media production. we have internet tablets and all kinds of sub-laptop smart devices which can surf the web these days. so it obviously doesn't take a fat client just to browse the web.

Re:lite

[sgt scrub]

No. I'm pretty sure Firefox uses one gecko process per browser instance. A Firefox window is a XUL window. A tab is a XUL tab element...

Re:lite

[aliquis]

I have 2 GB and Safari have to be killed every now and then to get them back, and sometimes it just hangs. I'd prefer recoverable memory bloat over continuously raising memory bloat.

I can get 4 GB and handle some more bloat / tab, but even if I had 100 GB as long as there is memory leaks it will run out.

Re:lite

[naasking]

Did you try it yourself? I have, and it led me to create a batch script just so I could load the user profile manager and launch a separate process when I wanted to.

Also, think about it: two processes sharing the same user profile is a consistency nightmare. With threads they can at least use in-memory locking for accessing disk-objects.

Re:lite

[multipartmixed]

Well, you see, it's like a Chevy Nova.. Or maybe a Ford Pinto.

Re:lite

[Varun Soundararajan]

do they share the same memory? in that case, a terrible problem with tab a (buffer overflow/underflow/whatever) can wipe off the memory of tab b? essentially that is just a better way of seperating than running all on a single thread. I guess process seperation is the right way to go.

Re:lite

[AvitarX]

But someone could check their webmail while the page loaded if multi-threaded.

Re:lite

[Ant P.]

FF3 has caused the strangest problem I've ever seen - it'll run fine for hours, but I can't go near certain sites (addons.mozilla.org is one of them) because there's a 90% probability my system will suddenly hard freeze while it's loading the page. Won't even respond to alt+sysrq.

Re:lite

[init100]

But basically this whole "story" is a meaningless attempt to generate hype for Google's browser and troll for post-high arguments.

Actually, the Ars article is not a troll. It contains a good argument for why Gecko has a future and why Mozilla is going to continue using it, instead of switching to Webkit as the Google Chrome fanboys demand. The Slashdot posting however, could be considered a troll post.

Re:lite

[spitzak]

You may be right. Further reading indicates that both Unix and Windows crash the entire process when a thread gets an exception. I thought they were more like processes with shared memory. It is probably not difficult to make just one thread die, just reuse whatever keeps a program crash from crashing all other programs. But it may be that a dead thread causes so many other problems (inconsistent state such as locks left locked) that there is no reason for the os to support it.

I also seem to have Google/Microsoft switched. Apparently it is Chrome that uses different processes, and IE8 that uses different threads. That would be more in keeping with previous design decisions.

Truly separate processes are safer but make communication much more difficult. It seems to me that attempts to solve the communication problems (ie shared memory) would cause all the problems that multiple threads have with inconsistent state in case of a crash. So I really can't see which solution is better.

Re:lite

[SoopahMan]

The main resource you would need to share in a browser is the core Javascript set of "classes" or prototypes or whatever you want to refer to them as nowadays. Core DOM element code etc.

Chrome is wasteful in this regard by making a full copy into each process of this set of objects and code.

This design is simpler, especially when you consider that the core Javascript classes allow you to modify them, meaning Tab 1 might modify Object.toString() to one implementation, and Tab 2 to another. Using a shared instance of the core classes in this scenario isn't just a threading issue, but a serious design problem (to be solved with the Facade or Flyweight pattern, etc).

Re:lite

[amn108]

Are you joking?

Re:lite

[Nutria]

which is buggy and unreliable in any brower, not just Safari.

I don't know why people still rag on (Linux) Flash. I can't remember the last time it caused FF to hang on my system.

Re:lite

[Shin-LaC]

Here's one excuse: complications when trying to have multiple processes render content on a single window in Mac OS X [mozilla.com] (mentioned near the end of the tab process isolation section).

That's just hearsay of hearsay. In Chrome, only the main process draws to the window: renderer processes draw into shared memory, then the main process takes that rendering and transfers it into a backing store, which it uses to paint the window. (reference)
There is no obstacle to using the same mechanism on Mac OS X.

Re:lite

[VanessaE]

Fat lot of good threads do if this reply gets attached to the guy below who is talking about classes and methods instead of your post :-)

/me watches firefox 3 eat 100% of one 2GHz core just by typing the above response.

Re:lite

[tabrnaker]

That only happens if you have bad karma :)

Heterogeny

[Just Some Guy]

Variety is the spice of life. If every browser used the same engine, there'd be no competitive spirit to improve it. Besides, when was a monoculture ever a good thing?

I've been using Konqueror for my primary browser for several years now, but still respect the Mozilla group and wish them the best of luck. As long as everyone follows the standards (which the Open Source browser folks have excelled at), the more the merrier!

Re:Heterogeny

[mcsqueak]

Variety is the spice of life. If every browser used the same engine, there'd be no competitive spirit to improve it.

Yes, and god forbid a web designer only has to design for ONE engine, and not several, each rendering what should be STANDARDS in slightly different ways, ugh. I don't understand why some design groups feel they can throw some of these things out the window when designing their browsers. "Well, we COULD follow the all the standards set for CSS, but hey... lets just follow SOME of them!" Bleh.

Re:Heterogeny

[Alien Being]

You already said it, so I'll just second the thought. When there's only one way to look at the web, the web is dead.

I use Firefox primarily because of a few plugins I use a lot. Konqueror seems to be a better renderer and its UI blows everything else out of the water.

I keep hearing about something called Internet Explorer, but it seems to be less of a browser than a vector for malware.

Pointy-haired-bosses used to say that the browser wars are over and MS won. They have no idea how wrong they were.

Re:Heterogeny

[Darkness404]

Ummm... If you develop for Gecko, webkit and presto based browsers will usually render the page correctly. You usually only need to make more than one version of the page to work with IE.

Re:Heterogeny

[mollymoo]

You do know the standards allow you to render things in slightly different ways, don't you? It's one of the principles behind HTML. If you need pixel-perfect rendering, the web isn't the right medium. It's not designed for that.

Re:Heterogeny

[bigstrat2003]

You do know the standards allow you to render things in slightly different ways, don't you?

What you say is true, but more or less meaningless. The fact that the standards allow this mean that the standards suck, not that the behavior is ok.

If you need pixel-perfect rendering, the web isn't the right medium. It's not designed for that.

Maybe it wasn't designed for that at the beginning, but it needs that now, and we should adjust how we address it accordingly.

Re:Heterogeny

[mikael_j]

Safari uses webkit and it's buggier, slower, and more bloated-feeling in general than Firefox or Chrome(at least on a windows box).

On OS X my experience is that Safari/WebKit is a lot snappier than Firefox although I will admit that I rarely use Firefox for extended periods of time so I can't really tell how well it handles running for days on end with lots of tabs open on OS X, but I know the Windows and Linux versions tend to start using a lot of RAM after a few days.

/Mikael

Re:Heterogeny

[ya really]

Safari uses webkit and it's buggier, slower, and more bloated-feeling in general than Firefox or Chrome(at least on a windows box).

You do know that chrome uses webkit as well, right?

Re:Heterogeny

[Enderandrew]

Gecko just had a major two-year-plus makeover, and it still isn't as good as Webkit. One could argue that Webkit of two years ago stacks up reasonably well with Gecko of today.

Mozilla spent so much time on rendering engine refactoring, and they want to focus on stabilizing 3, and then moving to Firefox 4.

Moving to a new rendering engine might seem daunting. I don't see Mozilla approaching the project themselves.

There is a new QT branch of Firefox, but even that isn't a proper QT branch. It uses QT widgets, but QT is integrated with Webkit, provides its own JS implementation, etc. I'd love to see an outside team fully develop a QT/Webkit/Xulrunner fork of Firefox that allows me to use Firefox extensions on top of a Webkit rendering engine.

Re:Heterogeny

[mollymoo]

Why do we need it now? Because many so many designers are control freaks stuck in the days of print and can't adjust their mindset? Resolution independence is coming to every major OS in the next few years. The web is viewable on everything from mobile phones to conference projection screens. Pixel-perfect rendering for a medium designed to reach those devices and everything in between is an utterly, utterly stupid idea.

Re:Heterogeny

[localman]

As a has-been web developer and regular web user, I'm going to suggest that the advantages of having many browsers (or more specifically, rendering engines) is largely overstated.

I don't see that browsers have made any wondrous leaps of progress due to competition. In fact it seems that competition has stymied progress at times, as browsers had to attempt supporting incompatible features that grew out of attempts to one-up the competition. Companies that develop websites have to waste a lot of resources on testing, which would benefit the user more if spent on UI or other types of development. Either that or they _don't_ spend the resources on testing so customers are variously frustrated as no one browser handles all sites correctly.

Flash is an example of something that seemingly progressed well, perhaps faster than browsers, while having essentially no competition.

So yeah, I understand that in some cases competition is a benefit, but not always. I think interoperability needs can sometimes trump the advantages of competition. I'm not sure I believe competition benefitted browsers or the web.

Of course I've been saying for a while that MS should pick up either Gecko or WebKit and not create another rendering platform. But nobody seems to agree with me except for Google :)

Cheers

Re:Heterogeny

[bigstrat2003]

Because it's impossible to design something which looks really good without having control. Wanting control doesn't make you a control freak, wanting control without reason does. Web designers have excellent reason to want control.

Re:Heterogeny

[Anonymous Coward]

Yes, you idiot.

He was trying to make the point that webkit-using browsers can be better(Chrome) OR worse(Safari) than the Gecko-using Firefox browser.

Re:Heterogeny

[Just Some Guy]

As a current web developer, I develop with KHTML. When I like it, I verify that it looks the same under Gecko (and it always does). If it's a major change, I'll check it under MSIE and screw around with the CSS until IE manages to display it without barfing. I don't bother testing with Opera anymore because I've never once seen it fail on a valid page that renders under KHTML - it's just kind of assumed that it will work.

So with all the HTML engines out there, you only have to test two camps: MSIE and everything else. Adding another standards-compliant engine wouldn't increase my workload one iota.

Re:Heterogeny

[QuantumG]

Because we're not just making web pages anymore.

Re:Heterogeny

[MightyYar]

When I wear my web designer hat, I can almost agree with you. The various browsers can be pretty frustrating.

As a web USER, I couldn't disagree with you more. I like being able to bump up my font size. For the most part, what you are describing sounds like those sites that take a big flash file and put an html wrapper around it. I HATE those sites, but if you need pixel perfect - go for it.

Re:Heterogeny

[fm6]

To avoid a monoculture, all we need is two rendering engines: one piece of bloatware that almost everybody uses because it's the de-facto standard, and one ubertech thing everybody else uses because we're so cool.

MSHTML has played the first role to everybody's satisfaction for many years now. We don't need a second candidate — unless you think a bloatware monoculture is a bad thing.

Re:Heterogeny

[santiagodraco]

"You know that the standards allow me to render things in slightly different ways, don't you? It's one of the most abused principles behind HTML. if you need pixel perfect rendering web designers like me aren't the right targets. I don't design for that."

Corrected.

Re:Heterogeny

[mollymoo]

Your post is a perfect example of why designers constantly need to be kept in check. Looking really good is an admirable aim but is not an "excellent reason" to harm functionality. A designer's role is secondary to function. Making something which just looks good is an artist's job, not a designer's job. Designers have to make things which look good and work well. Failing at either one is a total failure. Many designers are frustrated artists and would love to be able to just make something pretty, which would be so much easier if the damn thing didn't have to work too.

Car designers hate having to have boots (trunks) which can hold a set of golf clubs, because it means cars have to have high, fat arses. They hate having to cater for tall people in the back seats because it ruins the roof line. They hate laws about how high your bumpers (fenders) need to be, the fact that an airbag makes the steering wheel fat and the need for fat pillars so the occupants don't get crushed to death in a rollover. The car industry is more mature than the web design industry and there's a lot more money at stake, so the wannabe-artists get weeded out, re-educated or (only they're phenomenally talented artists) set to work on concepts which don't really need to work properly. We need to get rid of the wannabe-artists from the world of web design too.

Sorry if designing for the web is a hard job, but the notion that the web should get harder for everyone to use so it's easier for a few wannabe-artists to design for is only appealing to wannabe-artists.

Re:Heterogeny

[santiagodraco]

Ok, time for an education.

Comparing the capabilities of the different rendering engines with the INTENT of the content designer is, to use your words, utterly stupid.

DESIGNERS build pages to look ONE way, not "oh I want it to look like this on Firefox, and this on IE, oh oh and this on Chrome!" That's not how it works. Speak to a designer and you'll see.

So, the fact is, in an ideal world rendering engines will ALL do it right, which is to say the SAME and according to the STANDARDS which if are bad get CHANGED to render properly.

That is how it works and how it should work. The fact that it doesn't IS a problem and needs corrected, and it's improving all the time because developers don't think like you do... that this is some kind of "my way or the highway" kind of thing.

Re:Heterogeny

[SirBitBucket]

Spoken like a web-designer/control freak.

Re:Heterogeny

[bigstrat2003]

Yeah, except requiring things to be rendered the same way all the time isn't "harming functionality", it's common sense. In fact, where exactly does one get off saying that you have a "standard" if there's any room for interpretation at all?

Sorry if designing for the web is a hard job, but the notion that the web should get easier for everyone to use (because we don't have to adjust to any differences in different browsers) is only appealing to everyone.

Your concern is touching, but I'm not a web developer. Also, fixed that for you.

Re:Heterogeny

[cecil_turtle]

Well there are cases where the standard is slightly lenient in the interpretations, but they still generally provide a recommended method. The only time the recommended method shouldn't be used is for special circumstances like accessibility or small screens or touch-interfaces, etc. But "browsers" meant for use on "computers" should still pretty much use the standards the same way. And for the most part they do, with the one glaring exception.

Re:Heterogeny

[0123456789]

Yeah, except requiring things to be rendered the same way all the time isn't "harming functionality", it's common sense. In fact, where exactly does one get off saying that you have a "standard" if there's any room for interpretation at all?

A screen reader for the blind has to interpret standards compliant HTML differently to a visual web browser. The point of allowing clients to interpret the standards differently is that they can present the content in the way most suitable to the user, not the designer. We, the users, are more important than you, the designers.

Re:Heterogeny

[naasking]

If you want guaranteed pixel-perfect control, use images. HTML allows you that much.

Re:Heterogeny

[bigstrat2003]

As a web USER, I couldn't disagree with you more.

Fair enough, but be aware I am speaking from my perspective as a user, not from a developer's perspective (I haven't done any web development since I toyed around making web sites back in the IE4/Netscape 4 days). When I go to a site, I want it to look the same on any reasonable combination of browsers and platforms. It's understandable if the mobile phone version isn't the same as the regular version, but the regular version had better damned well look the same whether I'm on a computer that uses Firefox, IE, Safari, Chrome, Konqueror, whatever. Anything less is unacceptable to me, as a user. I highly value consistency.

Re:Heterogeny

[FlyingBishop]

The idea that we can create a standard that makes a page work both functionally and prettily on both an iPhone and a quad-core machine with a 30 inch display is just stupid.

Layouts must be open to change. The disparity between iPhone and 30 inch display is impassable next to the disparity between even IE5 and Webkit.

Re:Heterogeny

[fabs64]

If your website renders exactly the same on my 2.5" mobile phone screen as on my 22" widescreen desktop monitor we have a serious problem.

Re:Heterogeny

[cecil_turtle]

Speak to a designer and you'll see.

If you mean a designer who came from a print background and doesn't actually understand the web, i.e. 90% of the designers out there, then yes you're correct.

Now it's time for your education. Not everybody runs a 17" LCD screen at 1280x1024 with the browser maximized and has good eyes and Flash player [current version] properly installed and Javascript enabled. As stated by one of the parents, the web IS NOT SUPPOSED TO BE pixel-level accurate across all display mechanisms all the time. Incompetent designers don't understand this and try to force the issue, you are correct. But look at any successful website - Amazon, Google, eBay, slashdot, anything - none of them used fixed width layouts with pixel-level placement. They all use free-flowing layouts that work well at different text sizes / zoom levels across multiple browsers at various resolutions. That is the intent of the web. Not to mention getting into the semantic web, but that's a whole other discussion and way beyond 99% of today's designers.

Re:Heterogeny

[SanityInAnarchy]

Because it's impossible to design something which looks really good without having control.

Citation needed. I'm not a designer, but I do strongly disagree.

For that matter, there's a bit of a false dichotomy here, on both sides -- you all seem to be assuming that setting things to the pixel is the only way to get control, and giving up that per-pixel control is the only way to get resolution independence.

I would consider PDF to be resolution-independent, yet every document always looks exactly the same, everywhere, even on every third-party reader I've ever tried.

That said, I do think it's possible to design something that looks good without adjusting things to the pixel. I lost this argument at work, and we're using fixed-with, fixed-pixel everything -- even using images on our HTML buttons, because most people use an ugly widget set, so we have to control that thoroughly.

But there are definitely cases where giving up a bit of control (insisting on a particular button style, for example) is a gain in flexibility (now partially-blind people can use a high-contrast color scheme, and it'll work on our buttons).

Re:Heterogeny

[xenocide2]

Then I suggest you look into forms and faxes, because it's impossible. Even a problem as simple as screensize means a difference in layout. PDF and ps solved this whole perfect layout thing, but as it turns out, it's damn near impossible to write for.

Re:Heterogeny

[bigstrat2003]

I'm not a web designer. If we want to get technical about it, I did play around a bit building web sites in IE4/NN4, but I don't think that would get me any web design jobs. I'm a user who wants a) consistency, b) web pages that look good. I want the people who do design my web pages to have the tools they need to meet my needs, and an interpretable HTML standard is not it.

Re:Heterogeny

[mollymoo]

"You know that the standards allow me to render things in slightly different ways, don't you? It's one of the most abused principles behind HTML. if you need pixel perfect rendering web designers like me aren't the right targets. I don't design for that."

I'm a (former) web developer, not a designer. The only way to achieve pixel-perfect rendering is if your entire page is one big image. Can you make sure every line of text wraps at the same point on every browser on every platform with every combination of installed fonts and user-selected options? I'd be amused to see you try.

The most effective way I've found to design sites is for me to sit down with a designer, have them sketch and me point out what should stretch, what will change on different browsers, what they can control and most importantly what they can't control. After a few iterations of this with a designer they're generally pretty good at designing flexible layouts which look good, comply with standards and degrade properly. Designs which work on small and large screens. Designs which still look OK with images turned off. Designs which work if the user turns off CSS. Designs which work when a visually impaired person makes the fonts 4x the size or uses their audio browser. The better ones "get it" and relish the challenge and often go on to become highly competent at HTML and CSS so they can do all the front-end work themselves.

I was amazed how many still (this was a couple of years ago, but the web was a decade old by then) didn't know this stuff, they just worked in Photoshop and handed off designs to be coded up, expecting it to always look exactly they way their PSD did. Perhaps things have improved drastically in the past couple of years and the majority of web designers have added a text editor to their armoury, but judging by many of the sites I see that still hasn't happened.

Re:Heterogeny

[SanityInAnarchy]

I'd love to see an outside team fully develop a QT/Webkit/Xulrunner fork of Firefox that allows me to use Firefox extensions on top of a Webkit rendering engine.

I'd love that, too, but I'm not sure how it would work. How much hacking would it take for Qt/Webkit to support XUL?

Re:Heterogeny

[lysergic.acid]

IE is the scourge of web developers--at least the one who care about standard compliance.

to be honest, it's not really any harder to design to one set of browser specifications over another. it's very easy to design a web page that will render properly in any browser--if you only care about just that one browser. the problem arises from having to design a page that looks correctly in multiple browsers.

if you're coding for reasonably standards-compliant browsers like Firefox, Opera, Safari, Konqueror, etc. it's relatively easy to build a cross-browser compatible, and even cross-platform compatible, site. but IE follows its own specifications with proprietary extensions and non-standard implementations which conflict with open web standards. so it's incredibly difficult to get a site to render properly in both, IE and a standards-compliant browser.

making another version of the page just for IE is not a viable solution. user-agent checking is a bad practice and not an ideal means of achieving cross-browser compatibility. trying to predict every single browser type that might visit your site is simply infeasible, and it ends up making your site inaccessible to a lot of people whose user-agent string aren't recognized but still might render the site properly (this blocks Firefox users from a lot sites/services).

the only half-way decent solution is to use hacks to bridge the gap between IE specifications and open web standards. and this usually ends up requiring lots of trial-and-error and experimentation.

Re:Heterogeny

[tomhudson]

Because it's impossible to design something which looks really good without having control.

That just shows you don't get it. Learn how to design using css and a liquid layout instead of trying to do exact positioning with table hacks. This isn't 1999.

Re:Heterogeny

[SanityInAnarchy]

Flash is an example of something that seemingly progressed well, perhaps faster than browsers, while having essentially no competition.

It's not quite what it seems to be...

You make some interesting points, and your point about Flash isn't entirely invalid, but Flash is also a great example of the sheer lunacy of pinning any kind of "web standard" on a single closed implementation from a single vendor.

Let's start with the basics: Flash is slow. Version 10 might finally get hardware acceleration -- OpenGL has been available for how long, again?

Firefox already uses Cairo, a cross-platform vector graphics engine, which already has some acceleration, and is having more added to it -- but, being its own library, Cairo should be able to benefit other projects than Firefox. Flash hardware acceleration only benefits Adobe products.

Flash video is an absolute nightmare. It's probably the worst possible way to give me a movie to watch. All the controls must be done in Flash, or in the surrounding HTML -- which is great for particularly control-freak designers, but sucks if I want to, say, attach my own controls? (Think Apple Remote on a Mac, or just a global hotkey on Linux.) It's slow -- absurdly so, on the order of ten to a hundred times slower than any other video player I could find.

Yes, that slow. I compared with mplayer and VLC on Linux with Adobe's Flash player. I used the Video Downloader extension to grab the FLV. Turns out, mplayer and VLC use maybe 2%, if I go fullscreen. Flash uses 50%, even in a tiny YouTube window, and is unwatchably laggy fullscreen.

And, you see, if you give me any other format -- Windows Media, Quicktime, mpeg, Theora, Dirac, whatever -- it'll load up whatever player I decide to plugin to my browser. If one sucks, I can use another.

But see, Flash has no competition, and gives me no source code, which means that when things don't work well, I'm SOL.

I believe Gnash is finally good enough to watch YouTube, or getting close -- but keep in mind how many years Flash was out, and how much catching-up Gnash has to do. And Adobe's not helping -- the spec is still proprietary; you can get it under a license which basically lets you do anything you want with it, except develop a player. (WTF? Why anything but a player? Don't they make their money from the server products and creators anyway?)

Now, it's true, Flash was able to include shiny new features faster than browser. But when browsers do include those features, they get done right. Look at the HTML5 video tag -- not quite as many features as Flash, but out of the box, it'll talk to Javascript (so you can write those controls in AJAX), it's trivially easy to add to a page, somewhat more lightweight, and it's entirely up to each browser how they want to implement it -- nothing stopping you from giving the user some playback controls of their own.

Safari already has it -- ties into native QuickTime, I'd guess, which means it should be fast for h.264 and such.

Of course I've been saying for a while that MS should pick up either Gecko or WebKit and not create another rendering platform.

If MS could get it right, I'd say they should go ahead and keep using their own, or develop a new one. The more the merrier.

Where we see problems are when MS gets it horribly wrong, and the entire fucking industry has to pay for their mistakes.

Re:Heterogeny

[slimjim8094]

Things can look 'really good' by allowing content to scale to the screen (think CSS).

How do you propose to make the same code fit on a 60-pixel wide display and a 50,000 pixel wide display (and everything in between)?

I think you're looking for something called PDF

Re:Heterogeny

[tomhudson]

Too often the wanna-be "designer" comes up with something that not only doesn't even look good, but implementing it is impossible, because the design is full of contradictions.

They also tend to suffer from "widget envy" and featuritis. They'll lay out designs with powerpoint or photoshop, and not realize that there has to be some logical underpinning to the flow from one are to another, one page to another, etc.

Someone should remind them that in good design, form follows function. We don't need more "50s Cadillac fins".

Re:Heterogeny

[tomhudson]

Yeah, except requiring things to be rendered the same way all the time isn't "harming functionality", it's common sense. In fact, where exactly does one get off saying that you have a "standard" if there's any room for interpretation at all?

It's not common sense. The HTML standard doesn't say, for example, how form controls are supposed to be rendered visually - that's the job for either the browser or the underlying platform.

Ditto with fonts. A 12pt font can be one size on your device/platform, and different on someone else's.

Ditto with web pages themselves - the visual rendering is specified IN THE STANDARDS as being implementation-dependent. For example, a screen reader is free to render web pages as audio instead of glyphs and images.

Read the standards. They're posted at w3c.

Then learn proper design. A good workman doesn't complain about his or her tools.

Re:Heterogeny

[tomhudson]

I don't see that browsers have made any wondrous leaps of progress due to competition

Then you haven't compared the piece of shit known as IE6 with IE7 in standards mode. Not perfect, but a LOT better. Heck, IE wasn't supposed to get beyond version 6. And it wasn't supposed to get tabs. Firefox grabbing mindshare forced them to ressurect the IE dev team.

Re:Heterogeny

[nine-times]

Yup. I don't know how many times it has to be said, but apparently people keep forgetting: monoculture is *bad*. Like "crossing the streams" bad. People keep thinking that we want one OS with one UI and one browser, and yes, there's something attractive about the prospect. It raises the possibility that we could all put our efforts into one thing and make it the best.

Except that's not what happens. Instead, there's no competition, and there isn't a lot of freedom to make improvements unless everyone else also understands your vision wants the same improvements. Innovation suffers. Cool things stop being built.

Plus, it's bad for security, because any bug or flaw is automatically present in *everything*. You know the argument that Windows gets hits by so many viruses because it's such a large target? Yeah. That's why it's better to have a bunch of different implementations.

But the important thing is that they're implementing the same standards. As long as they're rendering HTML and CSS the same way, we can all visit the same sites and see the same thing. So really there's no problem. There's absolutely no reason to want them to stop work on Gecko. If you prefer using a webkit-based browser, that's great-- use it! If you prefer using a Gecko-based browser, that's great too. If you prefer using IE, on the other hand, then you're just causing problems.

Sorry, I know some people are going to think that last bit is anti-Microsoft fanaticism, but it's not. I won't have any problem with IE once MS gets on board and makes it render HTML/CSS properly. In fact, the diversity represented by Windows and IE is good for the Internet as an ecosystem, provided they start using standard protocols and formats.

Re:Heterogeny

[mollymoo]

Yeah, except requiring things to be rendered the same way all the time isn't "harming functionality", it's common sense. In fact, where exactly does one get off saying that you have a "standard" if there's any room for interpretation at all?

Sorry if designing for the web is a hard job, but the notion that the web should get easier for everyone to use (because we don't have to adjust to any differences in different browsers) is only appealing to everyone.

Your concern is touching, but I'm not a web developer. Also, fixed that for you.

I assumed you were a web designer rather than web developer, but either way I was wrong. I think I get what you're saying now though. You want what you would see if you borrowed my computer to be consistent with what you see when you use your computer. Sorry, but my needs are not consistent with your needs and our experiences shouldn't be consistent either. If you want a consistent experience, you can have it - just don't change things at your end. Demanding that your experience be consistent with mine simply for the sake of consistency, which is what your desires amount to, is wholly unreasonable.

Incidentally, if you want to strongly emphasise something, the correct tag is <strong> (which means "strongly emphasise this", typically rendered as bold in graphical browser, but will be emphasised by audio readers, text-mode browsers etc. as well). The <b> tag means "make this bold if you can, but you're free to ignore this tag if you can't" and the emphasis may be lost in an audio or text-mode browser. An extremely common mistake (it's not always a mistake to use <b>, but in your case it was as loss of the emphasis would change the semantics) and one which displays the widespread misunderstanding of the design of HTML and why it works the way it does. It's inconsistent because it's better for conveying information that way.

Re:Heterogeny

[ceoyoyo]

Actually, I think a design that hangs off the edge of my browser window because I've got the window set narrower than 800 pixels is pretty ugly. I also think text too small to read is ugly, and gets really ugly when I force it to increase size.

Yet a web page (even Slashdot does it) that lays itself out to fit MY choices is beautiful.

The standards allow a little bit of wiggle room, but the user being in control of the "page" you're drawing on and to a certain extent the printer as well, adds a LOT more variation. If you take the control freak approach you will have ugliness. Possibly with the exception of people who use Windows and are used to their browser expanding to fill the whole screen.

Re:Heterogeny

[nine-times]

I don't see that browsers have made any wondrous leaps of progress due to competition.

Right, because we all should be using Netscape 4. Or are you forgetting that browsers have come a long way. In fact, I remember a little upstart browser called "Phoenix" that was competing with the Mozilla Suite. I wonder whatever happened to that browser. Hell, Webkit is the competing "alternative" rendering engine right now, and it probably going to help push Mozilla to improve Firefox even more. The success of Webkit is in itself evidence that 1 browser is not enough, that competition works.

But even if you're not going to accept the idea that browsers have progressed all this time specifically due to competition and innovation from outside parties, let's look at the case of IE. When Microsoft thought they had the whole browser thing wrapped up, they simply ceased development on the browser. It wasn't until Firefox took a big chunk of their market that they announced plans for IE7, and now they're working on IE8.

Re:Heterogeny

[jellomizer]

Having Pixel perfect accuracy is not about art it is about correct functionality. The function of a webpage is to portray information in a way people can understand it easily. When you start getting to large amounts of data the normal web page metaphor starts to break down, and we need more of a application type layout. Once you cross the line from Web Page to Web Application Pixel Perfect rendering becomes more important. As fit more data on the screen and have it presentable there is less margin for fluff. Now you may debate the web application but it falls in the deal with it category. Like the GUI Windowed Interface, Spread Sheets, TCP/IP... It has became commonly accepted and fighting it will just make you bitter, I don't think anyone will argue that Web Applications have flaws to them and they may be more appropriate solutions, but the public wants Web apps so they get Web Apps. Being that they want Web Apps we need the ability for pixel perfect accuracy. If anyone has done any Widows Application Coding of any real scale the Windows Setting that makes any programmer shiver is the Large Fonts option. Which is a poor attempt in making the OS Resolution Independent, causing a wide verity of problems for apps that have more then just a little data to be altered.

There is making a Web App to look like a piece of art. Then there is making a web app and not making it look like a piece of Crap. and the Happy medium. But more accurate rendering across platform really does help.

The problem with your car analogy is the fact that there are still many different designs for cars compare a SUV to a Prius. Even across SUV. Yes the car designers have limitations on their design. But so do web developers.

Re:Heterogeny

[Breakfast Pants]

Thanks for conveniently leaving off Yahoo!, who do use a fixed width layout.

Re:Heterogeny

[ruin20]

That's completely bogus. Google is famous for doing exactly what you claim is impossible, they look good, are quick to load and do so on any device imaginable. It is impossible to be complex and not have control. And even then, I remember before every website was a flash site blizzard entertainment and westwood studios did fantastic jobs of this. My web browser is not a picture frame, and content designers should stop treating it as such.

Re:Heterogeny

[cecil_turtle]

Thanks for conveniently leaving off half of my one argument, "with pixel-level placement", since Yahoo doesn't do that either. Their site handles different text sizes, mobile browsers, zooming, etc. quite nicely. They don't use multiple abutting images or tight tables that require pixel-level precision. I didn't mean that fixed width layouts implied pixel-level precision on all content within the container, honestly I just wasn't thinking about Yahoo.

Re:Heterogeny

[mollymoo]

You've got it backwards. The "large fonts" option solves problems. Specifically, it solves some of the problems faced by visually impaired users and users with high-resolution displays. These are real problems faced by real people who pay real money for software. The problems lie not with the "large fonts" option or HTML's flexible layout, but with the varying needs of users. Catering for these varying needs does cause problems, but don't blame the problems on the tools provided to solve them.

Re:Heterogeny

[santiagodraco]

I never used the words "pixel level-accurate" you did. And all you are trying to do is make that case that bad rendering, which "differs from the intent of the designer" is ok.

Also, I said "Designer" not "Print" or "Magazine", designer, period. IF you are involved in any way in the design, oops I said the D word, of websites, or anything that requires, yes, design, you'd know what it means.

Most web "coders" or "programmers" or even "builders" if you will, will produce their pages with inherent capabilities to adapt to some variety of HTML version support. However that is not the same as what the designer intended, NOR is it the same as a rendering engine improperly displaying content.

Why is that so difficult for you to understand?

Oh, and more advanced HTML with CSS and other "design" features are absolutely intended to allow for rigid design implementations. However how capable is an issue that web designers, in this case, have to take into account when they design so that their design is... interpreted rigidly. If they design for some engine that they know does not conform to a standard but has some special nifty rendering capabilities then they will expect it to display improperly. But that's not what is at issue here.

Re:Heterogeny

[santiagodraco]

This time your comment makes sense.

However, as a web developer you also know that you can dictate to the designer certain limits so that the designer can develop to a rigid design. You can enforce the exact pixel width of the display area, you can enforce font use and font size, you can enforce margins. My point is that as long as you do so within the features available in the target standard you should, assuming a proper implementation of the standard end up with a "pixel perfect" (not my phrase but I'll use it anyway) rendition of the original design.

Let's not confuse the issue with the user missing fonts, increasing text size, or running at a different dpi than expected. Those things are not in the control of the standard or designer.

This is all about whether or not the renderer properly implements the standard and if it does it should look the same on Firefox, IE or Chrome.

Re:Heterogeny

[Icyfire0573]

I agree with mollymoo, this isn't a piece of paper that you are printing out a thousand times for a thousand people this is a sheet of paper that some people have stretched to 1600x1200 and some people have set at 800x600 and lets not forget all of the in-between resolutions to take care of.

and OH btw there are people using 3 different browser programs imposing 3 different height penalties on the top and bottom of the browser and oh goodness i'm using another program that embeds the renderer to impose yet another height requirement and a third of the left hand side of my screen. Oh yea, maybe i didn't max out the browser this time and maybe i had different requirements for resizing the browser this time and oh yea I want to view it on my PDA today.

and this fits into pixel perfect layout how?

Re:Heterogeny

[GotenXiao]

I guarantee even the best workman will complain about their tools if said tools are unable to complete the task they are supposedly meant to do.

Re:Heterogeny

[cgenman]

Because it's impossible to design something which looks really good without having control. Wanting control doesn't make you a control freak, wanting control without reason does.

Right. By demanding pixel-perfect control, designers ignore the fact that there are many aspects that they don't have control over. For example, Your website might be displayed on a screen in vga, uxga, wxga, wsxga+, NTSC, or one of a dozen other standard sizes. The window might be resized off to the side somewhere, or there might be toolbars taking up large chunks of screen real estate. The user might need to use alternative CSS files to increase text size or contrast, or might have zoomed in on the page itself to see details of a photo. The user might not have the fonts the designer intended, and the replacement font might use different kerning. Lots of users turn images off, block ads, or other things which can change layout. Personally, I use a css override that forces all link text to be underlined.

I worked with a web designer who just couldn't wrap her mind around the idea that we just didn't know how many pixels down the bottom of the screen would be. That a screen could be 1,600 pixels wide, or someone could be viewing it on their iPhone. None of the background images she created wrapped, and trying to talk to her about the elements we needed was like trying to explain advanced color harmony to a blind person.

Grandparent's point stands: If you're stuck in a pixel-perfect mindset, you're not a web designer. You're a print designer trying to fake your way through web, and you're making life hell on the rest of us.

Re:Heterogeny

[oever]

If you do not like flash, There is a lot of nice SVG around. All of these examples work well under Firefox 3.0 or Opera 9. Perhaps also on other browsers. It took SVG a long time (spec is from around 2000), but it is seeing more adoption now.

Re:Heterogeny

[FooBarWidget]

Agreed. These days standards compliance between browsers is very good. I design for Firefox, and in 99% of the cases, it renders exactly the same in Konqueror and Opera. Mostly gone are the days when all browsers render differently. The only browser that's continuously giving me rendering troubles is Internet Explorer.

Re:Heterogeny

[CreativeCortex]

I suggest that in the vast majority of cases "looks good" and "works well" are almost one and the same thing. We are after all talking about HCI and usability, and that is very much about what the user *sees*, in other words what the website "looks like". Let's not make the mistake of thinking that "looks like" and "works well" are competitors. In fact, they are in many cases the same issue for the users, and should be the best of allies. I have said it before, and I will say it again. The best websites are built by designer/programmer teams. Each skill keeps the other in check, but gives the best of their own expertise. Ultimately you have to admit, if it doesn't "look good" and users are turned off, then it doesn't "work well" either.

Re:Heterogeny

[mollymoo]

Let's not confuse the issue with the user missing fonts, increasing text size, or running at a different dpi than expected. Those things are not in the control of the standard or designer.

This is all about whether or not the renderer properly implements the standard and if it does it should look the same on Firefox, IE or Chrome.

If everything is explicitly specified, the system has all the facilities (fonts, screen size etc.) required and all options are the default then I agree the same page should look (and work) the same on different browsers[1]. Current web browsers do actually get pretty close to that ideal. However, I don't think it's right to expect consistent facilities to be available in every browser, or for the designer to be able to override user-specified options (eg font size), both of which would be required to actually achieve consistency in practice.

[1] Except, perhaps, the style of inputs in forms. There's a strong argument for consistency with the rest of the OS being more important than consistency with the same page viewed in another browser on another OS. Ideally, a designer would be able to specify the size so it fit with their design, but not alter the visual style so much as to make them unfamiliar.

Re:Heterogeny

[MrMickS]

Car designers hate having to have boots (trunks) which can hold a set of golf clubs, because it means cars have to have high, fat arses. They hate having to cater for tall people in the back seats because it ruins the roof line.

Going off-topic a lot Rover made a car called the Rover 600 that didn't comply to the tall people in the back rule, I am 6ft tall and couldn't sit up straight in the back. It was one of many decisions that saw the company go bust.

Re:Heterogeny

[ratboy666]

Looks good? LOOKS GOOD? How about function?

I use ssh to systems, and may not be using X. Which means that I often "surf the web" in TEXT. 80x24 character. Let me show you google in this mode (leading whitespace suppressed, slashdot anti-lame):

Google (p1 of 2)

Web Images Maps News Video Gmail more v
Groups Books Scholar Finance Blogs
YouTube Calendar Photos Documents
even more

iGoogle | Sign in

Google

_______________________________________________________
Google Search I'm Feeling Lucky Advanced Search
Preferences
Language Tools
Search: (*) the web ( ) pages from Canada

Google.ca offered in: Franais
Advertising Programs - Business Solutions - About Google - Go to
Google.com

(NORMAL LINK) Use right-arrow or to activate.
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list

Please notice that it works the same as a "GUI" browser -- after all, the information is textual. Web sites that are functional with Lynx? Try BestBuy, USAToday, and many others. Now, let's try one that DOESN'T work -- www.radioshack.com (no reason to pick on them, really, but I wanted an example):

RadioShack- Audio/Video Electronics, MP3, LCD TVs, GPS, Digita (p1 of 8)

Order any of the products available on this site. 24 hours a day, 7
days a week. 1-800-THE-SHACK
[pixel.gif]
Click here to find a Battery
[solutions_side_grey.jpg]
I'm looking for a replacement battery to fit my:
Find it by device type
Find it by device type
[solutions_r_side_grey.jpg]
Or, search by device or battery #:
device or battery [go_button.jpg]-Submit
Featured Products
[solutions_side_grey.jpg]
AcomData pureDrive 1TB USB eSATA External Hard Drive
Pure, high-performance
data storage.
Featured Online Promotions:
(Online or 1-800-843-7422 only)
Save up to 10% off select:
(NORMAL LINK) Use right-arrow or to activate.
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list

Compare to the "GUI" equivalent. Now, lets go back to your idea of "control" -- exactly how much control do you think you have over MY browser? Please note that Lynx does NOT execute "Javascript", does not display images, sound, or video. Textual information, baby. Now, I will admit that I can be considered an "edge case" -- but please note that this sort of browsing is ALSO done by Web Spiders that are collecting and indexing your web pages. Which is the first interface for many TO your web page. Don't you want to make it possible for Google (or whatever) to give good search results?

Note that if your site uses "Flash", that flash won't be indexed. Even TV is indexed (well, the text in the captions is indexed), but Flash Video?

Just something to think about.

Re:Heterogeny

[localman]

Well, when I say has-been I mean last year. I found significant behavioral differences (not necessarily appearance differences) between WebKit, Gecko, IE6, and IE7, all of which have significant market share. Depends on how much interactive stuff is on the page and how accessible you want it to be, but I had to test in four browsers.

The work to get things behaving the same in each browser using hacks (and testing that you didn't break the other browsers in the process) took more than the original development time in WebKit. Admittedly, if I only had to do WebKit and Gecko, it wouldn't have been too bad. But when I heard MS was coming out with IE8 instead of using an existing rendering engine I wanted to cry: you know that IE6, 7, and 8 are all going to require individual testing and they'll all be around for years to come.

Cheers.

Re:Heterogeny

[localman]

Oh, I know the differences quite well. I just don't know if the going from the complete mess of IE6 to the almost reasonable IE7 should be considered wondrous progress. The fact that you give that as an example makes me feel bad for how beaten down us web designers have become. We thank them for giving us a mediocre product as long as it's better than the steaming pile of crap they gave us last time.

Here's the deal: a rendering engine is complex, but it is not magical rocket science. And like a sorting library, we developers don't benefit from having multiple implementations of the exact same algorithms. It's just ways to get inconsistent behavior with no practical benefit. The idea that competition in this arena benefitted us is, I think, a misapplication of the general idea of competition being "good". It is, but not when complex interoperability is concerned.

Cheers.

Re:Heterogeny

[localman]

I admittedly don't know Flash that well, so I'll take your word on it's shortcomings. That said: as a user I always get a decent consistent experience and I imagine that developers, though limited, don't have to run through testing their app completely for four different platforms just to feel comfortable with a release.

I should specify that when I complain about rendering engines, I'm usually not talking about appearance but about functionality. I admit CSS is pretty good across WebKit, Gecko, and even IE7. (IE6 is a mess). But functionality -- DHTML type stuff, manipulating the DOM or CSS from Javascript, is still pretty different across all of them.

But here's my main point: I challenge you to explain why "the more the merrier". As a user and as a developer, I don't see how more than one or two rendering engines benefits us. In fact I am fairly sure it hurts both users and developers. It is a notion of "competition is always good" from markets where detailed compatibility is not required and I don't think it applies to rendering engines.

Users can benefit from many browser options, sure: like UI features and such. But at this point the rendering engine should be like a sorting library: the algorithms are figured out and there's no point in having multiple implementations of the same thing. In fact it's bad because you would never know which library you were linking to on the user's machine it introduces bugs. I've yet to hear a compelling argument for "the more the merrier" with rendering engines.

Cheers.

Re:Heterogeny

[tyrione]

Safari uses webkit and it's buggier, slower, and more bloated-feeling in general than Firefox or Chrome(at least on a windows box).

I'd wager that's due more to Cocoa than anything else.

Holy S*** that is an ignorant red herring.

Re:Heterogeny

[Serious Callers Only]

Designer's role is secondary to function.

This sentence betrays that you have no idea what design means, or what it involves.

Re:Heterogeny

[iNaya]

A 12pt font should not be a different size on two different devices. A point is a true measure of size, i.e. 1 point is exactly 1/72 of an inch. An inch should be the same size on all devices, as should a point, a cm, a mm, etc. If you want sizes that ARE different on different devices, you should use a non-real-life dependent sizing, like em, or even pixels.

Re:Heterogeny

[mollymoo]

Designer's role is secondary to function.

This sentence betrays that you have no idea what design means, or what it involves.

This sentence betrays that you have no idea what context means. I was referring to web designers. I've worked on plenty of websites, the designers have only ever decided how it looks, not how it works. Of course designers in other fields may be all about function (eg. racing cars) or a combination of form and function (eg. furniture).

Re:Heterogeny

[Peeteriz]

Yeah, well, that's the point - but if the designers want to match font size exactly with an image X pixels high, then they are setting up a failure.

Re:Heterogeny

[xaxa]

This kind of browsing is also done by people with phones (probably not many though). My phone has the option to disable images, and I activated it -- at the price I'm charged per MB, the images aren't worthwhile.

Re:Heterogeny

[xaxa]

As a user, I *don't* want it to look the same on my 1024x768 laptop screen as on my 24" LCD at 1920x1200. I don't want to have to scroll left-and-right on the smaller screen, and I don't want a massive white gap on the large screen. And I'd like to resize the window and have the web page still fit. And sometimes I like to increase the font size on the large screen by 400% and sit on the other side of the room with a wireless keyboard and mouse, and it's good if the layout scales well. Some other times I use the S-Video out on my laptop and show photographs on the TV -- it would be good if I could increase the size of everything to make up for the resolution and poor picture quality.

Re:Heterogeny

[xaxa]

I forgot another case: when my granddad wanders over to look at something, but doesn't have her glasses with her, I should be able to increase the font size with a keypress and not have the whole layout mangle itself.

This was a problem with car websites -- my granddad was looking for a BMW or Mercedes, but all their advertising websites had tiny grey text on a black background, usually Flash, but if it was HTML it wouldn't scale. Maybe small, illegible text is "cool", but at what cost?

Re:Heterogeny

[Jay L]

Standardized libraries: Why do we need them now? Because so many programmers are control freaks stuck in the days of assembler and can't adjust their mindset? Virtualization is coming to every major OS in the next few years. Programs are runnable on everything from mobile phones to clouds. Identical results from kernels designed for everything from a low-power ARM to a self-contained data center and everything in between is an utterly, utterly stupid idea.

[Yeah, I know, I could have done better. The point: Programmers think that they should have completely deterministic tools, but that designers are crazy for wanting the same.]

Re:Heterogeny

[iNaya]

Well of course, sizes should be set to their purpose. If it needs to match an image size, they should use points or pixel measurements. If it's normal text, they should use ems or percentages.

Re:Heterogeny

[smoker2]

I'll just add that a "standard" does not imply that every device must use the same way of doing things, or that complying with a standard implies quality.
There is a thing called British Standards in the UK, where if you pass inspection and auditing you can use this accreditation on your sales literature.
Sounds good, until you realise that all the standard means is that whatever you do, you always do it the same way. So you could make utter crap, but as long as you do it the exact same way every time, you can get the BSI accreditation.

Re:Heterogeny

[cecil_turtle]

all you are trying to do is make that case that bad rendering, which "differs from the intent of the designer" is ok

Ohh, so close. Take out the word "bad" from that sentence and now you've got it. I think your problem is the "intent of the designer" part, as if the designer only had one intent of how it should look - that's the core problem here. Designers need to understand ALL, or at least most of the ways that their content will be viewed and not make assumptions about the user's environment.

Most web "coders" or "programmers" or even "builders"

OK so you were using some terms a bit unusually. Generally in the industry "designer" implies "graphic" in front of it. If you mean somebody who writes code (yes HTML is code) then developer or programmer will suffice. "Web designer" is really ambiguous, go search Monster.com for "web designer" and a bunch of "graphic designer" positions come up.

However that is not the same as what the designer intended

I'm not even sure this follows on from your previous statement, but again I think this is the primary point where you and I seem to differ. What I'm saying is that a designer, web designer, web programmer, whatever - however many people are involved in the GUI design of a web page, should know that they shouldn't have one specific "intent" of what the page will look like. They should know that it will be viewed on an iPhone as well as in Firefox on multiple OS's with different font support, they should know that people with bad eyes and incorrect monitor color settings will be viewing it, etc. etc. If you design on the web, you must keep these things in mind. When you say things like "what the designer intended" that is where I assumed pixel-level placement because that is the level that many graphic designers want it to be (incorrectly). Then they end up doing dumb things like putting text (sentences, long paragraphs) in a graphic so they can control the font / anti-aliasing, etc. That's bad design and has nothing to do with rendering differences between browsers.

advanced HTML with CSS ... are absolutely intended to allow for rigid design implementations.

Let's clarify something here: by "rigid" do you mean "not controllable by the user/browser" (wrong) or "more precise placement of elements, on some browsers configured to allow for that"? Again, what I'm saying is that if you design a page improperly, and somebody zooms the text or has a minimum font size, your "rigid" design will break and it won't be as the designer intended. This is not the fault of a browser / rendering engine, it's bad design.

Re:Heterogeny

[godrik]

The web is about datas and I am a bit upset that my webbrowser has been taken over by web designer.

Why can not I choose the way datas are displayed ?

Web designer does not know how I would like datas to be displayed on my screen. They do not know the resolution of my window, how many color my screen can display or its refresh rate. I could browse using e-ink technology and thus animations would be wrong.

They do not even know if i got a screen or a braille reader or an audio webbrowser.

I dream every day of an Internet with no web. I mean, why all those data in slashdot are displayed like that ? Why can't I write my own software to display it ? I am fine with the web master of /. to provide me ONE way of displaying it. But why can't i chose everything by myself.

The web is about datas. Not about how they are to be displayed.

Re:Heterogeny

[OldHawk777]

I agree, best I remember, CGM standard (PNG is okay) for web-display, but SVG standard for CAD/CAM/GIS... storage to download for print/edit....

Anyway ..., a real artist (graphic, not music/theater) would use the medium/format that provides the ability to express their creativity and greatest probability for preservation and presentation for posterity (Open Standards/Formats). Even the transient/naturalist new-art hopes to be preserved in a form of permanent/digital media (not relegated to unrecoverable file formats).

The artist-authentic that creates for themselves are a very rare-breed (except theoretical, music, verbal/theater). Not until the last century was artist-authentic objects (most lost/tossed in trash) preserved for museums/posterity.

Pre-1900 being Graphic/Object avaunt-guard/artist-authentic was a sure way to be executed a/o die poor, hungry, disrespected.... Most (close to all) surviving human graphic/object art is exploit/patron (pharaoh... king... dogmatist) preference pretense-art/architecture. Antiquity graphic/object art provides a resultant historical, archeological, engineering, science ... value, but absolutely no graphic/object artist-authentic value/aesthetics.

Anyway, exploit/patron preference "pretense-art" expresses the darker, evil, petty, selfish ... side of human nature (much like a $+100K car...), JMO.

 

Re:Heterogeny

[jellomizer]

It solves some problems. But creates others as it is implemented rather poorly. Because it is not consistent across controls. Many of the partner tools that support the large fonts don't them selfs adjust to it, or allows methods make it easy to adjust to it. A non-pixel sized font in a grid control made by the same company that doesn't take its own feature into account thus crating text that gets cut off. Thus making me as a programmer having to create extra methods to rescale all the controls to match the font. I actually like witting this type of code, I find it fun. But it shouldn't be necessary. I should blame the tools offered to solve the problem, as it was implemented poorly. When having large fonts windows should automatically adjust all my controls and form sizes to match the size so the App looks and functions just like in normal size. Think about it. Having a Large Font size may be helpful for reading text but those 16x16 pixel icons (ok 32x32 for the 21st century) Are tiny icons. which are just harder to read without large fonts. For the most part I work with the disabled person and have them actually go to a lower screen resolution and they are happier because of it because not just my app works but all the other ones that have trouble match up.

Re:Heterogeny

[SanityInAnarchy]

I admit CSS is pretty good across WebKit, Gecko, and even IE7. (IE6 is a mess). But functionality -- DHTML type stuff, manipulating the DOM or CSS from Javascript, is still pretty different across all of them.

I'm talking about both, and again, very little difference. There are, as always, some browser-specific things, but if you follow the spec, you're mostly alright.

But maybe I've been spoiled by jQuery, lately.

As a user and as a developer, I don't see how more than one or two rendering engines benefits us.

First, I need to apologize -- this is ridiculously long. I'm going to try to bold-ify the important points, so you can skim through it.

I believe I've explained above, but it was buried in that rant about Flash. So let me be clear:

As a user, multiple engines benefit me directly, because if there's a problem with one, I can use another. They also benefit me because one size cannot fit all -- I don't often have problems with my Linux GUI, but when I do, I can use lynx from a virtual terminal. I doubt Webkit could be made to run there.

As a developer, multiple engines benefit me less directly, because while I don't often run into a bug in one particular engine, I can always test it on the others. If my page works in Webkit, Gecko, Trident (IE), and Presto (Opera), I can be reasonably sure it follows at least some subset of the spec.

If it breaks in Trident, I can still be pretty confident, because IE has such a shitty record.

But if it runs in Gecko, and breaks in Webkit -- or if it runs in Safari, but breaks in Konqueror -- I have to figure out whether my code is wrong (and Gecko was just more tolerant), or whether Webkit or Konqueror is wrong (and I should submit a bug to them), or whether the spec is too vague (and I should submit a suggestion to the spec people).

This is a pain for me as a developer, right now. It's a pain for users if I miss a browser.

But in the long run, it means that all three (my site, the browser, and the spec) get more robust. My code won't end up depending on some bug, or some transitory (but undefined) behavior, and break with an upgrade. All the rendering engines will get some bug fixes, and get closer to the spec. And the spec itself will be made more precise and explicit.

And that's indirectly good for users, too -- since they get some of the benefits of the One True Engine (all sites behave about the same), and the sites themselves have the opportunity to be more robust.

I've already shown Flash -- let me give you another example of where it went even more horribly wrong.

You see, Windows has a published API. Microsoft doesn't follow it precisely in any version of Windows, which means that developers have to work around (and come to depend on) broken behavior. And Microsoft really can't fix this -- every time they fix some part of the API to actually follow their own spec, thus closing an actual bug, making implementation simpler, and making it easy for developers...

Every time they do that, they break some third-party app which depends on the broken behavior.

In fact, they don't even have to change the API to do that. Some programs break simply because the Windows version number is too high -- classic newbie mistakes like

if (major_version < 3 || minor_version < 1) {
// Alert the user that we need at least Windows 3.1, and exit.
}

Of course, that example has the problem of not working with a version that reports itself as 4.0, because the minor version is less than one, even though the version as a whole is greater than 3.1.

That's not all -- too many really old programs allocate a fixed-length string in which to put things like a version number. Then, when the version is longer than they expected (say, Windows 3.11), BAM, buffer overflow and the program crashes.

The only reason Microsoft

Re:Heterogeny

[DorkRawk]

The problem arises when people who just want to be designers need to do web design and people who want to just be developers need to do web development.

The web is about form AND function. Yes, there are great sites the look like crap. Yes, there are cool looking sites that don't do anything. The goal is to make people want to use your creation. Good looks and good functionality are tools for that. Use them both!

Re:Heterogeny

[shutdown -p now]

That's the problem with the GGP - he's trying to use the tools (HTML+CSS) for something that they are not meant to do, and complains that they are not good enough. Interestingly, what he asks for - pixel-precise rendering - is available for a long time now; you can always use PDFs with embedded fonts (and they can contain hyperlinks). Then there's Flash, of course. But for some reason, the Web is still 99% HTML+CSS... for good reasons, too.

Re:Heterogeny

[shutdown -p now]

Being that they want Web Apps we need the ability for pixel perfect accuracy.

No, you don't, and I can say it as a Windows desktop app developer. For vast majority of desktop applications, it is entirely possible to use flexible UI layouts that are not in any way tied to font sizes etc. In fact, it is often preferrable to do that for localization purposes (because lengths of translated strings can vary a lot). And, while Windows apps often use hardcoded layouts (due to unfortunate limitations in the frameworks used), most Unix toolkits have used dynamic layouts for ages - Qt, Gtk, you name it. Take any Gtk program and look at its source - how many "rectangle 200px by 100px" or "sans-serif 12pt" hardcoded styles are you going to find there? Very likely, none.

If anyone has done any Widows Application Coding of any real scale the Windows Setting that makes any programmer shiver is the Large Fonts option. Which is a poor attempt in making the OS Resolution Independent, causing a wide verity of problems for apps that have more then just a little data to be altered.

It doesn't make me shiver at all, because the tools I use support it properly, and I'm aware of its existence. Indeed, Windows makes it easier for the programmers by disallowing the user to change the UI font face, because that would break proportions - it only lets changing the font size, and then just scales all dimensions linearly. It's not a problem when you code direct to Win32 API (because then you should use "dialog units" for measurement, and those scale automatically). It's not a problem with MFC. It's not a problem with Windows Forms. It's certainly not a problem with any dynamic layout-enabled toolkit, such as Swing, Qt, or WPF. It was a problem for Delphi and VB in their earlier years, if I recall correctly, because those hardcoded font size, and refused to scale up as the user requested - and even then, it was the user's problem in the end (of, say, being unable to read the tiny Tahoma 10px text on account of poor vision or high screen resolution), not the careless programmer's.

In fact, hardcoding layouts and font sizes in attempt to get pixel-perfect rendering match is a root of many evils in Windows world, which are only now being excised by Microsoft through WPF... and even then, it goes very slowly.

Re:Heterogeny

[shutdown -p now]

hen having large fonts windows should automatically adjust all my controls and form sizes to match the size so the App looks and functions just like in normal size.

Not at all. If you ask for a larger font, you just want a larger font, and that's what you'll get. If you want the entire UI to scale, then you ask for that - in Windows, for example, by reconfiguring the DPI (it's also there in Display Settings).

For browsers, again, the modern ones usually have proper zoom feature (which scales both text and images). At least Opera and Firefox do that. If your browser can't do it, blame the browser.

Re:Heterogeny

[shutdown -p now]

DESIGNERS build pages to look ONE way, not "oh I want it to look like this on Firefox, and this on IE, oh oh and this on Chrome!" That's not how it works. Speak to a designer and you'll see.

That's the problem with designers. They build pages to LOOK, not to let me get the information I need from them in a way most efficient for me (which, with my poor vision, and a 15" 1920x1200 display, means that e.g. Verdana 10pt is not exactly readable, and I want something larger - and Verdana looks crappy on larger font sizes). LOOK is secondary. Content is primary. And, for the most part, Web content is not visual - it's textual with some embedded visual bits.

So, the fact is, in an ideal world rendering engines will ALL do it right, which is to say the SAME and according to the STANDARDS which if are bad get CHANGED to render properly.

None of the existing Web standards (HTML, CSS and so on... well, except for SVG) require implementations to render in exactly the same way. This is by design (of the WWW). Designers often don't like it, but who cares?

That is how it works and how it should work. The fact that it doesn't IS a problem and needs corrected, and it's improving all the time because developers don't think like you do... that this is some kind of "my way or the highway" kind of thing.

No, that's not how it works, it shouldn't work like that, and gladly, most developers (and other people) seem to agree with it, which is why we don't have, say, Firefox, IE, Opera and Safari teams working tirelessly on getting the output of their renderers match. They work hard to implement the standards, but even so, each browser typically renders a given page in its own specific way - while staying faithful to the standard, which allows quite a lot of leeway in some areas.

Re:Heterogeny

[shutdown -p now]

One of my laptops has a 1024x768 screen, another is 1920x1200. You're saying that a website which is specifically designed - with sizes of fonts and page divisions in pixels - to look good for the first resolution, would be anywhere near acceptable for the second? How about those now-fashionable UMPCs with, what, 800x480?

Re:Heterogeny

[Al Dimond]

The web is a great way for people to get information on anything. Information can generally be massaged into the great mixture of linear and hierarchical structure called HTML. People, meanwhile...

People have big screens and small screens. Some people have their monitors at eye height on their desks, others hunch over cell phones and laptops on crowded trains. Some people use fine resolutions and others coarse ones. Doesn't matter why, they just do, and they're generally unable or unwilling to change. Some people are alert and others are tired and have strained eyes. Oh, yeah, some of these people are blind and use screen readers, a lot are color-blind, some need or prefer high- or low-contrast color schemes that are grating for the rest of us.

Some people broke their fucking xorg.conf and are fishing for help in Lynx at 80x25. Some can't or won't use Flash, from GNU/Hippies to Plan 9 users to JesusPhone disciples. Meanwhile self-important asshole businesspeople everywhere don't even get color on their Crackberries (unless it's changed since I last saw one). Some people print web pages. Some people like their Emacs keybindings, dammit (and this includes a growing number of hipster Mac fanbois).

Make it "easier for everyone", just try.

You can make it really easy for everyone you care about and still usable for many of the ones you didn't even think of if you give up pixel perfection and do it the easy way.

Re:Heterogeny

[localman]

Thanks very much for your well thought out reply. I even read the non-bold bits :)

You make a good case for having a spec and more than one implementation -- as opposed to the implementation being the spec, which is kind of what happens with singular systems whether intended or not. I'm still not sure we benefit from having more than two, though. I think we'd get most of the benefits you describe with just two independent implementations. I'd personally pick WebKit and Gecko.

But it's a free world, and of course I support anyone who decides to write an HTML renderer for their education and enjoyment. Unless truly superior it would probably never gain enough traction to be worth testing on. But something bugs me when a company with huge pull decides to write an also-ran renderer that doesn't have any significant benefits over what is available, yet is assured to be popular enough and unique enough to require testing. It seems to be just vanity and pride, and it creates needless work for others. I'd almost call it irresponsible. This was my criticism of IE8 and my praise of Safari and Chrome (i.e. the decision in both cases to use the existing KHTML).

Of course there's more important issues in the world to worry about -- time to move on :)

Cheers

Re:Heterogeny

[IdahoEv]

Your post is a perfect example of why designers constantly need to be kept in check.

....

Sorry if designing for the web is a hard job, but the notion that the web should get harder for everyone to use so it's easier for a few wannabe-artists to design for is only appealing to wannabe-artists.

Designers -and their designs- are, in my experience, more beholden to the clients than to the designers, and the desire for pixel-perfect control generally comes from that.

I know and care a great deal about making my pages flexible and accessible, and making them work beatifully on a variety of platforms. Where the rubber hits the road is when I meet clients who make hundreds of requests like "Please make the text wrap after the word *foo* instead of the word *bar*" (this is actually a pretty common request). Clients look at the site on one monitor on one browser on one OS and demand (their vision of) perfection on that combination. I do my best to educate them, but sometimes they won't listen.

Re:Heterogeny

[tomhudson]

Here's what happened in the last week. I developed the templates using divs and css - they rendered fine on browsers under linux (firefox, opera, konq, seamonkey, epiphany), and when I tested under windows, almost no changes (safari, firefox, opera, IE7, IE8, chrome) ... except for IE6, which of course barfed up a hairball.

I don't normally use windows, except on a laptop for compatability testing, so I was surprised at IE7 getting "good enough".

Re:Heterogeny

[tomhudson]

shhh ... you can do pixel-precise rendering using absolute positioning and layers in css - it's just that "designers" who can't grasp the concept of fluid content that reflows, and work with it (and the extra freedom of expression it brings), are still thinking in terms of a physical "page".

They still don't "get" that content is king. "If we make a really flashy sight, we'll get lots of users." Yeah, right. Lose the "wall of flash applets". Lose the fixed/pixel-spec'd positioning. Aim for simplicity, functionality and content, not "gee-whiz."

Of course, that would require them to come up with content ... that's a lot harder than cut-n-pasting graphics together for a mock-up.

Re:Heterogeny

[tomhudson]

A browser is free to render a "12pt" font at any size, or in any fashion. For example, if the browser is accessability-enhanced for the visually impaired, it may scale up a 12pt font by a factor of 3, but only scale up a 24pt font by a factor of 2.5. It may also render the font as audible sounds, using different tonality for emphasized, underlined, etc.

Just as mobile devices will also take liberties with font specs.

Then there's the question of resolution mapping. Try changing your resolution from something crappy (640x480 anyone?) to 1600x1200. Or better yet, pass it through a projector. Your 12pt font can be several inches high when thrown against a wall.

A browser is not constrained by the same limitations as print media. Get over it.

Re:Heterogeny

[iNaya]

Well then it shouldn't use the same print measurements as print media.

Re:Heterogeny

[shutdown -p now]

shhh ... you can do pixel-precise rendering using absolute positioning and layers in css

Not really - you could lay out the divs that way, but there's no telling how large the text of them will be. Even if you specify font sizes in pixels, different font renderers can still output different shapes, inter-letter spacing, and so on, giving sometimes wildly different results in terms of overall size of a text string. And that will either stretch your div, wrap inside it, or be clipped by it - none of which are likely to be acceptable for a "pixel-perfect" design.

Re:Heterogeny

[MikeBabcock]

There are lots of ways to design good looking sites without controlling them at a pixel-level, several of them involve scalable graphics formats though.

You want to design around pixels, you don't need to.

Stop doing it.

Re:Heterogeny

[MikeBabcock]

"Equally well" not "identically"

For example, a nice design may include a list of major site options like "Help | Privacy | Contact" along the top right corner with a nice font, low sized, no bullets, with vertical spacers.

That can be done easily for large screens AND tiny ones using something like:
<UL>
  <LI>Help</LI>
  <LI>Privacy</LI>
  <LI>Contact</LI>
</UL>

Just add an appropriate stylesheet and the above list will go from simple HTML bullets to a nicely rendered horizontal series of options with spacers for those big screen users and a simple "1,2,3" list for small screen users.

This isn't rocket science, but it isn't always obvious either.

Re:Heterogeny

[MikeBabcock]

When people see that I resize browser windows to be able to see more than one thing at a time, it actually confuses some people I know.

I hate browser windows that are too wide -- narrow columns are faster to scan for a good reader. That's why newspapers use narrow columns.

Re:Heterogeny

[ceoyoyo]

They're also easier to read when you're referring to them as you type in a word processor or write code on the other side of the screen. A lot of people still don't seem to have caught on to this newfangled "multitasking OS" idea yet.

Re:Heterogeny

[santiagodraco]

Good designers most certainly do build to convey information effectively. If they don't then they are bad designers. Remember, a good design will both convey information as well as conveying the company's brand and "visual ID" which is also a method of brand association. It's very important and it's an element of deisgn, not web site building.

As for the standards I'm somewhat suprised at your statement that it's not designed to allow for rendering pages identically. The standard is not written around browsers (which is what you imply if you understand the logic of your statement), it's written as THE standard. While it may allow for flexibility in certain situations it also provides design specific features and tools, such as table widths, border sizes, font sizes, typefaces, stylesheets and the like, all of which are designed to allow the "designer" to build a site that "should" display the way intended, when the standard is followed.

That has always been a goal of improving HTML design capabilities into the standard, whether you want to believe it or not. If that wasn't the case the standard would simply be written to provide for the placement of image blocks and be done.

Thankfully most good design houses have both designers and web developers that understand these things. They also know how to work around the improper implementations in browsers that cause rendering to fail to be true to the standard or the designers intended design.

Remember you as a web developer don't dictate look and feel (even though many developers wish they could design). A web developer's job is to impliment the designers "design" into a website and make it 1) work and 2) be true to the design.

Re:Heterogeny

[tomhudson]

Well then it shouldn't use the same print measurements as print media.

Why not? Because you don't think it's right? It's damn convenient when you want to change the output device to ... say ... a PRINTER!

Get over it, already. You're just being childish in your belligerence.

Or better yet, if you don't like it, come out with your own implementation and let the market decide.

Re:Heterogeny

[tomhudson]

If you need "pixel-perfect text", you'll probably decide not to go with the built-in glyphs that come with the platform/browser. In other words, make your own glyphs. Either individual letters, or blocks of text.

On the other hand, I think that the whole "images instead of text" has been way overdone. A menu should just be a menu, not an "experience." And those "walls of flash" have GOT to go!!!

Re:Heterogeny

[iNaya]

Hey hey, calm down.

I've got a different opinion from you. I'm not rubbishing your opinion, I'm simply expressing my own.

Also, style sheets allow one to specify different measurements for different devices using the media attribute. So it could actually be quite convenient. I'm also not saying that it should be changed, merely that it should have been that way from the start. Changing it now (to make a point a point) would be a mistake because it would ruin the layout of a few million websites. But that doesn't make the idea any less logical.

Re:Heterogeny

[tomhudson]

If the idea is good, I have no objection to "ruining the layout of a few million websites." For example, bringing IE into compliance is a good thing - I hate those sites that are "best viewed with Internet Explorer". Or worse, sites that don't work at all if you don't run IE. I won't want to do my online banking in Windows, even if they achieve a 100% score on acid3.

Re:Heterogeny

[shutdown -p now]

As for the standards I'm somewhat suprised at your statement that it's not designed to allow for rendering pages identically. The standard is not written around browsers (which is what you imply if you understand the logic of your statement), it's written as THE standard.

I was not saying that the standard is written around browsers - it's not, and it shouldn't. And it does allow to render pages identically, of course, it just doesn't require it.

While it may allow for flexibility in certain situations it also provides design specific features and tools, such as table widths, border sizes, font sizes, typefaces, stylesheets and the like, all of which are designed to allow the "designer" to build a site that "should" display the way intended, when the standard is followed.

Not at all. For example, even if you set the font size in pixels, you have no way of knowing how precisely the character glyphs will be rendered, and this may vary the width of the text a lot (compare Firefox rendering text on Win32 and on Linux) - and there goes your pixel-perfect precision already. Not to mention that you cannot mandate the user to have any specific font on his system, and thus any CSS styles asking for a specific font are, at best, hints (and this is also explicitly covered by the standard). The same goes for box sizes. In fact, the CSS spec in its section covering conformance of user agents, also explicitly states that "values may be approximated when required by the user agent", without any limitation as to the scale of approximations. So a conforming text-mode user agent may approximate all pixel sizes to multiples of character box size, for example. Not to mention the interesting clause that says, "the inability of a user agent to implement part of this specification due to the limitations of a particular device (e.g., a user agent cannot render colors on a monochrome monitor or page) does not imply non-conformance".

In short, if you really think that HTML/CSS, as specified by W3C, gives you enough control over layout of the page to guarantee precise, pixel-perfect alignment and wrapping of text and elements on any given user agent, you're plain wrong. It never did, it does not do it now, and there are no plans to change it to do that.

That has always been a goal of improving HTML design capabilities into the standard, whether you want to believe it or not. If that wasn't the case the standard would simply be written to provide for the placement of image blocks and be done.

Actually, "placement of image blocks" would probably be quite enough for plain design. The whole complicated CSS thingy is there so that you can think about the information itself first, and then add design on top of it as an optional component that can be partially or fully disabled. If you want to see what I mean, go to the Opera web site, disable scripts and CSS, and look at what you see, and how a properly made web site should behave.

Remember you as a web developer don't dictate look and feel (even though many developers wish they could design). A web developer's job is to impliment the designers "design" into a website and make it 1) work and 2) be true to the design.

As a web developer, I never dictate look and feel to web designers. I just wish the web designers stopped trying to dictate their look and feel (to unreasonable levels) to the end users, myself included, especially in a media that is deliberately designed in such a way that makes it impossible, and tends to break when people try to force it to do what it cannot and is not supposed to be able to do (see my examples above).

Re:Heterogeny

[shutdown -p now]

You mean text-as-images? Well, that's clearly stepping over the line, because, for one thing, such text cannot be searched or selected.

But yes, some designers apparently think teh shininess is more important than my convenience while trying to actually surf the damn thing!

Re:Heterogeny

[santiagodraco]

Fonts are not designed in pixel measurements and are not what designers expect to be exactly positioned. They flow and designs will take that into account. All other elements, including images which may contain text, are rendered exact. That is all part of layout.

As for wishing designers would stop dictating look and feel to end users... huh? That is exactly what they do and should do. IF the design is intended to be flexible in layout, ie the user has the option to widen the browser so that the page content will widen as well, then they need to design page elements for that situation. And the look of the page should retain it's "exact" layout relative to the intended movement of page elements on a resize.

For example a designer may state that this or that column can widen and flow, and that this element is left justified, 10 pixels from the left border, etc.

I think we all understand this. The argument here is simple, conformance to the standard should be uniform across browsers. If the standard is weak it should be strengthened, if the browser implimentation is inaccurate it should be fixed. Designers should be able to design to the standard and not the browser. It's the browser folks who are making life miserable for web designers and developers not the other way around.

Re:Heterogeny

[Serious Callers Only]

I've worked on plenty of websites, the designers have only ever decided how it looks, not how it works.

You weren't working with designers then, but layout artists, and I maintain that you lack understanding of what good design should be, and also of your own job, if you think that design is a gloss to be added at the end to your 'functional' work (which cannot be at its best unless it considers design).

Your dichotomy of function/form divides two things which should not be divided, and places undue emphasis on function without considering the medium used to convey that function to the user.

first appropriate use!

[d34thm0nk3y]

Holy begging the question Batman!

Yes, I did check Wikipedia to make sure a million angry slashdotters weren't going to kill me for its usage.

Re:first appropriate use!

[Vectronic]

I'm a beggar, you insensitive super-hero!

The real question is ignored here...

[creature124]

This article ignores the real question: Why change? I personally see nothing 'outdated' or 'bloated' about Gecko, and there is no point in changing if Webkit provides no real advantage.

Re:The real question is ignored here...

[bigstrat2003]

Did you RTFA, or just TFS? Because I RTFA'd, and the article specifically says that there's no reason for Firefox to switch engines. TFS is full of it, basically, so I could understand if you got the wrong idea from that.

Re:The real question is ignored here...

[PunkOfLinux]

I think it's more that WebKit is the new buzzword in browser dev. Plus, Apple uses it, so it's *obviously* the holy grail. I think Gecko is fine; if it's the bloat, maybe the competition from WebKit will whip it into shape.

Re:The real question is ignored here...

[techno-vampire]

There are some people who thing that change is always good, and that the latest must be the greatest. They're the people who are always using the latest beta version of everything simply because it's new. Then, when the new version is out, they adopt it on the first day so that they can brag that they have the newest version. Yes, they suffer through the teething problems any new version has to go through, but they don't care, as long as it's new.

Re:The real question is ignored here...

[Enderandrew]

Anyone who has looked at Webkit seems to fall in love with it. QT ships with it. KDE now includes a Webkit-part despite the bad Webkit/KHTML-feelings, Android uses it, Arora uses, Safari uses it, and Chrome uses it.

The amazing thing is that I keep hearing how huge browsers must be, and how complex browser code must be. Then arora comes along, and Chrome, and the basic QT-web-browser. I see these mini-browers based on Webkit that are amazingly light-weight and feature rich at the same time.

It is hard to just "trim bloat" when you're talking legacy code from 10+ years in an app that has changed so drastically in both form and function.

Re:The real question is ignored here...

[PunkOfLinux]

Legacy code can still be trimmed, you know.

Re:The real question is ignored here...

[aeoo]

You didn't read the article, because it actually addresses precisely that question, especially on the second page.

Re:The real question is ignored here...

[DocHoncho]

There are some people who thing[sic] that change is always bad, and that the latest must be garbage. They're the people who are still using OS/2, AmigaOS or CP/M. Then, when some new technology comes out, they hem and haw about how whatever crusty old software they hang on to is the pinnacle of computing. Yes, they suffer through the obsolete systems and ancient hardware, but they don't care, as long as it's not new. Then they tell you to get off their lawn.

FTFY

Re:The real question is ignored here...

[aeoo]

"Anyone who has looked at Webkit seems to fall in love with it."

Way to exaggerate. Many third-party devs go with Gecko as well. The article has the examples.

Plus, all the Webkit usages are crap. Safari is crap, so is Chrome, and Android is vapor. KHTML is crap.

I have a Macbook and I happily use Firefox 3 on it, because Safari just doesn't cut it for me. And on Windows Safari is just a dog! It's horrible, starting with the ugly UI and ending with the terrible performance and lack of features compared to Firefox.

So, what's the point of having a great rendering library if there is not a single solid product that uses it? Just because Chrome came out now some people think that EVERYONE is drooling on Webkit. Not so!

Also, you do realize Chrome and Android come from the same entity, so it's not two independent teams making the same decision. Those guys are very much influenced by each other and it makes sense for them to pick the same platform without re-evaluating everything from scratch.

Gecko, I am certain, has weaknesses. Those can be addressed. Bloat can be trimmed. Documentation can be improved. Code can be refactored in small steps to the point of being unrecognizable.

Re:The real question is ignored here...

[creature124]

Of course I didn't RTFA. Based off most of the comments I've seen, I figure it must be against the rules!

Re:The real question is ignored here...

[bigstrat2003]

It is, unless you're exceptionally bored at work. I admit, I broke the rules, but as long as I'm breaking the rules, I may as well enrich your life. ;)

Re:The real question is ignored here...

[Korin43]

Why exactly is Chrome crap? It loads in 1/4th of the time it takes for Firefox to load, you can do things while pages load (like switch to other tabs) without lagging, not to mention that Webkit gets a 100/100 on Acid 3 (Chrome is at 79/100, which I assume is a combination of them not using the most recent build, and using a different javascript engine). For comparison, Gecko's at 85/100.

On another note.. Webkit takes performance seriously.

Not that I think all browsers should use Webkit, but it's certainly not crap.

Re:The real question is ignored here...

[mattack2]

Ugly UI? Safari generally(*) uses the standard OS-supplied features.

That's specifically one reason why I don't generally use third party GUI browsers anymore (I use lynx or links once in a rare while). I like the idea of Firefox, but the UI is just "weird". It's close to, but not exactly the same as the real OS supplied UI. Maybe there is a variant of it that uses standard UI nowadays, I'm not sure. It at least used to be 'skinned' to be almost-but-not-quite the real UI, where things like control tracking don't work the way everything else does.

So I guess that's another good reason there's choice. We seem to like different browsers for partially the same reason the other DOESN'T like the browser.

(*) One specific example where it does not, is the 'tab bar'. Safari doesn't use a regular tab control, which I wish it did.

Re:The real question is ignored here...

[aeoo]

Chrome is crap because it has many bugs and it lacks features. Take a look at Chrome roadmap. Wait, I can't find an official one. Suffice it to say, Google made a statement that they plan to add support for extensions. Obviously the Chrome browser is not feature complete -- not even close. So how can it be not crap? I don't know about you, but I always, always use Firefox extensions and cannot live without them. Right now I have 11 extensions loaded and I use 10 of them all the time. I sometimes use greasemonkey and sometimes I don't. I like having it there just in case any web site gives me crap I don't want to deal with.

Secondly, Chrome has bugs. Many of them. It crashes often. The fact that you have independent tabs is NO EXCUSE. Those separate processes are meant to protect you from Javascript crashes that bad website programmers subject you to and not from Chrome internal bugs.

Chrome uses more RAM than Firefox.

Firefox is a real, honest to God product. It's available right now and it works 100%. I have no complaints about it as a user and a few niggles as a developer. Chrome is basically vapor. It's a prototype of what may shape up to be a decent browser. The amount of work Chrome devs have ahead of them is staggering. It's not something they'll finish in a few months!

It's completely unfair to compare a polished, feature-complete product, with a buggy prototype.

Gecko will get 100/100 on Acid 3 in due time, I am sure of it. Gecko has always had excellent standards compliance. Just because Webkit got ACID 3 test pass first doesn't mean a hell of a lot. It means something when you rub Microsoft's nose into it, because Microsoft has no intention of ever complying with standards (due to business reasons). But Gecko is not Microsoft. It will do ACID 3, I am sure of it, and if not, there will be a damn good explanation (like maybe the standard committee saying that ACID 3 is not a good representation of standard compliance, or some such...) why not (unlike with Microsoft which basically says "f-u" as its sole reason).

So the published Gecko software performs better on ACID according to you than the published Chrome software. So you are really stretching all credulity by comparing this prototype and wishful thinking with a solid product.

Re:The real question is ignored here...

[aeoo]

Choice is good.

I love Firefox UI vastly better than Safari or Opera. To be other browsers are not playing in the same league with regard to UI, that's how much I prefer Firefox. I could go on and on how great it is, but why? Mainly I love how Firefox UI JUST WORKS with minimum UI elements and the elements you get are very customizable. You can argue about the aesthetic looks of the icons, but if you look beyond that, the UI is solid. Opera in particular has made some bad decisions with the tab UI and the only redeeming thing about it is how pretty it is. But look beyond prettiness and it sucks. Hire Opera graphics artist on Firefox and Firefox UI will blow all the skin-deep beauties away.

I think (and hope) EVENTUALLY Chrome will become a great browser in its own right. But right now it's not. Webkit is arguably a very good piece of code. However, I don't see any great browsers using it. Safari is not great (I don't use it on a Mac at home and I don't use it on Windows at work). Chrome is a prototype, so it doesn't count. Android is not even a prototype. All I see are blogs about it but not the real thing. Not even beta! I can't even download beta Android browser for my Blackberry. Nothing. Zero. Supposedly it's coming. Where are the phones that use it? When they appear, we'll talk about it.

Webkit could really benefit from being used by a browser with a 20% market share. So far it hasn't had such luck. As great as it may be.

Re:The real question is ignored here...

[aeoo]

Let me make this clear: as a prototype, and as a tech demo, Chrome is great.

But as a complete product, it's crap. I respect what the Google coders have done, but from the user point of view, it's less ready than any Firefox alpha or nightly for day to day use.

Re:The real question is ignored here...

[darrylo]

Yes.

To everyone: Keep in mind that Firefox 3.1 will ship with TraceMonkey, which should produce performance comparable to chrome. So, the only real advantage of chrome is the process-per-tab feature.

For me, that's not a deal-breaker. However, the lack of addons is (and, in particular, the lack of certain specific addons, like Scrapbook, Evernote, Greasemonkey, etc., in addition to the usual ones such as Adblock Plus).

Re:The real question is ignored here...

[John Millikin]

This article ignores the real question: Why change? I personally see nothing 'outdated' or 'bloated' about Gecko, and there is no point in changing if Webkit provides no real advantage.

Have you ever tried to embed Gecko into an existing program? It's an absolute nightmare. All popular Gecko-using applications are actually written *in* XPCOM because it's easier to write an entire browser in XUL and Javascript than try to bind Gecko to a sane language like C or Python.

Re:The real question is ignored here...

[msimm]

It's the 90's all over again isn't it? All those poor megabytes and cycles just going to waste. Why it's practically unAmerican!

Re:The real question is ignored here...

[dunkelfalke]

firefox isn't slow because of the engine but rather because of the xul interface.
try kmeleon sometime, it is the gecko engine with native win32 interface. it is much faster than firefox.

Re:The real question is ignored here...

[shutdown -p now]

It's not so much about Apple using it. It just seems that lately, whenever another company ponders about what rendering engine to use in a new product, (particularly where light footprint is important, but not always so), they always go for WebKit, and not Gecko. "Why?" is a rather natural question in that case.

Re:The real question is ignored here...

[init100]

I respect what the Google coders have done, but from the user point of view, it's less ready than any Firefox alpha or nightly for day to day use.

I haven't tried Chrome for more than five minutes, so I cannot really comment on it, but I really agree that Firefox 3 has been remarkably solid, even when it was in the alpha stages. Since April last year, I used it as my primary browser, with extremely few issues, especially for a product in heavy development. Many kudos to Mozilla for providing such remarkably stable alpha releases.

And now, I use the Firefox 3.1 alpha, with similar results. No crashes at all yet, and I've been using it for almost two months.

Re:The real question is ignored here...

[init100]

I mean - running JavaScript and rendering pages in Chrome is REALLY FAST.

According to many sources, so is Firefox 3.1 nightly with the TraceMonkey Javascript engine enabled. It is said to be on par with Chrome and even pass it for some operations.

Because...

[not already in use]

It's required for the XUL based interface?

Re:Because...

[powerlord]

It's required for the XUL based interface?

and when you're trying to take over the world, there is no Julie, there is only Xul?

Re:Because...

[not already in use]

No, absolutely not.

Woah...

[JustinOpinion]

Why is Gecko worth keeping if it is outdated and bloated?

You've begged the question, there. The fact is that Gecko isn't outdated and bloated. Mozilla has kept the code up-to-date. They've improved rendering and javascript performance remarkably in recent Firefox releases.

Personally, I'd rather see alternatives being independently developed and improved; all the while competing with each other for mindshare and technical superiority. The alternative, of relying on a single rendering engine for all browsers, is a bad idea. History has taught us it will lead to stagnation and quirky (rather than standards-compliant) rendering.

Re:Woah...

[Anonymous Coward]

You've begged the question, there

GOD DAMNIT! No, Begging the question is a logi... wait, you used it RIGHT?

*reads it again*

Okay... WHO ARE YOU AND WHAT HAVE YOU DONE WITH SLASHDOT!?

Re:Woah...

[QuantumG]

Ya know what I'd like to see? Standards revision. It's great to tote out "standards compliance" as the holy grail, but the problem is that there are plenty of things that the standard just does not define.. and those things get discovered by web developers who work around the issues and it never gets back to the standards drafters. For example, how do you prefetch images? For a long time there was no standard way. Now there's the link tag but it's optional.. yeah, that's right, the standard says that a browser can optionally implement the tag.. what kind of standard is that anyway? So no-one used it. Instead, they use the img tag and set the width and height of the image to 0.. unfortunately, the standard never said "if the width of the image is zero, thou shalt not render anything." Yeah, yeah, I know, should be implied, by some browsers render a white pixel and figure that's good enough.. the fact that this isn't good enough should be fed back to the standard and made explicit.

Thankfully the interest in Acid tests has taken on this role. Unfortunately even a lot of stuff that is in the acid test never makes it back to the standard, so browser developers have to reverse engineer the Acid test!

Re:Woah...

[QuoteMstr]

What's wrong with visibility: hidden? Or using position: absolute to keep unused images out of the client area (and without affecting layout)?

Re:Woah...

[McDutchie]

WebKit has shown it's chops in fast rendering, small size, portability, etc. Everyone should just adopt it. Let it be the standard.

Remember when IE was the de facto standard? Remember how it stagnated and we were stuck with IE6 brokenness for years until Firefox came along and kicked their ass in gear? That's why we need competition. Having one single dominating platform will result in stagnation.

Re:Woah...

[QuantumG]

Yes, that's a suitable workaround.. but you should be able to assume that the browser will do what you tell it.

Re:Woah...

[JTek]

That is the first time I've EVER seen "begged the question" used properly on Slashdot. You get a gold star for the day!

Re:Woah...

[mixmatch]

You're insane for comparing WebKit with IE. IE is not open for development, which is why it stagnated.

Re:Woah...

[Kesch]

You must be old here.

Re:Woah...

[QuoteMstr]

there are plenty of things that the standard just does not define

The standard defines a mechanism to do what you want. The standard can't define everything. That's the case in any complex system. Consider C: i = ++i + ++i results in undefined behavior.

This is a "It hurts when I do this! Well, then don't do that!" situation.

Re:Woah...

[mikael_j]

I partially agree with you, there needs to be more than one rendering engine for (X)HTML out there. But WebKit would probably be good as the "reference" engine, unlike IE development isn't controlled entirely by a single company that's more concerned about squashing competition at all costs.

Also, a big problem with IE when it became the "standard" was that both MS and Netscape had been pretty much making up their own standards for a long time, remember all those "this site viewed best with Internet Explorer/Netscape Navigator" warnings?

I think WebKit should be coded to conform as closely to the W3C standards as possible and perhaps even be treated as a "semi-official" reference rendering engine.

/Mikael

Re:Woah...

[scott_karana]

Holy shit, a proper use of the phrase "begged the question!" Someone give this man a cookie.

Re:Woah...

[CastrTroy]

You're never going to get the same results out of 2 different computers, even if they are using the same rendering engine, or even the exact browser and OS. Monitor DPI can greatly affect the way things are displayed. Font sizes change completely especially when they are specified as points. Some users turn up the minimum font size because they can't see tiny fonts. Some monitors, especially 6 bit LCDs have really poor color rendering, and have problems with colors without much contrast. On my work monitor at work, #E7E7E7 looks exactly the same as white. There's tons of other things that the user can adjust that determine how your HTML+CSS will be displayed. If you think all the users of your site are seeing the same thing, you are quite naive. I think having different browsers is a good thing. Because it means developers at least look at the page until a few different environments. If there was only one browser, they would only check in their own browser, and assume it would look fine for everyone else. Which is definitely not the case.

Re:Woah...

[zobier]

I can't quite put my finger on it but Gecko renderings feel better to me than the competition. Maybe that's just because of familiarity.

Anyway competition is good, If everyone adopted WebKit we would end up back where we were with the IE monoculture before.

Also, I don't get what the obsession other web developers have with "consistent" results. It's the web, documents aren't meant to be pixel identical in different user agents, that's kind of the whole idea: I should be able to access the same information from a vt100, a PC with a high-res monitor, a screen reader or my phone. Obviously the experience is going to be different depending on which device I use.

I really wish more developers would learn about the concept of progressive enhancement. I know it's often due to ignorant marketeers and designers, however better than being shiny on one browser+platform is if it "works anyhow".

Anyone feel like starting a "works anyhow" button campaign?

Re:Woah...

[ya really]

You're insane for comparing WebKit with IE. IE is not open for development, which is why it stagnated.

Rather silly to compare rendering engines (webkit) to browsers (IE) to begin with. Sort of like comparing apples to oranges

Re:Woah...

[Trojan35]

"History has taught us it will lead to stagnation and quirky (rather than standards-compliant) rendering."

While I agree with your overall point, I need to nitpick. Standards-compliance isn't important if everyone uses the same browser. The browser IS the standard.

Re:Woah...

[QuoteMstr]

The browser IS the standard.

And that makes it impossible to develop new browsers, leading to stagnation.

Re:Woah...

[Moridineas]

Very interesting...the result of "++i + ++i" was not what I expected. Why does it do that?

Re:Woah...

[QuoteMstr]

Modifying a value more than once in a single sequence point is undefined behavior.

Re:Woah...

[perlchild]

Doesn't the W3C already collaborate with the INRIA on a reference browser? http://www.w3.org/Amaya/

There is a reference implementation.

It's not bloated.

It doesn't do plugins...

Noone wants to use it...

I imagine the name of the group pushing a browser does help, but I'd suggest google start looking into third party addons for Chrome anyways. And non-window versions...

Re:Woah...

[TheDugong]

Probably still uses email too.

Re:Woah...

[Moridineas]

Thanks for the link, that's good to know.

Re:Woah...

[shellbeach]

You've begged the question, there.

Hmmm ... it's not really begging the question, since there was nothing else in the /. story based on the premise that Gecko was outdated or bloated -- that statement just came out of nowhere at the end. What the article provides is at best an ad populum fallacy (X is popular, therefore X is better than Y).

And anyway, if you read TFA, you'll see that the article strongly praises and supports Gecko, concluding with (my emphasis):

From a technical perspective, Gecko is now very solid and no longer lags behind WebKit. A testament to the rate at which Gecko has been improving is its newfound viability in the mobile space, where it was practically considered a nonstarter not too long ago. Mozilla clearly has the resources, developer expertise, and community support to take Gecko anywhere that WebKit can go.

All of which means that (a) nobody on /. RTFAs (who knew?) and (b) the guy who wrote this story makes George W. Bush look like an intellectual.

Re:Woah...

[fuzzyfuzzyfungus]

http://www.anybrowser.org/campaign/

Already done.

Re:Woah...

[torstenvl]

i = ++i + ++i results in undefined behavior.

Link?

Seems like if i = 6, then i = ++i + ++i would result in 16. The assembly would look something like this:

add %l0, 1, %l0 ; this increments our first operand register
add %l0, 1, %l0 ; this increments our second operand register
add %l0, %l0, %l0; add them together and assign them to the original register

The + operator won't operate until both of its operands have been evaluated, at which point i = 8. I feel like someone who thinks the answer would be 15 (or, heaven forbid, something else) is mistaking the prefix increment operator for a function with a return value, rather than an operand with side-effects.

Re:Woah...

[SanityInAnarchy]

Now there's the link tag but it's optional.. yeah, that's right, the standard says that a browser can optionally implement the tag.. what kind of standard is that anyway?

One that makes sense?

Out of curiosity -- when was the last time you used lynx? Or links2? Or w3m? Browsers don't even have to implement images at all.

Seems to me, about the best they can do is define what the behavior should be when implemented. So, I'd suggest just using the link tag -- it's not like your page will break if it's not implemented, it'll just be slightly slower.

And I've found that prefetching images isn't useful, most of the time. Let the browser cache do its job.

Thankfully the interest in Acid tests has taken on this role. Unfortunately even a lot of stuff that is in the acid test never makes it back to the standard, so browser developers have to reverse engineer the Acid test!

Aren't the Acid tests documented?

Sure, it's easier if you only have to read the standards, but if you're just looking for a higher Acid test score, that seems like the obvious solution.

Re:Woah...

[SanityInAnarchy]

I'm a web developer, and here's what I've observed -- not all firsthand, but research it yourself if you like:

For years, it was IE vs Netscape, each adding features ad-hoc, without too much concern for standards. This sucked. You'd have to do everything twice -- once for IE, and once for Netscape.

So yes, a lot of us just said "fuck it" and went with IE, which was (at the time) smaller, lighter, and faster than Netscape, and already installed on most people's computers. And that was a step forward.

I, personally, was in that group when I first learned HTML.

Then, I discovered Linux. And I discovered that pretty much the only game in town for Linux (at least on GNOME) was Mozilla. And I discovered that in many ways, Mozilla was better than IE. But many, many websites were fairly broken with Mozilla, since Mozilla tended to follow the standards, whereas IE tended to break them horribly. The "fuck it" developers weren't checking for standards, they were just firing up IE to see if it ran.

So this is when I started being in favor of web standards -- though at the time, I pretty much assumed that Mozilla was the defacto implementation of the "real" standards, and so where Mozilla and IE disagreed, I assumed Mozilla was correct.

So when I would develop my own personal website, I'd make them work on Mozilla -- or Phoenix (I was in there since around 0.6), or Firefox. Then, if I detected that the browser wasn't doing something right, I'd slap a banner across the top explaining that I didn't have time to debug Microsoft bullshit, so the page might not work as expected, and here's a link to Firefox.

Don't bother, by the way -- my own website hasn't existed in any usable form for years. No time... I should stop posting to Slashdot.

For sites I was paid to develop, I'd make it work in the Mozilla browser du jour first, then I'd figure out how to hack it to work with IE, if that was a requirement. This added significantly to development time, but I was on Linux, so I wasn't about to fire up IE under Wine just to view my finished product -- it had to work in both.

I've gradually become aware of other browsers, like Konqueror, Safari, and Opera, but I've also discovered that my procedure hasn't changed. Maybe once every three or four months, I have to deal with a glitch in Firefox, or in Safari -- mostly, I just don't touch anything but Firefox for development (because of Firebug). But weekly, I have to deal with IE -- the only reason it's not daily is that I wait for other people to test it in IE, and that happens once a week.

Try it sometime, though -- develop entirely for any decent browser except IE. Then try it on as many browsers as you like. I bet at least one thing will break on IE, and I bet it'll work exactly the same everywhere else.

Everyone should just adopt it.

This is dangerous thinking. I used to think this way about other things -- let Linux be the standard; let everyone just adopt it. And if I'd had my way, we wouldn't have ZFS, among other things.

You'll never get everyone to just adopt one implementation. Even if you start out that way, if it's open, people will fork it. If it's closed, and you actually do get some adoption, well, you become Microsoft Office, or Flash, or any of the other examples I could point to of something without real competition, but with horrible implementation deficiencies that make it completely unusable at times.

The best you can do is provide one standard, and one reference implementation. But even in this case, it's entirely possible that a second implementation would flush out some bugs in that reference implementation, or even some vagueness in the standard that should be rectified.

I would say that it's more important for a standard to have a working reference implementation than a flawless spec. And I'd say it's more important for a standard to have a test suite for that reference implementation -- both unit tests, and higher-level, portable tests like Acid -- than to have an English spec.

Re:Woah...

[lysergic.acid]

Personally, I'd rather see alternatives being independently developed and improved; all the while competing with each other for mindshare and technical superiority. The alternative, of relying on a single rendering engine for all browsers, is a bad idea. History has taught us it will lead to stagnation and quirky (rather than standards-compliant) rendering.

that depends entirely on who's maintaining/developing the rendering engine. if it's a open-standards-flouting company like Microsoft, then you're absolutely right. but if it's a professional team of open source developers who work closely with the community and adhere to open standards & W3C recommendations, then it'd only improve things.

if you only have to code for a single rendering engine, then you spend a lot less time coming up with cross-browser compatibility hacks. and if that engine is standards compliant, then everyone would develop standards-compliant sites. it would make web development easier, more efficient, and lead to better and more robust web apps.

part of the reason why XHTML hasn't gained widespread adoption yet is because IE still hasn't implemented XHTML support, likewise with CSS level 2. similarly, it's nearing 2009 and we're still unable to use PNG's with alpha-layer transparency because IE doesn't support transparent PNGs (why are we even still using JPEGs and GIFs?).

because one single browser, albeit a popular one, still uses a non-standards-compliant rendering engine and proprietary specifications, the entire web development community is being held back from the adoption of common sense, well-established open standards.

i mean, would things be better if there were 2 competing organizations for establishing open web standards--and each one backed their own standard?

Re:Woah...

[tiptone]

If there was only one browser, they would only check in their own browser, and assume it would look fine for everyone else. Which is definitely not the case.

Honestly, it hasn't been that long since that really was the case for 90%+ of web developers.

Re:Woah...

[Just Some Guy]

More like Apples to steaming piles of horse crap.

Re:Woah...

[oldhack]

You must be old here.

Probably an email-using old Korean.

Re:Woah...

[supernova_hq]

Not any more, I've stolen his token, so he'll never be able to send another packet again!

Re:Woah...

[FrangoAssado]

Well, according to section 7.2 of the C# Language Specification, operands are evaluated from left to right, so the result is what I would have expected:

• first you evaluate the first i++, which yields 0 (and increments i to 1)
• then, you evaluate the second i++, which yields 1 (and increments i to 2)
• last, you calculate the sum (0+1 = 1) and assign it to i, overwriting the old value of 2.

Re:Woah...

[McDutchie]

You're insane for comparing WebKit with IE. IE is not open for development, which is why it stagnated.

If you think a lack of competition will not stagnate an open source project just because it's open source, you're the one who's insane.

Re:Woah...

[Mints]

He presupposes Gecko is old and bloated.

Let P be "is old and bloated"
Let Q be "is not worth keeping"

1. If Gecko has property P, then Gecko has property Q
2. Suppose Gecko has property P
3. Then Gecko has property Q

The poster's question works out to be: since Gecko has property Q (="is not worth keeping") (which follows from the above), why in god's name would Mozilla hang onto it?

But the poster presupposed that Gecko has property P (="is old and bloated"), so we have no reason to think it has property Q (="is not worth keeping"), making the whole question baseless.

Re:Woah...

[Mints]

I just re-read your post. The above is what I remember begging the question to be---distinct from circular reasoning. I may be wrong.

Re:Woah...

[miffo.swe]

"The browser IS the standard."

Stupidest thing i have ever read on Slashdot. Take it as a compliment, really.

Re:Woah...

[gr8dude]

Most likely lives in Korea.

Re:Woah...

[godrik]

godrik@mandan:tmp$ cat test.c int fnct (int i) { return ++i + ++i; } godrik@mandan:tmp$ splint test.c Splint 3.1.1 --- 03 Nov 2006 test.c: (in function fnct) test.c:3:16: Expression has undefined behavior (left operand uses i, modified by right operand): ++i + ++i Code has unspecified behavior. Order of evaluation of function parameters or subexpressions is not defined, so if a value is used and modified in different places not separated by a sequence point constraining evaluation order, then the result of the expression is unspecified. (Use -evalorder to inhibit warning) test.c:3:16: Expression has undefined behavior (left operand modifies i, used by right operand): ++i + ++i Finished checking --- 2 code warnings

Re:Woah...

[old_here]

No I'm old here!

Re:Woah...

[poot_rootbeer]

For example, how do you prefetch images? For a long time there was no standard way. Now there's the link tag but it's optional.. yeah, that's right, the standard says that a browser can optionally implement the tag.. what kind of standard is that anyway? So no-one used it. Instead, they use the img tag and set the width and height of the image to 0.. unfortunately, the standard never said "if the width of the image is zero, thou shalt not render anything." Yeah, yeah, I know, should be implied, by some browsers render a white pixel and figure that's good enough.. the fact that this isn't good enough should be fed back to the standard and made explicit.

The question is whether a content markup language that needs to work well on devices from Linux desktops to Windows boxes to Macs to PDAs to speech synthesizers should )or even CAN) be specific enough to guarantee consistent, pixel-perfect output in all cases.

Am I wrong to think that based on your points above, you think that a minibrowser on a mobile phone MUST implement image pre-fetching?

Re:Woah...

[torstenvl]

A compiler that turns three assembly instructions using one register into three assembly instructions using THREE registers as a way of optimizing is hardly the kind of place you'd want to look for authoritative answers.

Re:Woah...

[torstenvl]

splint is a program, not a standard, and is just as susceptible to bugs as any other program.

can you provide an actual citation to the standard or a discussion of it?

Re:Woah...

[torstenvl]

Hmm.

julien:~ torstenvl$ gcc -W -Wall -Werror -ansi -pedantic test.c -o test
cc1: warnings being treated as errors
test.c: In function 'main':
test.c:5: warning: operation on 'i' may be undefined
test.c:5: warning: operation on 'i' may be undefined
julien:~ torstenvl$

I'd still like to see what makes this true.

Re:Woah...

[godrik]

I have only a french edition of the K&R second edition. Thus the following is a translation from me and could be inconsistent with the english version.

In section 2.12 "priority and evolution order" is written:

The language does no specify the order of evaluation of the arguments of a function. Thus "printf ("%d %d\n", ++n, pow(2,n));" can lead to different results depending on the compiler.

Later in the same section is written:

The instruction a[i] = i++; can be dangerous. The problem is to know whether the index uses the old or the new value of i. Compilers can interpret this in different manners, leading to various results depending on their understanding of the expressions

Re:Woah...

[torstenvl]

Neither of those address the issue though.

The first example is different because pow() has no side effects and because pow()'s result will change depending on the order of evaluation. In addition, the order doesn't matter at all.

The second example is different because the storage space of a[i] changes depending on the value of i; however, the storage space of i does NOT change depending on the value of i. a[i] = i++ could be a buffer overflow, but i = i++ can NEVER be a buffer overflow. *(a + i) evaluates to different things depending on the value of i, but *(&i) does not.

Re:Woah...

[shutdown -p now]

The standard defines a mechanism to do what you want. The standard can't define everything. That's the case in any complex system. Consider C: i = ++i + ++i results in undefined behavior.

Yes, and the abundance of undefined behavior in C++, particularly on error conditions, is considered by many to be a major flaw in C/C++ when used as a high-level language. I hope you wouldn't argue that HTML is a rather high-level markup language...

I've nothing against flexibility, and of course the standard shouldn't dictate everything the browser renders. But specifying handling of errorneous input ("... SHOULD notify the user about the error ... MUST NOT attempt to interpret any following markup or render it") wouldn't hurt.

Re:Woah...

[J0nne]

Why do you even need to prefetch images? I haven't needed to do that in years. If you use it for rollovers, look into using css sprites. If it's for some fancy javascript stuff, use the javascript image object. If it's something else, please share.

Re:Woah...

[init100]

remember all those "this site viewed best with Internet Explorer/Netscape Navigator" warnings?

If I would make a personal web site today, where I could ignore IE users at will, I would seriously consider putting up a "Best viewed with anything but Internet Explorer" sign.

Re:Woah...

[Trojan35]

Yep.

I'll tell you why...http://tech.slashdot.org/login

[Anonymous Coward]

"Why is Gecko worth keeping if it is outdated and bloated?"

may be the same as saying...

"Commitment... instead of using Windows.... Why is UNIX worth keeping if it is outdated and bloated?"

Maybe it isn't outdated and bloated... we are not talking about the netscape code here.

Gecko, Mozilla and XPCOM

[daceaser]

The whole of the Mozilla code tree is tied into a framework called XPCOM. It is a Cross-Platform reimplementation of Microsoft's COM. The XPCOM influence is extremely pervasive throughout the whole of the Mozilla/Firefox/Thunderbid/Sunbird/Gecko code trees.

WebKit would not fit in very well with the existing ecosystem because it does not tie into the XPCOM framework which is used to tie all of the Mozilla group's projects together. A lot of the potential performance benefits of moving to WebKit would be lost because of all the bridging between WebKit and XPCOM that would be required.

Re:Gecko, Mozilla and XPCOM

[billnapier]

Whoa there buddy. Close but no cigar.

XPCOM is by no means a re-implementation of MS COM. They share some basic ideas (and so does CORBA, if we're going that far), but "reimplementation" is not a word I would use.

Another thing to point out is that you can bridge almost any API into XPCOM. XPCOM and WebKit isn't an XOR, you could (probably) provide XPCOM interface to WebKit

Re:Gecko, Mozilla and XPCOM

[DrXym]

XPCOM is just a way of defining an abstract interface to an object. You say what methods the interface has in .idl, compile it and out pops the equivalent C++ pure virtual class and methods as well as a type library. These you just implement on a class as you would any base class. Calling an XPCOM interface implemented by a C++ object is exactly the same as calling a direct method on the object. The compiler even spits out a stub implementation of the class making it easy to cut and paste any boiler plate for the object.

One distinct advantage of using XPCOM is that the idl is language neutral. There may be occasions where you don't want to implement an object in C++, or that object resides in another process or thread. XPCOM allows you to implement an object in JavaScript or any other language with a binding. XPCOM also has marshalling code so the caller and callee could even be running in different threads. Neither even cares what the other is implemented in because XPCOM takes care of everything. This is why a substantial amount of Firefox is actually implemented in JavaScript and the rest is largely platform neutral.

Yes there are occasions where XPCOM is not suitable. XPCOM objects are memory allocated and don't live on the stack (although you can cheat in some circumstances). There can also be an overhead in creating some objects (e.g. from a class id or string), and there is small overhead associated with querying the interface and reference counting. This means XPCOM is best suited to long lived objects, especially ones that represent or are passed between subsystems. It isn't suitable for temporary objects or objects which are used in very tight loops such as string classes and so on.

Anyway yes you could wrap WebKit and the overhead would likely be miniscule. Create an interface to represent whatever WebKit object you want to encapsulate and then do the minimal marshalling to connect the two worlds. After all, Safari manages it in Objective-C. I really don't see any big deal doing the same for XPCOM. The issue of course is why bother. Gecko is a robust, fast, mature and fully featured rendering engine. What point is there in junking it and stuffing another engine in instead?

Personally I see very little about Chrome (and I've run it) that justifies why they bothered with WebKit to implement it. Chrome could have been implemented in chrome (XUL) fairly easily from what I've seen.

Re:Gecko, Mozilla and XPCOM

[shutdown -p now]

XPCOM is close enough to COM that interfaces are usually reusable (both require compatible vtable layouts, and have root interfaces with the same AddRef/Release/QueryInterface stuff). XPCOM is certainly much, much closer to COM than CORBA is to either.

No chrome until adblock and flashblock

[Anonymous Coward]

Sorry, chrome is cute, but until someone implements adblock and flashblock plugins for it, it stays idle.

Re:No chrome until adblock and flashblock

[bigstrat2003]

So port them? I doubt it'd be super hard for a motivated user to port them, unlike developing them from scratch. If you pin your use of Chrome to "until someone implements"... you could be potentially denying yourself use of a far superior browser based on the whims of others, which isn't ideal.

Re:No chrome until adblock and flashblock

[stephanruby]

So port them? I doubt it'd be super hard for a motivated user to port them...

You're wrong. Some plugins and extensions have been ported to Webkit, but the thing keeps on crashing. I'm sure this will change, but Webkit is just not a stable platform to extend right now.

Re:No chrome until adblock and flashblock

[Enderandrew]

I heard a rumor that Google will implement their own version of ad block, which won't fully stop the ads from loading, but rather will hide them in the rendering process. Advertisers still see an ad generate, and users don't see the ad.

Re:No chrome until adblock and flashblock

[Daimanta]

That means that all the slowness from crawling adservers still grind the rendering of the webpage to a halt while it's downloading useless ads costing you and the ad company bandwidth.

Adblock plus simply ignores the sites and won't download any data from it giving you a fast rendering webpage and some saved bandwith too. the ad company also doesn't spend and bandwidth on ads that are never displayed.

Not a very hard decision...

Re:No chrome until adblock and flashblock

[bigstrat2003]

Fair enough.

Re:No chrome until adblock and flashblock

[glpierce]

Google makes its money by selling ads. You're saying that you heard that they will market a product that hides ads while making it look like they're being shown. There's no way that's even remotely legal (most likely fraud or deceptive business practices; IANAL). Even if they were just planning to block competitors ads, they'd be in major trouble for anti-competitive practices. Considering the current anti-trust investigation by the DoJ, that would be especially silly.

Re:No chrome until adblock and flashblock

[crunch_ca]

And mozex or It's all text.

Same reason I won't switch to Opera. I like vim.

Oh, and don't forget about noscript, even if Chrome runs javascript faster, most of the time, I don't care.

Re:No chrome until adblock and flashblock

[Enderandrew]

People suggested that Google would refuse to find Firefox, because Firefox recommends Adblock Plus, but Google still provides 85% of Mozilla's revenue, even though Mozilla users often block advertisers.

Re:No chrome until adblock and flashblock

[QuoteMstr]

You're saying that you heard that they will market a product that hides ads while making it look like they're being shown. There's no way that's even remotely legal (most likely fraud or deceptive business practices; IANAL).

There is actually no reason an ad-blocking product would be illegal. The developers of adblock and adblock plus haven't been sued, after all.

It's a sad reflection of the sorry state of our society that people assume that anything contrary to corporate interests must be illegal somehow.

Re:No chrome until adblock and flashblock

[styrotech]

Read it again.

I think the posters point was that Google charging advertisers for ad views that are never shown is fraudulent. Their point wasn't that blocking ads is illegal.

Re:No chrome until adblock and flashblock

[fuzzyfuzzyfungus]

While I agree that our enthusiasm for enshrining the Incumbent's God Given Right To Profit(tm) in everything is creepy, it is not quite relevant to what parent said.

Google sells ads. Many people pay google every time a particular ad is shown, or clicked through, or whatever. If Google makes a browser that pretends to show ads it does not actually show, then it is clear that Google is ripping off many of its ad customers. Similarly, if Google were to make a browser that blocks non-Google ads; but shows Google ads, they would be exerting leverage from one product category to another, in a manner that would probably get antitrust regulators interested.

Parent didn't say that blocking ads was illegal, seemed illegal, or ought to be illegal(none of which are true), but merely suggested that certain types of adblocking would almost certainly constitute fraud or anticompetitive practice if undertaken by Google.

Re:No chrome until adblock and flashblock

[torstenvl]

So make an independent program that modifies the user style sheet.

Shouldn't be too hard.

The hard part would be integrating it with Chrome itself -- adding it as a button or menu item or what have you.

Re:No chrome until adblock and flashblock

[SanityInAnarchy]

The developers of adblock and adblock plus haven't been sued, after all.

True, but they're not also selling advertising.

It would be a bit like Slysoft selling a DRM solution, and including the crack in AnyDVD. I don't know if it's actually illegal, but I doubt anyone would want to do business with them.

Re:No chrome until adblock and flashblock

[glpierce]

Others have already pointed out why your comment doesn't apply to what I wrote, but I just wanted to note that I was actually involved in Adblock's development for a time, and created the first widely-available set of filters for it. As a result, I got a bit of a chuckle out of what you said.

Re:No chrome until adblock and flashblock

[godrik]

I heard a rumor that Google will implement their own version of ad block, which won't fully stop the ads from loading, but rather will hide them in the rendering process. Advertisers still see an ad generate, and users don't see the ad.

I heard that General Motors will make better motors and will push towards bikes.

It's NIH

[coolgeek]

The Mozilla crew are still pissed at David Hyatt for choosing Konqueror over Gecko as "the best open source rendering engine available" when he defected from Mozilla to Apple.

That's why they will never consider WebKit. Too much pride.

Re:It's NIH

[Darkness404]

Or... You know the fact that a lot of AJAX apps will force you to either spoof the browser or use Firefox to access them. Heck, I had to spoof the Firefox 3.1 Alpha's browser ID because some AJAX apps wouldn't work with "Shiretoko" (even though once spoofed they worked fine)

Re:It's NIH

[adpowers]

Funny, I haven't had issues accessing any AJAXy websites from Safari in years. Google Maps and Docs didn't support Safari when they first launched, but they do now. I can't think of any webapps that don't work in Safari these days.

Re:It's NIH

[Whiney Mac Fanboy]

That's why they will never consider WebKit. Too much pride.

Not because the enormous investment in XUL - including the wealth of third party themes / extensions / etc?

Webkit & Gecko have different goals & strengths. It would be impractical for firefox to switch. This a pragmatic decision & nothing to do with pride.

Re:It's NIH

[Darkness404]

A lot of things don't work in Konqueror, or actually they do work but you have to spoof as Firefox.

Re:It's NIH

[fuzzyfuzzyfungus]

Despite the fact that Safari is derived from KHTML, a lot of sites that support Safari believe that they don't support Konqueror. I don't think I've ever actually run into one where this is true, with the appropriate spoofing; but the false belief is common.

What is the writer talking about?

[ya really]

He's going from talking about rendering engine (webkit/gecko) to talking about how great the features are in Chrome (not the rendering engine, the browser). Then back to rendering engine (gecko). What exactly is your topic?

Just a hunch, but the writer doesnt sound intelligent enough to know the features of a rendering engine.

Re:What is the writer talking about?

[interiot]

Chrome wasn't the only browser mentioned; the piece also mentions KHTML, Safari, iCab, Omniweb, Shiira, and Epiphany. The point is to demonstrate just how popular WebKit is, not to focus on any one browser.

Re:What is the writer talking about?

[ya really]

Was referring to the journal entry, not the arstechnica link.

Makes me wonder, too

[melted]

Recently, I'm seeing some indirect evidence of memory corruption in FF. After a while it fails to download images or connect to the network, for example. You restart the process and it all works like buttah again. Heck, Internet Explorer is more stable than this.

I guess fixing hard to repro bugs is far less glorious a job than bolting on a new JS interpreter (even though the old one was OK to begin with) or tweaking the UI.

Re:Makes me wonder, too

[jeremycole]

I'm seeing the same thing, ALL the time. I've been getting it for a few months with FF2, and I just upgraded to FF3 and it has gotten worse...

Re:Makes me wonder, too

[fabs64]

Submitted a bug report?

Re:Makes me wonder, too

[HouseOfMisterE]

As I recently had a problem with my PC's memory, I'll second the AC's suggestion that you check your RAM. I do a lot of very CPU/memory intensive stuff with my main PC, and it has always been a very stable box. A few months ago, though, it developed a problem where it would sometimes reboot when I would load a Flash-heavy page in Firefox. I was experiencing no other trouble with the computer, so I tried to troubleshoot the reboots as a problem with Adobe Flash or Mozilla Firefox. I had no success and gave up after a few weeks. On a whim, I decided to run memtest86 from a Ubuntu live CD and the PC failed the memory test after a few minutes. I swapped out the RAM and everything has been working properly since.

Re:Makes me wonder, too

[Chrisje]

Now as a support technician I shudder at your post. It lacks any specific information and therefore relevance.

1) What version of FireFox are you talking about?
2) What plug-ins are you running?
3) What platform are you running it on?
4) How is that patched?

I'm running an updated FF3 on Vista (my employer makes me use the latter) and have IETabs, some skin, FireFTP, Downthemall, PDFDownload and Download Statusbar installed. This whole construction works flawlessly all day every day, and you could argue my browsing requirements are on the heavy side.

It's not a bug / class issue until many users report the behaviour under particular circumstances. So until a bug is found, the time is well spent on bolting a new JS interpreter onto the thing and tweaking the GUI.

Re:Makes me wonder, too

[fabs64]

Speaking of IETab, that's about the only good reason I've come across for threading tabs in ff. The dodgy activex apps I have to open in IETab make the whole browser unresponsive all the damn time. To the point where I've just gone back to having them open in their own IE instance.

Re:Makes me wonder, too

[melted]

1. Latest. 3.0.1
2. Adobe Flash and several add-ins (Adblock, Greasemonkey, Firebug)
3. Windows (W2K8), Mac (Leopard, latest updates)
4. Latest patches are applied to everything

It does work OK, if you shut it down every now and then. I usually keep my browser windows open for days on end, since I just put my laptops to sleep at home and at work my computers are always on.

Not really a serious question.

[fuzzyfuzzyfungus]

While it is certainly true that the mozilla codebase has a rather sordid past, its trajectory has been extremely encouraging(particularly given that it essentially includes its own cross platform widget set, used by mozilla apps and a few others). Javascript performance is competitive with the best, memory performance has steadily improved, and rendering support is quite credible.

I can understand why a third party, starting a project from scratch, might be disinclined to use Gecko; but Gecko seems to be very much on the worthwhile side of the "improve vs. scrap" question.

Re:Not really a serious question.

[broken_chaos]

And why is using it's own widget set that doesn't entirely integrate with any existing operating system or desktop environment an 'encouraging' thing?

For the record, it's closest to fitting with Windows. With Linux, it emulates GTK+ reasonably closely, but it does not completely respect the GTK+ theme (particularly with respect to fonts and colours, among other things). With OSX it just... Doesn't look like a native app, and doesn't integrate with any other system component.

Re:Not really a serious question.

[fuzzyfuzzyfungus]

I don't say that having its own widget set is an encouraging thing. I say that Mozilla's trajectory(from slow and fat to faster and leaner) is extremely encouraging, particularly given that it is making this progress while also carrying a widget set. The progress not the widget set was what my wording described as encouraging.

This doesn't mean that the widget set is a good idea, or a bad one, I was merely noting that mozilla is moving at a fair pace, while carrying baggage. Whether or not the XUL stuff is a good idea seems to depend on whether you fall into the "Consistent means looking the same on all platforms, and I like consistent" or the "Consistent means each platform looking like itself, and I like consistent" schools of thought.

Re:Not really a serious question.

[Yer Mum]

FF3 does use OS X widgets. Making Gecko use native widgets was part of a major overhaul to the rendering engine.

Um, are you sure of that?

[Estanislao Mart�nez]

Because it's bloated as a single app, but less bloated then opening up a new process (or more than one!) for every single web page loaded. Until every computer in use has multi-gigabyte memory, including handheld devices, there will be a need for something lighter than webkit

First of all, WebKit itself doesn't impose the multi-process model that Google's Chrome uses. For example, Safari uses WebKit, and it runs as a single process.

With that cleared up, now, here's the more important flawed assumption in your post: that having the broswer use n processes to display n pages will require n times as much memory as doing it all with n threads in one process. That's far from true, because such a browser can be architected so that the processes use shared memory for all shared resources and state.

The multi-process architecture will carry additional memory overhead, but done correctly, it will scale up much better than linearly. The real costs are the costs of process creation and switching in the OS, plus the costs of the inter-process communication method. Using shared memory for the latter is cheap, but it can potentially make one process bring down the others, defeating the purpose of isolating each page into a process; it's a balancing act, and the memory overhead really depends on what tradeoffs one picks here.

Re:Um, are you sure of that?

[avanderveen]

Here's some clarification from the Google Chrome introductory comic: http://blogoscoped.com/google-chrome/5

Basically, you will see an increase in memory usage early on using the browser, but over time the browser's usage will not bloat as much. So, for extended use Firefox/Gecko could use more memory than Chrome, but for short periods of browsing Firefox/Gecko will be more memory efficient.

Also (comic, p.4) it's using different processes, not threads.

Re:Um, are you sure of that?

[tyrione]

Because it's bloated as a single app, but less bloated then opening up a new process (or more than one!) for every single web page loaded. Until every computer in use has multi-gigabyte memory, including handheld devices, there will be a need for something lighter than webkit

First of all, WebKit itself doesn't impose the multi-process model that Google's Chrome uses. For example, Safari uses WebKit, and it runs as a single process.

With that cleared up, now, here's the more important flawed assumption in your post: that having the broswer use n processes to display n pages will require n times as much memory as doing it all with n threads in one process. That's far from true, because such a browser can be architected so that the processes use shared memory for all shared resources and state.

The multi-process architecture will carry additional memory overhead, but done correctly, it will scale up much better than linearly. The real costs are the costs of process creation and switching in the OS, plus the costs of the inter-process communication method. Using shared memory for the latter is cheap, but it can potentially make one process bring down the others, defeating the purpose of isolating each page into a process; it's a balancing act, and the memory overhead really depends on what tradeoffs one picks here.

Isn't one dependent upon the OS shared memory model when developing your browser? In other words, the memory system on Windows is managed differently than on OS X and Linux, let alone on OpenSolaris, FreeBSD, AIX, et.al. Wouldn't this alone make design decisions targeting/optimizing low-level code platform specific?

And if so, wouldn't you have to make decisions on optimizations first targeting more generic areas and later, platform specific areas?

Re:Gecko is not outdated or bloated.

[bigstrat2003]

IE 8 is not outdated by any stretch of the imagination. I'd give you bloated, except you said that Gecko isn't bloated, and IE isn't what we'd call that far off from Firefox in terms of bloat. They're both weighty browsers, it's not like comparing a midget to a cow.

Amendment

[Estanislao Mart�nez]

The multi-process architecture will carry additional memory overhead, but done correctly, it will scale up much better than linearly. The real costs are the costs of process creation and switching in the OS, plus the costs of the inter-process communication method. Using shared memory for the latter is cheap, but it can potentially make one process bring down the others, defeating the purpose of isolating each page into a process; it's a balancing act, and the memory overhead really depends on what tradeoffs one picks here.

Actually, I take that back. The only real overhead is the OS overhead for separate processes.

The architectural choice of what memory contents should be shared between processes and which should be private aren't specific to the multi-process architecture. The same choices and tradeoffs exist in a multi-threaded application; you can choose between having each thread have its own copy of some piece of memory (uses more memory, but isolates each thread from the others), or have all the threads share it (uses less memory, but access must be synchronized, and any bugs involving that shared memory may make one thread bring others down).

Re:Amendment

[QuoteMstr]

Yes and no. There's no actual protection, correct, but the program under normal operation must act as if there were. Both you and the OP are correct. Threads provide no memory protection, and they impose most of the overhead of multiprocessing in a correct program.

"Outdated and bloated" is irrelevant

[Trevin]

Which engine is closer to being fully compliant with W3C standards? I can't tell how WebKit rates.

http://www.webdevout.net/browser-support?IE7=on&FX3=on&OP9=on&SF2=on&uas=CUSTOM

Re:"Outdated and bloated" is irrelevant

[WDot]

If you go by performance on the ACID tests, Webkit passes ACID1 and ACID2 (like all modern browsers including IE8 beta), and gets between 75-100 on ACID3, depending on whether it's Safari stable, Safari development, or Google Chrome. Firefox passes Acid1 and 2 and gets a 71/100 stable and an 85/100 development version.

http://en.wikipedia.org/wiki/Acid3

If we're basing engines purely on W3C standards support, there isn't enough difference to scrap either. Even getting a perfect on the Acid3 test won't imply complete compliance. Nobody's there yet. The best anybody can do is keep the rendering engines competing so they have a reason to improve.

Welcome to "Standards"

[statemachine]

Please do not take this negatively:

Ya know what I'd like to see? Standards revision.

And yet, they do revise them by working on and ratifying a new version.

It's great to tote out "standards compliance" as the holy grail, but the problem is that there are plenty of things that the standard just does not define.. and those things get discovered by web developers who work around the issues and it never gets back to the standards drafters.

That sounds nice, but you're advocating a moving target. Standards or recommendations would never be finished.

Now there's the link tag but it's optional.. yeah, that's right, the standard says that a browser can optionally implement the tag.. what kind of standard is that anyway? So no-one used it. Instead, they use the img tag and set the width and height of the image to 0.. unfortunately, the standard never said "if the width of the image is zero, thou shalt not render anything."

Just because *you* want it, doesn't mean others do.

Unfortunately even a lot of stuff that is in the acid test never makes it back to the standard, so browser developers have to reverse engineer the Acid test!

I'm guessing you're a web developer. Therefore, you or your company have a demonstrated interest in the recommendations, which means you can sign up and be a member of the committees and advocate your changes and proposals for the next version of the recommendation.

I hope this helps a bit to further your understanding of the process.

Re:Gecko is not outdated or bloated.

[actionbastard]

Touched a nerve did we?

Re:Gecko is not outdated or bloated.

[Enderandrew]

Firefox 3 on my system uses around 200 megs of memory. IE8 pushes 400 megs. Firefox is snappy. IE8 makes IE7 look snappy in comparison.

Re:Gecko is not outdated or bloated.

[actionbastard]

"...it's not like comparing a midget to a cow."
How about a midget cow?
Sorry. I should have added the sarcasm notifier (~) after the end of the sentence in the original post. My bad.

Wheeeeeee!

[maxume]

https://wiki.mozilla.org/Gecko:DeCOMtamination

Re:Why did Google Choose webkit!

[Enderandrew]

Google has Android. Apple isn't putting Chrome on the iPhone. End of discussion.

RTFA (more closely)

[nadamsieee]

From a technical perspective, Gecko is now very solid and no longer lags behind WebKit. A testament to the rate at which Gecko has been improving is its newfound viability in the mobile space, where it was practically considered a nonstarter not too long ago. Mozilla clearly has the resources, developer expertise, and community support to take Gecko anywhere that WebKit can go.

Re:RTFA (more closely)

[Blancmange]

The cool thing is that Gecko's improvements counts towards a win for web standards. Gecko needn't actually continue to exist for much longer for the good work put into it to benefit the web.

I prefer democracy.

[jbn-o]

Speak for yourself, I am a "web developer" (I fail to see how "programmer" doesn't suffice) and I prefer democratic control of software (software freedom) and letting a thousand flowers bloom. Software freedom can be messy but we're better off having that messiness than allowing any one implementation of something to dictate how things work.

Re:Gecko is not outdated or bloated.

[Dracos]

IE has had the same rendering engine, Trident, since IE4 (1997). MS may claim significant improvements in standards support, but in reality, they seem to only pick the bugs that have names. After five publicly available iterations (up to IE7), why is their overall standards support at least 25% below, on a feature by feature basis, nearly every other rendering engine?

Plus, I have yet to hear anything to rebut the rumors that MS simply can't fix Trident because the code is such a mess, and they "don't want to break websites", which is one of the most backwards arguments for anything on any topic.

Browser is not just for HTML

[kentsin]

I hope to point out that we need a browser which handle wiki like markups.

I think HTML need to compete with other formats, especially un-structural markups.

It is time to explore a un-structural markups, hopefully a standarized process will start soon. Structural markups is very expensive and incomplete. There are many cases which can not handle well, for example, it never handle footnotes nicely.

Thank you.

Re:Browser is not just for HTML

[Anonymous Coward]

I think HTML need to compete with other formats, especially un-structural markups.

It is time to explore a un-structural markups, hopefully a standarized process will start soon. Structural markups is very expensive and incomplete. There are many cases which can not handle well, for example, it never handle footnotes nicely.

Excuse me, but -- what? Do you even understand what the term "structured" means?

Also, just because HTML doesn't have a convenient method for handling footnotes doesn't mean that it's a failure of structured markups in general. For example, see LaTeX.

Re:Browser is not just for HTML

[QuoteMstr]

Ah, the Microsoft Paint school of user interface design.

Re:Browser is not just for HTML

[QuantumG]

It almost sounds like you're saying something interesting here.

Could you elaborate?

what's an "un-structural markup"?

Mozilla IS Gecko

[mysidia]

Gecko is what they developed.

This is like having an article on Redhat's commitment to the Linux kernel.

As if they could just arbitrary change their flagship product to use the BSD kernel instead.

Or like discussing Microsoft's commitment to the Windows platform.

Just because unix/Linux-based kernels and software are becoming more popular in some circles does not mean that it is conceivable for M$ to drop the Windows kernel in favor of a *IX one.

If Gecko in Mozilla dies it will be because they have developed a better Gecko, or because Mozilla as a whole has died.

Re:Mozilla IS Gecko

[merreborn]

Microsoft *has* replaced the windows kernel.

You don't seriously think Vista's running on anything remotely similar to Windows 95's kernel, do you?

Re:Mozilla IS Gecko

[supernova_hq]

well, so much for that

Re:Mozilla IS Gecko

[fabs64]

You don't seriously think FF3's running on anything remotely similar to Netscape 1.0's rendering engine, do you?

Re:Mozilla IS Gecko

[Tim C]

Vista runs on the NT kernel, which is roughly 15 years old.

Microsoft didn't so much replace the Win95 kernel as stop developing that OS line.

Re:Gecko is not outdated or bloated.

[actionbastard]

Ah! Sweet redemption!

And God bless them

[XanC]

for getting the kinks ironed out before they hit the rest of us!

Today's news

[teh moges]

Something stays the same from yesterday. More news on this breaking story at 6

Re:Today's news

[iNaya]

Something that stayed the same? What kind of world do you live in? Can I live there too? I want that to happen! It would be news!

What I would like to see in my browser

[aoeu]

I find it annoying when my browser renders a page one way, and then, just as I click on something, it re-renders, the links change, and I'm looking at goatse. Somebody should look very carefully at his kidney problem, but not me.

FTFA

[FlyingBishop]

From a technical perspective, Gecko is now very solid and no longer lags behind WebKit. A testament to the rate at which Gecko has been improving is its newfound viability in the mobile space, where it was practically considered a nonstarter not too long ago. Mozilla clearly has the resources, developer expertise, and community support to take Gecko anywhere that WebKit can go.

Who exactly is claiming that Gecko is bloated? Also, XUL holds an extraordinary amount of promise as a successor to old-style Java apps. Webkit has nothing resembling it: all it does is render HTML + CSS.

Re:FTFA

[init100]

Who exactly is claiming that Gecko is bloated?

The Google Chrome fanboys that has been all over the web touting Chrome as the future and "advising" Mozilla to drop Gecko and adopt Webkit.

Some of them even claim that Mozilla now has no reason to exist, since Google Chrome is so ooh, aah, etc. The silliest comment that I read even went as far as claiming that "the computing world has moved on (to Webkit) and left Mozilla/Firefox/Gecko behind".

That comic doesn't really tell us a lot.

[Estanislao Mart�nez]

Separating the browser into one process per tab only helps for the fragmentation problem in the case of memory that is truly private to each process. It doesn't help at all in the case of memory that's shared between processes. If that shared memory is managed as a heap like malloc and free do, it can still fragment. (And it's important to point out that the shared memory doesn't need to be managed like that; a custom memory management scheme tailored precisely to the way it's used could have zero fragmentation.)

There is no way of knowing the memory and performance costs of the multi-process browser without having a lot more detail about precisely which things are private to each process, and which are shared. The comic does nothing to tell us to what Chrome is sharing and what's private to each process, nor how any shared memory is managed.

Security?

[Shadow-isoHunt]

Why is WebKit worth switching to when Chrome had five vulnerabilities in two days?

2008-09-05: http://milw0rm.com/exploits/6367
2008-09-05: http://milw0rm.com/exploits/6386
2008-09-05: http://milw0rm.com/exploits/6372
2008-09-04: http://milw0rm.com/exploits/6365
2008-09-03: http://milw0rm.com/exploits/6355
2008-09-03: http://milw0rm.com/exploits/6353

WebKit isn't touching my machine, thank you very much. Might throw Bunny(the fuzzer) at the codebase, though.

Re:Security?

[LinuxInDallas]

Reading those it is not apparent to me that they are due to WebKit issues. Are they?

Re:Security?

[Just Some Guy]

Why is WebKit worth switching to when Chrome had five vulnerabilities in two days?

For approximately the same reason why Zsh is worth trying, even though Debian had a broken SSL library.

after all these years

[Kanasta]

waiting for Gecko to be completed 4-5yrs behind schedule, finally we get to use it for 2-3yrs and now you say it's "outdated and bloated?"

Re:after all these years

[Tablizer]

waiting for Gecko to be completed 4-5yrs behind schedule, finally we get to use it for 2-3yrs and now you say it's "outdated and bloated?"

Welcome to life in IT
     

Re:Gecko is not outdated or bloated.

[StrategicIrony]

Is that you Mr Balmer?

Process-per-tab protects you from rogue JIT

[Estanislao Mart�nez]

A thread per tab model does protect you from a rogue Javascript freezing the browser's UI, but it doesn't protect you from a poorly written plugin that does something stupid like dereference a NULL pointer.

Chrome's doing JIT compilation of Javascript. In this context, separating the broswer into multiple processes protects you from bugs in the JIT compiler that produce native code that makes memory access errors.

Re:Why use GEICO (advertisement)

[Eccles]

I never heard of Amica until a friend got rear ended by one of their customers.

Well that's a novel marketing approach...

Seriously, though, perhaps they save money by not blanketing the airwaves with commercials.

AHH THIS IS SURREAL MY BRAIN HURTS

[nomadic]

Webkit, which was adopted by Apple and Google for use in the Safari and Chrome browsers. I have been using Chrome on my work PC and find many of its features compelling, and wonder how soon we will see its best innovations in Firefox. Why is Gecko worth keeping if it is outdated and bloated?

It's like one of those stories where a sane traveller finds himself in a bizarre realm where everyone is crazy. Like something from the Twilight Zone.

Chrome's rendering engine is so ridiculously slow that I stopped using it after a few minutes. Hasn't anyone else noticed? Or is everyone too polite to point out that Google did a poor job? A quick google search shows that at least this guy agrees with me. What about the rest of you? Did you notice that Chrome takes like 3 times as long as Mozilla to render a page? Do you think maybe that's why Mozilla shouldn't adopt Chrome's rendering engine? Is Rod Serling going to suddenly appear in my living room and do a monologue?

Re:AHH THIS IS SURREAL MY BRAIN HURTS

[JStegmaier]

You're the second or third person I've heard this from. I can't find the other places I've read it at the moment.

However, having used Chrome on several Windows machines (including co-workers), I can say without a doubt Chrome has always rendered much faster than Firefox (and even more so than IE) for every page I've seen.

Could it be something different/wrong about the few computers that are having the slow rendering issues?

And do you honestly think the Firefox, IE, Opera and Safari zealots on Slashdot would possibly not point out that Chrome was incredibly slow every time it was mentioned if that was the case for everyone?

Re:AHH THIS IS SURREAL MY BRAIN HURTS

[nomadic]

Could it be something different/wrong about the few computers that are having the slow rendering issues?

I run a vanilla XP installation on standard commodity hardware; if there is an issue with my computer it is one that does not affect Firefox, IE, or Safari.

And do you honestly think the Firefox, IE, Opera and Safari zealots on Slashdot would possibly not point out that Chrome was incredibly slow every time it was mentioned if that was the case for everyone?

I don't really see that many Firefox, Opera and Safari zealots, and I see no IE zealots on Slashdot. There are plenty of Google zealots though. And considering how many Linux zealots will say with a straight face "Linux doesn't crash" then I can easily see Google zealots subconsciously refusing to notice the few extra seconds a page takes to load.

Re:AHH THIS IS SURREAL MY BRAIN HURTS

[Nicolay77]

Well, as an Opera zealot myself, I tested Chrome and found its javascript engine to be extremely fast.

So, merit where it's due.

Web applications

[KingSkippus]

but a web browser should still be a relatively lightweight application by itself...i should be able to have a web browser running in the background while i'm working in Photoshop, Illustrator, or other memory-intensive applications.

The idea behind Chrome is that "under the hood, [Google is] able to build the foundation of a browser that runs today's complex web applications much better".

In other words, if you want a lightweight browser that can simply browse simple web pages, there probably are better browsers out there. But Google is saying (and I agree) that as time goes on, browsers are being asked to do more and more, and we need something a little better to serve not just as a lightweight web surfing application, but an actual application platform itself. Pretty soon, your Photoshop, Illustrator, and other memory-intensive applications will probably run within your browser, not as stand-alone applications on your OS of choice. (In fact, Adobe has already launched an online "express" version of Photoshop with some photo editing capabilities that are limited, but well within the realm of what used to be handled by stand-alone applications. And Adobe is not alone in doing this.)

Some people disagree, and say that a web browser should be a web browser and leave other applications stuff to, well, applications. I can see advantages both ways. Javascript, Flash, Silverlight, or whatever your Web 2.0 platform of choice is aren't the most robust of development of platforms, but that may change over time. Browsers will undoubtedly get more bloated, but as long as it's not as fast as low-end computer capabilities grow, I don't really see that as a problem. And of course, most of these platforms (well, most not developed by the company that has a vested interest in you being locked into its operating system) will work under any OS. In the end, I guess it just boils down to what all you'll be asking of your web browser. Fortunately, web browsers tend to play nice with each other and you have choices galore for which one(s) best suit your needs.

Re:Web applications

[Lincolnshire Poacher]

> In the end, I guess it just boils down to what all you'll be asking of your web browser.

But the end-user is not asking for these developments.

As you noted, Adobe has released a photo editing web application. Who asked for this? Not the users since they still need a powerful computer to execute the fat browser, so there is no advantage over a native app ( and several disadvantages ). Adobe, or whomever, though, see web apps as a guaranteed ongoing revenue stream.

The vendors are driving the expansion of browser capabilities for their own purposes, not the whims of users. Have you honestly sat down in front of, say, a DTP program and thought ``I wish this were a web app?''.

Re:Web applications

[KingSkippus]

There are plenty of applications that I think should would make perfectly good or even great web applications that have traditionally not been. Anything that could be shared with or among people is game. Also, applications written using the web as a platform, when done right, tend to be much more portable. I can access my e-mail, Google docs, maps, etc. from any OS, most browsers, any location, even on my mobile phone.

Honestly, unless there's some compelling reason an application shouldn't be a web app (e.g. security), I can't imagine any application that wouldn't benefit from being a web app, all other things being equal. (Which, as time goes on and products like Chrome and companies like Google push us towards web applications being more robust and capable, all things will eventually become more equal.)

And yes, I have used applications like Google Docs and Spreadsheets. It is very handy being able to share documents on the fly, track revisions, simultaneously edit them (without some insane check-out/check-in system), access documents from anywhere I have a browser, and discuss documents live--from right there inside the document--with other people. It's not as feature-rich or user-friendly as mainstream non-web apps... Yet. But when it does catch up further, yes, I do indeed want it to be a web app.

Re:Gecko is not outdated or bloated.

[SanityInAnarchy]

And with threaded tabs, it kicks Firefox's ass up and down the street.

Firefox, maybe... Safari, maybe...

Interesting fact: Konqueror seems to be using a separate process for each window. Not necessarily for each tab, but absolutely for each window.

Worth mentioning: They aren't threads (in Chrome), they're processes. And they aren't foolproof -- on release, it was trivially possible to crash the entire Chrome browser. Say what you will, but Firefox and Safari are reasonably robust -- I've no doubt that Chrome will surpass them, but it hasn't happened yet.

Porn

[maop]

All I know is that Chrome is ridiculously slow with porn. Since Chrome was developed in a corporate environment it is no surprise that it can't run porn sites well.

one process per tab...OH MY!

[recharged95]

Please, please, please, stop with this one process per tab madness... It's almost been a week since Chrome has been out.

we made the comparisons, lets just move on...

Re:Why did Google Choose webkit!

[supernova_hq]

!(there.equals(their) || there.equals(they're) || their.equals(they're))

Monoculture can be good.

[Actually, I do RTFA]

Besides, when was a monoculture ever a good thing?

APIs, document formats, various networking protocols, pedal placements in cars, Ctrl+O => Opening a document, I could go on and on.

Re:Monoculture can be good.

[Just Some Guy]

Those are standards. Standard are good. A diverse set of products obeying the standards so that they can interoperate is even better.

Re:Monoculture can be good.

[Actually, I do RTFA]

Those are standards. Standard are good. A diverse set of products obeying the standards so that they can interoperate is even better.

What's the difference between a standard and a product? It seems like "standards" are just "products" where a monoculture is good. The rhetoric then works that monoculture is bad for products and good for standards, but that's circular based on how the two were categorized.

For instance, is the Gecko engine a standard? There are things outside the w3c standard for how a website should render that it does, as those standards are not exhaustive. Whay isn't using Gecko for rendering considered a standard?

think of it...

[speedtux]

as evolution in action. Only if we have multiple rendering engines do people have a choice, and only as long as there are multiple implementations does it make sense to speak of a standard (Sun: take notice). This is good for everybody.

Re:Firefox never crashed on me either

[Jarjarthejedi]

1. You're using acrobat? Well there's one of your problems, get something faster like Foxit or something. Don't blame FF for acrobat's problems.

2. I don't have any experience with slow javascript, mainly because I use noscript and only allow javascript on sites I trust.

Add both of these together and you get a browser that never crashes and only locks up when loading RSS feeds (which is acceptable since two of the RSS feeds are poorly designed by the site owners (pass all 500+ articles to the reader to check rather than just the most recent 50 or so) and I have 100+ feeds).

Here's my outlook on this issue. If you have enough problems with websites that you get lockups and crashes regularly, then go ahead and swap to Chrome. As for me, I don't really want that kind of a feature. It feels too much like planning for failure. If you build a browser around easy crash recovery, then you'll have little incentive to fix the problems that are causing crashes. Already I've had Chrome crash on me twice, and while I accept it's a beta product (what of Google's isn't?) I'd rather stick with my tried and true FF than settle for being able to easily recover from crashes. Better to never crash at all than to be able to recover quickly from a crash IMHO.

It's kind of ironic really...

[msimm]

Isn't Firefox (particularly after 3) one of the more efficient of today's applications? They improve the memory footprint, begin to seriously improve dom/javascript performance all without sacrificing today's best features; only to be called bloated and inefficient.

Re:It's kind of ironic really...

[init100]

only to be called bloated and inefficient.

Yesterday it was the Opera fanboys, today it's the Google Chrome fanboys. There is nothing new here.

Myself, I prefer Firefox, but I don't sneer at Presto- or Webkit-based browser users. The only users that I really hold in low regard are the Internet Explorer users, because it's their "I don't care" attitude that holds back the web and forces web developers to support ancient browsers such as IE6.

Design matters

[tjstork]

1. Threads are Hard
2. Threads are not magic bullets
3. Threads introduce WHOLE NEW CLASSES of bugs

Threading is only as hard as a bad design makes them. If you have to share data among threads so much that you have to put locks all over the place, that's really a tell-tale sign that the design isn't all that good to begin with. Really, the best threaded designs are almost like lightweight processes to begin with. Keep the number of points where data must be shared across execution chains low, and everything tends to fall into place.

Because what every parent wants...

[Bootarn]

...is for their children to succeed.

That, and don't fix what's not broken.

Are processes really that much heavier?

[tjstork]

The downside is that processes are a lot heavier than threads.

How much heavier are they? Off the top of my head, the big internal advantage of threads is that they share the same page tables whereas separate processes have their own... but, each thread is still going to have its own stack and its own state block for when its task gets switched out.

Correct my own stone age knowledge of the Linux kernel, but, aren't threads and processes practically the same thing internally anyway?

Re:Are processes really that much heavier?

[et764]

I believe the cost is mostly in memory. I'm going from something I heard somewhere right now, so take it with a grain of salt, but I seem to remember hearing that at least on Windows, the data structures to keep track of a process are on the order of 2-3 megs. A thread, on the other hand, I would guess takes well under 100KB. The stacks may be larger, but I'd expect they start out as demand zero pages, so they don't actually count yet. Two to three megs seems high to me, but I guess it's not totally inconceivable.

Re:Are processes really that much heavier?

[k8to]

Threads share a virtual memory setup, so in theory you don't have so many misses in your TLBs and L1 caches when switching threads, as compared to processes. Ie. it's not how much resources they consume, it's how much slowdown you incur when changing contexts.

My understanding is that over the last X years (where X is about 10) the cost of changing instruction streams of any sort has grown relative to the savings permitted by threads, thereby reducing the overall rationale to choose threads over processes. Meanwhile, forked copies of the same process which are designed to work together will *probably* have roughly the same amount of private data as threads in a single app would have, especially as the size of apps overall grows.

Re:Are processes really that much heavier?

[Your.Master]

You also have to deal with more complicated synchronization and cross-process interaction between the tabs and the process that hosts the tabs (god help us all if the tab processes try to cooperatively work the common UI elements like the tab row or the little Google logo where the titlebar should be -- that would drastically increase interaction). There's probably no real reason for any two tabs to directly communicate with the possible exception of launching a new tab from a link on the old tab.

Besides which, not every system has threads and processes implemented so similarly -- not even every *Nix. Chrome and IE8 both live on Windows, where threads are slightly cheaper than Linux but processes are significantly heavier.

Re:Are processes really that much heavier?

[kigrwik]

AFAIK threads and processes are almost as cheap under Linux. However, under Windows, a process is much much heavier and costly to create than a thread.

Re:Are processes really that much heavier?

[gbjbaanb]

its more OS overhead - a thread has its own stack BTW, so it can use a lot more than 100k.

But, what a thread doesn't have to deal with is the interaction with the OS - security permissions, allocating the heap, shared dll loading etc. Multiple threads in a process get to reuse these resources that the process had to create or deal with.

This is why Windows is traditionally worse at multi-process systems and unit is better: the cost of starting a process on Windows is high, whereas the cost of the same on unix is lower. In both systems, the cost of starting a thread inside a process is quite low however. (but not so low that you can create them all over the place: best to stick to pooling designs).

Once started, the OS only executes threads - all processes can be thought of as 'process overhead' + 1 thread.

The big problem with running threads is that you have to handle synchronisation yourself, with processes the OS does it for you, so a poor thread design can be worse performer than a multiple process model.

Re:Are processes really that much heavier?

[tjstork]

But, what a thread doesn't have to deal with is the interaction with the OS - security permissions, allocating the heap, shared dll loading etc. Multiple threads in a process get to reuse these resources that the process had to create or deal with.

Under Windows though, a thread can have its own security context. Impersonation is per thread, not process.

Re:Are processes really that much heavier?

[gbjbaanb]

true, but most people pass NULL to beginthread() as getting a security context is quite hard, and slow :)

Re:Are processes really that much heavier?

[tjstork]

LogonUser a challenge then? :-)

Depends on the market.

[tjstork]

Your post is a perfect example of why designers constantly need to be kept in check. Looking really good is an admirable aim but is not an "excellent reason" to harm functionality.

It really depends on the market you are trying to reach. Beauty is valuable and it has a price and a market. For some sites, such as financial services, cosmetics take a back seat to functionality. However, for other sites, where you are trying to create an experience for the use, or to do some sort of an ad campaign, then cosmetics and designers come first and foremost.

Now, your citation of cars is interesting because cosmetics matter a great deal in the segment. No matter how feature rich or well engineered a car is, people aren't going to buy it if it looks like crap. The car -must- look good, and, quite often, looks add a considerable premium to the price of the vehicle. I guarantee that the per vehicle margin on a Bentley is a lot higher than that of the Ford Taurus. Or, to put it another way .. you might be paying 10x as much for the Bentley as the Ford, but that Bentley doesn't drive 10x faster or 10x farther on the same tank of gas. Instead, people with that kind of money buy a Bentley because it looks -good- AND it happens to go faster than a Ford.. but the looks and the design of the thing matters first and foremost.

not as bad as it was

[Eil]

I'm happy to see WebKit being implemented in more browsers. For a long time, it was considered one of the hardest tasks in computing to make a good, solid, standards-compliant HTML rendering engine but when KDE 3.0 came out, the KDE folks seemed to have pulled theirs out of nowhere. It was fast, it rendered things properly, and it was good. Until Apple adopted it and renamed it to WebKit, I was always a little saddened that it never saw wide usage. I'm glad that's changing.

Gecko made huge a leap forward performance-wise with Firefox 3, however. This meant that Firefox finally wasn't sluggish on mediocre hardware. But it still doesn't quite match the speed of WebKit-based browsers.

The Maemo browser, MicroB (which runs on the Nokia N800 and N810) is based on the Firefox 3 version of Gecko and while it's usable, it's actually pretty painful to use for prolonged periods on such limited hardware. They're reportedly working on a WebKit engine which should speed things up dramatically. What I'd really like to see is the Maemo GUI completely rewritten in Qt. Probably won't happen on the N800 and N810, but now that Nokia owns Trolltech, it's a possibility for their next iteration of web tablets.

Coke and Pepsi, duh

[gig]

Obviously, WebKit and Gecko are the Coke and Pepsi of browser engines. If you create Web content to the (large) subset of standards that are supported by both WebKit and Gecko then you have universally readable content, the work you do is not linked to any one software application or organization, like Flash development is. So you can make documents throughout 2008 and stamp them "HTML+CSS+JS" and 20 years from now reading those documents doesn't have to involve WebKit or Gecko or Mozilla or Apple or Google. If Gecko went away we would all be WebKit developers instead of Web developers.

Google Chrome does not suggest to me that Firefox should stop using Gecko, it suggests that Microsoft should stop using MSHTML. Google went to great pains to invent new stuff for Chrome (new UI conventions, sandboxing, the JavaScript compiler, Gears, Chromebot testing) yet they specifically chose not to create yet another renderer. Instead they chose the most-suitable open source one and improved it. If Microsoft put WebKit or Gecko into Internet Explorer they could spend all their development time on things that are specific to Windows, and Internet Explorer would be 100 times better. But of course we know that Internet Explorer is just pissing in the pool, that is its purpose, that is the result.

Which Gecko?

[Chris Snook]

I have an old 12" powerbook with 384 MB of RAM. It started gathering dust when I got a much larger laptop for work, since modern ajax-and-flash-heavy websites were really crawling with so little memory, and that's using both Firefox 2 and Safari. When Firefox 3 came out, I heard how much lighter it was, so I gave it a try. Lo and behold, my old laptop had new life! Safari still feels a little snappier when I only have one tab open, but that's a fleetingly rare condition. Gecko isn't just the technology we have right now, it's the vibrant developer community hard at work making it better. WebKit has less ambitious aims, and achieves them well, but Mozilla would be throwing the baby out with the bathwater if they told everyone to forget Gecko and learn how to do that same optimization work on WebKit.

What an odd summary

[SmallFurryCreature]

The slashdot article is tagged as troll and flamebait, while the ars article is nothing like that, it simply explains that for Mozilla, Gecko is the right choice because it does a lot more then WebKit does AND has been overhauled recently to such a point that it now does MORE with LESS.

The person who submitted the article either made a mistake by thinking that slashdot readers could read the summary as being a question that was going to be answered when they RTFA OR, more likely, didn't RTFA himself and thought the ars article was going to come to a different conclusion.

To make it bloody clear, the article itself concludes that Mozilla uses Gecko because it needs it, Gecko has been improving rapidly to the point that its biggest weaknesses are now gone and WebKit itself would have to be hacked to bits if it was to be used by Mozilla for its projects.

Thread INTERACTIONS are hard

[SuperKendall]

Haven't done much multi-threaded programming, have you?

Say, one thread locks a mutex and hangs.

Whoops! Now all the other threads that want that mutex will wait forever!

I kind of agree with you, but...

The whole point was that generally, these separate tabs will have very little need to interact. Your example of a global mutex brings up the question, of why you would have them all after a global mutex anyway instead of pretty much keeping to themselves.

Obviously something like a memory error or a few other things can bring the whole thing down by bringing down the main process all the threads are a part of. But contention as you raise the issue seems to be less likely than it would be in other kinds of multi-threaded apps where the threads have to communicate or otherwise work in unison with other threads, or at least more manageable and confined to already centralized things like browser settings.

Re:Thread INTERACTIONS are hard

[multipartmixed]

> The whole point was that generally, these separate tabs will have very little need to interact.

I'm not really familiar with browser internals, but I'm guessing that there must be at least some points of common interaction
  - document cache
  - nameservice cache
  - connection sharing (?)
  - configuration
  - font resources
  - system libs (e.g. image rendering)
  - cross-frame/cross-window.open javascript
  - GUI container rendering

My post was really a counter example, though. The OP suggest that just slapping each tab into a separate thread would somehow magically make the browser more stable by allowing threads to hang or crash separately.

Other posters have made the point that appropriate design fixes many of these issues -- but design is hard to bolt on after ten years of development. Especially when innocuous things like this can mess you up:

static struct { int i, int j } a;
 
threadOne()
{
  a.i++;
}
 
threadTwo()
{
  a.j++;
}
 
spawn(threadOne);
spawn(threadTwo);
waitForBothToJoin():
 
printf("%i %i\n", a.i, a.j);

On SOME memory architectures, in multi-CPU configurations, the output could be "0 1" or "1 0", even though you'd expect "1 1" -- think how a.i and a.j are incremented, some arches will read double-ints out of the struct and put 'em back as double ints.

Now, obviously, this is a contrived example, but it's a great one for showing that MT design really does need significant forethought.

(And I _did_ preview. But whoever wrote the new CSS for the ecode tag is clearly a numpty)

Design really matters

[TheLink]

Maybe you're a really good coder and can handle all the issues related to threading.

However the browser you write won't just be running your own code. It will be running code written by Adobe, Facebook 3rd party apps, and so on.

Given that, it's wiser to design your browser to use processes, so if you or somebody else screws up, the offending tab can be killed without affecting the other tabs, and also the memory used gets freed up (this is quite important given the large amounts of memory a tab can use nowadays).

You could in theory have your browser threaded, but use processes for the plugins, javascript and future junk^H^H^H^Hfeatures the W3C comes up with, but at that point how much do you really gain?

Why do you think Microsoft sees Google as the enemy? They are right. Google have just launched a new "operating system".

It's wise for Google's "operating system" aka browser to have process isolation, so that it is harder for one misbehaving instance to take down the rest.

Cooperative multitasking is so 1980s.

Re:Design really matters

[tjstork]

Given that, it's wiser to design your browser to use processes, so if you or somebody else screws up

Well, I -would- use processes in the case of the browser. The other reason to is that a process enforces a security context much more rigidly than a thread. So I can have tabs running as different roles.

Re:Lies

[jjohnson]

If you'd RTFA, you'd know that the same conclusion was reached in by the Ars Technica writer. It's the summary that balls.

Re:XPCOMGC?

[jjohnson]

"True" garbage collection is an improvement over the simple, reference counted GC they were doing prior to FF3. GC now has many more advanced techniques than reference counting.

Gecko is required for Firefox and its extensions

[mr3038]

Firefox and all of its extension use JavaScript and XUL. Gecko implements JavaScript and XUL (in addition to XSLT, XML, XHTML, HTML etc.). Webkit implements (X)HTML renderer and a JavaScript engine. If you decide that Firefox has any value (and I think it has) plus if you want to use any its extensions (I use a lot), then you have no choice but to use Gecko.

Of course, if Webkit is first extended to support XUL and Firefox's extension mechanism - just go for it. That way you could use pretty much all the Firefox extensions in Safari, Chrome and friends. Then we could ask Firefox to dump Gecko if we still think so. I wouldn't expect that to happen too fast...

Back to the point...

[BrokenHalo]

I learned a while ago that Firefox has lots of zealots in the moderator ranks.

I must not feed the trolls.
I must not feed the trolls...

But damn it, that's nonsense. The moderators change from one day to the next, and meta-moderation works reasonably well at keeping things fair.

But a browser is only a browser, and flaming one or the other accomplishes nothing. I can even work with IE if I have to (though I don't have to like it).

But in any case, just because a new kid is on the block in the form of Chrome, it does not necessarily follow that Firefox suddenly sucks. With the latter, we are free to add as many extensions as we need (though I only use adblock and flashblock), and I guess that to some extent defines how big a footprint it is going to make.

Much has been made of breaking up tabs into separate processes to make things safer, which on the face of it is not a bad idea in itself.

However, I would ask how often you manage to crash Firefox. I have been using it since it was still Mozilla, and I struggle to remember ANY occasions when it has crashed. OK, yes, it has happened, but very very rarely.

But getting back to the point, I wonder if anyone here can get back to the point and enlighten us as to why (or whether) Firefox should embrace webkit?

Re:Back to the point...

[StrategicIrony]

But getting back to the point, I wonder if anyone here can get back to the point and enlighten us as to why (or whether) Firefox should embrace webkit?

It shouldn't.

There, done. :-)

Re:Back to the point...

[bigstrat2003]

The moderators change from one day to the next, and meta-moderation works reasonably well at keeping things fair.

In theory, yes. In practice, I've been modded down left and right, on more than one occasion, just for saying something critical of Firefox.

it does not necessarily follow that Firefox suddenly sucks.

I never said Firefox sucked, I merely said that its lack of breaking up tabs into separate processes was unacceptable. I stand behind this statement, and it does not in any way impugn the rest of the browser.

I must not feed the trolls.

Not trolling, merely frustrated that when I express a viewpoint that is unpopular, my karma has to suffer for it (and indeed it has, because, solely due to yesterday's postings, my karma has gone from capped to "positive". The only one of my posts that was worth down-modding at all was the one you responded to, the rest was perfectly allowable discussion... but I got penalized for it. Bleah.). If I were trolling, I wouldn't very well bother responding to my critics, now would I? I'd just throw something juicy out there to stir people up, and be done with it.

You got it backwards

[alien_life_form]

Actually, the article argues that Gecko is worth keeping exactly because it is no longer bloated and outdated. But to know that, one has to read the second page of the article. Cheers, alf

Re:Gecko is not outdated or bloated.

[onlyconnect]

IE8 has a new rendering engine. Trident is also included for the compatibility mode. Tim

Re:Gecko is not outdated or bloated.

[Sweetshark]

"Actually, that is far and away the best reason to not mess with it. The user experience is paramount, and when you mess with that, you have failed."
Here is news for you: Every use of a browser has two users - one providing the content, one recieving it. MSIE has constantly failed the first half until IE8.

Here's why:

[getuid()]

Why? I spend more time in the web browser--by far--than any other application.

I don't.

I guess you missed the second page ;)

[twilek]

I guess you missed the second page in the article http://arstechnica.com/articles/paedia/mozilla-committed-to-gecko.ars/2 where they explain why Gecko is worth keeping and where they also explain that it isn't as outdated and bloated as it felt before FireFox 3 ;)

Wait wait...

[xouumalperxe]

Chrome is all new and bright and shiny, Firefox has some (plenty?) memory leaks, and all of a sudden we go from comparing browsers to making sweeping statements over their respective rendering engines? Why?

How is a rendering engine that scores 85% on ACID3 "outdated"? Why should Mozilla drop a codebase that is quite successful in the marketplace, and that they know intimately and have full control over in favour of one they don't know all that well and is controlled by Apple, just because it's (arguably) king of the hill right now?

Frankly, the summary is a troll -- and the article feels like little more than a jab at free clicks.

Re:Wait wait...

[Shados]

I agree. In the marketplace, a well known engine is more important than a "bleeding edge" one, no matter how much better it is. Thats why IE's engine is still so big, and why Gecko is the only one that will make a dent in the short term. If it wasn't for the iphone rabid fanboys, WebKit (which I personally prefer, mind you) wouldn't even be on the radar.

Did the submitter even read TFA?

[Durkheim]

Seriously, they answer your question in the article, wich makes your submission completely irrelevant.

Chrome innovations?

[notrandomly]

I have been using Chrome on my work PC and find many of its features compelling, and wonder how soon we will see its best innovations in Firefox.

Could someone name some of these innovations?

One process per tab? IE8 did that before Chrome.

V8? Both Apple and Mozilla did those things before Chrome was announced.

Showing your favourite sites when opening a new tab? That's Opera's Speed Dial, except automatic and potentially constantly shuffling around, working against muscle memory.

Creating "standalone" applications from web pages? Mozilla and Apple were already doing that.

Incognito mode? IE8 again.

So what are these innovations?

Re:Chrome innovations?

[shutdown -p now]

So what are these innovations?

Having them all in a single application.

Re:Chrome innovations?

[notrandomly]

That's not innovation. Taking features from other browsers is the way you would go about creating a new browser. It happens automatically. There's no innovation involved.

Re:Chrome innovations?

[shutdown -p now]

You're right that it's not true innovation, but I would dispute that it "happens automatically". If it did, every browser would be virtually the same now, as every new version released would absorb all new features from the other browsers. Still, it does not happen. Chrome is the first with this particular feature combo, and judging by how well it's doing already, despite the beta status, they've hit the sweet spot (I know they're very close to it for me personally).

Re:Chrome innovations?

[notrandomly]

You're right that it's not true innovation, but I would dispute that it "happens automatically". If it did, every browser would be virtually the same now, as every new version released would absorb all new features from the other browsers.

They would not absorb all new features, but they do borrow features from each other. But in addition to new features, you have an "identity" to take care of. The browser has a history. That makes it very hard to turn things upside down. However, Chrome has no history, and was free to simply do everything anew.

Firefox did something similar. Popup blocking, tabs, search field, etc. All those features already existed in browsers.

So the problem is C/C++ actually.

[master_p]

Because in other programming languages, NULL pointers can be caught as exceptions, and the thread can be gracefully terminated.

Re:So the problem is C/C++ actually.

[shutdown -p now]

Guess what, you can have trapping smart pointers in C++, too. Or just ask the compiler to insert the checks. Or trap SIGSEGV (or the corresponding SE in Win32).

Re:So the problem is C/C++ actually.

[master_p]

Indeed, but an erroneous C/C++ plugin can cause havoc in other threads as well, but in other languages it is not possible to do so.

Chrome

[ypctx]

Wake me up when Chrome supports web development as Firefox does (via Firebug).
Altough everything considered, it shouldn't be too long before that.

Re:Gecko is not outdated or bloated.

[ypctx]

Actually, that is far and away the best reason to not mess with it.

No it's not - at least not for Microsoft. They could just code a new engine from scratch and provide this engine in a separate "mode", keeping the old one to support old webpages.

lack of diversity

[chrisboredwithlogins]

there seems to be what 4 render engines, all the more reason to be using gecko! The more different *standards* compliant engines there are the less chance one (*cough* m$) will have of steering the "standard" their way...

Bloated, sure, but outdated?

[Millennium]

Gecko is bloated. No one disputes this anymore, even within Mozilla. That is being worked on.

But outdated? I don't think so, or at least, it doesn't need to be. Fixing that is a matter of getting priorities back on track: standards support must be Job 1 again, and that means not just the specs but the test suites based on them.

The future of standards support is not in what specs you implement: it's in what tests you pass. Once the Gecko team wakes up and sees this, as its competitors have, then I believe we'll see it become competitive again.

Re:Why use GEICO (advertisement)

[Kevin72594]

Yeah, but there online Quote system sucks...:(

Firefox is Gecko's biggest problem.

[argent]

XUL is one reason I've switched from Firefox to Camino on the Mac, and why I wish I had the alternative of a decent Gecko-based browser with native UI on Windows.

I used to think Firefox extensions were great, but once I got to the point that I was turning most of the extensions *off* to make Firefox stable again, I changed my mind.

Re:Firefox is Gecko's biggest problem.

[Millennium]

It sounds to me like what you want is K-Meleon. But why not accept that the Web is not a native app, and neither needs nor should have native widgets?

Re:Firefox is Gecko's biggest problem.

[argent]

I've looked at K-Meleon, but it had a ways to go before I'd call it "a decent browser".

But why not accept that the Web is not a native app, and neither needs nor should have native widgets?

I'm not talking about the web user interface (the HTML document itself) at all, though I do admit that having standard widgets inside the HTML frame that supported most of the features of native widgets (such as services and contextual menus on the Mac) was an early advantage of Camino for me... on Windows that's less of an issue since Firefox has always mimicked the behavior of Windows controls best. No, I'm talking about the application user interface outside the HTML document (navigation bar, shortcut bar, tabs, status bar, etc...). Having the application interface itself implemented in HTML, XML, and Javascript means that it's far more complex, less reliable, and less secure.

This is not a theoretical objection, either. This is a matter of hard experience with Firefox on both Windows and the Mac, and actual vulnerabilities exposed in interfaces like XPI.

Re:Here's why:

[Moridineas]

What application do you use more than any other?

Terminal.app would be close for me, but I think the web browser wins overall.

WebK.I.T.T.

[pragma_x]

Michael, I can only use my popup blocker once per episode...

Re:Gecko is not outdated or bloated.

[jlobello]

Go read the IE blog. Trident is dead. MS wrote a new rendering engine for IE8.

Chrome vs. Firefox

[DragonWriter]

I have been using Chrome on my work PC and find many of its features compelling, and wonder how soon we will see its best innovations in Firefox. Why is Gecko worth keeping if it is outdated and bloated?

Chrome's innovations are mostly in the JavaScript engine and the process-per-tab architecture, neither of which have much to do with the rendering engine: Gecko v. WebKit is mostly a peripheral issue.

The new JavaScript engine

[veliath]

Shouldn't the real-question be whether FF should move to the new JS engine or not, right? Thats where much of the speed-up that Chrome is seeing seems to be from...

veliath

Re:Why use GEICO (advertisement)

[default luser]

Yeah, when I tried their online quote tool, I omitted my current premium with Progressive. Not surprisingly, I got a quote significantly higher than my Progressive rate. Then I did it again, but filled in my current premium, and got a quote back that was five dollars less than my Progressive rate.

Saddest thing is, even when they KNEW how much I was paying, they didn't even bother to try and beat my Progressive rates by %15. Talk about false advertising.

Re:Gecko is not outdated or bloated.

[FishWithAHammer]

Dunno about you, but I get random 2- to 5-second freezes in Firefox, and it crashes once a day or so on JavaScript.

Safari, I don't know, I won't pay extra to make my computer a style accessory.

Re:Here's why:

[Nutria]

What application do you use more than any other?

Terminal.app would be close for me, but I think the web browser wins overall.

I despise Gmail, and what it's done to formerly-intelligent bottom posters. Outlook for work email, and Tbird for home email. (But since all my email is accessed via IMAP, it doesn't really matter which MUA I use.)

ssh, a lot, because at work I all my computing is on remote hosts.

OOo to read/write documents, because my boss would go apeshit if I tossed confidential documents up onto the internet.

Nethack, Iango & PySol when I want to play games.

And, finally, FF3, which is up pretty much all the time.

Re:Gecko is not outdated or bloated.

[SanityInAnarchy]

Safari, I don't know, I won't pay extra to make my computer a style accessory.

I assume you're talking about buying a Mac.

Given that you're running Chrome, I assume you're on Windows. Safari does have a Windows port.

Sure, it's not the best Windows port. And sure, if you were going to criticize it, the default response would be "It's better on a Mac." But it does exist, and it does work, and I imagine it's pretty solid.

Re:Why use GEICO (advertisement)

[jp10558]

Hmmm, well, they don't let you choose online the coverage you need really, so they ended up being $500 more a year than I'm paying Geico. I really haven't seen any lower quotes, the only one close was Progressive... I get lots of ads saying they can save me $300 over geico, but I'm only paying ~ $800 a year... how low can they realistically go?

Re:Why use GEICO (advertisement)

[jp10558]

Interestingly, my rates have been going down a little every renwal I don't make a claim / have an accident... I've only been with them for 1.5 years though.

Battery-powered devices

[tepples]

CPU clock speeds are going up, and memory prices are going down, but a web browser should still be a relatively lightweight application by itself.

Why?

So that it can run efficiently on battery-powered devices, such as subnotebooks and handhelds.

Re:Battery-powered devices

[Moridineas]

Utterly irrelevant. Should screen resolution be limited to 320x240 so that subnotebooks and handhelds can run at the same resolution? Should games be forced to limit ther polgygons to something that can run on subnotebooks and handhelds? No, absolutely no. People don't use Firefox on their iPhones, and they don't use the Treo browser on their desktops. As it should be.

Why a single code base should scale

[tepples]

Should screen resolution be limited to 320x240 so that subnotebooks and handhelds can run at the same resolution?

No. Web pages should scale, and that's what CSS @media rules are designed for. But unfortunately, the entire HTML gets sent to the device no matter what @media it uses.

Should games be forced to limit ther polgygons to something that can run on subnotebooks and handhelds?

If the developers don't design their product to scale down to handhelds, then owners of handhelds will buy the competitor's product that does scale down to handhelds. A lot of early PSP games earned poor reviews for their long loading times because the PS2 assets weren't scaled down properly.

People don't use Firefox on their iPhones

Only because of Apple's lockout chip. They use Safari, which is equally heavy for a reason: If we have completely separate code bases for the mobile and desktop browsers, eventually the two code bases will develop "quirks" (incompatible interpretations of a spec), or features will end up missing entirely from the mobile version. This has already happened with Windows Internet Explorer and Pocket Internet Explorer.

and they don't use the Treo browser on their desktops.

How should a small web developer test his web site against the quirks of PDA browsers without owning all makes and models of PDAs?

Re:Why a single code base should scale

[Moridineas]

No. Web pages should scale, and that's what CSS @media rules [w3.org] are designed for. But unfortunately, the entire HTML gets sent to the device no matter what @media it uses.

Utterly irrelevant to the matter at hand. You replied to me asking why a browser "should still be a relatively lightweight application by itself." What relevance does what you've just said had to that? In fact it seems to me that you're arguing for further browser complexity, support of multiple presentation modes, etc.

They use Safari, which is equally heavy for a reason

Ok, now wait, I thought you were arguing about why modern browsers were bad...yet here is a clear example of the same codebase (Webkit) running fine on both handheld and desktop. Does that defeat your argument?

How should a small web developer test his web site against the quirks of PDA browsers without owning all makes and models of PDAs?

Ok, somewhat pedantic as you're clearly right--even the iPhone has a desktop emulator. However, your statement does not stand for users.

Re:Why a single code base should scale

[tepples]

Ok, now wait, I thought you were arguing about why modern browsers were bad

You appear to have confused my arguments with those of lysergic_acid. I argued that developers should make apps that scale; lysergic_acid lamented that they have chosen not to. There's a subtle difference.

yet here is a clear example of the same codebase (Webkit) running fine on both handheld and desktop. Does that defeat your argument?

Webkit scales. Some other software, be it a shell around Webkit or a completely different browser entirely, may not.

How should a small web developer test his web site against the quirks of PDA browsers

However, your statement does not stand for users.

Since Web 2.0, every web user is a potential web developer. For instance, if you're customizing your blog, you don't want changes to the template to fsck things up.

Re:Here's why:

[getuid()]

Short answer: xterm :-)

Long answer: when reading mail, for example, I use... uhm... a mail reader (mutt), for writing texts I use a text editor (emacs), for photo editting I use a... aehm... photo editor? For spread sheets... well, take a wild guess :-)

But joking aside, of *course* I use a browser. And I do use it extensively -- man, it's the 3rd millenium, of *course* I'm on line and all hip n'stuff and I use a browser quite a lot (like all cool kids). But I don't use a browser exclusively, and I don't see a reason for a browser to use up most of my ressources if I can get stuff done with less ressources, too, without converting an browser into an operating system. Running applications is what kernels are for, and mine works just fine, thank you very much! I mean... what's the point in having an OS kernel scheduling multiple processes, of which some are a browser scheduling multiple tabs, of which one is another (java?) kernel-like construction scheduling multiple applications, of which one part is a full-blown office package, of which's sub-parts one is able to do text editting?

What's *that* wrong about a conventional text editor, that it needs to be fixed by embedding it into a browser?

Re:Here's why:

[Moridineas]

I said I used a browser more than any other application. You then said you didn't. Now you're saying maybe you do? (or xterm wins) :p

Honestly, I'm not really sure where we are disagreeing anymore. You even mention a kernel scheduling multiple tabs (presumably via threads or processes), etc. I don't disagree. I'm arguing with the original statement that the browser SHOULD be a light-weight application. The browser is what a browser is, and as the web gets richer, browsers get bigger. As people do more and more activities in their browser, it's only natural that the browser becomes a more rich development platform and user interface.

In answer to your question, there's absolutely nothing wrong with a conventional text editor. I use vi myself..