Rhino vs. Node.JS

[GaryCrab]

I understand that Node.JS is built from the ground-up to be a server-side JavaScript framework. Rhino, however, can function well as a desktop scripting tool, with its built-in functions (e.g., reading files) and ability to use Java classes. Does the same apply for Node.JS?

[Florian Traverse]

Yes.

2011/10/20 GaryCrab <furas...@gmail.com>:

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

[Matt]

Well, no... It can't use Java classes. But there are node.js modules to do quite a lot of things that Java classes would cover (not everything - for example I think Oracle and MS-SQL Server support is still missing in database classes).

[Diogo Resende]

When people say server-side they should say "not browser-side".
Server/desktop
is the same thing, it's a computer. Apart from the Java classes (for
now), Node
can also function as a desktop scripting tool, reading files, etc..

---
Diogo R.

[Joseph Gentle]

On Friday, 21 October 2011 10:29:23 UTC+11, Diogo Resende wrote:

When people say server-side they should say "not browser-side".
Server/desktop
is the same thing, it's a computer. Apart from the Java classes (for
now), Node
can also function as a desktop scripting tool, reading files, etc..

---
Diogo R.

Sure - but unlike java, there are no UI libraries and stuff like that. Its expected that people will interact with nodejs applications using a browser.

-J 

[Christophe Eymard]

We're slowly getting there I think ; there are efforts to port GTK, SDL, etc... to the NodeJS world after all.

[Damianos Mylonakis]

We have great bindings to GTK ;) (under heavy development)
https://github.com/zcbenz/node-gui

[Sebastian Wick]

We have great bindings to GTK ;) (under heavy development)
https://github.com/zcbenz/node-gui

but thats fail-ish because we need dynamic bindigs!
https://github.com/creationix/node-gir

[Damianos Mylonakis]

I prefer this to this!

[Axel Kittenberger]

Well thats the beautiful thing about an alive ecosystem. Lets see
which approach works out better.

IMHO its often proofs to be less the "better" principle approach, but
which one is better catered for. And that also answers the OP, node.js
caters very well for webservers. Many new things are approaching and
they are all awesome, but they are still even younger than node.js.

[Sebastian Wick]

 I prefer this to this!

Thats just the api which is getting better btw,
https://github.com/swick/node-gir/blob/master/examples/browser.js

[Dean Landolt]

Meh, not to minimize the effort but ISTM there's a convergence happening where OSes are moving toward the web platform for various window management needs. It may be worth waiting on (or better yet, pushing harder for) the OSes to reach this convergence. IMHO what we need is more window managers built on the web platform, not more bindings to existing window managers.

[Michael J. Ryan]

On 10/20/2011 4:20 PM, Matt wrote:
> Well, no... It can't use Java classes. But there are node.js modules to do
> quite a lot of things that Java classes would cover (not everything - for
> example I think Oracle and MS-SQL Server support is still missing in database
> classes).

For Oracle/MS-SQL, or for that matter most RDBMS data sources, simply using
the node-odbc adapter is probably the best bet. I do with that JS supported a
multi-line string though.

