Mozilla borrows from WebKit to build fast new JS engine | Hacker News Reader

Mozilla borrows from WebKit to build fast new JS engine

arstechnica.com

35 pointsalexandros26 comments

Stories like this makes me appreciate open source. Combine the best components for everyone's benefit.

Wish they could borrow ICC V4 colour rendering at the same time. It would be nice to have Firefox looking normal again.

I don't know anything about ICC V4, but you've made me curious. Could you elaborate on what this does and what the problem is?

I didn't know what International Color Consortium (ICC) was, but Wikipedia has a lot[1] (browse till you have enough).

Apparently Firefox (as of Gecko/20100115 - FF 3.6) supports only the version 2 of their specification[2]. Adobe Reader supports the latest (4, don't know 4.2).[2]

[1] http://en.wikipedia.org/wiki/ICC_profile

[2] http://www.color.org/version4html.xalter

I'm not a colour expert but as I understand it ICC profiles allow you to configure the colours your monitor renders to match their intended colour. I know that I need to use one of these profiles in order to get my VA panel monitor (which tends to use over-vibrant colours) to render "normal" colours. I'm not entirely sure why Windows cannot override application rendering etc. but I do know that applications that do their own rendering need reference to this profile.

Prior to Firefox 3.5 this was all supported without issue. As of 3.5 Firefox revoked support for ICC v4 (offering only ICC v2 support). As a result all colours look darker and I can rarely see gradients etc. now which is problematic as I prefer to use FF + Firebug for web development.

I still wonder why Firefox even bothers with writing its own engines instead of using webkit and v8. There really is no need for 2 open source rendering engines, that do the exact same thing.

It would save a lot of compatibility issues for websites and web developers, as well as push standards further if they both ran the same engines underneath.

So essentially Firefox would kept its same UI and add-ons system and thus would still keep its users. Which browser users used would basically come down to their preference in the way the browser feels as speed/standards/etc would no longer matter since they would be roughly the same (FF/Chrome/Safari)

It seems that Mozilla has a bit of NIH syndrome.

(Edit for the downvote parade - people have been talking about NIH at Mozilla for years:

http://www.linux-mag.com/id/4144

http://diary.braniecki.net/2008/01/27/not-invented-here-synd...

http://talkback.zdnet.com/5208-9595-0.html?forumID=1&thr... )

TraceMonkey was started before anyone had heard of V8. If you want working code to ship, you can't sit around hoping that Google will maybe be working on a super-fast open-source implementation of the code you want. But sometimes it does happen.

Are you perhaps being downvoted for claiming NIH syndrome in response to a post which is about them taking code from another project? And which also details that they've already bolted-on a JIT that was created by Adobe?

(And the irony that you're wanting them to adopt a codebase that exists mainly because Apple didn't follow your anti-NIH advice and adopt Gecko has already been covered in other comments, though no-one seems to have mentioned that Google could have have just worked on Webkit's Squirrelfish/Nitro rather than write V8, which meant they had two competing projects internally until they switched fully in version 2.0 of Android last September)

I don't care what engine they use; it's largely irrelevant to me.

I mentioned that Mozilla is known for having NIH syndrome in response to the parent's question as to why they would use their own JS engine instead of V8. jrockway's point about the timing of it is probably correct, but it doesn't change the fact that people have brought up Mozilla's NIH for years.

When wanting to use your own engine instead of V8 ... it's not always NIH.

They have developers on board familiar with the TraceMonkey codebase. They have developers from Adobe helping out with the Tamarin codebase. That's inside knowledge they would lose and it's debatable if on the long term V8 will deliver ... yes, right now it's the fastest, but is it the fastest approach?

Outsourcing a vital component of a project to another open-source project that's younger and hasn't proven its long-term viability should certainly be taken with a lot of care.

Personally I'm pretty happy with Firefox. The only thing bothering me is the single-process model, versus the one process per tab of Chrome, but I'm pretty sure they'll fix that pretty soon.

The only thing bothering me is the single-process model, versus the one process per tab of Chrome, but I'm pretty sure they'll fix that pretty soon.

I really hope so. My average number of tabs open seems to be growing logarithmically over time (lately I've been weighing in at about 40, which is not even that many if you use Tree Style Tabs and put your tabs on the left), so I have a whole lot of tabs to reload every time I crash. And that happens quite a bit more often than it should, since I have so many tabs open.

If and when Chrome gets a left-side tree tab extension that works on OS X (haven't checked lately, I should keep an eye out), I'll be switching over almost immediately, for this reason alone.

The reason is because both executing tracing and method-based JIT are useful, but only Firefox has execution tracing, and only v8 has the other optimizations. The idea is to write an engine that does both.

Seems like WebKit should be able to use this code when it's working; Mozilla is GPL/LGPL/MPL, and WebKit is LGPL.

Two different, competing implementations is nothing but good. They will have different security vulnerabilities. They will try out different optimizations and learn from each other. The competition makes each of them better.

I disagree. I think this "browser war" (or rather, healthy competition) is the best thing that has happened to the web in a long time. The more quality players competing, the better.

As long as they use open standards, it can't hurt the web, and if on top of that their code is open source, there should be lots of cross-pollination that further speeds things up.

It might be tempting to think that consolidating to one main platform would make things better - and maybe they would be at first - but in the long-term, without real competition, the rendering engine and javascript engines would almost certainly improve more slowly than they otherwise would.

It seems to me that the best kind of competition is among open source projects, since they can all benefit from improvements made to any one. It's the opposite of proprietary competition, in which innovations are locked behind patents and cannot spread.

That's true, though even "proprietary" competition is better than monopoly. Look at almost any industry except software for an example of that...

"I still wonder why _______ even bothers with writing its own engines instead of using _______. There really is no need for 2 open source rendering engines, that do the exact same thing."

If Apple had said the same thing back in 2003, then Webkit would not exist today. Firefox didn't exist then, but Gecko sure did, and there have been plenty of opportunities since for them to give up and switch.

I say there's value in diversity.

I think it's worth noting that WebKit itself is based on KDE's KHTML library. Apple didn't develop WebKit so much as decided to use KHTML over Gecko.

Both the Gecko and KHTML projects were started around the same time.

Is there any development on KHTML since Apple's forked it to WebKit?

As far as I know there were at least some backports.

Gecko runs slower, less capable, and doesn't adhere to the standards as strictly last I checked. So they aren't "exactly" the same.

Gecko is also very very wide spread in other non-browser applications AFAIK.

I was under the impression that Gecko was sometimes slower because it implements standards better than Webkit.

Quote from: http://weblogs.mozillazine.org/bz/archives/020267.html

"This is not exactly an isolated incident; a number of the performance issues I've run into recently in Gecko have had to do with correctly handling edge cases that this particular open-source engine happens to just not handle. I guess it's easier to do well on tests if you cheat.

More interestingly, Opera's performance on this sort of thing is still quite good, and I have yet to discover them cheating..."

The comments are good too, and include input from Dave Hyatt, but you have to skip over the "contributions" of some aggressive webkit fanboys.

"I still wonder why Firefox even bothers with writing its own engines instead of using webkit and v8. There really is no need for 2 open source rendering engines, that do the exact same thing."

It's a good thing the WebKit and V8 teams didn't have that attitude, or the only open source rendering engine would be Gecko.

the two JS engines don't do the same thing.

Mozilla will continue to use the tracing engine to JIT loops. It will fallback to the webkit js engine when the tracing JIT can't be used.

I wait for the headline that reads, Microsoft borrows from Webkit to build the next IE. I'd never use it but for testing, but it would sure make my life as a developer easier...eventually.

Reply on news.ycombinator.com