views:

181

answers:

4

Why was it decided to ship javascript programs in plain text? Was it to achieve performance enhancement or the authors never imagined that javascript will be used in much more complex applications and developers may want to protect the source code?

+2  A: 

Take a look at YUI; it will compress javascript files by replacing all the names of variables, functions, etc to stuff like a, b, c, ...

It will also remove all unnecessary whitespaces, newlines, etc. So it will both obfuscate the javascript code and reduce its size.

Andreas Bonini
Obfuscation is a great way to reduce the size of the code, and make it extremely difficult to read (or steal). But it's a bitch to maintain, so it's good to use a tool for obfuscation so you don't have to code it that way.
DOK
+3  A: 

That's because JavaScript was never intended for large web applications, rather it was a way to do something "cool" on the browser. JavaScript wasn't a very popular language and was despised until the advent of AJAX, that is why there has never been much insight how JavaScript should be distributed. After all, simplest way to send JavaScript to a browser was through regular text files, why would they have bothered with anything else back in 1995?

Tatu Ulmanen
I guess we've had different experience developing with javascript. I've been using it for a long time on large web applications just fine. It may have been despised by folks who don't actually like to write code.
DOK
Also, originally the internet was made to share simple plain text documents, so it made sense to make web pages simple plain text documents.
Xavi
+5  A: 

I think part of the reason was that since HTML itself was delivered in plain text to the browser then so should JavaScript. It was the way of the Web.

Darrell Brogdon
-1. This is not an answer, just a pseudo-religious statement (you might have called it the way of the lord or something as well).
KooiInc
+1  A: 

Text is the one data form which transfers between any pair of computers without concern about computer architecture: endianness, word size, floating point binary representation, negative encoding, etc. Even EBCDIC computers readily handle ASCII.

Though any binary representation scheme can overcome these stumbling blocks—as TCP/IP internals do—code which does this is not completely pleasant to work with—or even to read. Experience is that even the most seasoned engineers occasionally forget to use a needed host-to-network or network-to-host conversion macro.

Indeed, many protocols which primarily transmit numeric information convert values to ASCII notation for transmission largely because of the generality. (PCL and ANSI 3.64 come to mind.) Text based transmission is handily supported by a wide universe of native numeric formatters and parsers, all of which tend to be well optimized. Also, virtually every programming language handily supports text encoded numeric data. Support for binary formatted data varies from adequate to painful.

wallyk