Hacker News new | comments | show | ask | jobs | submit login

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.


"...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.


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.


> His posts about "harm of exceptions"

So am I officially the only person who agrees with Joel on this?


OK, agreed. Stupid comment on my part. How would I know how good a hacker is unless I worked with him or used his output?

But I definitely stand by my "too old" observation. That's just silly.

Oh, and don't call me dude, shirley.


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

Nice Godelian statement :)


Was wondering if anyone would notice. You just won 6000 boxes of instant noodles.


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...


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).


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

...in the U.S.


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...


I know... I miss my 1 Gbit/s fibre to home connection...


> 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).


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?


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.


Any hints about what threatens Gmail?


Reliance on mail content for search and ad placement makes it less than ideal if the world is moving towards encrypted mail, which it ought to.


Think about it: gmail is an interface through which people read their mail. It won't be a problem that at some previous stage the mail was encrypted.


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: