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

181–190 of 214 posts

Re: WebKit is the jQuery of Browser Engines

#181

Post by saurik »

tolmasky wrote: post #122
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.…

Here's another interesting way to think about it: look at the mobile web on iOS. Does it matter that WebKit is open source and forkable? No, since Apple actively prevents "alternative" visions of what the web should be since they just don't allow custom builds of WebKit/JS on there. Any browser you make can only add superficial features, forcing you to use the built in WebKit. You may have a great idea that would ins…

> ...look at the mobile web on iOS. Does it matter that WebKit is open source and forkable?

The version of WebKit used on iOS is actually not open source and forkable; even WebCore, which is LGPL, Apple works around: rather than releasing code changes for iOS-specific features, they release the binary .o files users can link in.

Hell: Chrome for Android isn't even open source. People tend to totally forget that "WebKit is open source" is meaningless in the general case, as the BSD license allows specific forks to be closed, and all of the mobile ones hold stuff back.

Re: WebKit is the jQuery of Browser Engines

#182

Post by qu4z-2 »

camus wrote: post #104
pestaa wrote: post #56

Earlier quoted context omitted.

Wrong. At least Angular JS brings its own jQuery-like functions and does not depend on jQuery by itself.

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.

Re: WebKit is the jQuery of Browser Engines

#183

Post by tolmasky »

saurik wrote: post #181
tolmasky wrote: post #122

Earlier quoted context omitted.

Here's another interesting way to think about it: look at the mobile web on iOS. Does it matter that WebKit is open source and forkable? No, since Apple actively prevents "alternative" visions of what the web should be since they just don't allow custom builds of WebKit/JS on there. Any browser you make can only add superficial features, forcing you to use the built in WebKit. You may have a great idea that would ins…

> ...look at the mobile web on iOS. Does it matter that WebKit is open source and forkable? The version of WebKit used on iOS is actually not open source and forkable; even WebCore, which is LGPL, Apple works around: rather than releasing code changes for iOS-specific features, they release the binary .o files users can link in. Hell: Chrome for Android isn't even open source. People tend to totally forget that "WebK…

WebCore/JSCore for iOS are indeed open source, but yes certain pieces are released as .o's that you just link with it, and additionally it is released as source dumps instead of nicely managed versioning. If you go to http://www.opensource.apple.com/release/ios-61/ and download WebCore you will see plenty of source in there. The point is that you could for example meaningfully edit WebCore (for example adding python scripting support, or perhaps even putting in ogg support, whatever), link it with the .o pieces, and have an interesting new product, but still not be able to release it on iOS due to the rules.

Re: WebKit is the jQuery of Browser Engines

#184

Post by saurik »

tolmasky wrote: post #183
saurik wrote: post #181

Earlier quoted context omitted.

> ...look at the mobile web on iOS. Does it matter that WebKit is open source and forkable? The version of WebKit used on iOS is actually not open source and forkable; even WebCore, which is LGPL, Apple works around: rather than releasing code changes for iOS-specific features, they release the binary .o files users can link in. Hell: Chrome for Android isn't even open source. People tend to totally forget that "WebK…

WebCore/JSCore for iOS are indeed open source, but yes certain pieces are released as .o's that you just link with it, and additionally it is released as source dumps instead of nicely managed versioning. If you go to http://www.opensource.apple.com/release/ios-61/ and download WebCore you will see plenty of source in there. The point is that you could for example meaningfully edit WebCore (for example adding python…

