8 ms·
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 cl
by kenjackson 14y ago
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. I still strongly believe that being tied to JavaScript as really the only client side language is a mistake. It's not a great IL and limiting the language for such a pervasive platform is scary. I powerful plugin model would be, IMO, one of the best things to a truly powerful web.
I wish the web was more open. I wish that browsers were a truly extensible runtime that specified lower level abstractions, that allowed more innovation at the top of the stack.
It feels like we're walking into the dark age of the internet.
- etherealG 14y agoif 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.
- tolmasky 14y agoThey 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.
- jeresig 14y agoForking WebKit is effectively the same as writing your own browser, with regards to standardization. At the end of the day you want to get everyone to agree on the standard -- having an implementation that everyone can use only helps to sweeten the deal.
- tolmasky 14y agoThe response was more in regards to the grand-OP's desire for a lower level extensible runtime and lamentation about plugins, more than a comparison to standards now that I think about it. In other words, which web is more open: 1. One in which all the code is open source but there are huge hurdles to releasing your own browser, and any new feature is thus at the mercy of just a few big companies (Apple, Google, etc.). or 2. One in which perhaps all the browsers were closed source, but adding new features to any such browser really was just a matter of referencing a script on a web page? The questions is more or less only useful as a thought experiment by this point of course, and in particular I don't feel that the "standards" process was ever particularly open to begin with, so I don't think things have, or will, necessarily get much worse.
- kenjackson 14y agoI like how you've stated it, and made my original premise less confrontational and more of a question about what you value as "open".
- deleted 14y ago[deleted]
- kenjackson 14y agoOf course it matters. The "standard" becomes driven by the peculiarities of a specific implementation, rather than the best thing for the base of customers that are served by the standard. I think it's fine to have a reference implementation, but we need a broad set of implementations (with actual users) so that the standard doesn't get blinders on it due to an implementation decision made on a de-facto standard.
- etherealG 14y agoi see what you mean yes, that does make sense. to keep it honest so to speak.
- dinkumthinkum 14y agoI 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.
- pkulak 14y agoAnd that's bad why? So the web only works with one rendering engine. One rendering engine that's open source and can be used and modified by anyone for any purpose. Standards are great for things like protocols (even languages), but an entire web browser is a tad more complicated than TCP or even C++. No two browsers have ever implemented HTML/JS/CSS perfectly and they never will. If that's the case, then what's the point of a "standard" anyway?
- bzbarsky 14y agoOne rendering engine that has some serious limitations, like not being very parallelizable, because of highly entrenched implementation choices. Which means that if you want hardware capable of rendering the web it can't be low-power highly-parallel hardware; it has to be high-power-consumption fast-serial-operation hardware. Why is that bad? I guess that's a matter of perspective. I think that would be a terrible outcome, personally. I should point out that I'm not aware of any compiler that has implemented C++ perfectly, and I doubt any ever will given that it's a moving target. So why bother having multiple compilers or a C++ standard at all? For example, why does the WebKit argument not apply to gcc? And note that in compiler-land not being able to compile some codebases is OK as long as you can compile the codebase your user cares about, while the Web equivalent (only rendering some websites but not others) is a lot more problematic, because the typical compiler user compiles fewer different codebases than they visit websites. And also because using different compilers for different codebases is a lot simpler than using different browsers for different websites.
- malandrew 14y agoYou know that you can always start an open source project that fixes these parallelization issues and start building out an engine that is better, right? It'd probably be a 5-7+ year project, but it certainly is doable. In fact, it's possible that the poor parallelization support will be the Achilles' tendon of WebKit on a long-enough time scale. This is no different than the Achille's tendon of the DOM that is procedural-style immediate mode graphics instead of retain-mode graphics. Browser apps will never compete with iOS apps in terms of user experience until this procedural approach is replaced with a declarative functional reactive approach. Think long term. The Windows hegemony eventually buckled under its own weight. There's no reason to think that WebKit won't eventually do the same on a long enough time scale. Figure out what will lead to its collapse because that is an opportunity. In fact, letting WebKit lead the way allows you to learn all the ways in which WebKit does it wrong. WebKit will continue to trail blaze on the interface, but doesn't have to be the end all be all of implementations for those interfaces. Between Tizen and B2G, there is plenty of innovation in the web browser space. I just hope that transclusion is always considered a first world citizen in this brave new world.
- jahewson 14y agoproprietary binary plugins != open web
- rimantas 14y agoWeb being open has nothing to do with the number of rendering engines for browsers. Even having zero of them would not affect the openness of the web in any way. Firewalls would. > It's driven less by standards and more by de-facto implementations. That was always the case. In fact, one of the goals of WHATWG (fathers of HTML5) was to standardise how the code is rendered even if it is invalid.
- Me1000 14y agoLets 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 major web framework and library is open source. - Most of the servers running the web are powered by an open source OS. - The standards bodies are actually working faster than ever on new version of Ecmascript and HTML. - IE's marketshare is smaller than ever. Years ago some guys had a crazy idea to make a browser for KDE. Today it's powering much of the desktop web and almost ALL of the mobile web. Perhaps I just like a good love story, but it seems like this is a pretty great achievement for "open". Now, it seems pretty disingenuous to say "the web is not open" and even more so to say that just because more people are working on the same open source project that it's, "becoming increasingly less [open]." [edited for formatting]
- shmerl 14y agoThe "almost all of the mobile" part is really bad, and exactly resembles the IE situation on the desktop before. I hope Mozilla will shift the balance there again.
- Me1000 14y agoThe problem with saying "Webkit is the new IE" is that IE was allowed to stagnate because it was a singular browser with a dominate position in the market. When that position was achieved, it was no longer necessary for the company maintaining it to continue to compete. Webkit, in contrast, isn't controlled by any one company. The people using it have access to the source, and more often that not are contributing to the project themselves. I don't think the competition is going to end, It's just going to change form.
- shmerl 14y agoStagnation was only one aspect of the problem. Another big aspect was common bad quality of sites created with IE only in mind. The same often happens with WebKit on mobile.
- tolmasky 14y agoHere'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 instantly make everyone want to use web apps on iOS instead of native apps, but since you 1) can't ship that browser on iOS, and 2) can't convince Apple to commit that change to WebKit proper, you are effectively locked out. Compare this to a plugin-driven environment vs a standards-driven environment. Say what you like about Flash, but it was able to guerrilla video onto the web without anyone's permission.
- saurik 14y ago> ...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.
- tolmasky 14y agoWebCore/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/ 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.
- 14y ago
- mtgx 14y agoI'd be a lot more worried about implementing proprietary codecs like h.264 and HEVC, and DRM schemes on the web than about having one open source rendering engine as the "standard" for web browsers. At least you can fork webkit, and anyone can collaborate on it anyway.
- mgkimsal 14y ago+1 I've said for years that a pluggable javascript engine should be something that was fundamental to browsers. Extending it further, plugins that allowed for alternate and complementary lower-level technologies (easily embed a python engine, for example) would lead to more competition and innovation. We just had a discussion (or, I had a rant) about this at a local web meetup last night. 10 years ago it was "IE only". We're moving in to "webkit only" these days, especially if you're targetting mobile users. In some ways it doesn't feel like we've progressed all that much.
- runn1ng 14y agoPresto was not open source. WebKit is open source. So, the internet is becoming more open, not less.
- ChuckMcM 14y agoThis 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 impossible to change that." Similarly there is absolutely nothing standing between Ken, or anyone else, preventing them from building an entirely different "web" just like Tim Berners-Lee did back at CERN. So the definition of the word 'open' here clearly is needs some additional verbiage. The next statement helps a bit, "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'." This deliciously captures a debate that has raged for 30 years at least. "Which came first, the standard or the code?" Back when I was young and impressionable, the debate was something called the "ISO 7 layer networking model" and "TCP/IP". You see the international standards organization had decided that the world needed a global networking standard, and so they got their best standards engineers together to come up with what they gloriously christened the "Open Standards Interconnect" or OSI set of protocols. Meanwhile a scrappy bunch of network engineers and hacker types were in this loose knit organization called the Internet Engineering Task Force who were building networks that spanned countries and they wrote code and brought it to the meetings and debated stuff that worked well and stuff that didn't work well, and then everyone went back and wrote more code, Etc. The forces of evil ignored the IETF and focused on the ISO working groups, since the latter were making standards and the former were just playing around with code. As it turned out, working code tended to trump standards, and a process of debating changes to the system using working code vs debate using 'it should/it might' as opposed to 'version A does/ version B doesn't' meant that changes got made to standards based on a convincing argument that had never been tried or experienced in practice. The result was that the OSI standards had a lot of stuff in them to avoid issues that weren't issues, and were missing responses to things that actually were issues. A number of people found the 'code first, standard later' methodology superior for that reason. Assuming that the code was available and unencumbered by patent or licensing restrictions. The latter of course became a much bigger problem when the focus switched to the IETF and the 'big guns' started their usual games. My first response is then, "open" means anyone can implement and contribute new stuff. And by that definition the web is very open. However, since the community favors a implementation model over a theoretical standards model the 'cost' to influence change is you have to write code, as opposed to making a good argument. And that disenfranchises people without good coding skills. The second part of this screed is prefaced with this: "And I think even worse has been the wholesale discounting of plugins." Which speaks to the other side effect of "open" as in "we don't make any boundaries we don't have to." From a mass adoption point of view, the more variability you have in an experience the harder it is to capture the larger audience. This is why cars and motorcycles are all driven in basically the same way, Televisions have 'channels' and 'volume' and browsers have an address bar and bookmarks. The unification of the structure allows for mass learning and talking in generalizations that remain true without device specific knowledge. Can you imagine how hard it would be to write a driver's code if every vehicle had its own customizable UI and indicators? So as a technology matures the variability is removed and the common practices are enshrined into the structure. What that means in a practical sense is that if you're trying to push the envelope in such a mature technology you will face higher and higher resistance. However, you are always allowed to create an entirely new way of doing things. This isn't the 'dark age' it's the post renaissance start of the industrial revolution. Except instead of widely accessible books we've now got widely accessible information and a de-facto portal for accessing it.
- vor_ 14y ago> It feels like we're walking into the dark age of the internet. The persuasiveness of your argument is harmed by this sort of melodrama. By the way, the "Dark Ages" are named such because of a lack of written historical records from the Early Middle Ages. The negative connotation attached to the phrase by the general public is considered inaccurate by historians.
- firefoxman1 14y ago> Soon we can get rid of the standards committee and just talk to the implementers of webkit to define the "standard". Your comment in 1995: Soon we can get rid of the standards committee and just talk to the implementers of Netscape to define the "standard". And in 2001: Soon we can get rid of the standards committee and just talk to the implementers of IE to define the "standard". And in 2006: Soon we can get rid of the standards committee and just talk to the implementers of Firefox to define the "standard". ...and for more comparison: Your comment in the late 70's on computers: Soon we can get rid of the hobbyists and just talk to Apple to define "standard". And in 1996: Soon we can get rid of Apple and just talk to the creators of the PC to define the "standard". And in 2010: Soon we can get rid of the PC and just talk to the creators of the iPad to define the "standard". Just sayin'