5 ms·

Joel explains how a new monopoly will emerge around AJAX

101 points by herdrick 19y ago

jimbokun 19y ago
All made possible by 6000 packages of ramen noodles provided by pg: "And Paul Graham gives them another 6000 boxes of instant noodles to eat, so they stay in business another three years perfecting things."
- Readmore 19y ago
  Haha I know! I was just about to post that quote myself!
- Kaizyn 19y ago
  So that's why people go to YCombinator for startup funding... the free Ramen!
- mdemare 19y ago
  This made me laugh too: "But then, while you're sitting on your googlechair in the googleplex sipping googleccinos and feeling smuggy smug smug smug..."
  - dpapathanasiou 19y ago
    Between that and the ramen quip, Spolsky comes across as pretty smug himself.
ph0rque 19y ago
lol @ this line: "...you'll tell your children how excited you were to get 2GB to store email, and they'll laugh at you. Their nail polish has more than 2GB."
- create_account 19y ago
  That's neither funny nor witty.
pius 19y ago
Joel just blew my mind. Awesome article.
rms 19y ago
So what would it take to make NewSKD? and could it realistically be done by a YC style startup?
- palish 19y ago
  It would simply take a browser plugin for every type of browser. NewSDK code would be inside HTML comments, just like conditional comments are. The browser plugin would parse this code and cache it (aka compile it). From there, it would be trivial to implement image copy and paste. Keep in mind that I have no idea what the limitations of a browser plugin are, but if one can: 1) parse the raw source code that's sent down from the server, including comments 2) manipulate the DOM 3) open an outgoing connection Then you could do, well, anything. Embed Ruby into pages, for example. The reason you can do that is because the Ruby interpreter doesn't have to be a part of your browser plugin. All you have to do is convince users to download your C++ app that DOES contain a Ruby interpreter and runs in the background, then your plugin communicates with that via a socket. Your app then issues commands back to your plugin (you can think of those commands as assembly instructions) which manipulate the DOM or whatever else a plugin can do.
  - bokonist 19y ago
    I got the sense Joel was talking about an SDK that does not require a plugin. Otherwise it seems Flash and Silverlight already meet his requirements.
    - palish 19y ago
      Hmm.. They meet the requirements to an extent. They're really little islands of functionality. I'm talking about a plugin that can react to and manipulate HTML elements, persist across page loads, and doesn't have browser-specific quirks.
  - Readmore 19y ago
    I remember hearing about someone making a 'desktop' out of firefox. That would be the perfect way to implement some of the extra functionality he's talking about. Just run a browser as your window manager. Then you could build your interpreter into that and copy and paste between web applications as much as you want.
chaostheory 19y ago
Weird I thought the coming web ui monopoly was this little thing called Flash... I guess that's why MS came out with Silverlight and Google's paranoia came up with Google Gears...
- pius 19y ago
  Yeah, Flash kept coming to mind as I read the article.
- Tichy 19y ago
  I don't think so, I still hate Flash, and I am not the only one. In fact, I just switched to Linux, only to find that flash makes firefox crash (seems I was unlucky, it works fine for others). The point: just as always, flash simply doesn't work for everyone, so it is out. The last big company I worked for also didn't provide it's employees with flash.
  - mojuba 19y ago
    Flash is the only widely available system that gives you full control over every pixel in the browser and it does that in a pretty efficient manner. Although, yes, something intuitively stops me, too, from getting excited about Flash. Maybe it's that it's closed/proprietary and I just don't trust today's Adobe anymore. They definitely want to be the microsoft of the web. So there's Silverlight (well, potentially), Flash and still no decent alternative from the open-source world. No Mono/deIcaza stuff please. Thanks.