(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 source and forkable: no, WebKit isn't. There is a library used by WebKit called WebCore that is, but WebCore doesn't provide most of the juicy iOS functionality; Apple actually seems to actively avoid touching WebCore, lest their lives become more difficult due to it being under LGPL.

The reason, then, that I brought up WebCore was as a demonstration that even for things where Apple must release at least some source code (as WebCore is under LGPL), they still weasel around it: WebKit, which is under BSD, has no such protection, and you will note that there is simply nothing available for it on iOS at all.

(Trust me: I routinely download all of opensource.apple.com, to find not just new packages but redactions, and have scripts to reconstruct git repositories out of the various tarballs for key projects, which I then export for others in our community to more easily be able to work off of; you forward me there as if I haven't heard of it... ;P.)

Re: WebKit is the jQuery of Browser Engines

#185

Post by [deleted] »

tolmasky wrote: post #78
etherealG wrote: post #73

Earlier quoted context omitted.

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.

They are different things because its unrealistic to fork WebKit and get any significant market share. So even though you might make a worthwhile change to the engine, realistically you need that change to be accepted by WebKit proper for it to matter.

[deleted]

Re: WebKit is the jQuery of Browser Engines

#186

Post by tolmasky »

saurik wrote: post #184
tolmasky wrote: post #183

Earlier quoted context omitted.

WebCore/JSCore for iOS are indeed open source, but yes certain pieces are released as .o's that you just link with it, and additionally it is released as source dumps instead of nicely managed versioning. If you go to http://www.opensource.apple.com/release/ios-61/ and download WebCore you will see plenty of source in there. The point is that you could for example meaningfully edit WebCore (for example adding python…

(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 work. Then there is the "WebKit Project", which is an umbrella term for all that stuff together (WebKit/WebCore/JSCore). Chrome for example neither uses WebKit proper if I recall correctly, nor the engine in JSCore (opting for v8 instead), and yet it is still considered a "WebKit browser". That's because what makes you "behave" like WebKit is WebCore, which actually handles DOM, rendering, CSS, etc etc. So saying that Apple releases WebKit for iOS is perfectly acceptable terminology, even if you are wanting to be pedantic about it. Now I don't know what you define as "juicy functionality", but I can assure you that WebCore is not just some helper library or something, WebCore more or less IS WebKit. It is certainly enough for you to be able to build your own custom browser for iOS. In fact, even if the iOS version was completely closed source, you could still take the desktop 100% open source WebKit and port it to the phone (just like Nokia and Google did for their phones).

So I guess I'm missing the relevancy of your point. If you just wanted to rant that Apple doesn't open source as much as it should, then I sympathize, but it really has nothing to do with the point I was making that due to the separate restrictive nature of the App Store policies, it doesn't matter if WebKit is or isn't open source because you aren't allowed to ship a custom browser engine anyways (at least not one that runs JavaScript).

Re: WebKit is the jQuery of Browser Engines

#187

Post by gcp »

malandrew wrote: post #147
gcp wrote: post #11

Earlier quoted context omitted.

I believe KTHML->WebKit has pretty much illustrated that having standards that allow new implementations to be developed is a good, essential thing. We'd have been in an interesting, and perhaps worse state if Safari and Chrome were both Gecko based instead of competing therewith.

Why would we be in a worse state if Chrome and Safari were Gecko based?

We'd have one less rendering engine.

Re: WebKit is the jQuery of Browser Engines

#188

Post by kbrosnan »

malandrew wrote: post #152

I know this is OT, but how hard would it be to create a thin layer so that WebKit run on bare metal?

Mozilla is doing this with Gecko. Google is sort of doing this with Chromebooks (AFIK). There is little to no incentive for Apple or Google to do this on their flagship products of iOS and Android since they already have dev ecosystems using objective c and java respectively.

Re: WebKit is the jQuery of Browser Engines

#189

Post by stormbrew »

dasil003 wrote: post #173
stormbrew wrote: post #66

Earlier quoted context omitted.

This has always struck me as a really poor argument. For one thing, because webkit itself is by far the youngest rendering engine around and also among the most complete. You can't reasonably argue both for a webkit monoculture and an unreasonably high barrier to entry. Gecko was an open source ostensibly pluggable engine (even MSIE is pluggable, in fact), so why did we need webkit to bring about the monoculture? Wou…

What do you think exactly is my argument? I'm just talking about the way things are, not some ideal that I'm holding up. Also, your commentary has major holes in it: > webkit itself is by far the youngest rendering engine around and also among the most complete WebKit was formally released by Apple almost 8 years ago after being in development secretly for at least a couple years before that. That encompasses the ent…

I did not say it was brand new, but it is the youngest and that's inarguable. It's pre-webkit state also was not exactly much to write home about, and I say that having been a user of Konqueror back in the day.

Google seems to be replacing the AOSP browser in Android with Chrome, btw.

I think you underestimate the non-technical cost of entry of a new browser by a lot while overestimating the technical. I'm not saying that it's a small feat to make a compliant browser by any means, but if a non-Google company were to attempt to market a new browser the way Google did (including ads of equivalent value to links on Google's front page), it would be absurdly expensive. There's a reason all the dominant and growing players in this space are massive corporations: a plucky underdog stands little chance against Google, Apple, or Microsoft. So who else's browsers would they have to hold off exactly?

Re: WebKit is the jQuery of Browser Engines

#190

Post by dinkumthinkum »

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…

I think this is unfair to the parent. Comparing web standards to the OSI model is really not the same thing, in my view,, at all. Web "standards" are much more specific and prescriptive, as well as detailed than the OSI model.

It's hard to say whether the parent is correct about the dark age but such a thing clearly has been the case in the past with regards to standards. There was a time before in the not-so-distant past that browser vendors, particularly MS, did not care much at all about conforming to any sort of standards and created mess for which things like jQuery were partially created to solve. So I think there is real ground the parent's point. The issue is whether it is really getting worse, still.

One thing I think is different from previous years is that the programming community is less accepting, I think, of totally non-standard, even weird, proprietary implementations.

Post reply on HN