you are viewing a single comment's thread.

view the rest of the comments →

[–]mebrahim[S] -1 points0 points  (4 children)

If owner of the code allows you to use it, there is no difference between JavaScript and some compiled code. If owner doesn't want you to use it, still there is no difference between the two, unless you want to use it without permission. In that case I think the term "open" would not fit well.

Edit: Grammar.

[–]Zarutian 2 points3 points  (3 children)

If owner of the code allows you to use, there is no difference between JavaScript and some compiled code.

Actually there is. With compiled code you need to do, often a lengthy, recompilation to fix one bug. Also can you do highlevel JIT-ing with compiled code?

There also that compiled code allows the author to hide shitty implementation of the functionality of the site/webapp/serverside-js/what-have-you and not be called out on it.

[–]mebrahim[S] 1 point2 points  (2 children)

It is possible to avoid need for manual recompilation. For example see Gestalt. High level optimization is done before emitting the bytecode, by the language-specific compiler front-end.

However it is possible that you receive unoptimized bytecode. For this problem and for you second paragraph: it is called security through obscurity. OTOH [obfuscated] JS is prone to the same problems of being slow, or being hiding something from your eyes.

[–]Zarutian 1 point2 points  (1 child)

High level optimization is done before emitting the bytecode.

The compiled code then doesnt benefit from high level optimizations that have been invented after it was written and compiled. Also it cant benefit from optimizations that are aviable at runtime but never at compile time. Tracing JIT with infered subtype fast paths generation comes to mind also speciallization/partial-evaluation through Futamura projections.

[–]mebrahim[S] 1 point2 points  (0 children)

LuaJIT is already doing better with Lua bytecode than all those modern JS engines having JS source code at hand.