bokonist 19y ago
A couple of problems with his argument: 1) Web entrepreneurs working now still need to optimize for speed. It's not like the desktop world where you are launching a year or two from now and can wait for the computers to catch up. You are launching a month from now and it needs to be fast. I would prefer to use a web mail client other than GMail, simply because I'm scared of my Google dependency. But every other web email client I've used ( Yahoo, Joyent, inbox.com, Zimbra) feels much slower. Google spends enormous effort optimizing their javascript load times and it really pays off. 2) Broadband speeds are not growing at Moore's law. Terrible regulatory law trumps technological gains. 3) It be hard for a company to lock everyone into its javascript platform when the entire source code is downloadable. 4) The trouble with javascript is not cross browser incompatibility. If you use a good library and have learned common gotchas you should not have to spend too much time debugging IE ( I probably spend less than 10% of my javascript coding time on cross browser issues). The trouble with javascript is that there are still a number of things it just can't do, and won't be able to do until the browsers change. For instance, there is no way to detect the exact pixel size of a character of text. This makes it impossible to build a real word processor in javascript. Nor can you detect a collision between the opaque regions of two png images (this is needed for most simple 2-d games). Well ... it's almost impossible to do these things. I suppose you could define your own image and font formats completely in javascript, and render the entire screen using 1 pixel divs. But that's just crazy talk. It would be a huge library - maybe 250 MB - and would be very slow until computers got faster. And it would require eating at least 6000 packages of ramen to build the thing. Hmmmmm .... maybe I have an idea I can apply to YCombinator with ... :-)
- bootload 19y ago
  "... 3) It be hard for a company to lock everyone into its javascript platform when the entire source code is downloadable...." I hazard a guess that the real value is not (just) in the generated source code in the design tools - site used to generate the end result?
- Goladus 19y ago
  Another open question is how difficult it will be to obtain the different APIs. If NewSDK and ExtremeSDK are both compatible with your system, and both free/inexpensive, then monopoly conditions may not occur. People in the 90s had more reasons to choose only one platform.
greendestiny 19y ago
Unfortunately I really think this monopolist might just be Microsoft again. The web operating system is the browser, and when Microsoft start shipping silverlight with IE... The biggest challenge to this will be getting high performance out of javascript in firefox. Also a combination of svg for graphics and access to the local system via a google gears type api (I see firefox 3 has something like this planned or implemented). While this would all be nicely backwards compatible it wouldn't give you cut+paste support, some sort of MIME support for edit boxes/forms is needed perhaps.
- chaostheory 19y ago
  that's a good point... I think this is one of the key things Flash had to make its strong start (besides being fast and small) - as a bundle with IE then again I'm not sure how much freedom MS has this time around (anti-trust lawsuits and I think there may be some more pending settlements) or it would have been done with .NET on Windows already I could be premature - but I still think Adobe will eventually own web ui in the future... assuming that they eventually get it right on mobile devices
- stuki 19y ago
  If my future choices are being stuck coding in JS, Flash/As or Silverlight, I'm rooting for MS, monopoly or not. Despite what Joel seems to think, though, I still believe the general trend will be for successful browser apps to move out of confinement of the browser, rather than for successful desktop apps to move into it.
bootload 19y ago
"... Not just cut 'n' paste: cool mashup features like synchronization and single-point identity management (so you don't have to tell Facebook and Twitter what you're doing, you can just enter it in one place) ..." I've been doing something similiar to this. Here's what I'm finding working with lots of different 3rd party sites ... Using API's - not every site has an API or RSS so you have to CUT+PASTE :( - even sites with API's have poor documentation (code, txt) so it can be difficult to use - posting data (say to twitter,flickr ) is way easier than extracting via an API/RSS - no company(ies) want(s) their hard-won user data to be used commercially (check the legal agreements) so while you can integrate each site requires permission - yuk! - solve the password & authorisation problem for each 3rd party site Integration layer - abstract an API to talk to each service (eg: as Perl does to databases in the DBI module) - support the most popular sites that people use first (flickr, twitter, Facebook, MySpace etc) - constrain the features you want to support for each 3rd party site (eg: notifications by friends in twitter, or flickr. New books suggested in http://www.librarything.com http://www.librarything.com) - keep up with changes made to each service, handle bugs, quirky code Extraction layer - synchronise 3rd party added data and client side added data (the "add in 1 place" bit mentioned). This means being able to either/or add data at the client or get the data the user added at the 3rd party site as well and somehow sychronise them - you need tools to extract, manipulate RSS/ATOM feeds. A boon because you don't need API's Messaging layer - using your abstracted API be able to message various different services and here's the hard bit depending on the service. Do you want to send everyone on Twitter a photo update if you have entered 20 flickr photos? - you need to capture store, query, link check and update the various links, metadata and information that message generates. Presentation layer - layering of data. Intelligent hierarchies of data that be queried by other - flexible presentation layers that can export variety of data formats web pages as to XML, RSS files, mobile phone SMS, etc. - flexible presentation layer(s) that can support different levels of information from a complete archive of past posts to their titles or individual tags - metadata ... support things like tags, microformats at a per document level and be flexible enough to allow for more formats that arise. Of course on top of this you have to build something that others will use, that is bug free as possible in Javascript. Something on or along the lines of Yahoo's YUI ~ http://developer.yahoo.com/yui/ http://developer.yahoo.com/yui/ Maybe this YUI or NewSDK is what Steve Yegge meant when he was talking about the "Next big language" ? ~ http://steve-yegge.blogspot.com/2007/02/next-big-language.html http://steve-yegge.blogspot.com/2007/02/next-big-language.ht... In all this I can't help think that maybe just solving a few little problems might be a better starting point and if you do so make sure it's the open web and not some roach motel that sucks up data instead of allowing data to flow.
akshatch 19y ago
I think you are right that there is one entity who will come up with a uniform solution which will just get everybody to adhere to their set standard. What I fail to believe is that this is going to be a language or a SDK. Instead the real war in the internet will be who will keep your data together and present it to you in a uniform way. This step is already being taken by google with their whole integrate gmail, docs, calendar,... suite. What we are seeing the real Web OS being built and this is not any crap proclaiming to be WebOS.
paul 19y ago
He has some interesting ideas and analogies, but it's not clear that Joel actually understands AJAX/JS. The browser incompatibility problems are largely overblown, and the most annoying limitations are imposed by the browser (meaning that no JS library is going to fix them). He also doesn't seem to realize that all of the Google JS running in his browser IS generated by a compiler (from JS in most cases, from Java in a few others).
- tx 19y ago
  Agreed. Joel is growing old :-) He is young enough to keep up with major valley developments (Twitter and YComb) but too old to have a grasp on technical details (Java-to-JS-compilers, for instance). Another thing he is wrong about is "moore law of bandwidth": it does not exist. While CPUs are getting faster and RAM is growing like crazy, bandwidth is not growing. In fact I am starting to notice an annoying trend of businesses running on slower and slower connections. But his thoughts on parallels between terminal/HTML transition to Windows/FancySDK are cool nevertheless. He may not be right about everything, but something similar to what he's talking about sure will happen. Steve Yeggie blogged about inevitable "Rails for the Client" some time ago. Similar idea but expressed in more technical terms.
  - jimbokun 19y ago
    "While CPUs are getting faster and RAM is growing like crazy, bandwidth is not growing..." ...in the U.S.
    - mojuba 19y ago
      Maybe because the U.S. along with Europe, Japan, S.Korea and some other countries already hit today's bandwidth limits, while the rest of the world is just catching up in this regard. Although I'm a bit more optimistic about the possible application of Moore's law in communications. Some 20 years ago 9600bps seemed to be the physical limit for phone lines, and there was even proof for that based on physics. But see how many new protocols emerged since then. ADSL, for example, would have sounded like an alien technology 20 years ago, or take any high-speed wireless protocol in use nowadays. Essentially it's the same medium utilized by much, much faster protocols.
bootload 19y ago
"... new versions of the browsers come out that support cached, compiled JavaScript ..." Rhino supports this ~ http://www.javalobby.org/java/forums/t87870.html http://www.javalobby.org/java/forums/t87870.html ... http://developer.mozilla.org/en/docs/Rhino_JavaScript_Compiler http://developer.mozilla.org/en/docs/Rhino_JavaScript_Compil... Anyone tried this?
- wmf 19y ago
  But Rhino has nothing to do with browsers. If you want cached, compiled JavaScript, try Flash Player 9.