ex: C#: @"...";
VB.Net (via XML cheat): <![CDATA[ ... ]>.Value

It's nicer to have SQL code not broken up by \"\r\n\t+ \" Of course if the
google guys would allow E4X in V8, or the node trunk would support
spidermonkey(spidernode) then it would be much nicer in terms of supporting
certain things.

--
Michael J. Ryan - http://tracker1.info/

[Joshua Holbrook]

> I do with that JS supported a multi-line string though.

I usually do this:

[ "line1",
"line2",
"line3" ].join("\n")

It's not as lightweight as a multi-line string literals would be, but it helps.

--Josh

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

--
Joshua Holbrook
Engineer
Nodejitsu Inc.
jo...@nodejitsu.com

[Dean Landolt]

I'm pretty sure there's zero chance of v8 getting e4x. But quasiliterals are in for es-next and they enable a form of multiline strings [1]. It may be a while before this lands in v8, but it'll be a whole lot sooner than e4x :)

http://www.2ality.com/2011/09/quasi-literals.html

[Michael J. Ryan]

On 10/21/2011 11:10 AM, Joshua Holbrook wrote:
>> I do wish that JS supported a multi-line string though.

>
> I usually do this:
>
> [ "line1",
> "line2",
> "line3" ].join("\n")
>
> It's not as lightweight as a multi-line string literals would be, but it helps.

I have done the same... however, would be nice to just have multi-line
literals and/or e4x to support that behavior.. makes copy/paste in/out of the
utility for the dbms that much more prone to error.

[Michael J. Ryan]

On 10/21/2011 11:23 AM, Dean Landolt wrote:
>> using the node-odbc adapter is probably the best bet. I do with that JS
>> supported a multi-line string though.
>>

>> ...

>> It's nicer to have SQL code not broken up by \"\r\n\t+ \" Of course if
>> the google guys would allow E4X in V8, or the node trunk would support
>> spidermonkey(spidernode) then it would be much nicer in terms of
>> supporting certain things.
>
> I'm pretty sure there's zero chance of v8 getting e4x. But quasiliterals are
> in for es-next and they enable a form of multiline strings [1]. It may be a
> while before this lands in v8, but it'll be a whole lot sooner than e4x :)
>
> http://www.2ality.com/2011/09/quasi-literals.html

I know very well the feelings on e4x.. which would be far more useful in node,
than in the browser. Just the same, the quasi-literals thing seems pretty cool.

[Scott van Looy]

"In Javascript \
this is a multi \
line string"

What's so unreadable about that? Or am I missing something?

Scott

[Axel Kittenberger]

"In Javascript \

this is a multi \
line string"

Because this isn't Javascript! The v8 interprets its as one as property extension, but some browsers don't.

[Isaac Schlueter]

Scott,

That's not a multi-line string. That's a string with some escaped line breaks.

> "asdffoo" === "asdf\
foo"
true

What you want is something like python's triple-", where:

"""
asdf
foo
""" === "asdf\nfoo"

[Joshua Holbrook]

"I guess we could \n\
write multi-line \n\
strings like this? \n\
\n\
--Josh"

--

[Scott van Looy]

On 21 Oct 2011, at 23:35, Joshua Holbrook wrote:

> "I guess we could \n\
> write multi-line \n\
> strings like this? \n\
> \n\
> --Josh"

I guess we could if we were a n00b.

What's so important about multi line strings?
And what's wrong with something like:
[

'This is a multi'
,'line string that doesn\'t'
,'look particularly scary or'
,'hurt kittens. YMMV.'

].join('\n');

[Joshua Holbrook]

Nothing. I suggested it myself earlier.

--Josh

[Diogo Resende]

Here's a 3rd option:

"This is a multi\n" +
"line string that doesn't\n" +
"look particularly scary or" +
"hurt kittens. YMMV."

Get a job! :P

---
Diogo R.

[secoif]

you can always do multiline strings in coffeescript ;) http://jashkenas.github.com/coffee-script/#strings

[Dominic Tarr]

actually, javascript already has a syntax for multiline strings!

var string = /HERE(.*)HERE/.exec(function () {

/*HERE<--this is the start of the string...

yeah, so this is a little more arkward than

heredocs are in bash even....

but still here you go.

(oh, yeah... just don't do any source code transforms)

endOfString-->HERE*/}).toString())[1]

On Sat, Oct 22, 2011 at 8:28 PM, secoif <sec...@gmail.com> wrote:

you can always do multiline strings in coffeescript ;) http://jashkenas.github.com/coffee-script/#strings

--

[Dean Landolt]

On Sat, Oct 22, 2011 at 6:45 AM, Dominic Tarr <domini...@gmail.com> wrote:

actually, javascript already has a syntax for multiline strings!

Actually, no. Function.prototype.toString's behavior isn't standardized.

[Dean Landolt]

This is one of uncle Crockford's very naughty parts -- any whitespace after your "\" will lead to a syntax error. Except it's whitespace -- you can't see it -- so there's no way to tell the difference between a legal statement and a syntax error. I'll call that unreadable :)