Closed Javascript source code

[harish.mallipeddi]

Hi all,

This might sound a bit weird but anyways here I go. Recently after
witnessing the popularity of AJAX/DHTML, and after enjoying Gmail's
fairly cool UI, I'm left wondering...is there going to be a point in
the future when Javascript developers would like to hide their
sourcecode from prying eyes because they think they'd put in enough
efforts into coding and they wouldn't want to give up the commercial
value in their code for nothing? You spend a few nights creating a good
looking web interface with AJAX, and then some guy just steals it and
uses it for his purpose. Is that fine? (I do understand that something
like this would be deemed as copyright violation; but are you gonna
rely just on copyright law to protect your source code?)

This brings to my next question...Why don't we have clients executing
javascript binaries instead of interpreting javascript sourcecode? Are
there any architectural reasons why this is not possible?

Cheers,
Harish

[Jim Ley]

On 11 Jul 2005 12:17:48 -0700, ha************* **@gmail.com wrote:

Is that fine?
It's part of the contract that users allow you to run code on their
system, as long as they can read the code. I can't see it ever going
away.
This brings to my next question...Why don't we have clients executing
javascript binaries instead of interpreting javascript sourcecode? Are
there any architectural reasons why this is not possible?

Nope, there's nothing architectural, but it would be every bit as
successful as java applets...

Jim.

[Grant Wagner]

<ha************ ***@gmail.com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

This brings to my next question...Why don't we have clients executing
javascript binaries instead of interpreting javascript sourcecode? Are
there any architectural reasons why this is not possible?

Any "binary" executable containing JavaScript would still have to be
downloaded to the client to be executed. That binary would be trivial to
decompile, resulting in the source code.

Not to mention the security implications of arbitrary binary code
obtained from an untrusted Web site executing on your local PC.

The term "binary" code be replaced by "bytecode" and we could run the
JavaScript in a sandboxed virtual machine, but then we'd pretty much
have ... Java. And decompiling source code from the bytecode is still
trivial.

--
Grant Wagner <gw*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[RobG]

ha************* **@gmail.com wrote:

Hi all,

This might sound a bit weird but anyways here I go. Recently after
witnessing the popularity of AJAX/DHTML, and after enjoying Gmail's
fairly cool UI, I'm left wondering...is there going to be a point in
the future when Javascript developers would like to hide their
sourcecode from prying eyes because they think they'd put in enough
efforts into coding and they wouldn't want to give up the commercial
value in their code for nothing? You spend a few nights creating a good
That presumes that there is commercial value in good code. Does the
best code always win, or even get a reasonable return? (must be the
cynic in me).
looking web interface with AJAX, and then some guy just steals it and
uses it for his purpose. Is that fine? (I do understand that something
like this would be deemed as copyright violation; but are you gonna
rely just on copyright law to protect your source code?)
The reality is that any web site can be 'stolen' regardless of whether
the underlying source can be accessed or not.

Look back on some computer history - various GUIs were around before
Apple finally hit on a winner whose functionality continues to be widely
copied. Despite years of litigation, they never managed to protect a
single UI feature or function, despite the whole thing being created in
compiled binaries (originally Pascal).

It is still much easier, IMHO, to copy the UI of a web site rather than
stealing the underlying code. Invariably you want only some of the
ideas or some of the functionality to integrate it with your own ideas.
Implementing someone else's site when you can only see the UI means
guessing at the back-end functionality, so you have a significant design
task anyway.

Just look through the archives of this news group for the number of
posts that start with "I got this code from a web site...", followed by
some code which is at best ordinary and generally awful.
This brings to my next question...Why don't we have clients executing
javascript binaries instead of interpreting javascript sourcecode? Are
there any architectural reasons why this is not possible?

Because the ultimate in cross-platform compatibility is interpreted
ASCII text, i.e. scripting languages. They have been around for nearly
as long as computers have - there are lots of them other than
JavaScript. Cross-platform binaries have never lived up to expectation
- e.g. Java.

If you want cross-platform binaries, use Java. The reason most web
applications don't use use Java is the same reason why JavaScript isn't
compiled.
--
Rob

[Danny]

Well, what you call 'prying' is actually 'learning', as to hiding
material, sounds paranoid, reminds me of the White House confidential
papers criteria, who decides what is or what isn't confidential-worthy?
are you counted in the process? You can make copyrighted issues of
certain material and enforce it and also write some and not do so, is up
to you, as for js, you can make the same claim for any postprocessor
langauge, or any that is not binary-executed. Binary format isn't used as
means to 'hide' or obfuscate, just a lower-level set over an API to access
the objects, on some cases, you may not need it binary at all and require
the flexibility of a script. I mean, Perl uses .cgi or .pl, it really
depends on the needs and scenario but the .cgi is not compiled as means to
'hide' anything, which is what you assume.

We all learned from one another, noone was born taught as much as some
may presume of some speciality, so, You yourself as much as us have been
'prying' at others material, it be a writer's book, your Mom's recipe or
your Dads way to fix the car transmission, but the intermingling it of it
is what makes it improved. By the way, ASCII format goes quicker over a
network connection than binary, and you asked here due to AJAX, and the
nice gmail UIs, well, the intermingling made those 'nice gmail UIs' for
your liking, so, the intermingling worked.
On Mon, 11 Jul 2005 12:17:48 -0700, <ha************ ***@gmail.com> wrote:

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[harish.mallipeddi]

> That binary would be trivial to decompile, resulting in the source code.

I don't think it is as trivial as you seem to think it is going to be :)

[harish.mallipeddi]

I agree with your argument over the cross-platform compatibility of js.
I didn't think about it before :)

Thanks,
Harish

[Grant Wagner]

<ha************ ***@gmail.com> wrote in message
news:11******** ************@g4 7g2000cwa.googl egroups.com...

That binary would be trivial to decompile, resulting in the source
code.

I don't think it is as trivial as you seem to think it is going to be
:)

I do.

Java decompiler: <url: http://kpdus.tripod.com/jad.html />
C# decompiler: <url: http://www.saurik.com/net/exemplar/ />
C decompiler: <url: http://www.backerstreet.com/rec/rec.htm />
Delphi decompiler: <url:
http://delphi.about.com/od/devutilit...ecompiling.htm />

I could go on.

Any compiled JavaScript would almost certainly not be compiled into a
platform specific binary, but instead some form of bytecode or IL. As
shown from Jad and the C# decompilers, it's trivial to recover the
source code from the compiled IL.

If designed today, this fictional JavaScript IL would also almost
certainly contain a wealth of metadata which would probably not only
give you the original source code, but all the correct method and
variable names as well.

Even if JavaScript were compiled as a platform specific binary, it would
never be as complicated as C++ and so would be easy to reverse engineer.

--
Grant Wagner <gw*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq