Joel explains how a new monopoly will emerge around AJAX
joelonsoftware.com
joelonsoftware.com
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 ... :-)
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?
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.
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.
...in the U.S.
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.
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.
Dvorak has enough balls to make a prediction. Does that make him clever?
Nice Godelian statement :)
Besides, he never really was a programmer. If I remember correctly he started his career as a program manager at Microsoft.
He's great as a general technology trends observer and I find his thoughts on business side of software crafting immensely useful, bug a hacker? No.
But I definitely stand by my "too old" observation. That's just silly.
Oh, and don't call me dude, shirley.
So am I officially the only person who agrees with Joel on this?
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).
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.
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.
Personally, I prefer JS. My current project is mainly written in JS (using Rhino on the server).
In your opinion how easy would google cope with a need for a complete rewrite of Gmail?
There are a number of real threats to Gmail. This isn't one of them.
That said, I'd bet that this threatens encrypted mail more than webmail. Have consumers ever chosen security over convenience?
Burned once, consumers will choose security over convenience. They'll even go so far as to choose inconvenience on the assumption that it makes them safer. Witness people's acceptance of inconvenient airport security, even as baggage went on totally unscreened.
The very core of what makes Gmail so enjoyable is that their expertise in free form search allows me to pretty much stop caring about organizing my mail at all. I generally just hit archive, and rely on search to retrieve whatever I may need to later. No web mail client can provide such a service against encrypted mail.
At the same time, it is Google's access to my mails' content that allows them to show me 'relevant' ads. Without this ability, providing Gmail for free will get a lot harder to justify.
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)?
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.
"And Paul Graham gives them another 6000 boxes of instant noodles to eat, so they stay in business another three years perfecting things."
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.
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
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.
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.
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.
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.
"...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."
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.
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.
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.
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.
Good luck with that.
Good luck with that.
I haven't written any Java code, but I recognize that my opinion was not formed by modern experiences: I was woefully unimpressed with the insanely slow craplets of the late '90s (and Paul Graham's mentions of Java in his essays didn't help improve my opinion of it either ;).
Still, I'd be willing to believe that there are far more skilled Java programmers than there are skilled Javascripters, and something like GWT could only help the move to the web for many applications, especially if it truly helps to bypass the browser compatibility issues, not to mention far simpler testing and debugging.
"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...
http://code.google.com/webtoolkit/documentation/jre.html
Then you would want to wrap the other GWT classes. Mainly what you would be interested in is the RPC libraries so you can directly send Java data types over the wire to the server using GWTs serialization/deserialization routines. You dont know how nice it is to not have to deal with complex XML parsing until you've actually experienced it. Its heaven on earth compared to manual Ajax programming.
Oh and the debugging... I shouldn't even have to explain the merit of this to an experienced Ajax developer.
Using Rhino for this seems kinda pointless though when you could just write it directly in Java. I find it ridiculous how some hackers have such an aversion to coding Java. I think if people took the time to learn GWT they would quickly discover what kind of competitive advantage it brings when building complex web applications (web applications, not simply web pages). Yes, it is verbose, but once you get the hang of it its very intuitive.
Why cant it be some Y Combinator startup who builds what Joel describes? GWT in the hands of a small team can build web applications that compete with Googles. If you dont believe me, then I challenge you to give it a try and see for yourself. Just dont give up too quickly; the learning curve is a bit steep.
I also worked on SproutIt's Mailroom app, which is about 80% of the functionality of GMail, implemented by 2 dudes (one backend, one part-time front-end) over the course of a year (also in Ruby on Rails). Sprout's since released their toolkit, called SproutCore, but its docs are still a bit sketchy.
My $.02 -- too much of the plumbing for web 2.0 takes place on the server, which is why time to market on the server-side has been so important over the past few years. With Prototype, MooTools, YUI, etc. a lot of the fancy front-end tools can be bolted on after the fact.
Also -- how many apps fit the mold of a 100% full-screen AJAX app? Email, spreadsheet, word processing, calendar... what else? Reading news, surfing blogs (outside of an RSS reader), googling for information, etc. do not fit the mold of a 100% AJAX app.
Everything in GWT is treated as AJAX app, in that all RPC's are asynchronous. But all GWT apps dont have to be "100% full screen". You have the freedom to do whatever you want visually, including wrapping JS libraries for animation, drag drop, etc (which I've done with my current project).
In theory, you could write everything in native javascript and then just wrap it using GWT's JSNI functionality. Then you can use GWT for debugging and reliable RPC's. Or if you have your own server side JSON XML parsing for an existing Ajax framework, simply adapt your client side XML parsing to use GWT's XML libraries. Then everything is type safe and can be debugged and unit tested. You can also refactor your JS more easily this way, and everything is more modular. Bottom line is GWT is very flexible. It is designed this way so it can be integrated with existing JS projects.
That being said, I agree with your comment about not everything fits the mold of an Ajax app. Like if you are not building a web application. Rails will be faster and more immediately gratifying in most situations.
Now I DEFINITELY don't want to use GWT.
That is a bit odd, its a bit like saying you couldn't get Dojo to scale so you switched to Postgres. I assume if their startup was happy with ajax idioms in RoR, then they would be mad to build it in anything else, as it does so much for you (but if you stray too far, ouch).
In order for GWT to work for other languages it would need to be totally rewritten, unfortunately. That is unless you could somehow write an adapter for the core GWT JRE emulation library (java.lang & java.util classes). But like you say if the language your adapting to the Java code is not statically typed, you will have a hell of a time b/c the compiler is based on the assumption that the language is still java and therefore static. Like you say, you might end up having to force the programmer to follow certain conventions. Like always naming certain datatypes a unique way, so your adapter could map it back to specific static Java datatypes. But then doing this kind of defeats the purpose of using a dynamically typed language anyway..
I know its unpopular, but for GUI stuff I prefer statically typed code. It is more verbose, but I find GUI stuff really hard to test (even with friendly tools) and having the compiler do some more work for me I find saves time on silly errors when manually trying stuff out. Yes I type more (or my IDE does really), and I am doing the work for the compiler to some sense, but I find it easier then any other way I have worked for many years doing this.
Its actually ironic (in the alanis sense), I would love a good static typed GUI language, but a dynamic one on the server ;) Maybe my brain is backwards, but I haven't been convinced so far by anyone who has shown me they actually do anything with what they talk about.
I do like JavaScript the language, where its going, when it is removed from the browsers. I wouldn't be unhappy using it more (just less so for the GUI - well I am keeping an eye on where jQuery is going it seems about right as a general tool for front ends for me, but not yet).
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.
Rhino supports this ~ http://www.javalobby.org/java/forums/t87870.html ... http://developer.mozilla.org/en/docs/Rhino_JavaScript_Compil... Anyone tried this?
If you want cached, compiled JavaScript, try Flash Player 9.