Javscript is an implementation detail: this is the same old Google trap. [LWN.net]

Javscript is an implementation detail: this is the same old Google trap.

Posted Mar 23, 2009 0:22 UTC (Mon) by xoddam (subscriber, #2322)
Parent article: Stallman: the JavaScript trap

It's fair enough for Stallman to remind users that web page scripts are software and that you often don't get the real source even for scripting languages like Javascript.

There's a definite problem with a (very) few software vendors delivering 'obfuscated' source in the mistaken belief that it helps them to comply with copyleft licences that require source distribution. But web sites generally don't do that. They deliver 'minified' or 'packed' Javascript programs and libraries because it makes sense, just as it makes sense for GNewSense to deliver libc as a compiled binary.

There's nothing wrong with software that is provided without source code, so long as the vendors don't pretend that the object code *is* the source code. I don't see Google or anyone else doing that in the case of packed or minified Javascript software.

So if the devotees of the church of emacs are suddenly feeling they've been deprived of sainthood because they downloaded client-side non-source portions of the implementation of online services they would have felt free to use if they were provided solely by someone else's server, bad luck.

IMO the presence of client-side downloads in the service mix shouldn't make a difference to the choice to use or not use a web service. I use google in the full knowledge that if they 'turn evil', I may be lied to, or if they disappear, I may lose the service.

This is what Google-watch and http://www.scroogle.org/ are for.

I can't see the FSF stepping up to re-implement every imaginable online service in the name of freedom. But being a thorn in Google's side and reminding them of their motto every now and again is a very valuable service that all Google's users should appreciate.

to post comments

Javscript is an implementation detail: this is the same old Google trap.

Posted Mar 23, 2009 8:46 UTC (Mon) by niner (guest, #26151) [Link] (6 responses)

> They deliver 'minified' or 'packed' Javascript programs and libraries because it makes
sense

No, it does not make sense. We've had working server side transport compression for a
decade now. If you want to speed up page delivery and safe bandwidth, that's the way to
go.

Yes, you could save even a few bytes more by using packed JavaScript and
compression together. But that's really negligible compared with even just a few icons,
not to speak of the large images or Flash animations used on most websites.

Packed JavaScript code is just annoying if there's an error and you have to debug.

Javscript is an implementation detail: this is the same old Google trap.

Posted Mar 23, 2009 11:25 UTC (Mon) by OLPC (guest, #47981) [Link] (1 responses)

Minified code does not just save bandwidth. It also saves memory in the client, speeds up parsing and probably also execution speed on many interpreters.

Javscript is an implementation detail: this is the same old Google trap.

Posted Mar 23, 2009 16:06 UTC (Mon) by Wummel (guest, #7591) [Link]

You can have the best of both worlds. I deploy both minified and fully readable scripts on the server, eg. /js/xyz_min.js and /js/xyz.js.

When the application is in debug mode, the non-modified original files are loaded and can be debugged easily. In normal mode the minimized scripts are loaded.
Debug mode is automatically activated when the URL has an additional parameter ?debug=1.

Javscript is an implementation detail: this is the same old Google trap.

Posted Mar 23, 2009 12:53 UTC (Mon) by mrshiny (guest, #4266) [Link] (1 responses)

We've measured using packing AND compression and the effect is not insignificant. I'll thank you for not telling me how to spend my bandwidth money.

Javscript is an implementation detail: this is the same old Google trap.

Posted Mar 23, 2009 13:13 UTC (Mon) by lkundrak (subscriber, #43452) [Link]

Exactly. Our company's product has a rich Web 2.0 client that's written in JavaScript and runs in the browser. It's in fact several megabytes of our code, along with YUI and a couple of other libraries. Not only was the improvement "not insignificant", it was huge enough to change the initial application load from "unacceptably slow" to "usable". (Sorry for not having the numbers here. I could do the mesaurements, but I'm quite sure you'd find some paper on this after a minute of googling).

Javscript is an implementation detail: this is the same old Google trap.

Posted Mar 23, 2009 14:05 UTC (Mon) by Simetrical (guest, #53439) [Link]

Benchmarking has shown a very real difference between gzip alone and minification+gzip. This is especially true given that most browsers will block parsing and loading of further content in the page, and all browsers will block rendering, while waiting for a JavaScript include to download. (They have to block at least rendering in case it does some document.write()s, e.g., ad JavaScript.)

You can't get the same effect with just gzip. There's a ton of irrelevant stuff that gzip can't possibly compress away -- comments, for instance.

I suggest the O'Reilly book "High Performance Web Sites" for more info about this kind of thing. It does include benchmarks for minification.

Javscript is an implementation detail: this is the same old Google trap.

Posted Mar 24, 2009 17:18 UTC (Tue) by ByteCorrupto (guest, #57270) [Link]

What about Google Gears?
With Gears the client can save personal data (for backup) o application
data (for save bandwitch