Joel explains how a new monopoly will emerge around AJAX

http://joelonsoftware.com/items/2007/09/18.html

by herdrick • 19 years ago

101 82 19 years ago

jimbokun5• 19 years 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."

Readmore2• 19 years ago

Haha I know! I was just about to post that quote myself!

Kaizyn• 19 years ago

So that's why people go to YCombinator for startup funding... the free Ramen!

mdemare• 19 years 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• 19 years ago

Between that and the ramen quip, Spolsky comes across as pretty smug himself.

ph0rque• 19 years 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_account2• 19 years ago

That's neither funny nor witty.

pius2• 19 years ago

Joel just blew my mind. Awesome article.

rms2• 19 years ago

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

palish4• 19 years 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.

bokonist2• 19 years 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.

Readmore2• 19 years 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.

jimbokun5• 19 years ago

"All you have to do is convince users to download your C++ app that DOES contain a Ruby interpreter and runs in the background..."

Good luck with that.

phenylene2• 19 years ago

Or how about http://code.google.com/webtoolkit

palish4• 19 years ago

Java?

natrius• 19 years ago

I'm surprised that you're the first person to point this out. That's the first thing I thought of when I read this:

"But then somebody you've never heard of, some bratty Y Combinator startup, maybe, is gaining ridiculous traction selling NewSDK, which combines a great portable programming language that compiles to JavaScript, and even better, a huge Ajaxy library that includes all kinds of clever interop features."

No, it won't be some bratty Y Combinator startup. It'll be Google (but the Facebook/Twitter integration features won't be there, mainly because they're silly).

Even when GWT matures into the world-dominating SDK Joel speaks of, I still won't use it. To paraphrase jwz: Some people, when confronted with a problem, think, "I know, I'll use Java." Now they have two problems.

I'm waiting for someone to generate Javascript from Java through GWT from Javascript through Rhino. I wonder if that's possible...

tx3• 19 years ago

FireFox already has it built in, it is called XUL and "Mozilla Platform". FireFox itself is written in XUL (you can run 2nd instance of FireFox within Firefox).

What you would need is to build an IE/Opera/Safari plugin that runs XUL code. And possibly add some security system on top of that.

Zed Shaw, if I understood him properly, built a prototype of an application that used this "API": server side was Ruby/Rails, serving XUL UI to a browser. That works even now - only in enterprise environment where you can make everybody to run FireFox.

chaostheory2• 19 years 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...

pius2• 19 years ago

Yeah, Flash kept coming to mind as I read the article.

Tichy• 19 years 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.

mojuba3• 19 years 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.

bokonist2• 19 years 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 ... :-)

bootload3• 19 years 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• 19 years 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.

lupin_sansei2• 19 years ago

> Nor can you detect a collision between the opaque regions of two png images (this is needed for most simple 2-d games)

Crazy idea. At the start of the game use the server to determine the image's boundary, then send the info up to the client and get Javascript to use that pre-calculated boundary to detect a collision rather than getting Javascript to try and look inside the png.

greendestiny• 19 years 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.

chaostheory2• 19 years 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

stuki3• 19 years 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.

bootload3• 19 years 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)

- 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/ 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.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• 19 years 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.

paul3• 19 years 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).

tx3• 19 years 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.

jimbokun5• 19 years ago

"While CPUs are getting faster and RAM is growing like crazy, bandwidth is not growing..."

...in the U.S.

edw5193• 19 years ago

"...but too old to have a grasp on technical details..."

Huh? Am I the only one the notice how illogical this is?

We are not basketball players. Some of us do are best hacking in our 40's and 50's. (Lay off the drugs - you'll see.)

Joel has forgotten more than many here have ever known about hacking. His only problem with this essay is that he has the balls to make a prediction.

There is only one prediction that is always 100% accurate - that no prediction will ever be 100% accurate.

Great read, Joel. Now back to my ramen.

create_account2• 19 years ago

Joel is unimpressive, technically.

His software products are lightweights, and he makes most of his money from his fan base, selling books and job ads on his web site.

He's just not relevant any more (if he ever was in the first place).

lupin_sansei2• 19 years ago

> While CPUs are getting faster and RAM is growing like crazy, bandwidth is not growing

This isn't really true. In 1997 most users were lucky to be on 56k dial-up. Now for the same price (at least here in Australia) I can get a 28Mb ADSL 2+ connection. That's an increase of 500x in 10 years. Granted bandwidth increases in fits and spurts, but it's increasing alright.

jsjenkins1684• 19 years ago

Paul, did you use GWT (or a form of it) for GMail?

I am curious about the evolution of GWT from an internal Google tool into its current form as an open source platform. Did the JS compiler tools you describe simply evolve into GWT?

I see parts of GMail that could be highly custom GWT. Google Mashup Editor on the other hand is pretty obviously GWT.

paul3• 19 years ago

No, GWT has nothing to do with Gmail or the JS compiler. GWT was actually a startup that Google acquired a few years ago and made open source. I think it was probably released before any Google project made significant use of it.

Personally, I prefer JS. My current project is mainly written in JS (using Rhino on the server).

Neoryder• 19 years ago

paul, I was wondering, recent post of Steve Yegge extol the virtues of great coding standards/uniformity across google.

In your opinion how easy would google cope with a need for a complete rewrite of Gmail?

paul3• 19 years ago

The very concept is somewhat nonsensical. Gmail is a big system with many components -- there is no reason that Google would ever need to do a "complete" rewrite. That said, the individual components are frequently rewritten, and it already supports at least 4 completely different interfaces (AJAX, plain HTML, XHTML mobile, Java MIDP mobile, POP3, and probably others that I'm forgetting or can't mention). Adding a new UI for Joel's magical library wouldn't be a big deal.

There are a number of real threats to Gmail. This isn't one of them.

vegashacker• 19 years ago

When I read Joel's article, I was imagining in my head a JS-prime => JS + (maybe) CSS compiler, where JS-prime feels just like JS, except it makes it impossible to write something that doesn't work "the same" in all browsers. I think that this would be huge if it existed, except after reading your post, I'm thinking maybe it does already exist. Yes?

Also, could you clarify your statement: "The most annoying limitations are imposed by the browser (meaning that no JS library is going to fix them)." Do you mean the there are things that browsers simply can't do (e.g., your "file uploading that doesn't suck" example)?

olavk• 19 years ago

The compatibility problems are not in the core language (which is surprisingly portable between browsers), but in the DOM API. This can be solved by a compatibility layer library like JQuery, Prototoype et al. Joel claims that this layer slows JS an order of magnitude, which is greatly exaggerated. The difference between calling the DOM directly and through a library is barely noticeable. A very clever compiler could probably optimize some overhead away (e.g. transforming into browsers specific code with the compatibility layer optimized away), but I doubt there would be any major gain speed-wise.

bootload3• 19 years 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://developer.mozilla.org/en/docs/Rhino_JavaScript_Compil... Anyone tried this?

wmf• 19 years ago

But Rhino has nothing to do with browsers.

If you want cached, compiled JavaScript, try Flash Player 9.

ratsbane• 19 years 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.

nostrademons2• 19 years 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• 19 years ago

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

chubbard• 19 years 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• 19 years 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• 19 years 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.

Joel explains how a new monopoly will emerge around AJAX

Related Stories