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]

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]

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.

 

[RobG]

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.

 

[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]

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/devutilities/a/decompiling.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.