Examining Chrome's Source Code 288
An anonymous reader writes "Chrome is open source, and there's clearly still some work to be done on it. In this article, Neil McAllister decided to take a peek under Chrome's hood and view it through the eyes of the developers who will improve and maintain it in the coming years. It seems Google's open source browser currently has much to offer prospective hackers — provided they use Windows. Quoting: 'The Chromium site explains how to download the source code for Linux, Mac OS X, or Windows. Unfortunately, if you're eagerly awaiting a Mac version of Chrome, you shouldn't hold your breath. As the Mac OS X area of the Chromium developer site explains, "Right now, the Mac build is a work in progress that is much closer to the start than the finish." In fact, according to the latest status report, the Chrome developers have yet to get even the browser core running under Mac OS X. Rendering actual Web pages is still a long way off, to say nothing of a usable Aqua GUI. Then again, the Linux version is in arguably even worse shape.'"
What I don't get... (Score:5, Interesting)
So they want to develop a cross-platform browser.
Why exactly is it then tied that tightly to a platform that porting it over to other platforms seems to basically mean starting all over again? After all, it's not like all 3 platforms would be completely alien in the backend -- they are POSIX compliant. Then the GUI: it's not like there aren't any cross-platform widget sets out there. But even if you want to go for individual approaches for each platform, then you still can separate functionality from the GUI.
So why again is the Mac port "closer to start than finish" (especially when reminding that Chrome is based on Webkit) and the Linux port "even worse"?
It's going to have maintainability problems. (Score:2, Interesting)
Chrome is a combination of numerous libraries and source code, from sources as diverse as Google, Microsoft, the KDE project and Apple. While this allowed them to initially put together the browser relatively rapidly, there is a lack of cohesion. This will surely lead to maintenance issues later on down the road, due to the hacks necessary to get everything to mesh.
There are enough maintainability issues with, for example, the Mozilla codebase, where they wrote most of the code themselves. It'll be far worse for Chrome.
Re:It's not over for Mozilla after all (Score:5, Interesting)
They still have a near monopoly on the entire Linux desktop market!
Truth is, I don't really care if Chrome runs under Linux or not. What _is_ important is that there is a lot of buzz about a non-IE browser out there, and that will help Linux users no matter which browser they use. Chrome will get the attention of at least some PHBs and Frontpa^w webdevs who code IE-only websites. I have been complaining about this for years [dotancohen.com] but now there finally is a product that they will have a hard time ignoring. Firefox was close, but was only talked about by gearheads. Even my mother-in-law asked me about Chrome. Which is too bad, as she's on Ubuntu and feels left out...
pffff (Score:2, Interesting)
Re:Does it really matter? (Score:1, Interesting)
the point is that since webkit was written for and compiles on mac, what've they done to break it?
Tracemonkey vs. V8 (Score:5, Interesting)
Chrome is currently faster than Firefox at most things even when Tracemonkey is enabled. I mostly work with browser based math/finance apps, and one of the most intensive things that can be done is a numerical integral. No other browser even comes close to Chrome in terms of speed. The only drawback is that it isn't cross platform yet. From what I hear, Tracemonkey is working really well on different processors so it will be an interesting match up. Try pasting this code into JavaScript Shell [squarefree.com] from Chrome and Firefox for a comparison.
Re:the core not even running under mac? (Score:5, Interesting)
It uses webkit for layout, but it uses a (sort of) homegrown library for rendering:
http://gigaom.com/2008/09/02/google-open-sources-skia-graphics-engine/ [gigaom.com]
http://src.chromium.org/viewvc/chrome/trunk/src/skia/ [chromium.org]
Re:It's not over for Mozilla after all (Score:4, Interesting)
Unfortunatelly, Firefox wasn't close at all; it simply shifted the mindset in most places from "we support only IE" to "we support only IE and Firefox".
It was noticeable when you use something else, like Opera... (luckily not on sites originating in my area of the world, since Opera here has from 5 to 25 percent, depending on the country; and since Firefox has over 40% in most of them, aiming sites for duopoly doesn't work)
Seems like three major browsers is a minimum needed for them to start noticing _true_ interoperability...
the great irony (Score:3, Interesting)
The great irony of all of this is that Chrome (also Safari) directly owe the KDE and Qt projectÅ credit for constructing the base on which this is built. And now they are primarily targeting windows. When discussing either Safari or Chrome, I never ever even see mention of the F/OSS projectÅ to which they owe their existence. More than a pity, itÅ a crying shame. Do no evil my ass.
Re:What I don't get... (Score:2, Interesting)
Re:Sandbox (Score:3, Interesting)
That was a fun read.
I mean FireFox 3.0 was touted for its "security"....In reality that browser offers even less protection / mitigation against web exploits than IE7 on Vista...
and this
I for one don't run FireFox 3.0 . . . I don't consider it even a worthy challenger (though it sure is fast) to IE7 let alone IE8 (due to lack of protection / mitigation technologies, the vuln counts etc.),
Now, I'm no expert, I'm not saying he's wrong, but what I do know is that this goes against everything I've been hearing around here.
Re:It's going to have maintainability problems. (Score:5, Interesting)
And, yuck, they checked in a whole bunch of binaries. If you so a checkout of the Subversion repository (weighing in at 1.5G for the single revision checkout, 8G or so to build!) it is a huge mess. I don't think Chrome is going anywhere for a long time due to these maintainability problems you mentioned, and you won't find hackers poking around Chromium with the mess that the codebase is in. Plus, it's all tied very closely to Windows, and who wants to hack in the hacker-unfriendly Windows?
Once I saw this, I sort-of forgot all about Chrome/Chromium. It's all hype for now.
Re:It's not over for Mozilla after all (Score:5, Interesting)
And google is really happy with that. They don't need to target the linux market because Mozilla is already working for them here.
The target is obviously internet explorer.
I disagree for two reasons.
First, we can only presume Google wants Chrome to run on Android, Google's handset OS. Which is based on Linux. So clearly Google has a direct and powerful motivation to target Linux with Chrome. (In fact a much stronger motivation than to get Chrome running on OS X - I wouldn't be surprised to see the Android/Linux version out earlier.)
Second, one of the best ways to weaken IE is to weaken Windows - the less people running Windows, the less run IE. But if Chrome is Windows-only, that just strengthens Windows as the only platform able to run the 'best' browser ('best' at least in Google's eyes and those that like Chrome).
In other words, every IE convert to Chrome is still locked in to Windows. Whereas Google's long-term goal is to make the OS irrelevant so long as it can access Google's web services.
Re:It's going to have maintainability problems. (Score:2, Interesting)
Re:What I don't get... (Score:2, Interesting)
Re:What I don't get... (Score:4, Interesting)
mod-parent up. QT is the native toolkit for KDE.
IT isn't some artificial toolkit people only use for cross platform work, wxwindows or tk. It's a real native toolkit on Linux.
Heck, there's a windows port of KDE4.x in the works.
I mean come on...
Re:What I don't get... (Score:4, Interesting)
There can't be a grand unified HIG, but you're thinking about the problem backwards. Instead of trying to unify the HIGs, just have classes that abstract out the differences. For example, wxPython actually handles much of this already - the SizedControls library gives controls HIG-compliant borders and spacing on Win/Mac/GTK, while wxStdDialogButtonSizer (long name, I know ;-) will take your OK and Cancel button and make sure they appear in the right order on each platform. The platform-specific code is all built into the library - you don't need to deal with it yourself.
The reason most cross-platform apps don't follow HIGs too well is that rather than use a library like this, they hand-code spacing, positioning, etc., usually doing the whole thing on one platform first. So then when they decide to make it cross-platform, going through and making a huge preferences window, for example, follow HIGs is a massive task.
Re:It's not over for Mozilla after all (Score:5, Interesting)
Re:the core not even running under mac? (Score:5, Interesting)
Chrome naturally consists of many other components as well, such as the actual user interface, all the glue code to actually read and write files (like the cache), doing network connections, DNS lookups, checking SSL certificates, handling its famous sandbox processes, loading plugins and all sorts of other things.
Re:What I don't get... (Score:3, Interesting)
Not true. Qt4 is widely regarded as an excellent open source toolkit and does cross-platform very very well. And since they're using WebKit for the rendering engine (based on KTHML which was designed to work with Konqueror which was written with Qt to begin with), it would have been a snap to put the two together. I'm not a Qt fanboy or anything, but it boggles the mind why one wouldn't use Qt for any open source cross-platform development.
Re:What I don't get... (Score:3, Interesting)
TThis is somewhat odd though. The original NT Posix subsystem at the very least, was not an independent subsystem. It translated some calls into the NT kernel Native API, but for others, it translated them into Win32 System calls, leaving the POSIX subsytem dependent on the win32 susbsystem. I would find it hard to believe then that the programs could not directly call the Win32 API.
Of course, I have the feeling that
Interix (which is now the new windows NT Posix subsystem) has little or no real relation to the original NT 4 era POSIX subsytem. If it is a true independent subsystem, then I can definitely understand the difficulties of using a win32 API form them.
For what it is worth, cygwin 1.7 is propping support for non-NT versions of windows, which will allow it to use NT native API's in many places. This should notably improve performance, but it is a shame that the SUA subsystem is not good enough to eliminate the need for Cygwin.
Re:the core not even running under mac? (Score:4, Interesting)
Re:It's not over for Mozilla after all (Score:3, Interesting)
Less crashing, more fastyness.
The *real* benefit would be to have a button that reloads the page using the MSHTML engine, and then intelligently remembers that for next time, so that broken shitty sites would continue to work. It could be a sort of crowdsourced, 'everyone seems to prefer this in IE' kind of approach.
Some sort of automated compatibility would basically remove any reason to use IE over the faster, snappier, more stable Chrome.
Re:What I don't get... (Score:3, Interesting)
The point is:
1. KDE is a reference client for the QT toolkit. I consider it a very good reference. KDE is basically a really heavy work out with a lot of critical developers. If you make them happy, chances are your API is pretty solid.
2. That the toolkit is used in a lot of other contexts (Qtopia phone environment, for example)
3. QT has been cross-platform since the beginning. It actually pre-dates KDE. KDE was built because they saw this cute ('scuse the pun) API and decided to build the desktop environment around it.
Compare this to TK. No-one has ever built an entire windowing environment around it. It is thought of as a scripting tool. It does not get the heavy use and thorough work out in testing that a toolkit used natively by one of the porting environments uses.
Don't even get me started on wxwindows. That environment wants so desperately to be cross platform that it utterly sucks on all of them.
If your implication is that because a toolkit is very heavily used in one environment it therefore must be crap for the other environments is nonsense.
I have used/had to deal tk (in tcl and perl), as well wxwindows in smaller projects, and they frankly suck compared to QT from api elegance perspective.
Re:Not open source! (Score:3, Interesting)