The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Joel on JavaScript

"Right now the big hole in the portability story is — tada! — client-side JavaScript, and especially the DOM in web browsers. Writing applications that work in all different browsers is a friggin’ nightmare. There is simply no alternative but to test exhaustively on Firefox, IE6, IE7, Safari, and Opera ... [Y]ou can try begging Microsoft and Firefox to be more compatible. Good luck with that."

What about third-party libraries that abstract that away, like Prototype, YUI, MochiKit, Scriptaculous, etc.?

Joe
http://www.joegrossberg.com
Joe Grossberg Send private email
Wednesday, September 19, 2007
 
 
I've got to agree with you there. In my experience DOM differences are a non-issue since using Prototype. Perhaps it doesn't fit in with Joel's "find the dependencies and eliminate them" principle?
John Topley Send private email
Wednesday, September 19, 2007
 
 
DOM differences are (largely) a non-issue if you do this stuff for a living. You don't need a framework. But there's no compelling reason not to use one either. So YMMV.
Paranoid Android Send private email
Wednesday, September 19, 2007
 
 
Don't Fog Creek do this for a living though? Nethertheless, Joel seems to be of the opinion that DOM differences are a "friggin' nightmare".
John Topley Send private email
Wednesday, September 19, 2007
 
 
Joel, since you are using GMail as an example here... Did you ever consider that GMail is made using GWT, the Google Web Toolkit, which is Java with a lot of GUI widgets and utility classes compiled down into cross-browser JavaScript? :-)

/* Steinar */
Steinar H. Gunderson Send private email
Wednesday, September 19, 2007
 
 
Firefox compiles Javascript and runs on PC/Mac/Linux.

Javascript can manipulate XUL.

I'd expect that to be your new Windows SDK.

or <a href="http://figital.typepad.com/blog/2006/02/windows_is_dead.html">YUI</a>.
Scott Fitchet Send private email
Wednesday, September 19, 2007
 
 
"Joel, since you are using GMail as an example here... Did you ever consider that GMail is made using GWT"

Have Google ever confirmed that?
John Topley Send private email
Wednesday, September 19, 2007
 
 
Steinar - GMail apparently does not use GWT.

But still to an extent it does sound like he's describing GWT.

If only it could make stuff render the same across browsers.

Wednesday, September 19, 2007
 
 
Hm, I just googled "gmail gwt" and found an article that said it did, but it might of course be wrong. In any case, the point was that GWT exists and seems to be part of what he called for. (Other companies have competing, similar products.)

By the way, I think a disclaimer is appropriate here: I work for Google Norway, but my opinions are definitely not those of Google. In particular, I'm not working on anything related to GWT nor GMail, and I haven't seen any GMail or GWT source code. :-)

/* Steinar */
Steinar H. Gunderson Send private email
Wednesday, September 19, 2007
 
 
IMO the fundamental error in the article is the idea that the problem is Javascript compatibility. It isn't. If you avoid a few well-known nonportable constructs, the language itself is a non-issue. The problem is the libraries, especially the DOM.

Why does this matter? Because building a compatibility wrapper around a library is a much smaller task than sandboxing the entire system a la Java, and doesn't carry the same performance penalties.
clcr
Wednesday, September 19, 2007
 
 
Gmail was not written with GWT. See comment from Paul Buchheit, the original developer:
http://news.ycombinator.com/item?id=56768
marty
Wednesday, September 19, 2007
 
 
When I read this paragraph in Joel's article:

"What’s going to happen? The winners are going to do what worked at Bell Labs in 1978: build a programming language, like C, that’s portable and efficient. It should compile down to “native” code (native code being JavaScript and DOMs) with different backends for different target platforms, where the compiler writers obsess about performance so you don’t have to. It’ll have all the same performance as native JavaScript with full access to the DOM in a consistent fashion, and it’ll compile down to IE native and Firefox native portably and automatically. And, yes, it’ll go into your CSS and muck around with it in some frightening but provably-correct way so you never have to think about CSS incompatibilities ever again. Ever. Oh joyous day that will be."

...it made me think of the OpenLaszlo project.

http://www.openlaszlo.org

You write code in XML and JavaScript, and you tell the compiler whether you're compiling for the Flash runtime or the DHTML runtime. Regardless of which runtime you use, the same animations and interactions are possible, and the results are nearly pixel-perfect.

The DHTML runtime writes all of the HTML, CSS, and JavaScript for you, taking into account all of the fiddly browser differences. It's actually a very impressive piece of work.

But nobody seems very interested in OpenLaszlo. I wonder why it hasn't gotten the same attention as Adobe Flex or MS Silverlight.

