Hey guys,

Curious as to what you think about adhering to commonjs module
specifications, if you are unfamiliar check this out:
http://wiki.commonjs.org/wiki/Modules/1.0#Sample_Code

The reason I mention this is because of this thread:
http://groups.google.com/group/nodejs/browse_thread/thread/9a248d871e...

I would love to aid in the porting of envjs to allow its inclusion into
various commonjs compliant platforms, but I am really not sure how it fits
into the envjs roadmap.  I was thinking I could branch off and go my own
direction, however I'm not certain that is the best option for the project.

What do you guys think?

-- Elijah

This topic has been covered in this group, albeit I dont think any
action was taken.  At the time, commonjs was being called serverjs.
The topic was raised w/r/t Narwhal integration.

Two threads:
http://groups.google.com/group/envjs/browse_thread/thread/34a6285294c...
http://groups.google.com/group/envjs/browse_thread/thread/9758a0e4653...

Frankly, without some tooling to automate the process, a sizable
amount of env-js would have to largely be rewritten to conform to the
Modules specification. Env-js is a must have for serverjs, so
something is going to have to clear this roadblock.

-rektide

On Dec 7, 11:36 pm, Elijah Insua <tmp...@gmail.com> wrote:

So I'm a little confused about what would make adherence to the commonjs
specifications useful in this case.  If you want to run client-side
javascript like pure templates, they should work just fine in envjs, just
like they would in a browser environment.  If not we can help iron out the
bugs.  I'm generally not opposed to using commonjs spec but I feel like it's
generally a barrier to entry and at this point we just don't have the cycles
to try to seperate our distributables into modules etc

Thatcher

--
Christopher Thatcher

Hiya Thatcher; I'd like to talk this through so at least we can get to
an understanding--

Commonjs' "big idea" is interoperability.  Currently envjs uses the
Rhino API and various pieces of java, no?  Well, commonjs is trying to
define common APIs all the various new javascript run-times can agree
upon, such that envjs could run on Rhino, or V8, or node.js, or
spidermonkey, or narwhal.  Instead of writing envjs as javascript with
a couple java items cribbed in, a common-env-js would be written
entirely to javascript API's. "Fully native" javascript, so to speak.

Its at this point I'm going to try to explain why people want envjs to
be able to run on these runtimes.  These various commonjs runtimes are
most frequently used for server side web development.  Its not just
the allure of envjs running on a different (non-Rhino) runtime, its
the overwhelmingly beautiful draw of having an HTML and DOM library
(envjs) in your runtime, an HTML and DOM library on which to base a
web-framework-cum-web-server.

Although these runtimes use JS-- a "web" language-- for the most part
they lack even basic notions of what HTML and DOM are, and so they're
all reinventing simplistic ways of building HTML code (as these
runtimes dont have any notion of DOM or HTML).  J Resig's Micro
Templating is about as fancy as it gets, and its actually entirely
HTML naive ( http://ejohn.org/blog/javascript-micro-templating/ ).

"If you want to run client-side javascript like pure templates, they
should work just fine in envjs", except envjs doesnt work in our
particular javascript runtimes.  We'd love to be using client-side
javascript code to build and send templates on our servers!  Everyone,
_everyone_ would _love_ to be using jQuery on the server side!
Currently its a separate systems issue-- if we want to use jQuery, we
have to run one envjs/rhino runtime, and then we have to make our
commonjs web server talk to and interact with envjs/rhino.

The long and the short is, there just isnt a good way for server side
developers to host web pages built with envjs.  And, rather than add
the responsibility to envjs to be a good web serving platform-- in
addition to its current role fulfilling the DOM/browser API specs--
it'd be better if envjs could interact and enable the new breed of web
serving platforms-- commonjs runtimes.

Particularly since these runtimes dont have any DOM/browser API
implementations of their own, and desperately want them.

This is all about taking away barriers to entry-- allowing envjs to go
tons of new places-- not erecting new ones.  I'm not sure what your
perceived fear is, I dont think it would change the current user
experience significantly.  Just as envjs bundles an easy start Rhino
environment now, it ought be easy to bundle an easy start Narwhal or
easy start ___ environment in the future.  Here's what using envjs
might look like, on any given commonjs platform:

var envjs= require("envjs")
var page = envjs.load("file://myTemplate.html")
page.window.$("#myDiv h1").css({fontWeight:"bold"})
var content = page.getElementById("myDiv").innerHTML

There are two obvious gotchas:
a) Right now, there's very little spec'd up, and even less implemented
in commonjs.  SecureModules seems to be the common one.  Not enough to
fully implement envjs on.
b) Moving envjs to commonjs would require removing all the Java code.
At present, there are 36 references to java.**, and I have no idea
what /other/ java references there are (nor even how to find out,
aside from manually inspecting each & every "new" construction)