ratsbane 19y ago
Joel just hit the nail right on the thumb. His hypothetical NewSDK doesn't give javascript any new abilities nor would his NewSDK provide any new ways of using those abilities which couldn't be duplicated in other ways.
nostrademons 19y ago
It's happening already - the contenders are JQuery, Prototype, YUI, Mootools, Dojo, GWT, haXe, etc., along with Apollo/Silverlight/Parakey if you allow desktop plugins. We just don't know who the winner will be yet. Personally, my money is on JQuery (literally - I'm using it for my startup), but it really is too early to tell. Interestingly, nearly all the "serious" contenders are open-source: it's possible that the developer community learned their lesson from the Microsoft monopoly of the 1990s. It's very difficult to get any sort of programming tool adopted these days unless it's open-source.
axod 19y ago
I want those 3 minutes back I wasted reading this!!!
deleted 19y ago
[deleted]
chubbard 19y ago
Of all the Joel articles this one was better than most. As someone else said I see Joel has a very practical kinda guy. He so practical that I don't look to him for setting the future. I've never seen a practical programmer, such as Joel, make anything that is future. I digress. However, his practicality in this article was an interesting slant on the future. I do believe the next level is making my Google mail work with Flickr or vice versa. Right now all these applications are islands, but there is a lot of benefit to joining them into the larger part. Whatever, that is could be a great thing. Is it just an Web SDK? Is it the real Web OS? It's a practical prediction.
stoptypingnow 19y ago
First we need to remember Joel doesn't spend as much time on his blog entries as Paul Graham spends on his. With that in mind - what did Joel mean? Joel meant at leat these two things: a) Complex design patterns will be refactored into fewer elements. GWT is a nice try but Java isn't simplification - and you Java heads know this. b) Optimization isn't the only secret sauce to rely on. Companies that put all their eggs in this basket get burned by companies that understand the larger problem begging for a solution. When resource scarcity relaxes, the companies that understand this will automagically appear at the front of the line.
jsnx 19y ago
I think he's missing the point by focusing on the GUI -- it's a uniform userland, not a uniform appearance, that facilitates interoperability. User management, permissions and a model for resources go a long way toward making a platform. As Firefox, Silverlight & al. become more and more like desktops, virtualization allows Linux to become more like a cross-platform application environment. Web apps often find themselves recreating userland fundamentals. The people at Vita Nuova caught on to this a few years ago, and released a version of Inferno (Unix relative) as a browser plugin.

101 points by herdrick 19y ago

All made possible by 6000 packages of ramen noodles provided by pg: "And Paul Graham gives them another 6000 boxes of instant noodles to eat, so they stay in business another three years perfecting things."

Readmore 19y ago
Haha I know! I was just about to post that quote myself!
Kaizyn 19y ago
So that's why people go to YCombinator for startup funding... the free Ramen!
mdemare 19y ago
This made me laugh too: "But then, while you're sitting on your googlechair in the googleplex sipping googleccinos and feeling smuggy smug smug smug..."
- dpapathanasiou 19y ago
  Between that and the ramen quip, Spolsky comes across as pretty smug himself.

ph0rque 19y ago

lol @ this line: "...you'll tell your children how excited you were to get 2GB to store email, and they'll laugh at you. Their nail polish has more than 2GB."

create_account 19y ago
That's neither funny nor witty.

pius 19y ago

Joel just blew my mind. Awesome article.

rms 19y ago

So what would it take to make NewSKD? and could it realistically be done by a YC style startup?

palish 19y ago
It would simply take a browser plugin for every type of browser. NewSDK code would be inside HTML comments, just like conditional comments are. The browser plugin would parse this code and cache it (aka compile it). From there, it would be trivial to implement image copy and paste. Keep in mind that I have no idea what the limitations of a browser plugin are, but if one can: 1) parse the raw source code that's sent down from the server, including comments 2) manipulate the DOM 3) open an outgoing connection Then you could do, well, anything. Embed Ruby into pages, for example. The reason you can do that is because the Ruby interpreter doesn't have to be a part of your browser plugin. All you have to do is convince users to download your C++ app that DOES contain a Ruby interpreter and runs in the background, then your plugin communicates with that via a socket. Your app then issues commands back to your plugin (you can think of those commands as assembly instructions) which manipulate the DOM or whatever else a plugin can do.
- bokonist 19y ago
  I got the sense Joel was talking about an SDK that does not require a plugin. Otherwise it seems Flash and Silverlight already meet his requirements.
  - palish 19y ago
    Hmm.. They meet the requirements to an extent. They're really little islands of functionality. I'm talking about a plugin that can react to and manipulate HTML elements, persist across page loads, and doesn't have browser-specific quirks.
