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).
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.
Joel is light on the technical details. He's old enough to remember when C was going to be the language for everything. But not guru enough to mention or properly analyze anything else from that time. (Eiffel, Forth) Joel is just one of the mainstream programmer sheeple, just louder and with a bit of panache.
Dvorak has enough balls to make a prediction. Does that make him clever?
Am I the only one who thinks his description of CICS is quite wrong? CICS was a transaction server, there were many layers usually in front of it before it reaches the terminal. The terminal was actually quite dumb, which was the advantage of the solution since it allowed for full backend integration. That is the problem Microsoft hit their head against in the late 90's, and their 'innovative' new direction was to move back towards thinner clients
Dude, I've been reading Joel since 2002, and every time he goes on to blog about hacking he looks silly. His posts about "harm of exceptions" (he prefers -1 as a return code), about "mistake of .NET" and, from relatively recent ones, about poor Ruby performance do not make him look good as a hacker in my opinion.
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.
Well assuming there are 20 packets of ramen in a box, you just put three meals on his table for the next 109ish years. I think you, sir, should be in charge of the World Food Program...
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.
The U.S. is behind much of the world in bandwidth to the consumer. Are you talking about server bandwidth? I think consumer bandwidth is more relevant to Joel's essay.
I don't think the rest of the world is "catching up" with the U.S. They're simply going to jump over and skip ahead without having to deal with legacy systems...
they've passed us a while ago. we are the ones that need to do the catching up. go check out the speeds they are getting in japan, europe and the likes...
> 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.
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)?
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.
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.
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).
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.
Though if people were really to move towards encrypted mail, it'd threaten the whole webmail industry. It does no good to encrypt your mail if it's then sent in plain text over the web. Even if you used https, it's a little nonsensical to let a third party decrypt your mail and then re-encrypt it for transmission.
That said, I'd bet that this threatens encrypted mail more than webmail. Have consumers ever chosen security over convenience?
I don't know what's going to happen to encrypted mail, but I can answer your last question.
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.
By encrypted mail, I meant end to end, pgp style encryption. For this to be of much use, Google (nor anybody else) would not have my private key, so all they see is a wall of random bytes.
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.
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 ... :-)
> 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.
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.
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..."
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.
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.
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
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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 haven't taken a look at GWT but I know of at least one ex-Googler that was trying to do a startup in Java/GWT and was hitting some major roadblocks/slowness of dev speed; they've since switched to RoR.
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.
You will definitely be very slow in building stuff initially, if you have not used GWT before. Much slower than using RoR. Unless maybe you've done lots of SWT/Swing programming, then you will at least have a general understanding on how to layout stuff graphically and use event listeners.
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.
"Unless maybe you've done lots of SWT/Swing programming, then you will at least have a general understanding on how to layout stuff graphically and use event listeners."
>I haven't taken a look at GWT but I know of at least one ex-Googler that was trying to do a startup in Java/GWT and was hitting some major roadblocks/slowness of dev speed; they've since switched to RoR.
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).
I think it would be interesting to see if the GWT "back end" compiler (which works off its own AST) could be integrated with another language front end. the GWT compiler is indeed impressive - so it would be useful to see it used in general (even if it was from javascript to start with, this sort of compiler would be useful). Although, GWT java code is 100% static, which means they can analise the heck out of it, and compile it tightly. A more dynamic language would not have so much luck unless you forced people to follow certain conventions.
I've had the same curiosity. The GWT compiler essentially parses the Java source code and uses a series of complex rules to convert it to JS. This is why whenever you use any client side libraries you must have the source code itself rather than just the binaries. If the source code cannot be parsed directly, it cannot be converted to JS.
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..
Yeah my thoughts. Although I don't know if it impossible - GWT does work of an AST - no reason why other languages couldn't drive it. Perhaps the contenders would be scala (static) and JavaFX markup stuff (which is also static, and designed for UI).
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).
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.
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.
"... 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.
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.
