I said that browsers are not all that large. Secondly, I didn't say that Safari is "not all that large".
So you see the actual source code for Webkit only comprises about 5% of the archive, and there's a bunch of testcases and support tools I missed removing there. Deleting the websites drops that ~100MB to ~80MB. Deleting most of the testcases drops that ~400MB to ~100MB. Deleting the Subversion directories alone drops the uncompressed size by a gig from ~1.4GB to ~400MB.
But even assuming 100Mġ65MB is a HUGE amount of source code for something that you claim has a 'much smaller and cleaner' design and is "not all that large".įirstly, that tarball is a SVN working copy and includes such things as Bugzilla and other Webkit-related websites/web applications, testcases, etc. Since I am on a slow connection right now, maybe someone can perform a more accurate analysis and post the results here.
I tried to download the latest snapshot of the WebKit source tree from the webkit site so that I could separate the resources(binary files, changelogs etc.) from the source code and get the size of it, but I was struck by a 265MB (yes you read it right) download. Since we don't have access to Opera's source code, lets look at khtml/webkit. No, browsers aren't actually all that large (the rendering engines for the Opera desktop browser and the mobile browser are the same), and you don't have to painstakingly discuss absolutely everything. When you invest in clean design up-front, the cost of efforts like this is vastly reduced. What you are seeing here are not crazy hacks, but the consequences of years of savvy architectural and management decisions. Opera have been focusing on the mobile market for a long time now, it's a core part of their business and a substantial portion of their revenue, so they've always kept the code small and manageable. And that choice has paid off in spades, the turnaround on new features and functionality is extremely quick. One of the reasons Apple chose KHTML instead of Gecko for Safari was that it was much smaller and had a cleaner design.
Internet Explorer has three very different rendering engines attempting to remain compatible with years-old intranet applications. Changing one thing can have knock-on effects all over the place. But that is because they are much smaller codebases. Extremely fast compared with Firefox and Internet Explorer. Yes, Safari and Opera are both moving fast. So this is actually just wild-ass speculation and not something you have solid reasons to believe? I think there is a very good chance of the code containing hacks and workarounds and also tons of security loopholes because of the insane speed at which features are being thrown into the code. Being a programmer, I am sure that non-trivial portions of the code will have to be rewritten later. I think there is a very good chance of the new code containing hacks and workarounds and also tons of security loopholes because of the insane speed at which 'features' are being thrown into the code just to make headlines. It's just that the high speed of the compatibility improvements for ACID3 in almost all the mainstream browsers screams of hackathon coding sessions to get those few points a day till 100 so that there can be a marketing and PR blitz rather than properly planned programming. So a browser can pass the test and still suck at implementing standards, though passing the test is good step.
Any developer worth his salt knows that browsers are huge and complex applications and every change must be discussed, designed and implemented properly as to not impact something else and be modular, be properly commented and be clean and well written code.Īlso, Acid3 is just about the corner cases, and might not reflect the full standard completely. The speed at which the browsers seem to be gaining acid3 compatibility is frankly worrying me. The problem with races is that the teams do almost anything just to cross the finish line faster.