- Readmore 19y ago
  I remember hearing about someone making a 'desktop' out of firefox. That would be the perfect way to implement some of the extra functionality he's talking about. Just run a browser as your window manager. Then you could build your interpreter into that and copy and paste between web applications as much as you want.

chaostheory 19y ago

Weird I thought the coming web ui monopoly was this little thing called Flash... I guess that's why MS came out with Silverlight and Google's paranoia came up with Google Gears...

pius 19y ago
Yeah, Flash kept coming to mind as I read the article.
Tichy 19y ago
I don't think so, I still hate Flash, and I am not the only one. In fact, I just switched to Linux, only to find that flash makes firefox crash (seems I was unlucky, it works fine for others). The point: just as always, flash simply doesn't work for everyone, so it is out. The last big company I worked for also didn't provide it's employees with flash.
- mojuba 19y ago
  Flash is the only widely available system that gives you full control over every pixel in the browser and it does that in a pretty efficient manner. Although, yes, something intuitively stops me, too, from getting excited about Flash. Maybe it's that it's closed/proprietary and I just don't trust today's Adobe anymore. They definitely want to be the microsoft of the web. So there's Silverlight (well, potentially), Flash and still no decent alternative from the open-source world. No Mono/deIcaza stuff please. Thanks.

bokonist 19y ago

A couple of problems with his argument: 1) Web entrepreneurs working now still need to optimize for speed. It's not like the desktop world where you are launching a year or two from now and can wait for the computers to catch up. You are launching a month from now and it needs to be fast. I would prefer to use a web mail client other than GMail, simply because I'm scared of my Google dependency. But every other web email client I've used ( Yahoo, Joyent, inbox.com, Zimbra) feels much slower. Google spends enormous effort optimizing their javascript load times and it really pays off. 2) Broadband speeds are not growing at Moore's law. Terrible regulatory law trumps technological gains. 3) It be hard for a company to lock everyone into its javascript platform when the entire source code is downloadable. 4) The trouble with javascript is not cross browser incompatibility. If you use a good library and have learned common gotchas you should not have to spend too much time debugging IE ( I probably spend less than 10% of my javascript coding time on cross browser issues). The trouble with javascript is that there are still a number of things it just can't do, and won't be able to do until the browsers change. For instance, there is no way to detect the exact pixel size of a character of text. This makes it impossible to build a real word processor in javascript. Nor can you detect a collision between the opaque regions of two png images (this is needed for most simple 2-d games). Well ... it's almost impossible to do these things. I suppose you could define your own image and font formats completely in javascript, and render the entire screen using 1 pixel divs. But that's just crazy talk. It would be a huge library - maybe 250 MB - and would be very slow until computers got faster. And it would require eating at least 6000 packages of ramen to build the thing. Hmmmmm .... maybe I have an idea I can apply to YCombinator with ... :-)

bootload 19y ago
"... 3) It be hard for a company to lock everyone into its javascript platform when the entire source code is downloadable...." I hazard a guess that the real value is not (just) in the generated source code in the design tools - site used to generate the end result?
Goladus 19y ago
Another open question is how difficult it will be to obtain the different APIs. If NewSDK and ExtremeSDK are both compatible with your system, and both free/inexpensive, then monopoly conditions may not occur. People in the 90s had more reasons to choose only one platform.

greendestiny 19y ago

Unfortunately I really think this monopolist might just be Microsoft again. The web operating system is the browser, and when Microsoft start shipping silverlight with IE... The biggest challenge to this will be getting high performance out of javascript in firefox. Also a combination of svg for graphics and access to the local system via a google gears type api (I see firefox 3 has something like this planned or implemented). While this would all be nicely backwards compatible it wouldn't give you cut+paste support, some sort of MIME support for edit boxes/forms is needed perhaps.

