Sync loading of JavaScript source

[tjholowaychuk]

I know this sort of goes against the goals of this library.. but for
example I am writting Express (small web framework) for node.js
but I cannot even really run Specs since any loading via node.rs.cat
() / eval() is non-blocking and just loads at random, causing tons of
errors.

http://gist.github.com/139598

I know you have include() and require(), but to be honest I would much
rather just load some JavaScript normally and leave 'exporting' to the
code itself.

This issue somewhat crosses over to views as well, for example this
would be ideal. Where display() would simply return a parsed view, but
since everything is callback-crazy I cant really do that

get('article/:id', function(){
display('article', Article.get(param('id')))
})

Any ideas?

Thanks!

[ryan dahl]

> I know this sort of goes against the goals of this library.. but for
> example I am writting Express (small web framework) for node.js
> but I cannot even really run Specs since any loading via node.rs.cat
> () / eval() is non-blocking and just loads at random, causing tons of
> errors.

So, you need to use the onLoad() callback. Only when that is called is
it assured that the modules are loaded. Otherwise it could be
somewhere in-between.

I think a synchronous module loader could be considered. Web Workers
is doing this. On the other hand, the idea of a purely asynchronous
system is appealing. (At the moment node.debug() is the only
synchronous function.)

> I know you have include() and require(), but to be honest I would much
> rather just load some JavaScript normally and leave 'exporting' to the
> code itself.
>
> This issue somewhat crosses over to views as well, for example this
> would be ideal. Where display() would simply return a parsed view, but
> since everything is callback-crazy I cant really do that
>
> get('article/:id', function(){
>  display('article', Article.get(param('id')))
> })
>
> Any ideas?

This should be able to made to work - you'll just need to do a couple
callbacks before finally calling response.finish(). I had a look at
express.core.js and while I haven't spent time time to really look
through it, i can see that
http://github.com/visionmedia/express/blob/651f4abc4741dfe04634fbf1ee0dad8abd85b359/lib/express.core.js#L33
is not going to work except for non-I/O performing requests.
There has to be some callbacks before response.finish() is called.

In node_chat for example, I have requests hold for other I/O
http://github.com/ry/node_chat/blob/0f0296f4183a87f50982fce279838f75921dc40f/server.js#L147