The first part is going to get better on its own (although envjs may
have to call out specific features it needs in the future).  The
second part means two things: mindfulness going forwards to use JS
native in favor of Java solutions wherever possible, and eventually it
means going back and removing whatever Java dependencies there are. As
stated, I'm not sure the extent of the issue.

After re-reading the SecurableModules spec, I can say I no longer have
fear this would be a major rewrite.  Module Loaders seem intended to
provide the sandbox required to prevent global namespace pollution.
All envjs has to do is, after its loaded, extend a global "exports"
object with its public facing API to be.  Quite simple, no major
restructuring.

I'm free for chatting on this topic.  You can email or XMPP me
personally at rekt...@voodoowarez.com .  Alternatively, #commonjs on
irc.freenode.net may be a decent spot to chat.

Regards,
-rektide

On Dec 8, 4:08 pm, chris thatcher <thatcher.christop...@gmail.com>
wrote:

to do to get envjs to run on another platform is fulfill the interfaces.
its a relatively small number of functions.  I believe steven parkes has
done this for johnson so envjs can run on spidermonkey. we just use the
build process to allow use to use different platform implementations, so
this is why we have env.rhino.js and should soon have env.johnson.js.

window has to be available globally and equal to the global this.  I dont
see how using 'require' is more effective than just using closures to keep
variables off the global scope and using whatever platform load call you
need.

load('env.rhino.js');
//now you in a browser javascript environment
window.open('file://some.html');

--
Christopher Thatcher

Just a couple of side notes, adding to Chris's comments:

There are two very important aspects to this as regards env.js. First, env.js needs the infrastructure to support multiple global/window objects. Second, env.js needs the interpreter to support an "invisible proxy" object for globals, necessary to support the way window references work on the client side. This latter part appears to be pretty non-standard: there's even some language in the html5 draft spec that implies this willfully violates ECMA. Both the Rhino and SpiderMonkey ports use native code to implement this.

Any substantiation for "most frequently"? I'm not saying it's not true, but I have no data whatsoever to either support or refute this.

For the record, server-side web dev with env.js is of no interest to me at all. I use env.js solely to do out-of-browser testing. Anything that would make env.js different than a browser (prohibiting frames, not implementing window correctly) or that meant I had to change my code to use env.js in a way that would make my tests incompatible with a real browser is not of interest to me.

I don't mean to imply that commonjs can't bite off these things. For all I know, maybe it already does. I haven't heard of such features but I only know commonjs in broad strokes.

On Dec 10, 7:30 am, chris thatcher <thatcher.christop...@gmail.com>
wrote:

Superb, I'll take a look this weekend and try to get a feel for what
else is required.

Let me ask you a question; does envjs have any faculty to deal with
multiple pages?  If I wanted compare data on two pages, I'd have to
scrape one page, then load the other page, then run my data
comparison?

What I wanted to imply was not code rewriting, but sandboxing, the
notion that individual envjs instances can be brought up in their own
sandboxes and interacted with.

I'm investigating sandboxing now, as envjs usability in a serverjs
environment, to me, hinges upon the ability to deal with more than one
page at a time.  Narwhal has some kind of sandbox implementation
already, I'm not sure the extent of its capabilities nor what other JS
runtimes have sandboxing.  I will try to learn more and follow up.

On Dec 10, 2009, at Dec 10,10:34 AM , rektide wrote:

Not multiple pages per se, but it does support multiple window objects. I don't think those windows are completely isolated. They can probably interact with each other via things like .top and .opener, but otherwise they're pretty independent (with the extended rhino and spidermonkey versions).

It might be possible to flesh out the platform API to do even more isolation. It'd be hard to get complete isolation, though, since env.js is pretty much single-threaded, at least from the JS point of view (XHR, WebWorkers, etc, notwithstanding), and that means the timer implementation has to share some state.