I realise that we are an international community here at Ajaxian, but for the American Thanksgiving holiday, I thought it would be OK to take stock and say some thanks too.
Firstly, to the bright hackers who brought us not only XHR (thanks Microsoft), but porting it to other browsers, and then the hard work of giving us the Ajax libraries. The Ajax framework authors have done the hard work so we don’t have too. They boldly go where no Web developer wants to.
Thanks to the browser vendors, especially recently got getting back in the game and charging ahead. We have another game on our hands as we see browsers add features and come a huge way with respect for performance.
Finally, thanks for you all. You provide the colour that we get to cover. You build the great applications that we get to showcase. The engine that is Ajax matters little if there isn’t a great body on top. Thanks for pushing the Web forward, and for supporting the platform that tries hard to be Open for all. We have a unique opportunity to have developers “own” the platform that we all build on rather than a particular vendors. We need to push even more to make this happen in spades.
If you notice that we haven’t covered something that you have found cool… perhaps you made it, please don’t assume that we glossed over it. Chances are that we simply didn’t see it. So please email us and contribute some news! One of the Ajaxians will make sure to check it out. To the other Ajaxian editors, I appreciate ever post that you do to contribute to this community.
As it is Adobe MAX this week, there is a lot of talk about the Flash platform. How does this relate to the Open Web? Well, it turns out that Dion and I have been discussing how Flash can join and become a part of the Open Web.
Adobe (via Macromedia) has traditionally been a Web designer company, but developers haven’t jumped in to the same degree (note: not to say they haven’t been wildly successful!). I think that the perception is something like this:
Dion discusses how Adobe has an opportunity to position themselves relative to Silverlight much more strongly in the Open Web camp:
With Silverlight making a huge charge I worry about a world where you have “Best viewed in Silverlight and IE” (which in fact is “only viewed in…”) and people often ask: “But isn’t Flash just as bad?”
Adobe has an opportunity here. They can move to the right and Flash could become strongly in the Open Web camp. Then we would all be stronger as we come up against Silverlight :)
The next logical question related to this is open sourcing Flash:
The conversation tends to end up with opensourcing Flash, which I think will happen at some point through necessity, and the sooner the better (for everyones sake). Flex has a loyal base and has some open source help, but hasn’t gotten the love that it could get because it sits on top of something that isn’t open source itself. It is hard to get excited about an open source tech that sits on top of the same vendors proprietary platform!
I agree with Dion that open sourcing Flash and having it join the Open Web camp is a very compelling idea. Open source would just be the first step, though, so following up on Dion’s post I put together an editorial titled “How Flash Can Integrate With The Open Web”:
As Dion points out open sourcing Flash is one big part of making this happen, but another huge aspect would be to have Flash and Flex integrate better into the web stack and be less of a ‘black box’ on the screen…The important point is to integrate Flash and Flex more deeply into how the Open Web works:
Cross-Platform Standards
No Vendor Lock-in
Anyone Can Innovate
Powerful, Universal Clients
Open Source Implementations
Mashable, Searchable, and Integrated
I give a list of suggested ways to do this; the important thing is to have Flash integrate more deeply — these are just some suggestions to kick things off. Here are some of them; click on them to read more in-depth how this might work:
At the end of the day Adobe is a tools company, a really damn good tools company actually. Doing the above should allow Adobe to continue creating powerful tools that help authors and content creators while expanding the size of the market they can target.
The above list was just a suggestion to kick things off. The real focus is on having Flash integrate into the web stack better itself (and evolving both Flash and the web stack themselves into the future).
Over on my personal blog I’ve started a new semi-regular series called Fixing the Web. From Part I of the series:
We’ve made major progress on the web since 2005 and the rise of Ajax. JavaScript toolkits like JQuery, Dojo, and YUI have expanded what we can do with web browsers and increased our productivity, while dynamic high-profile web sites have legitimized using DHTML and Ajax. The rise of web browsers like Firefox, Safari, and Chrome have done a huge amount to help revive the web and web applications. Developers such as all of us in the Ajax community have shown that it’s possible to do things with the web cross-browser that no one expected, including Comet, cross-browser vector graphics, and more.
However, even with all of the amazing work the last few years, the web has some very serious foundational issues that we need to solve or else it’s game over. In the next year or two we will begin to hit the limit of what we can achieve with clever JavaScript tricks (I’ve literally made a career out of this browser black magic). As an industry we’ve put off having to solve some very serious issues. Unfortunately the bill is going to come due soon, and if we don’t take action, solve these issues, and push the web in a new direction some other possibly much less open technology will take over the bulk of new development.
We need to do something about this. This blog post is part of a new, semi-regular series called Fixing the Web. The goal is to highlight these issues, identify potential solutions, and have a dialogue. I don’t claim to have the answers for the situation we are in. However, I do know this — if there is any community that potentially has what it takes to solve these issues I believe it’s the Ajax and JavaScript communities, which is why this is a perfect place to have these discussions.
I propose some starting ways to address this and fix things:
To start, I see four areas that are broken that must be fixed:
1) Make developing for the web much easier and more powerful. There are gaping holes in the web that need to be fixed. Examples include:
* Layout - layout needs to be _much_ easier. We need real, kick-ass, drop dead simple layout. You shouldn’t have to be a CSS wizard to get multiple columns, for example.
* JavaScript++ - JavaScript needs to evolve for programming in the large and medium.
* Bling - Browser’s need much better native multimedia support, real vector graphics, and _fast_ (really fast) animation
* Tooling - We need much better open web tooling support, such as IDEs.
2) Solve the standards problem. The web standards process is broken. There is a real disconnect between developers needs and the W3C’s standard setting process, creating a dangerous power and leadership vacuum. We need to come up with better mechanisms for creating standards, as well as organizations that can help manage them.
3) Solve the distribution problem. Both Gears and Yahoo BrowserPlus are attempting to address this area. There is just a sheer mass of inertia on the web. It doesn’t matter if you have the most amazing standards, developer tools, etc. if they aren’t in enough places to do anything. This problem can also be re-framed as ‘Solve the Internet Explorer problem’, because the other browsers are pretty damned good at getting things out there — IE is the mass that blocks any positive forward web progress. IE 8 is a start, but at the end of the day it’s not doing enough. This is also linked to how hard it is to do web development, since you have to be a wizard to know the potholes or do crazy workarounds.
4) Solve the innovation problem — There is a saying in politics that you create ideas so that you can draw on them when there is a crises, such as we are seeing now. Much of the innovation on the web has surprisingly happened by Flash, with some by Silverlight lately — when we get excited about being able to do video on the web, which is great, that’s a pretty sad indictment of the open web ‘owning’ the future. We’ve got to have better mechanisms for stamping out potential futures and innovation that can then compete, the successful ones turning into standards. Mozilla has done a good job of this with the web “concept cars” type work they’ve been doing.
What do you see as the major areas we need to address? Expect to see the issues above, and others, discussed in future blog posts in this series.
In recent presentations, Ben and I have been taking a look back on the rise of Ajax (where Ajax == popularity of dhtml :). At its core, I think it all comes down to UI responsiveness.
When you look at the killer apps such as Google Suggest and Maps, they broke through a set of myths on the Web.
Latency is the killer issue on the Web
We are used to autocomplete in fields and forms these days. However, if you think back to when Google Suggest came out, if someone had asked you whether it was a good idea to do a background request on each key press you may think they were insane. The beauty of suggest is that it broke through and gave great performance. You could do this on the Web.
Rich interactions are not possible on the Web
Again, we are used to applications that allow us to interact with data in a better way. With Google Maps, you feel like you are moving around the map. You are interacting closely with the data. Before hand, we were used to a static view that had us clicking up/down/left/right or zooming around. Every click responds with a wait and a repaint of the entire screen.
This seems crazy. No application framework would ever do a refresh like this, and dhtml broke us out of that box.
This is all pretty obvious, especially when you take a look back at the HCI research on how anything that takes more than a second drives your users batty (and gets them out of the zone). Getting down to 0.1 seconds and your users will feel like they are at one with the app :)
The responsiveness that Ajax gave us opened up the Web for truly useful applications that users could live in without getting frustrated. This bridged us from pages to apps.
We continue to see movement here too. The reason that WorkerPool was added to Gears (Web Workers in the standard) was to give developers the ability to send “work” (run code) to a place that isn’t on the UI thread, which is a big no-no for building any kind of responsive application. As we write bigger and bigger Ajax applications, we end up running more code, which competes more with the browser. Having Web Workers in the browsers natively, and available to those that don’t via Gears, allows us to build compelling applications.
Add to this fast JavaScript (SquirrelFish Extreme, TraceMonkey, V8), and we can get to a happy place with respect to performance.
So, if the original Ajax revolution was about UI responsiveness, where do we go from here?
I think that we have a few directions that we need to go in:
Productivity
We need to be more productive. We all feel a lot of pain with Web development, even as we get a lot of benefit from the reach and openness. This is pain is the reason that Ben and I are working under a developer tools umbrella at Mozilla. We want to work with the community to become more productive. It is extremely important to do so.
It shouldn’t be hard to put together the hundreds of applications that the Enterprise and beyond spend too much time and money on every day.
We shouldn’t have to fight the browsers to get things working as much as we do today.
Any ideas on what would help you? We are all ears.
Compelling applications
We have spent a lot of time in the weeds talking about the engine of the car. We jump on a point release of some framework, and argue about the minutia of framework differences.
Maybe it is time to pop our heads up a little and think about how we can build compelling, feature rich applications.
The browser is extending to the desktop more, to give you nice full experiences. The real-time Web is kicking off, and Comet will become a big part of how we develop many applications in the future. It needs to be as natural to us as the simple request/response world that we are used too.
UI latency is only one piece of user experience. There are many others. HTML 5 gives us richer components and semantics to work with. We have been working on different UI paradigms such as the Form History pattern that we have discussed before. Aza Raskin and others have been doing really good work on new paradigms too.
Personally, I think that new input devices are going to create a huge change for us, and the abilities of Web applications. We played with the WiiMote as an input device. We then have multi-touch, which is available on touch pad devices as well as touch screens. Finally! We are moving past the prehistoric inputs where we can point and say “Ug”.
I am incredibly excited about where we are, and where we are going. There is a ton of work to do, but people feel engaged. Let’s “get ‘er done”.
Where do you think we are going?
This presentation goes over some of these points, in more detail:
Joe Walker was thinking about accessibility and wrote about a thought experiment that he had where he ponders ‘What if we didn’t lump all “accessibility” requirements together?’
What if, instead, apps are written for one audience. What could you do differently for different use cases?
Designing for Screen Readers
So you want to create a version of your site specifically for screen readers, ignoring everyone else. What might you do?
Scroll bars are generally bad for sighted people. They hide content, slow things down, and some people find them hard to use. But screen readers don’t care about long pages; the scrollbars are invisible anyway. So how about packing the whole site into a single page? Since the graphics are irrelevant, we can skip those, and for many sites still have less to download. The page can then start with a description of the access keys and the user can then navigate really quickly. We could quickly summarize the access keys at each page boundary in case they’ve been forgotten.
Designing for Dyslexia
Dyslexia is generally less of a barrier to web use compared to blindness, however it is very common and often overlooked. In contrast to the low graphic, high text approach for Screen Readers, some dyslexics think in terms of pictures, and may prefer a layout which uses a standard set of icons to back up common concepts. Many users without this disability may find this approach distracting, and it’s certainly going to be annoying to anyone with a screen reader, if the text goes on regular side-tracks reading the ALT text that is only there to back up the text anyway.
Designing for Cognitive Disability
One of the problems with the web, and computers in general is the level of distraction. Distractions are a problem for everyone whatever their abilities, but the problem is exacerbated by disability. I’ve noticed that as people slow down, they start to look around at their screens using their neck muscles, pointing their entire head rather than just their eyes, and I think it’s all about focus. We need a way to narrow our focus to concentrate on the important questions.
It might be possible to have a site where we could “zoom in” on what was important. If you could “zoom-in” to simplify GMail, what would you throw out? Invitations would go, as would links to other services, settings, maybe labels and the 2 sets of buttons that do the same thing. I think many people use email by just seeing their inbox, and maybe search. Ultimately email could be a wizard where you see what’s new and that’s it. Clearly this lack of detail isn’t going to be good for everyone, but having a “simplify it” function could be really useful in many cases.
Designing for Low Vision and Motor Impairment
I don’t know, but I suspect that the “zoom-in” to simplify concept is going to require lots of complex layout. In comparison to which, people with low vision or motor impairment want simple layout. They also want to zoom in, but probably just to make the words/buttons bigger. People with low vision often differ in how they need the screen enhanced. Is it black/white or white/black. Have colors gone, or might a flash of yellow help? Often the OS takes care of much of this problem, but websites that use yellow-fade might be helping, or might not, depending on OS settings. Good design for low vision is probably going to let the user select the type of visual aid that helps.
Of course, this sounds interesting in theory, but we have the sliding scale:
How many developers build for more than one browser, let alone…
Old browsers, let alone…
Accessibility, let alone…
Multiple accessible sites.
Christian Heilmann talked about having a movement for accessibility, and how we need to not be flailing in the wind.
I found myself pondering the Open Web recently, and I posted about my thoughts as I revisited why the Open Web matters. The piece is not about the Open Web being better, or for Open Web people to feel high and mighty. Rather, it is working out why the Open Web makes sense, and how it fits into the world at large.
I am curious to hear your thoughts. Does the Open Web matter to you? Or, do you just want a productive place to get stuff done?
Here is the piece:
I have been thinking more about the Open Web recently, and decided that it may be time to go back to first principles and work out why I am such an advocate for it. The Open Web has plenty of flaws. I wish it was more productive, more seamless, and more beautiful :)
This came about as I pondered the same thing for feeling an association to a political party. Why do people associate themselves as Democrats, Republicans, a member of a smaller party, or just independent? How often do you join a team and just stick with it? It feels like there are a few types of people, including (sorry for a football analogy!):
At birth: I was born in Tottenham, so I will be a Spurs fan for life
Fair weather: I never liked Chelsea particularly, but after that Russian guy got involved I go to games and cheer them on
First principles: I like teams who play attacking football. I used to hate “boring boring Arsenal” but after that French bloke go involved, I have changed my mind.
Things change. The party of Honest Abe kicked into gear with the “core values” revolving around abolishing slavery, rather than all of the conservative values that the party espouses today.
Of course, within a party there are many factions. The Neo Cons and the traditional fiscally conservatives may share a party, yet be at odds on various decisions. The exact same goes for the Democrats and their beliefs.
Because of this, I am trying to regularly take a step back and match my belief system to the current politics of the day. Often parties use deep wounds and values to try to tie people together, but in other times we see the need to be reborn. Tony Blair famously did this recently in the UK by creating the “New Labour” brand. He ended up doing what Neil Kinnock never could, and becoming prime minister.
How does this all fit into software?
It is easy to get sucked into the same trap. “I believe in the Open Web!” Things change, so you can challenge yourself on why that matters to you.
As I look into why I care so much for the Open Web, a few core thoughts come out.
Power will lead to bad things
If I look back at the recent history of software and platforms, I come to the conclusion that at various points on the road the interests of developers and vendors align for awhile. Ben and I have been talking about this. For example, Microsoft nails the productivity of Visual Basic, and developers take that gift and run with it. But, over time, developers get frustrated and some of them feel like Microsoft uses their power to do bad things. Many lose trust and look elsewhere. Others don’t care and keep listening.
When the Java community came to the realization that Applets weren’t the killer app, but rather the JVMs, the “better C++” for the time, and the write once, run anywhere promise took hold quickly. Despite Sun, the Java developer community is still strong to this day. The problem though, is that at some point the vendors got too involved in a way that created EJB. Forget solving developers problems, it is time to argue over what to standardize, where the game is having your approach be the standard. IBM, Oracle, Sun, and many others fought about EJB and thus we ended up with the monstrosity that would create fortunes for consultants. Once the success of Java kicked in, everyone jumped on how to make money for it. Sometimes the companies that innovated were able to both make money for themselves, and help developers. Other times, not so much.
The power of the Open Web is in the fact that no one company controls it. When the interest of developers and The Uber Company aren’t aligned, developers are no longer screwed. They have choice.
This choice can come at a cost though.
Mussolini may be a dictator, but he made the trains run on time!
There is a notion that the less voices that we have, the faster we can move. A dictator that owns multiple sides, or the entire stack, can make a more productive, technically superior solution. In some ways this makes sense of course, but remember that Mussolini set the trains perception by changing the clocks. It doesn’t have to be this way.
One key is to keeping the democratic process moving appropriately fast (but not too fast).
I have talked about the Fly wheel approach in the past, and I think that this is a key issue for a healthy democracy, and a healthy Open Web.
There are reasons why Winston Churchil said:
Democracy is the worst form of government except for all those others
On the bad side, you get the issue of it never being able to become pure (just the same as communism). We are dealing with people. Once people get in power they have reasons to tweak the system in their favour. Obvious examples exist such as redrawing the congressional boundaries to do what you can to keep your party in power.
In technology you get the same thing. On the Open Web for example, we only have a few viable browsers (like the few number of viable parties issue). This gives huge power to these browser vendors, and it can break the fly wheel. Browsers have barely had a chance to innovate in the last decade. Imagine using a cell phone from 10 years back? It is crazy! The silence in the chasm is frustrating as hell. Even when the browsers change, we still have the lead weight of the users who don’t update. We need to solve that problem.
Microsoft got such a huge leader in the browser war, that they turned off. This cut off the circle of healthy Web life:
Vendor creates technology
Developer uses technology
Developer pushes boundary of technology
Vendor sees what is being done, and works on newer better technology
REPEAT
It turned out that developers have really kicked this into live again via the Ajax revolution. With poor dhtml support, many developers moved from the client side of Web browsing, and ran screaming from dealing with Netscape layers, and IE equivalents (IE was quickly better in fact). They made their home on the server for the coming years, spending time on Web frameworks in every language camp out there. We went from CGI to NS/ISAPI, to mod_*/Servlets/PHP, to Rails/Django/and more.
It took the joining of Mozilla implementing XMLHttpRequest, and visible applications such as Google Maps and Gmail (among others) to wake up the developers to the wasted CPUs and functionality available in the browser. Only brave folks such as Dean Edwards, Alex Russell, Erik Arvidsson, Emil Eklund, Dan Pupius, Aaron Boodman, Scott Isaacs carried the flame and pushed during the lean years.
With developers back in the game, thanks to Ajax, the browser vendors had the push they needed to really kick into gear again. Richer Web applications required better JavaScript and APIs. If a browser got really good at powering these rich applications they could set themselves apart.
This wasn’t enough though. Web developers were frustrated. We had teams at Google that mirrored many others. They wanted to add more functionality to their applications, and they needed a vector to make that happen. This is how Gears was born, and I bet the case was similar for what became the Yahoo! BrowserPlus team (am I right Lloyd? :).
Now that we are back in sync, and the flywheel has been turned on again, my thoughts are on how to keep this effect going. How can we put developers first and make sure that the cycle continues and doesn’t get derailed? We need to balance the power and constantly be watching it. No one company can get to a point when the power can corrupt. This is subtle, as it isn’t just watching out for the Sheriff of Nottingham and seeing how he is taking all of the money. These things often happen by mistake. You can easily think that you are doing a “good thing for the community” and yet you are creating a very unlevel playing field. One simple example that shows this is if we put CSS and JS from Google properties directly into Google Chrome. We could argue that this would be good for users as it would make the experience faster. How harmless is that? I believe that it would destroy the level playing field.
This isn’t to say that you can’t innovate, far from it. We need to be very clear that we require innovation. We just need a path for taking the evolution and moving it into the standards. In the above example, we could create a system for richer caching of resources. We could implement the hashing work that Aza Raskin and Douglas Crockford talked about. Good work will stick and will become part of the Open Web naturally. This is the beauty of the Open Web. Someone can come up with a piece of technology and others can share and use it. An independent developer could think up OAuth and make it happen. If it is worthy, big companies can come along and implement it too, and we can standardize. It doesn’t have to come FROM the huge companies first though. Think about how rare that is.
This is why I come full circle to realize that the Open Web is important. We all need to do our best to make sure that this deeply evolving system doesn’t get cancer. We need the bursts of innovation to kick out new DNA that allows us to try experiments.
With all of the work being done right now, it feels like the end of the Dark Ages. I can’t wait for the next chapter, can you? What have I missed?
I met with a colleague recently who wants to take his project and create a standard on the web that actually gets adopted. We talked for a long time, and when we finished up I pointed him at a paper that had a huge impact on me, called “In Praise of Evolvable Systems” by Clay Shirky.
This paper was written a long time ago in the ancient year of 1996 by the web’s timeline, but everything in it still holds on why the web won and some possibilities of how we can move forward from where we are today. Under the tagline for his paper Clay has the summary “Why something as poorly designed as the Web became The Next Big Thing, and what that means for the future.”
Clay starts by pointing out how bad the Web is:
If it were April Fool’s Day, the Net’s only official holiday, and you wanted to design a ‘Novelty Protocol’ to slip by the Internet Engineering Task Force as a joke, it might look something like the Web:
The server would use neither a persistent connection nor a store-and-forward model, thus giving it all the worst features of both telnet and e-mail.
The server’s primary method of extensibility would require spawning external processes, thus ensuring both security risks and unpredictable load.
The server would have no built-in mechanism for gracefully apportioning resources, refusing or delaying heavy traffic, or load-balancing. It would, however, be relatively easy to crash.
Multiple files traveling together from one server to one client would each incur the entire overhead of a new session call.
The hypertext model would ignore all serious theoretical work on hypertext to date. In particular, all hypertext links would be one-directional, thus making it impossible to move or delete a piece of data without ensuring that some unknown number of pointers around the world would silently fail.
The tag set would be absurdly polluted and user-extensible with no central coordination and no consistency in implementation. As a bonus, many elements would perform conflicting functions as logical and visual layout elements.
HTTP and HTML are the Whoopee Cushion and Joy Buzzer of Internet protocols, only comprehensible as elaborate practical jokes. For anyone who has tried to accomplish anything serious on the Web, it’s pretty obvious that of the various implementations of a worldwide hypertext protocol, we have the worst one possible.
Except, of course, for all the others.
The web, however, was better than the contenders of that time. He argues that all the other formats, such as Gopher, Interactive TV, and so on were too well designed and had too much internal consistency:
These various [non-web] protocols and services [Gopher, Interactive TV, AOL, etc.] shared two important characteristics: Each was pursuing a design that was internally cohesive, and each operated in a kind of hermetically sealed environment where it interacted not at all with its neighbors. These characteristics are really flip sides of the same coin — the strong internal cohesion of their design contributed directly to their lack of interoperability. CompuServe and AOL, two of the top online services, couldn’t even share resources with one another, much less somehow interoperate with interactive TV or CD-ROMs…In other words, every contender for becoming an “industry standard” for handling information was too strong and too well-designed to succeed outside its own narrow confines. So how did the Web manage to damage and, in some cases, destroy those contenders for the title of The Next Big Thing? Weakness, coupled with an ability to improve exponentially.
Clay then goes on to argue that successful systems must be evolvable and gives three rules:
Evolvable systems — those that proceed not under the sole direction of one centralized design authority but by being adapted and extended in a thousand small ways in a thousand places at once — have three main characteristics that are germane to their eventual victories over strong, centrally designed protocols.
Only solutions that produce partial results when partially implemented can succeed. The network is littered with ideas that would have worked had everybody adopted them. Evolvable systems begin partially working right away and then grow, rather than needing to be perfected and frozen. Think VMS vs. Unix, cc:Mail vs. RFC-822, Token Ring vs. Ethernet.
What is, is wrong. Because evolvable systems have always been adapted to earlier conditions and are always being further adapted to present conditions, they are always behind the times. No evolving protocol is ever perfectly in sync with the challenges it faces.
Finally, Orgel’s Rule, named for the evolutionary biologist Leslie Orgel — “Evolution is cleverer than you are”. As with the list of the Web’s obvious deficiencies above, it is easy to point out what is wrong with any evolvable system at any point in its life. No one seeing Lotus Notes and the NCSA server side-by-side in 1994 could doubt that Lotus had the superior technology; ditto ActiveX vs. Java or Marimba vs. HTTP. However, the ability to understand what is missing at any given moment does not mean that one person or a small central group can design a better system in the long haul.
I know we sometimes get frustrated with the state of the web today, but its useful to know why we are here, and what characteristics any new ideas, features, or standards probably need to have in order to be successful; Clay’s paper helps guide me in terms of navigating these issues.
But fighting the web is like holding back the ocean; it will route around you or it will wear you down, but will never go away, and it will never tire or give up. Yet in spite of the futility of fighting the web, Silverlight is being positioned in opposition to the web, not in support of it
This is one of a few great quotes from DeWitt Clinton’s post On Fighting the Web itself. DeWitt is a colleague at Google, one that I have shared offices with, and great conversations. He has very strong ethics, but at the same time is very practical. But, back to his writing.
This is not a post saying “the Open Web rules and the proprietary Web is evil”. If you actually read this carefully you see a very interesting argument that covers:
We can’t be blind:
The short answer is that the technology behind Silverlight, and most certainly the company creating it, has the potential of changing how the web itself works.
The Web has strengths, but man it is tough to work with:
If you’re a web developer then you’ve felt the acute pain involved in writing applications inside the browser. Even armed with the most state-of-the-art toolkits, such as jQuery, Dojo, etc., you’re still limited to the available runtime of HTML, CSS, and JS, and worse, the absolute morass of cross-browser incompatibilities and restricted access to native client-side capabilities. I remain in awe of what people have accomplished in this environment, but I’m sad that this is all we’ve been able to accomplish so far.
Man, if the client is involved… evolution is slooooow:
The web revs slowly. Very, very slowly. In 10 years we’ve seen virtually no meaningful advances in the the ubiquitous web client; just a painful slog forward as web developers learn to eek out just a little more functionality in a constrained environment. Progress is slow because revving the ubiquitous client requires the coordination of multiple parties, not all of whom have shown consistent interest in working together to move the web forward.
There is some hope for an Open Web-style speedup:
More recently we’ve seen some earnest attempts at breaking that cycle. Rather than wait for the entire web to catch up, projects like Gears seek to rev the client from the inside out. It may take several years for standards like HTML5 to be widely deployed, but if developers can gain a toehold inside the client and start forcing the issue immediately then we’ll quickly see what works and what doesn’t, and be that much more informed about what to standardize and adopt as part of the long-term web platform.
The proprietary folks have a huge advantage, as they can just innovate and run without getting consensus:
But there’s another approach, an approach best exemplified today by the Flash runtime, whereby one doesn’t seek to improve the web from the inside, but rather replace it entirely. Sure, technologies like Flash take advantage of the web via http-based delivery mechanisms and in that they run inside the browser, and yes, they can use network connections like anything else, but these alternate runtimes fundamentally divorce themselves from the web ecosystem, and in doing so gain a significant advantage, but at a cost.
In spite of circumventing the web — no, because they circumvent the web — these new runtimes have the potential of offering a far better developer experience, and hence, a far better user experience, then the least-common-denominator of the standard widely-deployed ubiquitous browser runtimes of today.
And, thus, the proprietary stuff can be very good indeed:
Which leads us to Silverlight: Silverlight is positioned to take the fork-and-forget approach to the web pioneered by Flash and bring to it an unprecedented wealth of technology and corporate might. With a better underlying runtime and VM, better tool support, far superior multi-language capabilities, and more marketing muscle, Silverlight has all the potential to make rapid and noticeable inroads over the next several months, cleaving a large section clean out of the web.
And the scary thing? That this isn’t entirely a bad idea. The browser itself is anemic, the dependency on a single language is a handicap, the security models simultaneously constricting and flawed, the development environments underpowered, and frankly, the whole ecosystem is deserving of a major disruption. We’ve lived too long thinking that what we have today is good enough.
And will get better, fast:
Granted, these technologies won’t be perfect at first. On the contrary, they might be slow, cumbersome to deploy, buggy, and feature deprived. But right now that doesn’t matter. The strategy is all about getting a wedge in place, a bit of leverage that can be used to further pry open a vector for escaping the existing ecosystem. And over time, as the technology improves and adoption grows, so will the size of that tear in the fabric of the web.
But, there is a reason why the Web does so well:
But fighting the web is like holding back the ocean; it will route around you or it will wear you down, but will never go away, and it will never tire or give up. Yet in spite of the futility of fighting the web, Silverlight is being positioned in opposition to the web, not in support of it.
Why in opposition to the web? This stems from the principle that the web is axiomatically defined as an open system, where the underlying technologies are resistant to the centralization of control, where the protocols and formats are extensible and malleable, and where the power to effect change is shared and distributed. The DNA of the web is one of ceding control, and of learning to work with, rather than against, the collective wisdom and power a larger community.
Whereas a development monoculture, a centralization of control, and a tight grasp on the ability to change and adapt, all stand against these basic ideals, and give rise to the forces that, given enough time, will erode and eat away at any temporary advantage gained.
A violation of these principles does not necessarily make for a bad technology, but it does make it something other than the web.
And finally, and this is so key, the answer isn’t to try to destroy the innovation in Flash, Silverlight, and others. Instead, the biggest win will be for us to make technology from those worlds into the Web itself. If we can do that, I think it will be a win-win, and we will have a much better Web to show for it:
But the call to action here is not to go and try to fight the disruptive technology. On the contrary, the ideas are sound and the improvements are very much needed. No, the call is to discover ways in which these ideas can become a part of the web, rather than working to tear it apart.
I do not want to see ambitious attempts like these fail. Just the opposite — I want to see them succeed. But success on the web requires a different kind of DNA, the type of DNA that is difficult to adopt when one’s attention is focused on fighting the web itself.
Brad Neuberg got a huge amount of feedback on his call for a definition of the Open Web. He distilled that information and tried hard to come up with something that fits into one sentence, and ended up with this:
The Open Web is an interoperable, ubiquitous, and searchable network where everyone can share information, integrate, and innovate without having to ask for permission, accessible through a powerful and universal client.
His litmus test for this asks if the technology in question has:
Composability The ability to innovate, link, contribute, search, and integrate without red tape, fear of a lawsuit, or having to ask “please?”
Interoperability The ability for developers to interoperate without having to know of each others existence
Ubiquity The ubiquity of a set of open technologies and services agreed upon by the widest possible community
Universal Client Empowering and evolving the browser and web technologies as a universal client
Alex Russell has another one of his insightful posts titled Power and Authority. He talks about the core tenets and then ties it to the W3C, and who we should be “blaming” for the slow upgrade of the Web, and it requires a look in the mirror:
As a case study in putting your faith in the wrong idols, you can’t do better than posts like this which “blame the W3C†(via Molly). Blaming the W3C for not pushing the web forward is both humorously off-target and distressingly common. I’ve written about this before, but fundamentally you can’t blame the W3C for failing to act because it’s not the W3C’s job to act. An MBA should be able to tease this out a bit more effectively – any decision only requires that you have answers for five questions: why? what? how? when? who?
Answering these for pushing the web forward is straightforward, even on a simplistic level:
Why?: it’s too hard to build reasonably sophisticated interactions with current web technology
What?: new tags, JS and DOM APIs, CSS syntax, and renderer support for all of the above. Eventually, a spec or five reflecting these new technologies.
How?: we could try asking the W3C to do it, but they don’t have any power. When they’ve been left to their own devices, the W3C has failed. Miserably. Over and over and over again. Instead, browser makers should introduce new stuff and then agree to agree on it (via the W3C or similar organizations).
When?: introducing new features in any given browser seems doable in short-order. In the case of Open Source browsers, the answer is “as soon as someone decides to invest in themâ€. Competition has even spurred Microsoft to some level of action. The likely time-scale for new features over all, though, appears to be on the order of 5+ years. That’s clearly not soon enough. TODO: investigate ways to speed this up.
Who?: browser makers and others in a position to affect the code that goes into the renderers we use.
Figuring out “how†leads you directly to “who†in this case. The action we all want is the sole purview and responsibility of the browser vendors and they alone have the power to push the web forward. The “web standards community†has made it clear that they’ll need the imprimatur of some authoritative body where agreement can be forced, but that hasn’t kept the browser vendors from taking the initiative there, either. The big, open questions then center around how the “web standards community†can make enough room for renderer vendors to try out new stuff, since that’s how we get new things. Demanding agreement on what to do before trying it out demonstrably doesn’t work, so it’s then imperative that there be a mechanism for the web to iterate prior to standardization. In fact, I’ll argue that this is now the biggest reason that Paul Ellis isn’t getting the improvements he wants out of the web: there’s no mechanism in place by which any browser vendor can take significant risks without incurring the wrath of a swarm of WaSPs, or worse. Attempts to even begin to lay the groundwork for such a mechanism have been shot down forcefully by may folks who, like Paul, view “fixing the web†as the W3C’s job.
Standards bodies are animated only by the needs of industry to reduce costs by forcing vendors to agree on things. Like Open Source, they can act as a back-stop to the monopoly-creating power of network effects by ensuring that the price of software commodities eventually does reach zero. In this context, then, the W3C’s only effective function is to drive consensus when visions for how to go forward diverge or lead down proprietary ratholes. Asking the W3C for more is the fast path to continued disappointment.
The W3C is just a sail and all sails need the wind to function. You can’t blame the sail for the wind not blowing.
He talks about how languages are branded, e.g. “Java†is enterprise. One of his main points is that brands are “const identifiersâ€, i.e. it takes an entire generation to change brand perception, so it’s often more effective to simply re-brand. e.g. GTE had a poor brand, so they tried a self-deprecating ad campaign, which backfired, and subsequently re-branded to Verizon.
He then mentions Javascript has a branding problem, because it represents “browser†and “toy language†and “damnit, I gotta learn Javascript†and it’s the language no-one wants to use. He also notes the name itself isn’t great either, nor the rhino imagery. (I’m not sure why Steve assumed many programmers would associate Javascript with rhinos; the Rhino product and O’Reilly cover weren’t really promiment enough to do that; rhino ain’t camel!).
But, wait a minute, didn’t we already have a rebranding?
Javascript has already been rebranded. In fact, I’d go so far as to say “Ajax†was one of the most successful rebrandings in software history.
Although technically Ajax != JavaScript, and the rebranding is really DHTML, he is right. Ajax rebranded the Web, and we have all benefited from it.
I also think that this is just the beginning, and we haven’t seen the best of the Ajax revolution yet.
A couple of posts from my personal land that are related to the Ajax world:
First up, I am building an application that uses some canvas and ran into an issue handling events which sent me down a merry path that took me through: initMouseEvent, error fun (Component returned failure code: 0×80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMEventTarget.dispatchEvent…..] ), tabindex=0 (thanks Alex), and finally Event.stop(e).
It reminded me of how much I have forgotten, and how debugging can be too hard for Ajax applications. The good news, was that the solution was simple, and the event system does have some very nice properties.
Secondly, some folks tried to make a story out of Passpack adding an AIR application, but we quickly saw how they ended up with both an AIR app, and Gears support in their browser based application. I talk about how this is a valid choice:
I also expect to see more joint applications. Gears functionality is working into HTML5 the standard, which will end up in WebKit (as Apple is great in that regard), and AIR uses…. WebKit as its renderer!
I really hope that AIR will be able to bridge to those APIs, and you get the best of all worlds. I would love to use the Workerpool API from within an AIR application that is doing a lot of JavaScript work for example.
