Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebKit is the jQuery of Browser Engines

ejohn.org

Post reply on HN
Print view View original

191–200 of 214 posts

Re: WebKit is the jQuery of Browser Engines

#191

Post by dinkumthinkum »

Me1000 wrote: post #113
kenjackson wrote: post #71

The web is not open and becoming increasingly less so. People love to talk about how the web is about open standards and such, but it really is rather quite closed. It's driven less by standards and more by de-facto implementations. Soon we can get rid of the standards committee and just talk to the implementers of webkit to define the "standard". And I think even worse has been the wholesale discounting of plugins.…

Lets step back from the "open" buzzword and look at the empirical facts. Less than a decade ago you made sure your web sites ran well in Internet Explorer, a closed source browser that was allowed to stagnate. IE took the W3Cs standards as more like "guidelines" and not a specification. - Today, every major web browser (except IE) uses an open source rendering engine (or the browser itself is open source. - Every maj…

Honestly, in my view "guidelines" is even a strong word for what Microsoft did with the browser and "standards." This is not to hate on MS at all but honestly, even though you could, I suppose, argue IE has gotten much better, I don't really see a reason for it to exist anymore. It's been such a bad boy and has so few redeeming features that I really think the "blue e" on the desktop should be made to be like simply a shortcut to whatever your default browser is, be it Chrome, Firefox, Opera, or whatever (but not IE because it's development, in my view, should stop).

Re: WebKit is the jQuery of Browser Engines

#192

Post by saurik »

tolmasky wrote: post #186
saurik wrote: post #184

Earlier quoted context omitted.

(edit: This comment's first paragraph is wrong, as pointed out in the reply below; in fact, this functionality is not in WebKit, it is in WebCore. However, it is still closed source, and it is not available on the website that was linked to: you cannot find the source code for anything that makes WebKit on iOS work on iOS, as it is all closed. The point stands.) WebCore != WebKit. You were saying that WebKit was open…

No, trust me: I was on the original iPhone team and was responsible for Mobile Safari and "WebKit" on iOS, and you are pretty confused about the project. For starters, "WebKit" is an overloaded term. There is "WebKit" the framework, which is a bridge between the actual gears (WebCore and JSCore) and applications. In other words, it is an API: an increasingly thin Obj-C layer on top of all the C++ that does the real w…

So, I just spent some time digging around in these libraries, to figure out where I might be wrong about this, and it seems like this is my mistake: a bunch of functionality I thought was in WebKit is actually in the closed-source parts of WebCore. Specifically, I'm talking about the tiled rendering (TileCache.mm) and all of the multitouch logic (PlatformTouchEventIPhone.mm). Even simple things like the copy/paste support are redacted, as is scrolling (yes: scrolling). For other platforms, all of this code is available.

This closed source part contains tons of simply critical things, such as how to interact with the iPhone's memory management notification system, how to manage the network state transitions, how to interact with embedded video... pretty much everything about MobileSafari that makes it MobileSafari as opposed to a less-than-half-operational desktop version of Safari with a touch screen (which would suck) is closed source.

I'm therefore quite sorry that I thought that this stuff was in the other library, but my point about the "open source and forkable" stands, and I think it stands pretty well: I can't fork WebCore and make meaningful changes to it for this system. In fact, even for people who have access to the system's internals (we jailbreak users), the few people who used to recompile WebCore for it (the Hebrew community) gave up and moved to writing Substrate extensions instead.

To be clear: I consider these iOS-specific things to be "the juicy parts" of MobileSafari: if you want to compete, you have to have really strong compatible answers for them. It isn't sufficient to take a desktop copy of WebKit and recompile it, because if you did that you'd just have a totally unusable browser experience... you wouldn't even have as much functionality as embedding a UIWebView in your application and attempting to externally script it.

So, yes: you are right that these are in WebCore, and that my complaint about "WebCore != WebKit" was wrong. The reason I made that argument was to try to reconcile your insistence that WebKit for iOS was open source with the reality that there really is no source code available from Apple for anything but "something that renders HTML (slowly, and missing features)"; my reconciliation was wrong, but the reason for it is still correct: WebKit for iOS, including WebCore, is not "open source and forkable" enough to make a web browser.

To the extent to which one can then put in the elbow grease to add back all of these missing parts in order to make a web browser, honestly one may as well be starting with any other rendering engine that isn't yet ported to this platform. Therefore, if WebKit for desktop systems is relevant to this discussion, then Gecko being open source is equally as relevant and libcurl in general being open source is largely as relevant. You can also build web browsers out of those.

Given this, I'm having an increasingly difficult time trying to figure out where your correction to kenjackson's argument was: you tried to give him a different way to think about it (in a way that might undermine his argument that WebKit is a defacto implementation due to an inability to install your own copy on iOS), but it is starting to seem like you just agree with him? Am I simply misunderstanding why you were responding to him?

Re: WebKit is the jQuery of Browser Engines

#193

Post by dinkumthinkum »

etherealG wrote: post #73
kenjackson wrote: post #71

The web is not open and becoming increasingly less so. People love to talk about how the web is about open standards and such, but it really is rather quite closed. It's driven less by standards and more by de-facto implementations. Soon we can get rid of the standards committee and just talk to the implementers of webkit to define the "standard". And I think even worse has been the wholesale discounting of plugins.…

if the code for the de facto implementation is open source, does it matter? i see the code and the standard as the same thing in different languages personally.

I don't think you can say the code is the standard. An implementation will have many quirks or things not related to the issue we are interesting "standardizing." Where do you draw the line? That would mean no implementation that was not simply 100% the same would conform to the standard.

You could say "Well standards document is irrelevant because no one follows them anyway" but that's another issue.

Re: WebKit is the jQuery of Browser Engines

#194

Post by Shorel »

ChuckMcM wrote: post #139
kenjackson wrote: post #71

The web is not open and becoming increasingly less so. People love to talk about how the web is about open standards and such, but it really is rather quite closed. It's driven less by standards and more by de-facto implementations. Soon we can get rid of the standards committee and just talk to the implementers of webkit to define the "standard". And I think even worse has been the wholesale discounting of plugins.…

This comment captures a lot, perhaps not in the way Ken intended, but I feel compelled to respond. Lets start with the thesis statement, "The web is not open and becoming increasingly less so." On its face, this statement is not only false, it is painfully so. Sort of like saying the world is not round and becoming increasingly less so. To pretty much anyone they would say "the world is clearly round, and its impossi…

Sadly a group of backwards people stopped WebDB just because SQLite being fast, fully featured and in public domain was not enough for them.

Re: WebKit is the jQuery of Browser Engines

#195

Post by tolmasky »

saurik wrote: post #192
tolmasky wrote: post #186

Earlier quoted context omitted.

No, trust me: I was on the original iPhone team and was responsible for Mobile Safari and "WebKit" on iOS, and you are pretty confused about the project. For starters, "WebKit" is an overloaded term. There is "WebKit" the framework, which is a bridge between the actual gears (WebCore and JSCore) and applications. In other words, it is an API: an increasingly thin Obj-C layer on top of all the C++ that does the real w…

So, I just spent some time digging around in these libraries, to figure out where I might be wrong about this, and it seems like this is my mistake: a bunch of functionality I thought was in WebKit is actually in the closed-source parts of WebCore. Specifically, I'm talking about the tiled rendering (TileCache.mm) and all of the multitouch logic (PlatformTouchEventIPhone.mm). Even simple things like the copy/paste su…

Yes that is the misunderstanding, I do agree with him (you can see another response to him here where we continue agreeing: http://news.ycombinator.com/item?id=5214213 ). I was not correcting him by saying "Here's another way to think about it", I was offering another interpretation of why kenjackson is right by looking at the case of mobile in particular.

I chose to focus on mobile for iOS precisely because here you have the greatest example of how open source is helpless and irrelevant. Even if Apple were to satisfy all your requirements for WebKit being open source, you still would not be allowed to compile it and ship it in your app, let alone modify it and ship it. Even if I write the best browser ever for iOS, I am not allowed to ship it on iOS. This is why I keep coming back to it not mattering whether you can or can't fork WebKit for iOS, just like it doesn't matter whether you can or can't write a completely new engine from scratch for iOS, just like it doesn't matter whether you can or can't fork FireFox for iOS: due to the nature of the platform, the web is closed on iOS PERIOD. Apple is THE gatekeeper of all features that enter the iOS web. Continuing to agree with kenjackson, that is why he is right that a better runtime or plugin system are ultimately more important for the web to be open than source code being released: as long as I can have a direct relationship with the user where they can install a plugin and modify the behavior of their browser, then there is a shot for non-dominant market players to always influence the direction of the web (the same way Adobe created the video revolution of the web without needing to own a browser or a cell phone or any other way of forcing people to use their tech).

I was really confused why you kept arguing with me about how open source WebKit is when my point was "whether or not its open source and you can fork it, it doesn't matter because the web is closed on iOS for deeper reasons".

Re: WebKit is the jQuery of Browser Engines

#196

Post by [deleted] »

jeresig wrote: post #55
nicholassmith wrote: post #51

Earlier quoted context omitted.

That stuck out for me as well, I could argue that Chrome isn't a better browser than Safari for me , but functionally they're both using WebKit so they render sites identically in most cases.

Except when it comes to the JavaScript engine. Safari's JS engine is the slowest out of Chrome/Firefox/Safari: http://arewefastyet.com/

[deleted]

Re: WebKit is the jQuery of Browser Engines

#198

Post by camus »

qu4z-2 wrote: post #182
camus wrote: post #104

Earlier quoted context omitted.

angularjs uses jquery api , like zepto does it is a hidden dependency. but you are basically using a subset of jquery when you use angularjs.

And Gecko uses most of the WebKit api. We're talking about implementations here, not specs.

the implementation is the same.if you use jQuery script the jQlite code is disabled in AngularJS. it is only possible if the subset code respect all the behavior or the main code. And Gecko doesnt use Webkit api at all. Chrome just cant swap its webkit code to to Gecko without significant rewrite.

Re: WebKit is the jQuery of Browser Engines

#199

Post by dvhh »

breck wrote: post #178
oinksoft wrote: post #19

Earlier quoted context omitted.

I think that's an easy argument simply by looking at the numbers Popular does not imply "better."

Popularity is highly correlated with quality. Given that A is 10-100x more popular than B, what are the odds that B is "better" than A? Slim. Now, popularity does not imply that something is the best. Often times there is something better that isn't as popular. But generally the popular thing is better than most alternatives.

Popularity is no correlated with quality, more with "good enough for the price".

Re: WebKit is the jQuery of Browser Engines

#200

Post by dvhh »

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.)

yeah because creating a closed fork of an open source project is really popular.
Post reply on HN