WebKit is the jQuery of Browser Engines • Hacker News Board

Re: WebKit is the jQuery of Browser Engines

#211

Post by gsnedders » Thu, Feb 14, 2013, 11:24 AM UTC

bzbarsky wrote: post #202

gsnedders wrote: post #179

Earlier quoted context omitted.

Carakan was 16.5 months from first commit to shipping (and a month or so more to not being notably buggy), with a team of five for the vast majority of that time. The only code carried over verbatim from Futhark was the regexp engine (though that had machine-code generation added to it), and the parser was also pre-existing (though not shared with Futhark!). For comparison: MS were the last to do a major rewrite of t…

When discussing timeframes, it's important to keep the moving goalposts in mind. Back in 2009 it took order of 16 months to write a competitive JIT. But today's JITs are a good bit faster than they were in 2009, which means more special cases that need to be considered and made fast, from what I've seen of JIT development. I should also note that I included QA resources of various sorts in my team size estimate....

Right: I think if Carakan were done now it would likely take two years to being competitive, given the same team size (and I included QA in team size — varying between 1.5 and 2).

Re: WebKit is the jQuery of Browser Engines

#212

Post by likeclockwork » Thu, Feb 14, 2013, 6:57 PM UTC

dclowd9901 wrote: post #46

spicyj wrote: post #10

Earlier quoted context omitted.

"…because it's already happened and the world hasn't exploded ." It's hard to know now what the very–long-term effects will be but John's point that the web has benefited from Chrome's creation is hard to argue with. As for whether it's benefited more or less than if Chrome had used a different rendering engine, we'll never know…

I think we should at least touch on the real reason Chrome is the de facto standard and baseline for web page rendering: it's essentially to front end development what IntelliJ is to backend.

It is very nice to develop for.

Firefox isn't terrible but its developer tools always seem a little clunkier than Chrome's.

Re: WebKit is the jQuery of Browser Engines

#213

Post by podperson » Thu, Feb 14, 2013, 8:08 PM UTC

dpark wrote: post #166

podperson wrote: post #161

I'd say the big risk with webkit which no-one is addressing is that it's LGPL not GPL. Someone could get a dominant position and use a closed fork of it. (The fact that Apple open-sourced Webkit is to its credit.)

The LGPL doesn't work that way. You can't fork WebKit and keep your changes closed unless you don't distribute your browser to anyone. Now, you could use webkit along with (for example) a closed Javascript runtime, but that really has nothing to do with WebKit itself.

Right, my mistake, but you can effectively borg it.

Re: WebKit is the jQuery of Browser Engines

#214

Post by tmzt » Sat, Feb 16, 2013, 12:48 AM UTC

bzbarsky wrote: post #121

Arelius wrote: post #118

Earlier quoted context omitted.

While it may be true, we haven't actually seen a new layout engine written, so it's pretty difficult to estimate how long it'd take. Webkit was mostly functional as KHTML many years and tens to hundreds of developers ago.

We've seen a new layout engine written. Gecko. It took about 15-16 years to get to where it is now, with on average probably ~100 developers. Granted, you can argue it wasn't the most efficient path to get there, but I doubt that you could rebuild Gecko (or WebKit) from scratch today in fewer than 5 years with a team that's about that size... For that matter, it's not like KHTML sprang out of the void fully-formed; I…

Ah yes, NGLayout :)

And of course moving from XPCOM to a more direct smart pointer implementation, and various other stages along the way.