Cloud 2
Browsers are, really, not a very good platform for building Web applications. I take 'Web application' in a much broader sense here; any interactive Web site, really, is somewhat vulnerable to the same problems.
Separation of concerns. The Unix philosophy is, supposedly, to do one thing and do it well. The idea is to have a collection of specialized tools that are very good at some specific tasks and very good at talking to each other. In the command line world, I end up with a very powerful text editor and a lot of little programs for finding files, examining files, sorting text, rearranging text, transforming text, and so forth. Because everything is just text, it's easy to take the output of one program and feed it to another. Piping is integral to using the command line with Unix(-ish) systems.
But the same goes for a lot of other areas, albeit not so explicitly. A lot of young sprite artists who haven't yet figured out how to use a more powerful image editor might create art in a simple editor like Paint, mask out transparent areas with some Web tool, and convert to an appropriate final format with IrfanView. 3D animators and designers will use an assortment of tools for various steps from research to creation to polish.
More functionality in a single app means development resources are spread more thinly. There are more places for bugs to hide. More interactions between features mean more edge cases that might not work correctly and more resources spent making it work. Keep it simple, stupid.
The problem, then, is that Web apps don't work together very well. Rather than being designed to take data from anywhere and pump it anywhere else, Web apps are walled gardens by design. While I can export everything from LiveJournal, for example, it's extremely rare to find a comparable service that will let me import an entire history. If I want to move from FA to DA, well, that sucks for me; I have to reupload everything manually, rewatch everyone manually (after tracking them down!), and spread the word about the move manually.
As such, Web sites try to build in every relevant feature they can. Anything they don't have, well, that sucks for you. Guess you get to move, after discovering that a site is lacking some feature you need. Anyone who even wants to communicate with other sites is going to have problems, as there's not very much work done in the area yet; you'd have to create your own entire cross-site communication system yourself. Even OpenID is glacially slow to gain ground after all these years, and it's very rarely used as an outright replacement for a traditional login.
(This has crossed over a bit with walled gardens, which I want to go into tomorrow.)
Web browsers themselves, unfortunately, are stuck handling a lot of features at once. You could say the one thing they do well is "browse the Web", but that implies a growing mishmash of various flavors of XML and styling rules that all have to work together.
But for similar reasons, I'm not very comfortable having IRC clients inside a browser (like Chatzilla) or IM client (like Pidgin), or having an email client inside a browser, or a video game inside a browser, or anything else that's not even remotely related to browsing the Web. These things make the browser more fragile, and if any one part of it goes down, everything else you were doing does, too. And any program shoehorned into a second program will be constrained by the limits of the first: Pidgin IRC is not nearly as customizable as a dedicated IRC client, and Quake Live doesn't interact with a window manager very well.
Process management. Process management does help alleviate some of the problems with cramming lots of apps into one browser, such as ballooning memory use. And now most browsers are trying to implement it, with each tab being a separate process that can die off when it's closed (or crashes) and release whatever resources it was holding. My only comment is that we already have decades of effort put into doing exactly this sort of thing. It's called an operating system.
Hardware access. Tablet pressure. Webcam. Hardware acceleration that doesn't suck. Printers and scanners. Browsers can't access any of these. Some of these would be cool to have for certain applications, but this is again turning into replicating all the functionality of an operating system. If the day comes that iPods are updated over the Web, I'm just going to give up and go live in a cave.
Language choice. If I want to make a desktop application, I can use GTK+ or wxWidgets or Qt; I can use C or Java or Python. All manner of toolkits exist for all manner of languages for doing whatever I want. For the Web, meanwhile, we're stuck with HTML, CSS, and JavaScript. HTML is a bit of a mess and not very well designed as a document markup language. CSS is still built primarily for aesthetics rather than large-scale structure. JavaScript is a fascinating language-I like its object system-but would certainly not be my first choice if other languages were available. There are a handful of toolkits that try to hide all of this behind another language that compiles to JavaScript, but they are a leaky abstraction at best.
The worst part, though, is that we're stuck with what we have now. New versions of HTML and CSS take years of squabbling before they're considered ready for use, and then we have to wait for (at least) four different browser makers to implement it all. With IE lagging behind by years, we're pretty much doomed to the status quo.
(This one sucks. Hoping for something better tomorrow.)
Separation of concerns. The Unix philosophy is, supposedly, to do one thing and do it well. The idea is to have a collection of specialized tools that are very good at some specific tasks and very good at talking to each other. In the command line world, I end up with a very powerful text editor and a lot of little programs for finding files, examining files, sorting text, rearranging text, transforming text, and so forth. Because everything is just text, it's easy to take the output of one program and feed it to another. Piping is integral to using the command line with Unix(-ish) systems.
But the same goes for a lot of other areas, albeit not so explicitly. A lot of young sprite artists who haven't yet figured out how to use a more powerful image editor might create art in a simple editor like Paint, mask out transparent areas with some Web tool, and convert to an appropriate final format with IrfanView. 3D animators and designers will use an assortment of tools for various steps from research to creation to polish.
More functionality in a single app means development resources are spread more thinly. There are more places for bugs to hide. More interactions between features mean more edge cases that might not work correctly and more resources spent making it work. Keep it simple, stupid.
The problem, then, is that Web apps don't work together very well. Rather than being designed to take data from anywhere and pump it anywhere else, Web apps are walled gardens by design. While I can export everything from LiveJournal, for example, it's extremely rare to find a comparable service that will let me import an entire history. If I want to move from FA to DA, well, that sucks for me; I have to reupload everything manually, rewatch everyone manually (after tracking them down!), and spread the word about the move manually.
As such, Web sites try to build in every relevant feature they can. Anything they don't have, well, that sucks for you. Guess you get to move, after discovering that a site is lacking some feature you need. Anyone who even wants to communicate with other sites is going to have problems, as there's not very much work done in the area yet; you'd have to create your own entire cross-site communication system yourself. Even OpenID is glacially slow to gain ground after all these years, and it's very rarely used as an outright replacement for a traditional login.
(This has crossed over a bit with walled gardens, which I want to go into tomorrow.)
Web browsers themselves, unfortunately, are stuck handling a lot of features at once. You could say the one thing they do well is "browse the Web", but that implies a growing mishmash of various flavors of XML and styling rules that all have to work together.
But for similar reasons, I'm not very comfortable having IRC clients inside a browser (like Chatzilla) or IM client (like Pidgin), or having an email client inside a browser, or a video game inside a browser, or anything else that's not even remotely related to browsing the Web. These things make the browser more fragile, and if any one part of it goes down, everything else you were doing does, too. And any program shoehorned into a second program will be constrained by the limits of the first: Pidgin IRC is not nearly as customizable as a dedicated IRC client, and Quake Live doesn't interact with a window manager very well.
Process management. Process management does help alleviate some of the problems with cramming lots of apps into one browser, such as ballooning memory use. And now most browsers are trying to implement it, with each tab being a separate process that can die off when it's closed (or crashes) and release whatever resources it was holding. My only comment is that we already have decades of effort put into doing exactly this sort of thing. It's called an operating system.
Hardware access. Tablet pressure. Webcam. Hardware acceleration that doesn't suck. Printers and scanners. Browsers can't access any of these. Some of these would be cool to have for certain applications, but this is again turning into replicating all the functionality of an operating system. If the day comes that iPods are updated over the Web, I'm just going to give up and go live in a cave.
Language choice. If I want to make a desktop application, I can use GTK+ or wxWidgets or Qt; I can use C or Java or Python. All manner of toolkits exist for all manner of languages for doing whatever I want. For the Web, meanwhile, we're stuck with HTML, CSS, and JavaScript. HTML is a bit of a mess and not very well designed as a document markup language. CSS is still built primarily for aesthetics rather than large-scale structure. JavaScript is a fascinating language-I like its object system-but would certainly not be my first choice if other languages were available. There are a handful of toolkits that try to hide all of this behind another language that compiles to JavaScript, but they are a leaky abstraction at best.
The worst part, though, is that we're stuck with what we have now. New versions of HTML and CSS take years of squabbling before they're considered ready for use, and then we have to wait for (at least) four different browser makers to implement it all. With IE lagging behind by years, we're pretty much doomed to the status quo.
(This one sucks. Hoping for something better tomorrow.)