My hunch is that the developers using these browser-rich-client technologies don't really care whether the application is rendered directly within the browser or within the Flash player (though there's obviously a lot of reluctance to rely on the as-yet-not-very-ubiquitous Silverlight runtime), so the DHTML runtime hasn't generated a whole lot of buzz.

It's an answer to a question no one is really asking (except perhaps Joel).
BenjiSmith Send private email
Wednesday, September 19, 2007
 
 
2 questions

1) "People are figuring out how to precompile JavaScript."

Can someone give me an example of this?

2) "To build a sandbox you pretty much doom yourself to running at 1/10th the speed of the underlying platform, and you doom yourself to never supporting any of the cool features that show up on one of the platforms but not the others."

How does JS take advantage of "cool features"?  Isn't JS "sandboxed"?

-Thx
Kilik Send private email
Wednesday, September 19, 2007
 
 
http://tinyurl.com/ohct5

(sorry, no IE)
Scott Fitchet Send private email
Wednesday, September 19, 2007
 
 
One might even ask what FogBugz is written in.
Rick Tang
Wednesday, September 19, 2007
 
 
Precompiling JavaScript is potentially worthwhile, but it would require that all browsers support some common JavaScript object file format. Currently that's not the case. And given the way the last 7-10 years have gone, I wouldn't hold my breath for anything that depends on a new standard being implemented. Especially if Internet Explorer matters, and it almost always does.
clcr
Wednesday, September 19, 2007
 
 
Interesting but I'm not sure how right Joel is.

Firstly nobody gives a shit about a web enabled word processor. Give us one for free and we might use it now and again. But pay for it; no way.

Secondly Joel really seems to overestimate cool. He actually reminds me of those forty something bosses in the dotcom era who were so scared of being out of date that they surrounded themselves with twenty-somethings and parrotted nuspeke or whatevs.

The analogies he gave from the past had nothing to do with being cool, they met a very definite old-fashioned productivity need. You can produce a cooler email client than gmail or yahoom mail, but guess what -- I'm not going to bother signing up for it. Webmail is not going to get any less horrible because no amount of pre-compiling Javascript is going to let me search 350MB of mail in a couple of seconds, as I can do with Lookout. And of web mail clients what is the most popular? Hotmail, which is by far the worst of the big ones.

Where Joel really shows himself behind the times is when he keeps talking about web apps for the PC. Err, no! The future for Ajax apps lies on mobile phones, and as has been pointed out the incompatibility problems there make the differences between IE and Mozilla trivial.

I don't know how much the difference between DOM objects is a problem, but there are other more annoying incompatibilities. I just found out three days ago, after testing on IE7 that in practice you can't use transparent .png's in IE6. The problem is not the restriction in itself (it is easy enough to convert the files to .gif's) but the time it takes to wade through the internet to find out! And then there are scripts that work in IE but get mixed up in a blur in Firefox. And CSS serendipity (you design the CSS and it's happenstance if it works in all browsers).

One problem that needs looking at is IE7's "improved security" features. I'm producing language teaching web pages, and the standard tool is Hot Potatoes which uses Javascript. IE7 however has decided that programs that use code to run (as opposed to those that just provide a blank page for Zen-like meditation) might be dangerous because code does things to your computer (like make programs work). The result is that every single page gets a security alert. Luckily for its main purpose the web pages run within another application (Blackboard) which doesn't trigger the alerts, but  I suspect start-up web app companies and IE7 aren't going to go down that well. When I access the megasoftware our university has bought for its portal I get security warnings on nearly every page. Can a start-up Ajax developer afford all the security certificates a mega-contractor doesn't get round to buying?
Stephen Jones Send private email
Wednesday, September 19, 2007
 
 
Kilik,

I have learned about HaXe today, and it is definitely what Joel is talking about: http://haxe.org/intro
Victor N. Send private email
Wednesday, September 19, 2007
 
 
" Webmail is not going to get any less horrible because no amount of pre-compiling Javascript is going to let me search 350MB of mail in a couple of seconds, as I can do with Lookout"

Gmail can already search 350MB of mail in a couple seconds. Searching is done in parallel on a giant server farm, not in Javascript in your browser, which may well be faster than a fat client. Think about how quickly a search engine can search through hundreds of terabytes of web documents, and then assume that the same technology powers your e-mail search.

Same principle applies to video processing--the only thing you have to transmit over the network is the current frame (what the user is seeing). All the heavy lifting can be done on a cluster of servers. Since the processing can be done in parallel, a video editing web app could even be faster than editing video on your desktop if well-designed.
CS Student
Thursday, September 20, 2007
 
 
You're telling me gmail has the search capacities of Lookout (including indexing so that I can find a phrase in an email in five seconds or so?> I doubt it very much.

What about when I want to open that 8MB attachment? Are you telling me a 512kbs DSL connection is as fast as a SATA hard disk read-write or Gigabit internet LAN?

And what happens when a coconut tree falls down in a storm and brings down the telephone wire?
Stephen Jones Send private email
Thursday, September 20, 2007
 
 
How are you going to get that 8Mb attachment off your SATA disk at all when you are on holiday?
el tel
Thursday, September 20, 2007
 
 
"Because building a compatibility wrapper around a library is a much smaller task than sandboxing the entire system a la Java, and doesn't carry the same performance penalties."
--clcr

This is especially true since right now everybody has to write little snippets of piecemeal code to provide the compatibility anyway.  A compatibility layer around the DOM would therefore be just as fast.  The problem is that right now there are about 50 different layers to choose from (every little AJAX toolkit has this at it's core).  We need to have one or two win out in the market so that they can become a real platform on which the next generation of tools can be built. 

Once we have a common compatibility layer, the creator of that layer will have enough power to push a common framework out to developers that can include things like a common web upload mechanism + a common web clipboard, so you can copy/paste pictures from one app to another or .  If the creator of a winning framework doesn't develop this app, other developers can.  However, we'll be in the same situation where we are now with about 50 different options to choose from, none of which work with any of the others, waiting to see which tools wins out.


Re: Stephen Jones--
Yes, gmail can search all your mail in <5 seconds very easily.  And uploading an 8Mb video will rarely be an issue for two reaons:
1) As Joel mentioned, bandwidth is getting cheaper.  8Mb is nothing.  Larger files could be a problem, but they'll come up with a solution.
2) You won't need to upload the data at all, because you'll have created it online in the first place.
Joel Coehoorn Send private email
Thursday, September 20, 2007
 
 
----"How are you going to get that 8Mb attachment off your SATA disk at all when you are on holiday?"----

Never heard of a pen drive?

When I go on holiday I don't even bother with the laptop any more. I just take a USB 2.5" 60GB HD that has my data and hook it up to my vacation desktop. If I'm vacationing somewhere else, a laptop, or if I'm going to be on the road, a pen drive does just fine.

----"As Joel mentioned, bandwidth is getting cheaper.  8Mb is nothing.  Larger files could be a problem, but they'll come up with a solution.
2) You won't need to upload the data at all, because you'll have created it online in the first place."----

Bandwidth is not getting cheaper for those who live where there isn't cable or DSL.

I was thinking of downloading a file rather than uploading it (got confused) but as it elicited your reply that I would soon be doing graphics editing online the mistake was worth it for the subsequent hilarity.

Incidentally Gmail search is fine (I forgot that Google reads all emails so it can target what ads it serves you). However the interface, unlike Yahoo's, does not allow me to  open my mails in separate tabs, so it's dead in the water as far as day-to-day use is concerned.

Moreover in any local email client I can scroll down until I reach the message I am looking for. As far as I can tell with gmail I will just have to keep clicking older. Fun in a folder with a couple of thousand emails!
Stephen Jones Send private email
Thursday, September 20, 2007
 
 
"Moreover in any local email client I can scroll down until I reach the message I am looking for. As far as I can tell with gmail I will just have to keep clicking older."

Don't do that, then. After all, like you said:

"Incidentally Gmail search is fine."

Funny how Microsoft seems to be moving in the same direction as Google: You have acess to so much stuff (online with Google, on your terrabyte hard drive with Vista) that you can't possibly organize it all yourself. Just search for it.
Drew Kime Send private email
Thursday, September 20, 2007
 
 
I find Joel's comments bit out of touch with the actual JS development I have done and experienced.  I agree with others DOM issues are not a big consideration.

Additionally....
 Downloading one megabyte of javascript for a web app, I reckon is most uncommon. I mean, I'm sure there's very few of us who've actually worked on projects that come any where near, say downloading 1 meg of JS for a web app, let alone have worked on projects that exceed 1 meg in total source code (which surely is much more common).

Regardless, bandwidth is not the limiter for Ajax/DHTML rich web apps.  In my experience it is the efficiancy of the web browser handling memory allocations. 

For instance, the more DOM objects you dynamically create, the execution speed of the interpreted JS code execution slows down what seems like exponentially. 

JS functions are also treated as first class functions.  Each function you write, I reckon is another pointer to some allocated data.  For instance, try an alert(myCustomWrittenFunction);