chaostheory 19y ago
that's a good point... I think this is one of the key things Flash had to make its strong start (besides being fast and small) - as a bundle with IE then again I'm not sure how much freedom MS has this time around (anti-trust lawsuits and I think there may be some more pending settlements) or it would have been done with .NET on Windows already I could be premature - but I still think Adobe will eventually own web ui in the future... assuming that they eventually get it right on mobile devices
stuki 19y ago
If my future choices are being stuck coding in JS, Flash/As or Silverlight, I'm rooting for MS, monopoly or not. Despite what Joel seems to think, though, I still believe the general trend will be for successful browser apps to move out of confinement of the browser, rather than for successful desktop apps to move into it.

bootload 19y ago

"... Not just cut 'n' paste: cool mashup features like synchronization and single-point identity management (so you don't have to tell Facebook and Twitter what you're doing, you can just enter it in one place) ..." I've been doing something similiar to this. Here's what I'm finding working with lots of different 3rd party sites ... Using API's - not every site has an API or RSS so you have to CUT+PASTE :( - even sites with API's have poor documentation (code, txt) so it can be difficult to use - posting data (say to twitter,flickr ) is way easier than extracting via an API/RSS - no company(ies) want(s) their hard-won user data to be used commercially (check the legal agreements) so while you can integrate each site requires permission - yuk! - solve the password & authorisation problem for each 3rd party site Integration layer - abstract an API to talk to each service (eg: as Perl does to databases in the DBI module) - support the most popular sites that people use first (flickr, twitter, Facebook, MySpace etc) - constrain the features you want to support for each 3rd party site (eg: notifications by friends in twitter, or flickr. New books suggested in http://www.librarything.com http://www.librarything.com) - keep up with changes made to each service, handle bugs, quirky code Extraction layer - synchronise 3rd party added data and client side added data (the "add in 1 place" bit mentioned). This means being able to either/or add data at the client or get the data the user added at the 3rd party site as well and somehow sychronise them - you need tools to extract, manipulate RSS/ATOM feeds. A boon because you don't need API's Messaging layer - using your abstracted API be able to message various different services and here's the hard bit depending on the service. Do you want to send everyone on Twitter a photo update if you have entered 20 flickr photos? - you need to capture store, query, link check and update the various links, metadata and information that message generates. Presentation layer - layering of data. Intelligent hierarchies of data that be queried by other - flexible presentation layers that can export variety of data formats web pages as to XML, RSS files, mobile phone SMS, etc. - flexible presentation layer(s) that can support different levels of information from a complete archive of past posts to their titles or individual tags - metadata ... support things like tags, microformats at a per document level and be flexible enough to allow for more formats that arise. Of course on top of this you have to build something that others will use, that is bug free as possible in Javascript. Something on or along the lines of Yahoo's YUI ~ http://developer.yahoo.com/yui/ http://developer.yahoo.com/yui/ Maybe this YUI or NewSDK is what Steve Yegge meant when he was talking about the "Next big language" ? ~ http://steve-yegge.blogspot.com/2007/02/next-big-language.html http://steve-yegge.blogspot.com/2007/02/next-big-language.ht... In all this I can't help think that maybe just solving a few little problems might be a better starting point and if you do so make sure it's the open web and not some roach motel that sucks up data instead of allowing data to flow.

akshatch 19y ago

I think you are right that there is one entity who will come up with a uniform solution which will just get everybody to adhere to their set standard. What I fail to believe is that this is going to be a language or a SDK. Instead the real war in the internet will be who will keep your data together and present it to you in a uniform way. This step is already being taken by google with their whole integrate gmail, docs, calendar,... suite. What we are seeing the real Web OS being built and this is not any crap proclaiming to be WebOS.

paul 19y ago

He has some interesting ideas and analogies, but it's not clear that Joel actually understands AJAX/JS. The browser incompatibility problems are largely overblown, and the most annoying limitations are imposed by the browser (meaning that no JS library is going to fix them). He also doesn't seem to realize that all of the Google JS running in his browser IS generated by a compiler (from JS in most cases, from Java in a few others).

tx 19y ago
Agreed. Joel is growing old :-) He is young enough to keep up with major valley developments (Twitter and YComb) but too old to have a grasp on technical details (Java-to-JS-compilers, for instance). Another thing he is wrong about is "moore law of bandwidth": it does not exist. While CPUs are getting faster and RAM is growing like crazy, bandwidth is not growing. In fact I am starting to notice an annoying trend of businesses running on slower and slower connections. But his thoughts on parallels between terminal/HTML transition to Windows/FancySDK are cool nevertheless. He may not be right about everything, but something similar to what he's talking about sure will happen. Steve Yeggie blogged about inevitable "Rails for the Client" some time ago. Similar idea but expressed in more technical terms.
- jimbokun 19y ago
  "While CPUs are getting faster and RAM is growing like crazy, bandwidth is not growing..." ...in the U.S.
  - mojuba 19y ago
    Maybe because the U.S. along with Europe, Japan, S.Korea and some other countries already hit today's bandwidth limits, while the rest of the world is just catching up in this regard. Although I'm a bit more optimistic about the possible application of Moore's law in communications. Some 20 years ago 9600bps seemed to be the physical limit for phone lines, and there was even proof for that based on physics. But see how many new protocols emerged since then. ADSL, for example, would have sounded like an alien technology 20 years ago, or take any high-speed wireless protocol in use nowadays. Essentially it's the same medium utilized by much, much faster protocols.

bootload 19y ago

"... new versions of the browsers come out that support cached, compiled JavaScript ..." Rhino supports this ~ http://www.javalobby.org/java/forums/t87870.html http://www.javalobby.org/java/forums/t87870.html ... http://developer.mozilla.org/en/docs/Rhino_JavaScript_Compiler http://developer.mozilla.org/en/docs/Rhino_JavaScript_Compil... Anyone tried this?

wmf 19y ago
But Rhino has nothing to do with browsers. If you want cached, compiled JavaScript, try Flash Player 9.

ratsbane 19y ago

Joel just hit the nail right on the thumb. His hypothetical NewSDK doesn't give javascript any new abilities nor would his NewSDK provide any new ways of using those abilities which couldn't be duplicated in other ways.

nostrademons 19y ago

It's happening already - the contenders are JQuery, Prototype, YUI, Mootools, Dojo, GWT, haXe, etc., along with Apollo/Silverlight/Parakey if you allow desktop plugins. We just don't know who the winner will be yet. Personally, my money is on JQuery (literally - I'm using it for my startup), but it really is too early to tell. Interestingly, nearly all the "serious" contenders are open-source: it's possible that the developer community learned their lesson from the Microsoft monopoly of the 1990s. It's very difficult to get any sort of programming tool adopted these days unless it's open-source.

axod 19y ago

I want those 3 minutes back I wasted reading this!!!

deleted 19y ago

[deleted]

chubbard 19y ago

Of all the Joel articles this one was better than most. As someone else said I see Joel has a very practical kinda guy. He so practical that I don't look to him for setting the future. I've never seen a practical programmer, such as Joel, make anything that is future. I digress. However, his practicality in this article was an interesting slant on the future. I do believe the next level is making my Google mail work with Flickr or vice versa. Right now all these applications are islands, but there is a lot of benefit to joining them into the larger part. Whatever, that is could be a great thing. Is it just an Web SDK? Is it the real Web OS? It's a practical prediction.

stoptypingnow 19y ago

First we need to remember Joel doesn't spend as much time on his blog entries as Paul Graham spends on his. With that in mind - what did Joel mean? Joel meant at leat these two things: a) Complex design patterns will be refactored into fewer elements. GWT is a nice try but Java isn't simplification - and you Java heads know this. b) Optimization isn't the only secret sauce to rely on. Companies that put all their eggs in this basket get burned by companies that understand the larger problem begging for a solution. When resource scarcity relaxes, the companies that understand this will automagically appear at the front of the line.

jsnx 19y ago

I think he's missing the point by focusing on the GUI -- it's a uniform userland, not a uniform appearance, that facilitates interoperability. User management, permissions and a model for resources go a long way toward making a platform. As Firefox, Silverlight & al. become more and more like desktops, virtualization allows Linux to become more like a cross-platform application environment. Web apps often find themselves recreating userland fundamentals. The people at Vita Nuova caught on to this a few years ago, and released a version of Inferno (Unix relative) as a browser plugin.