

WebKit for Developers - paulirish
http://paulirish.com/2013/webkit-for-developers/

======
maerek
Very interesting article. I never really understood the nuances of the
different WebKit ports (and once naively assumed that WebKit === WebKit). I
also didn't have an appreciation for the amount of work going in behind the
scenes. The link referenced in the article
(<http://trac.webkit.org/browser/trunk/LayoutTests>) is a fascinating line of
sight into the testing that goes on for the core.

------
kybernetikos
This is why the webkit- prefix is nearly worthless. I've had a lot of problems
where chrome and safari were rendering prefixed things differently and I
couldn't target them individually, because they both use the same prefix. This
is the whole point of having the prefixes!

~~~
eric-hu
"CSS parsing is the same, though. Slurping up your CSS and turning it into
CSSOM’s pretty standard. Yeah, though Chrome accepts just the -webkit- prefix
whereas Apple and other ports accept legacy prefixes like -khtml- and
-apple-."

Using this information, can you target Chrome with the webkit- prefix and
Safari with the apple- prefix? Specifying the apple- prefix after webkit- will
ensure that Safari uses that one, right?

------
eridius
> So first, WebKit parses HTML the same way. _Well, except Chromium is the
> only port so far to enable threaded HTML parsing support._

Nope. Recent WebKit Nightlies have threaded HTML parsing as well.

[https://www.webkit.org/blog/2259/last-week-in-webkit-
threade...](https://www.webkit.org/blog/2259/last-week-in-webkit-threaded-
html-parser-and-background-blending/)

~~~
abarth
I'm one of the developers of threaded HTML parsing in WebKit. Threaded HTML
parsing is only enabled in Chromium (for now). We're still working through the
kinks. :)

~~~
eridius
Oh? So the "Last week in WebKit" isn't actually in the nightlies yet?
Interesting.

~~~
paulirish
It'd be better to think of it as "Last week in the WebKit project". As as the
post points out, the WebKit nightly is only representative of the mac port of
WebKit, which Apple mostly calls the shots on. In many cases Apple takes a
conservative approach when enabling features that other ports may be
implementing or experimenting with.

------
taeric
I don't really get the initial point. The browser is, for most developers, a
black box. And it should probably stay that way. Ideally, it is an exchangable
black box.

Still a neat article. I just find that point odd.

~~~
igrigorik
For context, check out the video of the presentation where I made this point:
<http://www.youtube.com/watch?v=kiPe7DPmEgE>.

TL;DR: to build efficient applications in the browser, you _do_ need to
understand how the browser works. Just like understanding how an operating
system works will help you design good applications for the OS (especially
when it comes to performance).

~~~
taeric
I think my concern is that more of us should just follow the standards and
build a minimal document for the users. Obviously, those of us that need
efficiency should know what we are doing. But, just as the vast majority of
programmers today have high zero understanding of cache impact on algorithm
performance, the vast majority have little understanding how browsers do their
thing.

Is it worth knowing for other purposes? Well, I think so. It is worth knowing
just to know, if no other reason. And it is also worth knowing in the cases
where you are building something highly specialized. However, when I see
things like the template tag making it in to webkit, we are no longer treating
it as a blackbox where we focus on inputs and outputs. Instead, a growing
number are getting to muck around in the internals.

Is this bad? I honestly can not say. However, I do know that from my
perspective web apps have not been getting more impressive. Nor do I feel I am
missing something from them. Seems if folks want items that are as efficient
as you are alluding to, you should be doing a native application.

------
petepete
I'm interested to see whether Opera's move to WebKit means the end of the
Dragonfly suite of tools (which are fantastic, by the way).

~~~
kmfrk

       *sad panda* @hzr The switch to WebKit unfortunately means
       that Opera Dragonfly is no more.
    

<https://twitter.com/runeh/status/301616059729969152>

And yes, it is/was an amazing tool. My favourite web inspector by a mile.

------
daredevildave
I'm a little surprised by this line, in reference to Chrome on iOS:

    
    
        "Also, for what it’s worth, JavaScript is so rarely the
        bottleneck on mobile that the lack of JITting compiler 
        has minimal impact."
    

But then I'm making HTML5 games so JavaScript performance is pretty much the
only thing I care about.

------
buildnship
Levi Weintraub has a really great tech talk hosted at airbnb, where he talks
abouts all the different aspects of WebKit and it's components:
[http://www.youtube.com/watch?v=GGzmST5nNSM&playnext=1...](http://www.youtube.com/watch?v=GGzmST5nNSM&playnext=1&list=PL_gU0T3qTDt-1nyGuNoqKW3N5BYDNlZ3y&feature=results_main)

Some more really good tech talks @ <https://www.airbnb.com/techtalks>

------
cpleppert
Does anyone know why there are two different font paths and how WebCore
chooses which one to use? I assume the difference between fast and complex
would be very platform dependent.

~~~
idealisms
The fast path is for most languages where the text glyphs are placed in order.
The complex path is for languages where the shape and size of a glyph depends
on the characters around it. For example, Arabic text or Thai text would go
through the complex code path. There are some other cases where the complex
text path is used (I think "text-rendering: optimizeLegibility" forces the
complex text path).

In Safari and most of the time on Chromium Mac, the complex code path is
handled by CoreText. In other Chromium ports and on Blackberry, complex text
is handled by Harfbuzz-NG, which is also used by Firefox.

------
ireadzalot
Is anyone aware of any resources that shows you how to setup your machine to
see how an HTML page is rendered in Webkit, step by step, like remote
debugging?

~~~
paulirish
The Chrome DevTools timeline gives a solid overview of the construction of
each page. You can see the progression of grabbing network assets, Parsing
HTML, Recalculating styles, Layout (aka reflow), Paint, Compositing

Here's a trace of this page, for example: <http://paulirish.com/i/dd8f40.png>

A far more low-level view is available in about:tracing - More on that here
<http://www.html5rocks.com/en/tutorials/games/abouttracing/>

~~~
Mahn
+1 the timeline tool is great. Whenever you have performance issues in a web
app and javascript is not the culprit, that's the tool to turn to.

------
leeoniya
in FF, on every page load the page scroll jumps to around the "Opera just
moved to WebKit. How does that play out?" section. is this intentional?

~~~
Surio
I can confirm this too. Can only be intentional

~~~
paulirish
Not intentional. I believe it's the embedded slide deck afterwards. I'll de-
embed it for the time being. Weird bug, not sure whose it is, yet.

~~~
paulirish
Addressed. I bet it was a focus() coming from inside the iframe slidedeck
embed.

~~~
wasd
Still an issue.

------
zobzu
Reading the article, it sounds like "its cool because now you only have to
'dev for webkit' and forget the rest".

Makes me uncomfortable.

~~~
Volpe
why?

------
zenocon
I'm working on a project to embed WebKit in vehicles. One of the things I'm
interested in doing is running a suite of tests to ascertain things like
compliance with various specs and performance. I see the 28k layout tests in
the WebKit repo, but would be interested in any other tests -- especially
those that can be easily loaded into an iframe.

------
autoreverse
@paulirish FYI the link to CoreFoundation is invalid

<http://developer.apple.com/corefoundation/%3Cbr%20/%3E>

------
WayneDB
Just curious - How close is WebKit in terms of complexity, to the Linux
Kernel?