Last, there's only so much client side JS one would wish to write without it resembling a COBOL program or a spaghetti code like classic ASP script. It is an OOP language, but it is not quite robust with OOP like C++, C#, Java, etc. which would help ride much more readable/maintainable logical components instead of resorting to hacks like closures. With the 2.0 EMAC spec, that should help matters, but it will be sometime before that becomes mainstream...
Foo Fighter
Thursday, September 20, 2007
 
 
---"Don't do that, then."-----

So one of the great advantages of web email is that it stops me doing useful things I want to do! I think you'll have to get Marketing VP Dogbert on that.

There are plenty of reasons why I might need to scroll down to see what emails I got a month ago.

Gmail won't open me individual emails in a separate window. That in itself makes it a total non-starter. Yahoo beta refuses to open in a separate tab, but will open in a separate window.

All of these web email clients incidentally are three times slower than Outlook, which itself being a single-threaded app is pretty lethargic.
Stephen Jones Send private email
Thursday, September 20, 2007
 
 
"Gmail won't open me individual emails in a separate window. That in itself makes it a total non-starter. Yahoo beta refuses to open in a separate tab, but will open in a separate window."

Is this really your argument against javascript web mail? That one particular feature? If inability to open your emails in a separate window is all web apps have going against them, then it looks like they've already won.

None of these are hard technical limitations. They're all features than can be added within the existing technology.
CS Student
Friday, September 21, 2007
 
 
Your tagline CS Student sums up your attitude.

You don't actually work so see something taking twice as much time as it should do as a mere academic problem instead of a bloody nuisance that is costing time and money.

If I have to click on every email message in gmail and then wait for it to fill the window that is wasted time. And what if I want to have two or three seperate emails open at the same time so I can compare them, or cut and paste between them.

It's all very well saying that the solution is trivial, but the fact remains that there is no webmail client that offers 50% of the productivity of Outlook Express circa 1996. If you combined Gmail search with the Yahoo beta interface crossed with the ability of the non-beta yahoo to open in separate tabs, then maybe you would be approaching 50%.

The dotcom boom collapsed because those involved forgot they were actually supposed to be producing something. A lot of Web 2.0 will collapse because its acolytes are forgetting that they are supposed to produce something people need, not just something to satisfy their self-indulgence.
Stephen Jones Send private email
Friday, September 21, 2007
 
 
Back to issues of compatibility...

Many of the complaints I see about differences between IE, Firefox, et al aren't strategic.  I mean, most of the differences seem to be sort of accidental, not intentionally engineered by their companies to gain any marketing advantage.

What if there was a ISO (or whatever) spec for JavaScript?  Or browswer functionality?  That certainly wouldn't solve all the differences, but would it close the gap?  It certainly would make lives easier for developers and users.

This is an extremely naive thought, I know.  Asked another way, why isn't there a standards body of some sort for these technologies?
OneMist8k
Friday, September 21, 2007
 
 
By the way, this is one of the reasons I like working with Java.  The operating environment at my company has three different OS'es, and I really appreciate the fact that Java has not become fragmented for each platform.
OneMist8k
Friday, September 21, 2007
 
 
There is a specification for ECMAscript aka JavaScript
  http://en.wikipedia.org/wiki/ECMAScript

The browser compatability problems, which are small, niggly types at this point, are due to different interpretations of the specification whether it be the specifications written for (x)HTML, CSS, or ECAMAscript.
Foo Fighter
Friday, September 21, 2007
 
 
"Your tagline CS Student sums up your attitude."

That you're resorting to personal attacks now tells me your argument is bankrupt.

Again, nothing you point out is a technical limitation of javascript or the browser. And, get this: I found out you can open e-mail in a new window (at least in gmail) if you hold down shift and click. A little obscure, but if this was the reason "Web 2.0 will collapse" then I don't think those companies have much to fear.
CS Student
Friday, September 21, 2007
 
 
I'm not resorting to a personal attack. I'm trying to point out that you are looking at entirely the wrong things. You are looking at the technical limitations of Javascript. As a user I couldn't care less about the technical limitations. What I do know is that my productivity with online email was less than half my productivity with offline email, and Outlook wipes any web email out of the water.

I used email because I was hiring people. I needed to read through a load of emails every day, check back on all other emails sent, search for similar emails sent previously, check up large attachments that could be several megabytes and quite a lot of other stuff. On occasion when not physically at work I tried to do this through the web interface. It was a nightmare.

The problems with internet based software is the bandwidth and the reliability of the connection. Basically the web, and much of javascript is an attempt to compensate for this. But if you are on a LAN or working on your own you don't need to.

Thanks for letting me know the shift + click trick. It is standard in web browsers but I was put off by the fact that you don't get the option when you right click on the link.
Stephen Jones Send private email
Friday, September 21, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz