Monday, November 17, 2008
Fixing the Web, Part I
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.
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:
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.
[Disclaimer: I work for Google. However, this opinion piece is my own and does not represent an official stand of Googles]
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.
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.
[Disclaimer: I work for Google. However, this opinion piece is my own and does not represent an official stand of Googles]
Labels: ajax, fixtheweb, open web
Comments:
Links to this post:
<< Home
I think developers on the web have done themselves a disservice by continuing to submit to the tyranny of the "IE problem". By being willing to create workarounds IE's problems are allowed to remain.
There are enough people out there now that the "we can't just discard N% of the audience" doesn't play quite as well as it once used to.
Obviously there's a fine line of balance here: we don't want to return to the days of "You need to use browser X to use this site" but we do want lightweight adherence to standards.
There are enough people out there now that the "we can't just discard N% of the audience" doesn't play quite as well as it once used to.
Obviously there's a fine line of balance here: we don't want to return to the days of "You need to use browser X to use this site" but we do want lightweight adherence to standards.
@cdent Unfortunately there aren't a lot of ways to advise the user to change their browser without annoying them. Users aren't developers and many will not have heard of anything besides the "blue e".
I'm trying to make a little headway in this issue on a project I'm working on. I haven't checked the layout in IE6, and I don't intend to.
When I implement OpenID as an alternative login I'll make sure that every user who visits the login/registration page will come away knowing *what* OpenID is, and hopefully they might sign-up for an account (or discover they already have one).
I think extensions/Add-Ons have a big part to play as far as innovating goes - and I'm glad IE7 added support for this. I'm a little scared IE will rely on users to offer innovations in the future however.
I'm trying to make a little headway in this issue on a project I'm working on. I haven't checked the layout in IE6, and I don't intend to.
When I implement OpenID as an alternative login I'll make sure that every user who visits the login/registration page will come away knowing *what* OpenID is, and hopefully they might sign-up for an account (or discover they already have one).
I think extensions/Add-Ons have a big part to play as far as innovating goes - and I'm glad IE7 added support for this. I'm a little scared IE will rely on users to offer innovations in the future however.
One of the best features that Firefox has is the auto-update notification. This takes it out of the users' hands and keeps their browser up-to-date.
The Internet Explorer mess isn't entirely Microsoft's fault. I think a large part of the blame lies with corporate America. There are far too many IT departments unwilling or unable to upgrade from IE6 because internal sites will only render with that browser.
I personally think that the only way to move on from IE6 is for Microsoft to give an ultimatum. To make it known that IE7 or IE8 will be pushed via windows update on a certain date, to ALL machines. Enough time has passed to allow people to fix their sites to render properly with a modern browser.
The Internet Explorer mess isn't entirely Microsoft's fault. I think a large part of the blame lies with corporate America. There are far too many IT departments unwilling or unable to upgrade from IE6 because internal sites will only render with that browser.
I personally think that the only way to move on from IE6 is for Microsoft to give an ultimatum. To make it known that IE7 or IE8 will be pushed via windows update on a certain date, to ALL machines. Enough time has passed to allow people to fix their sites to render properly with a modern browser.
Wonderfull article. And tottaly agreed. I use to say in my Twitter that the browser and all web technologies must be re-invented from scratch. I can't handle CSS. I'ts just too much work to do so simple things. And must of us developers can't see this: we are blind for the standards race that everyone is missing the point: the costumer. I have to deliver products, not code-art-pieces. Semantics are cool but if I have to choose, I would preferer deliver my work faster. My dad could not believe when I told him the same work I do today takes so much longer to be developed that 5 years ago.
What I miss most are web technologies that behave _exactly_ like the desktop development. Programing in VB is so much easier and fast, so more productive. I think web development should folllow the same steps. EVeryone talks about XML, but for Christ sake, we do not have comboxes in HTML ! The simpliest of the UI controls are not in the web (just for start)
To begining designing the whole web infraestructure again, we have to get what we got better: web allow separation of semantics, layout, server-side, client-side. This must continue. Te UI controls and language description (HTML, CSS) are just bad: must be re-created, based in the desktop apps. Web must have the same controls and UI elements of the desktop. Layout descriptors, to create fluid-design for all kinds of resolution (in the real world, CSS only work well with fixed width - pixels).
Just to begin.
I hope more of this series
Lex Blagus, lex.blagus@gmail.com
What I miss most are web technologies that behave _exactly_ like the desktop development. Programing in VB is so much easier and fast, so more productive. I think web development should folllow the same steps. EVeryone talks about XML, but for Christ sake, we do not have comboxes in HTML ! The simpliest of the UI controls are not in the web (just for start)
To begining designing the whole web infraestructure again, we have to get what we got better: web allow separation of semantics, layout, server-side, client-side. This must continue. Te UI controls and language description (HTML, CSS) are just bad: must be re-created, based in the desktop apps. Web must have the same controls and UI elements of the desktop. Layout descriptors, to create fluid-design for all kinds of resolution (in the real world, CSS only work well with fixed width - pixels).
Just to begin.
I hope more of this series
Lex Blagus, lex.blagus@gmail.com
Re, major problems that need fixing:
Far too little attention has been given in web standards development to the need for web applications to interoperate. Browsers are light years ahead of web apps in being able to process the same markup.
At the web app document exchange level, however, we don't yet even have a standard markup for such a common data structure as footnotes. And it's not on the agenda for CSS 2. It shouldn't be, IMHO, because the footnote call and footnote elements belong on the (X)HTML side of the separation of content and presentation. With CSS near completely stuck in site and page templates, footnote call and footnote elements in CSS would not do much for interoperability of web apps.
As a result of such issues, interop between web apps really isn't happening. Mashups are a poor substitute for apps being able to process the same data.
Bottom line: for such reasons, web apps do not achieve the networking economic benefits of interoperability. Everyone has their own file formats, just as has been true of client-side word processors for some three decades.
Far too little attention has been given in web standards development to the need for web applications to interoperate. Browsers are light years ahead of web apps in being able to process the same markup.
At the web app document exchange level, however, we don't yet even have a standard markup for such a common data structure as footnotes. And it's not on the agenda for CSS 2. It shouldn't be, IMHO, because the footnote call and footnote elements belong on the (X)HTML side of the separation of content and presentation. With CSS near completely stuck in site and page templates, footnote call and footnote elements in CSS would not do much for interoperability of web apps.
As a result of such issues, interop between web apps really isn't happening. Mashups are a poor substitute for apps being able to process the same data.
Bottom line: for such reasons, web apps do not achieve the networking economic benefits of interoperability. Everyone has their own file formats, just as has been true of client-side word processors for some three decades.
"You shouldn't have to be a CSS wizard to get multiple columns, for example."
You don't if you're doing simple columns. The only wizardry comes in when you're doing really complicated stuff.
"JavaScript++"
Please, no. Scripting in the browser was all fun and games until someone decided to build office suites with it. Now we've just got loads of unholy crap (jQuery et al, Google Docs et al) that just should not be in a browser and are brutally inefficient.
"Browser's need much better native multimedia support"
Why native? Browsers should be able to retrieve and render web pages: multimedia embedded in web pages can be rendered by the plugin of your choice.
That said, I do agree we need more, better, and more common plugins for common formats.
Nothing really to say on tooling... I hate IDEs.
"Solve the standards problem"
Industries much older than the web or ever the Internet are still struggling with this. We may solve it someday, but this is a really hard problem and no one has come close yet.
You don't if you're doing simple columns. The only wizardry comes in when you're doing really complicated stuff.
"JavaScript++"
Please, no. Scripting in the browser was all fun and games until someone decided to build office suites with it. Now we've just got loads of unholy crap (jQuery et al, Google Docs et al) that just should not be in a browser and are brutally inefficient.
"Browser's need much better native multimedia support"
Why native? Browsers should be able to retrieve and render web pages: multimedia embedded in web pages can be rendered by the plugin of your choice.
That said, I do agree we need more, better, and more common plugins for common formats.
Nothing really to say on tooling... I hate IDEs.
"Solve the standards problem"
Industries much older than the web or ever the Internet are still struggling with this. We may solve it someday, but this is a really hard problem and no one has come close yet.
First of all, I agree completely with cdent's and Ross' remarks. Until IE is unable to access the full capability of key websites, the IE problem won't go away.
One of the primary problems in building applications is the disconnect between client and server. This problem wasn't there with VB, but VB also didn't lend itself to separation of concerns. Frameworks such as Sproutcore (http://www.sproutcore.com/) are a step in the right direction. An additional step will be freeing ourselves from the relational database mess.
As far as IDEs are concerned, we're beginning to see some work here such as Wavemaker (http://wavemaker.com/), but they're not taking advantage of existing frameworks such as dojo (http://www.dojotoolkit.org/) so it is very difficult to extend capability. Having data aware controls would be a HUGE step forward, but I don't see anything like XFORMS having widespread acceptance. (BTW, Sproutcore enables this).
I'm not associated in any way with any of the organizations or projects listed.
One of the primary problems in building applications is the disconnect between client and server. This problem wasn't there with VB, but VB also didn't lend itself to separation of concerns. Frameworks such as Sproutcore (http://www.sproutcore.com/) are a step in the right direction. An additional step will be freeing ourselves from the relational database mess.
As far as IDEs are concerned, we're beginning to see some work here such as Wavemaker (http://wavemaker.com/), but they're not taking advantage of existing frameworks such as dojo (http://www.dojotoolkit.org/) so it is very difficult to extend capability. Having data aware controls would be a HUGE step forward, but I don't see anything like XFORMS having widespread acceptance. (BTW, Sproutcore enables this).
I'm not associated in any way with any of the organizations or projects listed.
With regard to "solving the distribution problem": Safari, Firefox, and Chrome are still nowhere close to Paper Airplane, and Paper Airplane is part of really solving the distribution problem.
Hope you're doing well! Sorry I've been so out of touch. Looked at a coworking space here in Buenos Aires today; will probably sign up there tomorrow.
Hope you're doing well! Sorry I've been so out of touch. Looked at a coworking space here in Buenos Aires today; will probably sign up there tomorrow.
@Kragen: Hey Kragen! Long time no chat. Sounds like you are doing well and are still in South America. I'm not sure if Paper Airplane solved the distribution problem in terms of disseminating innovations faster to an existing installed base; it was more about decentralizing the storage of data itself.
What are you hacking on these days?
What are you hacking on these days?
@Brad Neuberg: Oh! I misunderstood the sense in which you meant "distribution problem" — I thought you meant "the problem of building a distributed system", not "the problem of getting software from authors to users". I agree they're both pretty important.
I'm sorry I've been so out of touch! Yes, I'm still in South America. Lately I've been hacking on watchdog.net and some other things. Not spending enough time trying to solve the other distribution problem. What have you been hacking on?
Post a Comment
I'm sorry I've been so out of touch! Yes, I'm still in South America. Lately I've been hacking on watchdog.net and some other things. Not spending enough time trying to solve the other distribution problem. What have you been hacking on?
Links to this post:
<< Home
Subscribe to Posts [Atom]