Thinking about your program in terms of I/O events is different and
requires different structure, but somehow, I think it also makes more
sense (it's also massively more efficient)

[tjholowaychuk]

Thats certainly the only issue, everything else is fantastic, I am
just used to Rhino and others so having
crazy amounts of callbacks everywhere is a bit odd although it
obviously fits the goal of node.js

I am not very knowledgeable with server-side JavaScript but IMO I
really dont like the whole module / exporting idea,
it keeps things clean I suppose but whatever happened to:

(function(){
function notExposed(){}
somethingExposed = function(){}
})()

I would really like to have the framework as clean as possible, using
routes without have foo.get('whatever') and
without nesting tons of callbacks to make sure library files load in
order.

Not trying to diss any of your work I think its awesome and I love
node.js :D just expressing my issues

> through it, i can see thathttp://github.com/visionmedia/express/blob/651f4abc4741dfe04634fbf1ee...

> is not going to work except for non-I/O performing requests.
> There has to be some callbacks before response.finish() is called.
>

> In node_chat for example, I have requests hold for other I/Ohttp://github.com/ry/node_chat/blob/0f0296f4183a87f50982fce279838f759...

[tjholowaychuk]

What would you recommend in order to keep the public API the same as
it currently is?
At least as far as the route functions go

[tjholowaychuk]

Another reason I wouldnt mind a simple load() function is for testing.
JSpec was designed for
Rhino / client testing but I would really like to support node.js as
well, but blocking IO would be needed
to load all the suites / library files in order. The Rhino source
looks like this http://gist.github.com/141804

On Jul 2, 4:05 pm, ryan dahl <coldredle...@gmail.com> wrote:

> through it, i can see thathttp://github.com/visionmedia/express/blob/651f4abc4741dfe04634fbf1ee...

> is not going to work except for non-I/O performing requests.
> There has to be some callbacks before response.finish() is called.
>

> In node_chat for example, I have requests hold for other I/Ohttp://github.com/ry/node_chat/blob/0f0296f4183a87f50982fce279838f759...

[Urban Hafner]

tjholowaychuk wrote:
> Thats certainly the only issue, everything else is fantastic, I am
> just used to Rhino and others so having
> crazy amounts of callbacks everywhere is a bit odd although it
> obviously fits the goal of node.js
>
> I am not very knowledgeable with server-side JavaScript but IMO I
> really dont like the whole module / exporting idea,
> it keeps things clean I suppose but whatever happened to:
>
> (function(){
> function notExposed(){}
> somethingExposed = function(){}
> })()
>
> I would really like to have the framework as clean as possible, using
> routes without have foo.get('whatever') and
> without nesting tons of callbacks to make sure library files load in
> order.
>
> Not trying to diss any of your work I think its awesome and I love
> node.js :D just expressing my issues

I agree. It also took me a while to understand how to load the modules
in a specific order (and mimic namespaces as used by node internally,
like node.http.createServer, node.debug, ...).

Though I'm not sure how to really fix it.

Urban

[tjholowaychuk]

haha I had to hack the shit out of the IO to get specs to load in
sync :(
http://gist.github.com/142232

would be great if there was at least an option for sync IO, or
seperate functions

[Joshaven Potter]

When I hear routing, I think of sessions & resource location, I don't think these tasks are applicable to all uses of node and thus should be kept external to the core of node.  I intend to be build a large webapp myself and will be releasing the majority of it under the GNU licence.  I have every intention of being fully in sync with node.js and maintaining a minimalist approach while employing a MVC style framework.  

Furthermore, I think routing is outside the scope of the stated purpose of node... "Purely event-based I/O for V8 javascript."

I think it is reasonable to expect to find good projects like routing engines & MVC frameworks to emerge very quickly that run on node.  Its also reasonable to find projects that give you a good mix of these resources that can be something like a turn key web server solution.  I envision a "www-node" project (probably by another name) that would have routing, data access & storage, etc all baked in just like Rails or Django but I don't think node should become an equivalent to Rails & Django.  I believe that node is a great foundation for great new projects.

--
Sincerely,
Joshaven Potter

"No man making a profession of faith ought to sin, nor one possessed of love to hate his brother. For He that said, “Thou shalt love the Lord thy God,”  said also, “and thy neighbor as thyself.”  Those that profess themselves to be Christ’s are known not only by what they say, but by what they practice. “For the tree is known by its fruit.”" -- Ignatius

[tjholowaychuk]

Well that is what my project 'Express' is for
http://github.com/visionmedia/express

I never said node should have anything to do with routing, just that
the option to perform sync IO would be very handy and allow me to do
some things that cannot be done the same otherwise.

I know many devs use Rhino but its slow shit and I really dont like
Java
so I thought it would be much more fun to use node.js

On Jul 7, 1:33 pm, Joshaven Potter <yourt...@gmail.com> wrote:
> When I hear routing, I think of sessions & resource location, I don't think
> these tasks are applicable to all uses of node and thus should
> be kept external to the core of node.  I intend to be build a large webapp
> myself and will be releasing the majority of it under the GNU licence.  I
> have every intention of being fully in sync with node.js and maintaining a
> minimalist approach while employing a MVC style framework.
> Furthermore, I think routing is outside the scope of the stated purpose of
> node... "Purely event-based I/O for V8 javascript."
>
> I think it is reasonable to expect to find good projects like routing
> engines & MVC frameworks to emerge very quickly that run on node.  Its also
> reasonable to find projects that give you a good mix of these resources that
> can be something like a turn key web server solution.  I envision a
> "www-node" project (probably by another name) that would have routing, data
> access & storage, etc all baked in just like Rails or Django but I don't
> think node should become an equivalent to Rails & Django.  I believe that
> node is a great foundation for great new projects.
>

[Brian Hammond]

Express is nice so far. It could use a few examples. JSpec is pretty
killer too BTW :)

[tjholowaychuk]

Thank you! Just started Express a few days ago so it has quite a while
to go
until it is even ready to use at all, I will post a release and add
examples at that point.

JSpec has come along way as well, very fun to use though much better
than any other BDD framework
I have used including RSpec

On Jul 7, 7:09 pm, Brian Hammond <or.else.it.gets.the.h...@gmail.com>
wrote: