Stallman: the JavaScript 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) [Link] (7 responses)

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.

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]

+1

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

Stallman: the JavaScript trap

Posted Mar 23, 2009 1:52 UTC (Mon) by qg6te2 (guest, #52587) [Link] (1 responses)

Updated: $Date: 2009/03/23 00:41:09 $

The FSF (and by extension or perhaps due to Stallman) are not know to be the fastest movers on this planet. This useful piece about Javascript does raise some valid points, however I do wonder whether the time taken to write this would have been better spent resolving the current GCC licensing issue that is causing serious delays in progress. There is currently much developer unrest and angst, with many GCC developers less than impressed with FSF's holdups and delays.

Problems can't be reduced to matters of Stallman-hours

Posted Mar 29, 2009 20:56 UTC (Sun) by coriordan (guest, #7544) [Link]

It's very unlikely that he had that choice.

I'd imagine that he's consulting the GCC devs and a lawyer or two about that issue, so that means he'd sometimes be waiting for input. During that time he would obviously work on other things.

Stallman: the JavaScript trap

Posted Mar 23, 2009 2:35 UTC (Mon) by dlang (guest, #313) [Link] (5 responses)

I think they are missing the point (and therefor making the wrong one)

the problem with javascript isn't that it's hard to substitute your own version for what's provided by the website (it's not that hard to do this with tools like greasemonkey), but rather the fact that increasingly javascript is the generated code, not the language the code was initially developed in. javascript is increasingly being used as a 'portable byte code' substitute with the real code work being done with other tools (which may be java, python, or something else including GUI tools.

to make matters worse, JSON (a substatute for XML in AJAX apps) boils down to sending data around by generating javascript executables that set the appropriate variables and distribute that code. in this case the code is mechanicly generated from all sorts of things (down to and including SQL statements)

Stallman: the JavaScript trap

Posted Mar 23, 2009 3:38 UTC (Mon) by zooko (guest, #2589) [Link]

"I think they are missing the point" ... "increasingly javascript is the generated code, not the language the code was initially developed in."

I think RMS made that point in the article.

By the way, I found that article to be very interesting and constructive. By the title of it I might have thought it was a rant intended to sway my emotions, but instead I found some interesting and practical suggestions.

JSON

Posted Mar 24, 2009 12:18 UTC (Tue) by rfunk (subscriber, #4054) [Link] (2 responses)

JSON, while being parseable as Javascript, is much more restrictive and contains no
executable instructions, just data structure definition. It's also much more compa, readable, and
parseable than XML.

JSON

Posted Mar 25, 2009 0:54 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

'properly formatted JSON' may have the limitations you specify, but what is happening is the server sends a string to the browser, and the browser issues 'eval' on that string (possibly after stripping comment tags out so that it doesn't get evaluated accidently). there are no limitations on the client side about what can be executed as part of that eval command

JSON

Posted Mar 25, 2009 12:09 UTC (Wed) by rfunk (subscriber, #4054) [Link]

That's not a problem with JSON, but rather a problem with misusing JSON.
The right thing to do is load JSON into Javascript without doing an
arbitrary eval(), and plenty of people do it right.

Then there are those at the other extreme that load executable Javascript
snippets from the server, and eval() those..... :-/

Stallman: the JavaScript trap

Posted Mar 27, 2009 2:11 UTC (Fri) by pjm (guest, #2080) [Link]

dlang, I'm not sure why you emphasize that the problem with javascript isn't that it's hard to substitute your own version for what's provided by the website (it's not that hard to do this with tools like greasemonkey), as the article itself points to greasemonkey and other techniques, while also noting some problems with these techniques.

Apart from that, I don't actually follow your point about Javascript being generated code: I don't see that it makes much difference whether the original source code is non-minimized/obfuscated Javascript or whether it's some other language; the important point is that we don't have that source code. (Granted, there may be a quantitative difference in that if the original language is Javascript then the minimized form may be more readable than the output of a compiler.) Would you mind explaining what you mean by this being a problem, and how it affects the proposals in the article? Thanks.

Insanity: the Stallman trap

Posted Mar 23, 2009 4:52 UTC (Mon) by mheily (subscriber, #27123) [Link] (4 responses)

The idea of a web browser that only loads "free" JavaScript is going to be *very* popular. There is clearly a huge demand for web browsers that are unable to access Google, Yahoo, and other major sites. Look out, Internet Explorer -- all freedom-loving users will be switching to the GNU Web Browser! I can see millions of web developers adopting this idea and adding the appropriate GPLv3 license tags to all their JavaScript source code. Who wouldn't?

This idea makes as much sense as writing a complete clone of the Unix operating system but leaving out one important piece: the kernel.

Re: Insanity: the Stallman trap

Posted Mar 23, 2009 5:46 UTC (Mon) by JesseW (subscriber, #41816) [Link]

Um. You were doing alright up until the last sentence, in making your screed against Stallman and the FSF. But, as for the GNU goal of making a clone of the Unix system, and releasing the pieces as they were usable, we *know* how well that worked out. Extremely well: it improved the state of the art for the Unix tools, was (and is) used in a vast array of places, and provided the basis and example for the creation of fully FOSS operating systems.

If that success is what you are comparing Stallman's GPL-your-JavaScript efforts to, you are giving it the highest of praise.

Making sense

Posted Mar 23, 2009 6:11 UTC (Mon) by pjm (guest, #2080) [Link]

The article makes several proposals; a web browser that only loads "free" JavaScript does not seem to be one of them.

Also, note that the proposals don't require cooperation from millions of web developers, at least no more than the Free Software we use today requires the cooperation of proprietary software developers.

It makes sense to be able to modify software that we run; I don't think anyone here doubts that. The article proposes a feasible means of modifying the software that we run. So it seems strange to me for you to suggest that it makes no sense.

Please refrain from sarcasm: it may get a laugh, but it tends to discourage constructive discussion that actually helps us.

Insanity: the Stallman trap

Posted Mar 23, 2009 8:17 UTC (Mon) by job (guest, #670) [Link] (1 responses)

Go away or I will replace you with a short Perl script.

(Oh, something along "while (<STDIN>) { if (/free software/i) { IncoherentRant; } }". Thanks for asking.)

[ot] -e s/signal/chuckle/

Posted Mar 23, 2009 9:58 UTC (Mon) by k3ninho (subscriber, #50375) [Link]

>replace you with a short Perl script
The example you list is quite a long Perl script.

Not only JavaScript...

Posted Mar 23, 2009 7:38 UTC (Mon) by eduperez (guest, #11232) [Link] (6 responses)

What about photos? Most web pages I visit have non-free photos on them, photos that my browser downloads and displays without any kind of warning. I can see them on my computer; but I cannot edit them, or post them somewhere else.

Well, now that I think of it, even web pages' content are non-free...

Not only JavaScript...

Posted Mar 23, 2009 9:43 UTC (Mon) by johill (subscriber, #25196) [Link] (5 responses)

But it's not executed by your computer, only, in a way, by your brain!

Oops.

Not only JavaScript...

Posted Mar 23, 2009 10:34 UTC (Mon) by ikm (guest, #493) [Link] (4 responses)

No, it is in a way executed by your computer, by being instructed where to put what on the screen and how to react on clicks over the page via anchors. It doesn't have to be Turing-complete to be said it gets executed. It doesn't have to get variables and branching, either. In fact, this whole point of JavaScript-vs-everything-else differentiation is just moot. It's all the web content you happen to be viewing. It's a service, not a program.

Not only JavaScript...

Posted Mar 23, 2009 13:48 UTC (Mon) by k8to (guest, #15413) [Link] (3 responses)

Someimtes it's a service and a program. The error in my mind is believing that freeing the javascript will free the program. The javascript is usually only a portion of the user interface.

Not only JavaScript...

Posted Mar 23, 2009 18:57 UTC (Mon) by ikm (guest, #493) [Link] (1 responses)

Today's trend is to move increasingly more parts of work to the user side, but it still is a program running on the other side, even if some bits of it do happen to run on the client.

Not only JavaScript...

Posted Mar 24, 2009 4:23 UTC (Tue) by k8to (guest, #15413) [Link]

I thinkt he amount of computation on the client side is in flux. Pivotal developers have talked about reducing the amount of logic in logic, and generally viewing putting any essential logic on the client side as unwanted.

Obviously some applications are moving in the other direction. But even for them, it seems much more about interacting with datastreams produced by the server.

Not only [client-side software]...

Posted Mar 26, 2009 23:53 UTC (Thu) by pjm (guest, #2080) [Link]

Allowing changes to client-side code is valuable even if one can't change the software that runs on the server.

Whether the server-side software is free depends on the definition of free: remember that unlicensed software in ROM counts as free for some people's purposes (I believe including RMS'), just because they seek negative rather than positive liberty.

Stallman: the JavaScript trap

Posted Mar 23, 2009 9:49 UTC (Mon) by ledow (guest, #11753) [Link] (22 responses)

There's a point at which you have to say... hold on. What the bloody hell are you talking about?

The point of a web browser is not to render a webpage written in Javascript, it really isn't. It is to provide a virtual machine that the webpage can use to display itself. Whether the "tags" in that virtual machine are of the form "<body>" or "<script=>" doesn't matter. By its very nature, each non-free Javascript is necessary for the site to render and virtually impossible to replicate or replace without being the site's owner. If you *want* to do that, you already can... proxies, Javalets, etc. in certain browsers allow you to do that. But you are giving the owner of that website a virtual machine in which to display their website, NOT letting them run arbitrary code.

It just seems to me that this is a "Freedom" too far. The OS is Free, the browser is Free, even the protocols and language are Free. But the Javascript itself is part of the *content* of the website. Removing it or changing it removes and/or breaks the content. Asking the owner to replace it is the same as asking the owner to re-license their content as Free - they can, or they cannot, but you're not going to get anywhere by telling them they must, and do it now. And if they have Free content, they will already have Free Javascript, and be avoiding other similar technologies.

You're asking site owners to re-license their content. That's a BIG problem. Sure, a Free, Open web would be marvellous. We have bits and pieces of it, sure we do, but it's naive to assume that you're going to turn it into a giant, intellectual exercise in "Freedom", or even a small part of it.

This is the only problem I've ever had with the FS movement - there comes a point where you just have to say... whoa, no, hold on a moment. You can go too far. "Open" OS. Wonderful. "Open" apps. Brilliant. "Open" BIOS/firmware even. No problem there, no problem at all. "Open" data (GIS, etc.). Fantastic. "Open" text (e-books, GFDL documentation etc.). Wonderful. But "Open" webpage Javascript? You've strayed into the wrong territory, thinking that the world wants to be Free.

Yes, in some cases the Javascript is a necessary part of the website, because it *is* the content. But you're not going to do much more than have a handful of GPL / BSD / public-domain etc. Javascript libraries from the people who are already giving them away. There's tons of them - you can get thousands of things that will do the job... I've never paid for a Javascript yet, I'd much rather write one and give it away. But to suggest that using a non-free Javascript as a user is somehow evil and damaging and to restrict the browsers experience to only-Free code? It's like saying I want to write an OS that will only run GPL programs. Of course I can do that. Of course, nobody has to run it. But that's NOT a Free OS. You have gone too far.

It's like the people who curse the WINE project - it is Free, but it allows you to run proprietry code *if you want*. More importantly, they don't expect or provide the option to "Only run Free Windows programs". That's a *good* thing. This is one of the reasons that I stay away from "purist" distributions - I want the choice (the Freedom, if you will) of using programs that I want to, not of having to find an OS equivalent of EVERYTHING. This is why there are many more "non-purist" distributions than "purist" ones. People don't want Freedom of software, necessarily, they want Freedom of choice. If they have to pick between two evils, they want the choice to pick, not be told that they "can't" use the proprietry software and must use a limited OS equivalent.

And I don't WANT to run a modified version of Javascripts on a website, any website. If the Javascript is really that broken that I need to modify it, then it is up to the author of that website to fix it... I'll just stop using the website and/or complain until it is fixed. Sure, if the code is open, I can fix the Javascript, but even where it IS open and I *can* fix it, the only thing I will ever do is email the author and tell them how to fix it. They need to attract my visits, I don't need to look at their website. If the website dies because the author dies and takes his code with him, so be it.

At worst, I would seek out and/or create an Open equivalent of their content if it was really that necessary. Running home-brew "equivalents" will cause nothing but problems and the creators of the content will not care about them. In fact, by doing so you are hiding the problem - like the browsers that let you "fake" User-Agents. It lets you get at the content, sure, but you're not fixing the underlying problem of a broken website. The user is free to choose to do that, but I've been in no-end of meetings where things are said like "Yes, but we don't get any Opera visitors to our website at all!"... that's because the site is BROKEN for Opera visitors and/or they have to masquerade as a different browser to get it to work. Masquerading actually fixes one user's problem temporarily, and masks the real problem of a crappily designed website. This is no different - Javascript replacement will fix one user's problem temporarily but the site will STILL be broken.

If you are viewing a webpage, you are viewing content produced by other people. Some of them will Open their content, some of them won't. You are just using a well described, open source implementation of a virtual machine to display it. You can't then try to sensibly enforce that licensing down to the content you are trying to view and expect people (especially content-producers) to follow.

Encourage Open Source. Encourage freedom of content. Encourage relicensing of content to Open licenses. But to "enforce" it, or to somehow suggest that Javascript is any different or deserves any more attention that any other content on the website? That's ludicrous. As the article itself indicates, if it's not Javascript, it's Flash. If it's not Flash, it's Silverlight. If it's not Silverlight, it's Java. If it's not Java, it's Real streams. If it's not that, it's other encumbered codecs. They are all *content*.

I would kill for decent, open-source content *interpreters* for all of the above - why? Because it's plainly obvious that the people using non-free content in the first place don't care about free content and are not going to change, so a content "player" is the only way to effectively view that content if you decide it is vital. If the authors cared, they'd already be producing it in some other language or releasing the source to their Flash files etc. The point of free interpreters is that it will play non-free content. It is *not* so that you can then force or even encourage that content to be free - in fact, it works against you and should only be used as a last resort. You use a Free interpreter when there are no other options to let you progress further. Free interpreters exist for Javascript. That's the best you'll do. Everyone who wants to have Free content has already got it. The message is out, but the people you want to hear it aren't listening. "Shutting them out" is an option that they don't care about and which won't help.

This is just a sneaky way to introduce an automated "verification" of a license, something which is dangerous in my opinion, and use it as a stepping stone to having every webpage, every text file, every video stream, every executable tagged with a license. Although noble, it doesn't solve any problem we currently have, and creates the problems of people somehow "altering" commercial content to pretend it is Free and then causing tons of hassle when automated systems then propogate that worldwide as "Free" source code. Licensing is not a "tick-the-box" choice... it is a legally binding agreement that varies depending on the jurisdiction and should be checked carefully.

And Javascript is *content*. Be grateful that we can even run it, or 75% of website would not perform as well as they do. Asking those 75% of website to re-license is stupid, because if they wanted to, they wouldn't be using that code in the first place.

Stallman: the JavaScript trap

Posted Mar 23, 2009 10:27 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link]

Do remember that Stallman isn't referring to small elements of page-layout code. He's talking about some large applications such as google-docs.

Also, he isn't saying that we must not run non-free code; what he is asking for is a way to *optionally* substitute free code, and to have a way to make the licensing clear.

Stallman: the JavaScript trap

Posted Mar 23, 2009 12:43 UTC (Mon) by zotz (guest, #26117) [Link] (2 responses)

"You're asking site owners to re-license their content. That's a BIG problem."

First of all, I have a big feeling you are attacking a straw man. I have seen him say (in articles) that code needs to be Free, but he does not feel the same way for "art" and there are some who think he does not go far enough. And I don't think that is the only straw man you attacked in your post.

Second, to address the quote above. There is nothing wrong with asking for something you want. It is up to the party you ask to decide if they will give what you ask. If enough people start asking for the same thing and spending time on the sites where they get what they ask for, things may go that way.

I ask people to re-license their work from time to time if they want me to contribute to it. So far, it has never caused a problem with attitudes.

all the best,

drew

What's the difference?

Posted Mar 23, 2009 20:00 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

I have seen him say (in articles) that code needs to be Free, but he does not feel the same way for "art" and there are some who think he does not go far enough.

Yes, but he does distinguish "code on server" and "code on client". And this is Just Wrong(tm). JavaScript code on web page is not some separate program. It's part of server program. Heck: with things like GWT you can move code between server and client with few mouse clicks in IDE! Yet somehow sites like LWN (where server code is closed and client code is simple markup) are OK, while complex sites like Google Docs are not? Where is the logic?

The article glosses over the issue (The client and server sides raise different ethical issues, even if they are so closely integrated that they arguably form parts of a single program. This article addresses only the issue of the client-side software. We are addressing the server issue separately.) and this makes it impossible to discuss seriously.

What's the difference?

Posted Mar 24, 2009 0:13 UTC (Tue) by deleteme (guest, #49633) [Link]

Because LWN isn't an application but gdocs is? But there are several occasions when you want the source even though it isn't an application. Map stylesheets e.g. you get the map rendered as a png but the stylessheet is locked on the server.

Stallman: the JavaScript trap

Posted Mar 23, 2009 13:12 UTC (Mon) by pboddie (guest, #50784) [Link] (17 responses)

But you are giving the owner of that website a virtual machine in which to display their website, NOT letting them run arbitrary code.

Please familiarise yourself with applications such as Google Docs, mentioned in the referenced article, which are large, non-trivial applications and can thus be said to be "arbitrary code". This isn't like CSS by any stretch of the imagination.

Licensing is not a "tick-the-box" choice... it is a legally binding agreement that varies depending on the jurisdiction and should be checked carefully.

I hardly think Stallman is oblivious to the complexity of licensing, somehow.

And Javascript is *content*.

No it is not. This is quite obvious if you switch off JavaScript or use a browser that doesn't quite match up to the expectations of the developers of a site relying on JavaScript and using it extensively: you get the "canvas" that is the Web page showing a distorted or incomplete version of the site (or a blank page). It arguably isn't even the Web as we know it (or knew it), any more.

JavaScript is not "content" any more than C, C++, Python or Java are "content" in traditional user interface applications, manipulating widgets from traditional user interface toolkits. That's what many JavaScript "Web" applications do: they treat the browser like just another toolkit. It is therefore absurd to claim that the code is just "content".

Huh?

Posted Mar 23, 2009 19:49 UTC (Mon) by khim (subscriber, #9252) [Link] (16 responses)

This is quite obvious if you switch off JavaScript or use a browser that doesn't quite match up to the expectations of the developers of a site relying on JavaScript and using it extensively

It maskes as much sense as trying to read the document by converting it from some rich format (like .doc or .odt) to plain text and then complaining that it's illegible now. JavaScript is part of the content - of course if you throw away part of the content or mishandle it the rest becomes illegible. Try to throw away every second word from any article here and try to understand the rest - quite a challenge, right? No JavaScript mishandling needed...

JavaScript is not "content" any more than C, C++, Python or Java are "content" in traditional user interface applications, manipulating widgets from traditional user interface toolkits. That's what many JavaScript "Web" applications do: they treat the browser like just another toolkit. It is therefore absurd to claim that the code is just "content".

Actually this distinction was lost long ago: TeX files removed distinction between "content" and "program". Yet somehow people are ready to accept compiled Postscripts/PDFs without source for "program" - funny that. Ditto with web apps: if you can not use it without web-server - does it really matter if the code for client part is free or not? Source code for client part of LWN is entirely free - yet you can not recreate LWN with it even if we forget about content. Source code for Google Docs is not free, but even you'll somehow manage to obtain unobfuscated copy you'll be unable to use it anyway - and if you'll change it and try to use change version it'll be broken next month. What's the hoopla is all about? How the JavaScript changes the story?

Huh?

Posted Mar 24, 2009 13:42 UTC (Tue) by luigi82 (guest, #57340) [Link] (1 responses)

Hi,

did you know about OpenLayers?

http://www.wired.com/science/discoveries/news/2005/07/68071
http://trac.openlayers.org/wiki/History
http://en.wikipedia.org/wiki/OpenLayers

This exists now. Maybe in the future we have a OpenDocs etc.

best regards

How it's relevant to the discussion?

Posted Mar 25, 2009 10:33 UTC (Wed) by khim (subscriber, #9252) [Link]

Of course if you are producing FOSS program it makes sense to produce free JS library too. But most applications today and tomorrow will be proprietary - and nothing will change it. You are not seeing code of LWN and you'll not ever see code for most web-sites out there. If they are using proprietary server code then suddenly the idea to produce free javascript side is totally unappealing. The good old Greg's explantion it even more true here then in original place (in kernel).

And if interface between server side and client side can be broken at any time - what good will it do to you if client side will be free?

Huh?

Posted Mar 24, 2009 16:03 UTC (Tue) by pboddie (guest, #50784) [Link] (13 responses)

It maskes as much sense as trying to read the document by converting it from some rich format (like .doc or .odt) to plain text and then complaining that it's illegible now.

Frequently, document formats can be converted to purely textual formats and remain accessible. If you'd written "complaining that the macros don't work" then that would have been a credible response, but then macros aren't "content".

JavaScript is part of the content - of course if you throw away part of the content or mishandle it the rest becomes illegible. Try to throw away every second word from any article here and try to understand the rest - quite a challenge, right? No JavaScript mishandling needed...

Again, JavaScript is in no way equivalent to "every second word". You could write a "Web page" which has JavaScript rendering a jumbled collection of words in a comprehensible order, or even have the JavaScript download the words and display them. It is absurd to claim that the JavaScript and the words on the page are the same thing.

Actually this distinction was lost long ago: TeX files removed distinction between "content" and "program".

And that is why people generally don't want to work with TeX files. They'll try and treat LaTeX like structured content in various tools, however, but the whole TeX basis for the documents is undesirable precisely because of the programmatic basis of the document format.

Yet somehow people are ready to accept compiled Postscripts/PDFs without source for "program" - funny that.

I haven't studied PDF in depth, but it would appear to be a lot more like a genuine document format, despite various programmatic extensions for things like form filling, than PostScript. Again, like TeX, people doing document processing (not, in other words, just sending it to a device which renders something) don't really want anything to do with PostScript for the same reasons.

The principle issue with HTML and, to an extent, with improved formats such as PDF (when compared to their predecessors) is accessibility. Sure, the text in a PostScript document is "in there somewhere", but you don't really want to be given the job of writing a program to get at it. Even PDF is, from what I've heard, quite awful if the authoring solution has been clever at structuring and positioning content. In contrast, HTML documents should generally preserve the accessibility of their content.

What has happened with some Web applications is that JavaScript has been used not just to enhance the actual content in a page, delivered by traditional mechanisms, but to treat the browser as a user interface toolkit. As a result, the role of the JavaScript becomes central in actually accessing the content provided in the application. Try saving the page source in a JavaScript-intense application - you won't get anything meaningful, even though getting the content being shown is a legitimate thing to do. That's why the ability to control and modify the code has become an important and desirable thing to do.

Huh?

Posted Mar 25, 2009 0:58 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

PDF is postscript, just compressed and condensed (with very similar tactics to condensing javascript, one character function names included)

Huh?

Posted Mar 25, 2009 19:00 UTC (Wed) by pboddie (guest, #50784) [Link]

PDF is postscript

No it isn't. Wikipedia, for example, summarises the distinction adequately enough.

Accessible? Yeah, right.

Posted Mar 25, 2009 10:24 UTC (Wed) by khim (subscriber, #9252) [Link] (10 responses)

Frequently, document formats can be converted to purely textual formats and remain accessible.

Have you actually tried to convert document with a lot of rich data (tables, graphs, etc) to textual format? It's as legible as text on websites with JavaScript turned off: you can decipher the content... sometimes... if you are lucky... But in general it's often illegible.

I haven't studied PDF in depth, but it would appear to be a lot more like a genuine document format, despite various programmatic extensions for things like form filling, than PostScript.

It was true some time ago. Last versions iclude ECMAScript inyerpreter - and you can do a lot with it... actually some tools already use this capability. And a lot of texts are only available in PostScript form.

Sure, the text in a PostScript document is "in there somewhere", but you don't really want to be given the job of writing a program to get at it.

It's not even necessary true. Have you tried to work with PDF created from TeX not via pdftex, but via "old good" tex->dvi->ps->pdf way? It's a mess. DVI to PS conversion transfers "Hello world!" to something like !"##$%&$'#() and there are no easy way to get legible text back (it's done not out of malice but because it was easier: to reduce size of PS file dvips will create special fonts with glyphs: first letter in the document will be put as " ", next one as "!" and so on - when all 95 positions in first font are filled out the second one is started). Thus resulting PS (and then PDF) can be viewed and printed but that's it - you can not easily pull text back... It's easy for any decent cryptoanalyst, but not for normal person...

In contrast, HTML documents should generally preserve the accessibility of their content.

Yeah, it was the idea behind HTML. But like PDF HTML evolves and this idea is in the past. Today HTML is treated like "new PostScript": you have original version of content somewhere, but what the site actually serves is not an easily parseable document but more like opaque program for web- browser...

Try saving the page source in a JavaScript-intense application - you won't get anything meaningful, even though getting the content being shown is a legitimate thing to do. That's why the ability to control and modify the code has become an important and desirable thing to do.

You lost me at the last step. Why this ability is not important and desirable for PostScript and PDF but suddenly important and desirable for HTML? If HTML is "a new PostScript" then it should be treated as such: demand content in easy to use and understand formats (like ODS or even "simple HTML" with just a few markup tegs), don't try to turn sausage back to cow...

Accessible? Yeah, right.

Posted Mar 25, 2009 19:20 UTC (Wed) by pboddie (guest, #50784) [Link] (9 responses)

It was true some time ago. Last versions iclude ECMAScript inyerpreter - and you can do a lot with it... actually some tools already use this capability.

That's why I wrote "despite various programmatic extensions for things like form filling" which is where one usually sees these features.

In contrast, HTML documents should generally preserve the accessibility of their content.
Yeah, it was the idea behind HTML. But like PDF HTML evolves and this idea is in the past. Today HTML is treated like "new PostScript": you have original version of content somewhere, but what the site actually serves is not an easily parseable document but more like opaque program for web- browser...

But isn't this part of the problem? People have decided to subvert the original objectives of the Web in order to use it as yet another opaque platform.

Try saving the page source in a JavaScript-intense application - you won't get anything meaningful, even though getting the content being shown is a legitimate thing to do. That's why the ability to control and modify the code has become an important and desirable thing to do.
You lost me at the last step. Why this ability is not important and desirable for PostScript and PDF but suddenly important and desirable for HTML?

I wasn't saying it wasn't desirable for PostScript and PDF. Various programs do a reasonable job at, for example, copying text from those kinds of documents, but the effort required is substantial and the results not necessarily reliable.

If HTML is "a new PostScript" then it should be treated as such: demand content in easy to use and understand formats (like ODS or even "simple HTML" with just a few markup tegs), don't try to turn sausage back to cow...

But the point is that HTML isn't supposed to be a new PostScript, and HTML plus CSS isn't anything comparable to PostScript. I think that even our verbose guest contributor asserting that JavaScript is "content" can accept that. A principal benefit of the Web is that your data (the actual content) is supposed to be delivered to you in a way that makes it relatively easy to access (like a "view source" function actually working). I think that out verbose contributor could acknowledge that JavaScript changes all that.

However, the genie is out of the bottle, and people are turning the Web into yet another platform where the data is locked away behind code which, as Stallman points out, you might not be able to improve or to fix. In your terminology: there's only sausage on the menu. Again, I think Stallman sees the bigger picture - the risks of "cloud computing" and software as a service - before the majority does.

Accessible? Yeah, right.

Posted Mar 26, 2009 5:30 UTC (Thu) by TRS-80 (guest, #1804) [Link] (7 responses)

A principal benefit of the Web is that your data (the actual content) is supposed to be delivered to you in a way that makes it relatively easy to access (like a "view source" function actually working). I think that out verbose contributor could acknowledge that JavaScript changes all that.
However, the genie is out of the bottle, and people are turning the Web into yet another platform where the data is locked away behind code which, as Stallman points out, you might not be able to improve or to fix. In your terminology: there's only sausage on the menu. Again, I think Stallman sees the bigger picture - the risks of "cloud computing" and software as a service - before the majority does.

I doubt very much data is natively stored as HTML - it's simply not a format useful for storing data in. So whether we get the data as HTML transformed from the SQL database server-side or piped via JSON and then transformed client-side, it's not the preferred means of storage; the data is already hidden behind code. Arguably, JSON interfaces are better since you can write your own JavsScript application that runs on a page you control (modulo same-origin restrictions, but running a proxy is easy). Of course, none of this is necessary if you have direct access to the data in question because you're running it on your own server. That's where Stallman should be focusing his efforts, rather than worrying about those who use hosted systems - they've already lost.

The view source principle is about understanding the structure of a webpage so you can write your own, not extracting your data from it.

Already lost? Not really.

Posted Mar 26, 2009 6:14 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

That's where Stallman should be focusing his efforts, rather than worrying about those who use hosted systems - they've already lost.

I beg your pardon. I can pull all data from GMail via IMAP - and this is a lot better then just to have some "free JavaScript"! I can take my data and go elsewhere - I don't need any "free JavaScript" for that. Yes, I can not easily change the interface, but that's secondary grief. I can pull my data - and that's enough for me. As for Google Docs - I'm avoiding them not because the JavaScript is not free, but because their export capabilities suck: exported .ods often has broken macros and you can not be even export Presentation to .odp! This is much bigger grief to me then freeness of JavaScript.

I care about my data first, about code availability second. And even if you care about availability of code to discuss availability of code for server and client parts make no sense: they are tied more tightly than Siamese twins!

Already lost? Not really.

Posted Mar 26, 2009 7:48 UTC (Thu) by TRS-80 (guest, #1804) [Link] (1 responses)

I care about my data first, about code availability second. And even if you care about availability of code to discuss availability of code for server and client parts make no sense: they are tied more tightly than Siamese twins!

The sentence previous to the one you quoted was "Of course, none of this is necessary if you have direct access to the data in question because you're running it on your own server." IMAP is direct access to the data in question, I'm not sure why you think we disagree on the uselessness of replacing the client-side JavaScript.

I've talked about cloud...

Posted Mar 26, 2009 12:04 UTC (Thu) by khim (subscriber, #9252) [Link]

The sentence previous to the one you quoted was "Of course, none of this is necessary if you have direct access to the data in question because you're running it on your own server."

Yes, but I'm not running GMail on my own server! This was side-note about cloud. Even if you are NOT using "your own server" your data is not always held hostage: it's trivial to pull all data from GMail via IMAP (and it's probably good idea to do this from time to time - who knows when Google will declare you nasty spamer and remove your account?). So it's not true that people who are using hosted systems "already lost". But it's much better to use sane protocol (IMAP) for that rather then try to pull the data via "free JavaScript".

IMAP is direct access to the data in question, I'm not sure why you think we disagree on the uselessness of replacing the client-side JavaScript.

This is not about client-side JavaScript. This is about cloud: as long as my data can be pulled out of cloud I don't particularry care if cloud server is free software or not (I don't have resources to run my own replacement anyway): it's acceptable situation (of course free software is better... but it's only one factor out of many). If my data is held hostage on server and can only be accessed by JavaScript client - I don't really care if it's free software or not: I'll try to avoid such service as much as possible.

Accessible? Yeah, right.

Posted Mar 26, 2009 12:57 UTC (Thu) by pboddie (guest, #50784) [Link] (3 responses)

I doubt very much data is natively stored as HTML - it's simply not a format useful for storing data in. So whether we get the data as HTML transformed from the SQL database server-side or piped via JSON and then transformed client-side, it's not the preferred means of storage; the data is already hidden behind code.

The question of native storage is not directly relevant to the issue of accessibility: HTML is principally an interchange format, and an obviously desirable property of such formats is that the data "stored" in exchanged documents can be accessed by the recipient. Similarly, JSON is an interchange format. I don't know whether Google Docs, for example, uses JSON or a similar open interchange format, but if it did not, then obviously the lack of a documented interface would be a hindrance to anyone who has issues (technical or other) with the code.

Arguably, JSON interfaces are better since you can write your own JavsScript application that runs on a page you control

Indeed. But you're referring to applications built to be interoperable, which is a step up from "black box" applications who ask your browser to run code on their behalf. Another factor is what kind of data the JSON interfaces expose. If you're only getting small fragments of the larger whole, building up an entire document is likely to be very awkward.

I have personally had to migrate e-mail data out of a Web-only system where POP and IMAP support was not available. In the end, I had to write a script to pull out each message one at a time, and I had to settle for an inferior version of the original content. I've also used another Web-based system where I was fortunately able to use POP - "fortunately" because the Web interface was very heavy on the JavaScript, and automating the Web browser and then traversing the browser's DOM would have been necessary to access the content. Moreover, that application's JavaScript didn't always work on various browsers that were normally adequate for browsing the Web - another reason for wanting to improve the JavaScript employed by that application.

Sometimes I think that people who apparently don't see the need for the kind of interoperability advocated in this matter - summarised as "I can't see why you'd want this" - have either been fortunate enough never to experience data access or migration issues, or didn't really care when a chunk of their personal data went away once upon a time.

"I CAN see why you'd want this - I just don't think it's realistic

Posted Mar 26, 2009 13:51 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

The question of native storage is not directly relevant to the issue of accessibility: HTML is principally an interchange format, and an obviously desirable property of such formats is that the data "stored" in exchanged documents can be accessed by the recipient.

It's quite relevant, of course. There are two choices:
1. Give sane access to the native storage (POP, IMAP, etc) or
2. Create stable server<->client API and build free JavaScript client on top of that.

Without stable server<->client API free JavaScript is pretty useless and I can not see how FOSS guys can demaind stable API from web-sites after declarations like this one. If you care about data at all you need to talk about solution #1 because solution #2 is totally not realistic.

I have personally had to migrate e-mail data out of a Web-only system where POP and IMAP support was not available.

And this IS the problem with such systems. If they had IMAP access - will you still need "Free JavaScript(tm)", or not? It's easier to implement IMAP then to offer free and usable JavaScript on client...

"I CAN see why you'd want this - I just don't think it's realistic

Posted Mar 26, 2009 17:52 UTC (Thu) by pboddie (guest, #50784) [Link] (1 responses)

The question of native storage is not directly relevant to the issue of accessibility
It's quite relevant, of course.

I should have written "in the context of the original complaint". And when someone says "I doubt very much data is natively stored as HTML", it's a total red herring: we're talking about applications where the only interface may well be HTML plus CSS plus JavaScript, with no "line of sight" to the native storage.

I have personally had to migrate e-mail data out of a Web-only system where POP and IMAP support was not available.
And this IS the problem with such systems. If they had IMAP access - will you still need "Free JavaScript(tm)", or not? It's easier to implement IMAP then to offer free and usable JavaScript on client...

Well, of course I wouldn't need to run a modified version of the JavaScript code if I could have access to the underlying data, but we don't always get the choice. And of course Stallman talks about solution #1, but I guess he realises that sometimes solution #2 is worth demanding if that's all you're likely to get.

Meanwhile, in all this discussion, I think we've completely demolished the "JavaScript is just content" notion, which is what I mostly objected to in the beginning.

"Let them eat cake" approach just does not work...

Posted Mar 27, 2009 15:29 UTC (Fri) by khim (subscriber, #9252) [Link]

Well, of course I wouldn't need to run a modified version of the JavaScript code if I could have access to the underlying data, but we don't always get the choice.

If you can not convince people to give you this access how the hell are planning to ask them to give you stable client<->server API - without which free JavaScript is useless? It's usually easier to give you access to raw data than to create and support stable client<->server API...

Meanwhile, in all this discussion, I think we've completely demolished the "JavaScript is just content" notion, which is what I mostly objected to in the beginning.

I see no such demolishing. Sure JavaScript is what server uses to show you tables, circles and other figures but it's no different from how PostScript and PDF are used. Either you should declare all these countless PostScript and PDF papers "programs" and fight for freedom (good luck) or you should accept that JavaScript is just a content in pretty opaque form...

Yeah, it was nice idea

Posted Mar 26, 2009 6:23 UTC (Thu) by khim (subscriber, #9252) [Link]

A principal benefit of the Web is that your data (the actual content) is supposed to be delivered to you in a way that makes it relatively easy to access (like a "view source" function actually working).

Unfortunatelly this idea was killed while Web was in it's infancy. Almost before it was born. If you remember initially HTML was supposed to only contain content and have no style. It got some usage but Web only started to spread like wildfire when this idea was abandoned and Netscape added tons of tags to make styling possible. Gopher (which refused to budge) was more-or-less killed. To think that the people will stop at this point is uttery ridiculous.

example of free software vs. proprietary bits

Posted Mar 23, 2009 12:06 UTC (Mon) by DeletedUser32991 ((unknown), #32991) [Link]

The free software yocto-reader had a problem like this not too long ago.

I would be a shame if developing free web (-interfacing) applications was increasingly unfeasible. Having all these web APIs that make you use some proprietary library (include, even...) is a serious departure from developing in a free operating system with free libraries, and it does deserve some attention.