7 ms·

He has some interesting ideas and analogies, but it's not clear that Joel actually understands AJAX/JS. The browser incompatibility problems are largely overblo

by 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.
    - brlewis 19y ago
      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.
    - cyggie 19y ago
      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...
      - twism 19y ago
        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...
        cyggie 19y ago
        I know... I miss my 1 Gbit/s fibre to home connection...
- edw519 19y 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.
  - stcredzero 19y ago
    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?
    - kokey 19y ago
      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
  - mojuba 19y ago
    There is only one prediction that is always 100% accurate - that no prediction will ever be 100% accurate. Nice Godelian statement :)
    - edw519 19y ago
      Was wondering if anyone would notice. You just won 6000 boxes of instant noodles.
- create_account 19y 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_sansei 19y 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.
jsjenkins168 19y 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.
- paul 19y 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 19y 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?
- paul 19y 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.
  - rms 19y ago
    Any hints about what threatens Gmail?
    - stuki 19y ago
      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.
      - brlewis 19y ago
        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.
        nostrademons 19y ago
        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?
vegashacker 19y 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 19y 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.

by paul 19y ago

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.
  - brlewis 19y ago
    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.
  - cyggie 19y ago
    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...
    - twism 19y ago
      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...
      - cyggie 19y ago
        I know... I miss my 1 Gbit/s fibre to home connection...
edw519 19y 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.
- stcredzero 19y ago
  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?
  - kokey 19y ago
    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
- mojuba 19y ago
  There is only one prediction that is always 100% accurate - that no prediction will ever be 100% accurate. Nice Godelian statement :)
  - edw519 19y ago
    Was wondering if anyone would notice. You just won 6000 boxes of instant noodles.
create_account 19y 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_sansei 19y 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.

jsjenkins168 19y 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.

paul 19y 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 19y 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?

paul 19y 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.
- rms 19y ago
  Any hints about what threatens Gmail?
  - stuki 19y ago
    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.
    - brlewis 19y ago
      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.
      - nostrademons 19y ago
        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?

vegashacker 19y 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 19y 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.