What JavaScript Needs
Nick Spiegel
1) <b>To save a file.</b> Imagine if any local app couldn't save what
you were doing! GIMP? Powerpoint? The thought is absurd. Somebody
declared that this feature in JavaScript would be a security breach,
and everyone seems to nod their head in solemn agreement. It doesn't
take filesystem access! How could a 'javascript variable' sourced
file be any different, security-wise, than sending a 'url' sourced
file? They're the same.
2) <b>The .jsz format.</b> JavaScript Zipped. Send less code over
the internet by using a basic zipping algorith.
3) <b>A method to dynamically include .js files.</b> In a complex
internet app, only have a user download the .js files that they need.
If you're making a spreadsheet and you want to make a bar graph, then
includewhenneeded('graphing.js','makebargraph();');.
Thoughts?
Daniel Friesen
> Javascript could use the following features:
>
> 1) <b>To save a file.</b> Imagine if any local app couldn't save what
> you were doing! GIMP? Powerpoint? The thought is absurd. Somebody
> declared that this feature in JavaScript would be a security breach,
> and everyone seems to nod their head in solemn agreement. It doesn't
> take filesystem access! How could a 'javascript variable' sourced
> file be any different, security-wise, than sending a 'url' sourced
> file? They're the same.
JavaScript is a language, you're completely out of scope.
JavaScript is a programming language like Java, C, C++, Ruby, etc...
None of them actually have the ability to save a file, all of that is
provided on top of the language itself.
Java has it's stdlib, Ruby has it's own, C/C++ depend on libraries
provided by the system.
For filesystem access take a look at the ServerJS pesudo-wg group which
is standardizing things like filesystem access for non-browser
JavaScript environments.
As for saving a file in a browser environment, that IS a security
vulnerability to just arbitrarily allow a script on the web to save a
file on your system anywhere it wants.
> 2) <b>The .jsz format.</b> JavaScript Zipped. Send less code over
> the internet by using a basic zipping algorith.
Completely unnecessary. JavaScript sent over the internet follows the
same rules as other things sent over the internet... HTTP. And HTTP
already provides the ability to send anything compressed, just gzip the
contents and send a Content-Encoding: gzip header. Most web servers will
have an option you can enable to turn on this feature.
There is also minification if you want to squeeze out a tiny bit more.
> 3) <b>A method to dynamically include .js files.</b> In a complex
> internet app, only have a user download the .js files that they need.
> If you're making a spreadsheet and you want to make a bar graph, then
> includewhenneeded('graphing.js','makebargraph();');.
Dynamically inserted script tags. Take a look at any decent JS library.
Most of them give you a easy helper to let you dynamically include
scripts into the page, and they aren't even needed, you can do it yourself.
For non-browser javascript again, see ServerJS and require() being
standardized.
> Thoughts?
You're on the wrong list, preaching the wrong things, without knowing
what you're talking about.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Nick Spiegel
> vulnerability to just arbitrarily allow a script on the web to save a
> file on your system anywhere it wants.
Ok, forgetting everything else - could the browsers (firefox!)
facilitate a 'save-as' process and an 'open file' dialog? I'm not
talking about direct filesystem access, just the same saving
machinations that work when you link to a file.
The problem with the AJAX solution is that it requires a server to do
all the work. Why are there no free 'xls' to 'csv' converters on the
internet (for large files)? Nobody wants to provide the bandwidth and
processing required to download/upload/convert the world's files.
That should be an entirely client-side program. Why make an online
javascript image program, if the user can't save their file? Or even
an online notepad? This especially hinders the small developers whose
programs might be crippled by insufficient bandwidth. Try running
AJAX from rural India!
A programmer wants a language that a) works on every OS, b) has a wide
body of support 3) can save and load files, and 4) doesn't have to be
hosted (I don't want to run my program for the world, just give it to
them). Every programming language fails one of these points.
Languages like Java must be compiled separately for each OS, JS can't
save files, and php must be hosted. If JS could do the most basic
file saving, it would be the clear and absolute winner; the king of
the hill.
> You're on the wrong list, preaching the wrong things, without knowing
> what you're talking about.
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
HA! And you humored me with a response! So thank you. Is this post
any more intelligible than the last?
Daniel Friesen
>> As for saving a file in a browser environment, that IS a security
>> vulnerability to just arbitrarily allow a script on the web to save a
>> file on your system anywhere it wants.
>>
>
> Ok, forgetting everything else - could the browsers (firefox!)
> facilitate a 'save-as' process and an 'open file' dialog? I'm not
> talking about direct filesystem access, just the same saving
> machinations that work when you link to a file.
>
http://hacks.mozilla.org/2009/06/xhr-progress-and-richer-file-uploading-feedback/
It's not directly related, but newer versions of firefox seam to support
pulling the content out of file inputs you have selected a file with.
In fact, even in Firefox 3 I can go in and access a .files list with [0]
being that file and there are .getAsBinary and .getAsText methods.
Though either .getAsText is broken, or Firebug is broken for me, I
dunno... But I can use .getAsBinary().toString() to get the file fine.
For save as, I'm sure you can already emulate that kind of thing using
data: urls. Just construct a <a> tag with a data: url in the href, give
it a application/octet-stream mime type and theoretically clicking on it
should give you the option to save the data as a file.
> The problem with the AJAX solution is that it requires a server to do
> all the work. Why are there no free 'xls' to 'csv' converters on the
> internet (for large files)? Nobody wants to provide the bandwidth and
> processing required to download/upload/convert the world's files.
> That should be an entirely client-side program. Why make an online
> javascript image program, if the user can't save their file? Or even
> an online notepad? This especially hinders the small developers whose
> programs might be crippled by insufficient bandwidth. Try running
> AJAX from rural India!
>
> A programmer wants a language that a) works on every OS, b) has a wide
> body of support 3) can save and load files, and 4) doesn't have to be
> hosted (I don't want to run my program for the world, just give it to
> them). Every programming language fails one of these points.
> Languages like Java must be compiled separately for each OS, JS can't
> save files, and php must be hosted. If JS could do the most basic
> file saving, it would be the clear and absolute winner; the king of
> the hill.
>
What, Java compiled separately for each OS? Since when?
C/C++ you need to compile for each OS. Java you just compile the
bytecode and any JVM runs it. In fact you can embed a Java applet into a
webpage, and access the filesystem if it's signed.
If you think there is something missing inside browsers in general you
should bring it up in the WHATWG mailing list and perhaps it might get
standardized in HTML5.
An individual browser mailing list (this isn't even the right one, iirc)
isn't the place to bring it up. If you think one browser having that
kind of feature is going to make people flock to using that feature,
think again. IIRC IE's ActiveX exposes the system in some pretty
insecure ways, theoretically you could program an IE targeted app that
could provide those kind of file open and saving api's, if you knew the
right codes.
If Firefox implemented that kind of feature on it's own it will still
fall under your failure list because support for it is not uniform
across browsers, and we're through with the days of "Please use X
browser to browse this site".
You might want to take a look at WebWorkers. A new HTML5 bit that
actually aids the kind of stuff you're thinking of. ;) Think XLS to CSV
done in-browser in the background without disturbing the UI and using
postMessage to fire off progress messages to update a progress meter, heh.
>
>> You're on the wrong list, preaching the wrong things, without knowing
>> what you're talking about.
>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>>
>
> HA! And you humored me with a response! So thank you. Is this post
> any more intelligible than the last?
>
--