Best Server Side Synchronous Implementations

[Brian McCann]

I have recently set up a V8cgi server and I think it is great but I want to make sure I do all my research before committing a lot of time to my project.

My goal is to get an idea of what other CommonJS implementations would also be worth considering.

I wish the synchronous server side javascript community was less fragmented but hopefully a clear front runner will emerge.

Thanks in advance,

Brian McCann

[Wes Garland]

FWIW, we are happily using GPSEE for real-world production work.

Of course, we are also the authors. ;)

Wes

--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/commonjs/-/JSn-gU2TlOoJ.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Michael Schwartz]

Check out SilkJS

http://silkjs.org

[Oleg Podsechin]

There's Common Node (https://github.com/olegp/common-node) and RingoJS (http://ringojs.org).

I'm all for discussing ways for us to decrease fragmentation of synchronous server side JavaScript. In fact the reason Common Node is RingoJS compatible is because I see Ringo as being the most widely used and active synchronous server side JavaScript community out there at the moment.

Oleg

[Ondřej Žára]

Hi Brian,

thanks for trying v8cgi :-)

Nevertheless, the overall goal of CommonJS community is not to define,
declare and celebrate a common winner: ideally, you should be able to
choose an implementation which suits your needs while NOT having to
care about your own code. CommonJS APIs are the way to this goal...


O.


2012/5/25 Brian McCann <bmcc...@gmail.com>:

[Brian McCann]

Thank for all the input, I personally really like the CommonJS implementations and am glad I switched over from using Node.JS, but if I had never seen Node.JS I would probably never

have seen CommonJS.

On Saturday, May 26, 2012 7:25:43 AM UTC-4, ondras wrote:

Hi Brian, 

thanks for trying v8cgi :-) 

Nevertheless, the overall goal of CommonJS community is not to define, 
declare and celebrate a common winner: ideally, you should be able to 
choose an implementation which suits your needs while NOT having to 
care about your own code. CommonJS APIs are the way to this goal... 


O. 

 

Yeah Ondras, I didn't realize the modules were standardized such that  I hadn't read enough about commonjs there is a standard for modules so you can use them in multiple environments. So if I were to create

a module to do xyz in v8cgi, then someone using Silkjs, Ringojs, Common-Node or GSPEE. That help everyone using commonjs so in that case

having lots of options is great because you get to pick from a lot of great choices so you can use the one that suits you best..

I like v8cgi a lot because It works perfectly with apache which I am more familiar with having used it at work so it puts me in a similar environment

the only difference is I get to use a great modern language like Javascript.

Thanks again,

I hope to contribute to the community as my project develops because I think sync JavaScript could be very popular just like Node.js,

 

2012/5/25 Brian McCann <bmcc...@gmail.com>:
> I have recently set up a V8cgi server and I think it is great but I want to
> make sure I do all my research before committing a lot of time to my
> project.
>
> My goal is to get an idea of what other CommonJS implementations would also
> be worth considering.
>
> I wish the synchronous server side javascript community was less fragmented
> but hopefully a clear front runner will emerge.
>
>
> Thanks in advance,
> Brian McCann
>
> --
> You received this message because you are subscribed to the Google Groups
> "CommonJS" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/commonjs/-/JSn-gU2TlOoJ.
> To post to this group, send email to comm...@googlegroups.com.
> To unsubscribe from this group, send email to

> commonjs+unsubscribe@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/commonjs?hl=en.

> commonjs+unsubscribe@googlegroups.com.

[Wes Garland]

 > having lots of options is great because you get to pick from a lot of great choices so you can use the one that suits you best..

Not only that, but being able to share test cases and programs makes for more robust code across platforms.  Christoph Dorn found a large number of bugs in GPSEE when he ported the PINF loader over.

Best of all, if your program runs on multiple platforms, you can have multiple platform "vendors" competing to see whose platform works the best. This in turn should help to stimulate an overall improvement in the community.

Wes

[Christoph Dorn]

Wes Garland wrote:
> > having lots of options is great because you get to pick from a lot
> of great choices so you can use the one that suits you best..
>
> Not only that, but being able to share test cases and programs makes
> for more robust code across platforms. Christoph Dorn found a large
> number of bugs in GPSEE when he ported the PINF loader over.

FYI

The PINF loader is here [1]. The goal is to devise a portable loader
that shims various JS engines/platforms to the CommonJS APIs and provide
a foundation for portable JS components & applications.

The PINF code was the result of a lot of research & prototyping and I am
now in the process of cleaning up the implementation (still early) under
the sourcemint umbrella [2][3].

> Best of all, if your program runs on multiple platforms, you can have
> multiple platform "vendors" competing to see whose platform works the
> best. This in turn should help to stimulate an overall improvement in
> the community.

Or run your components on one engine on the server and another embedded
within a desktop application.

A presentation I did on where I see this going: "CommonJS Everywhere" [4].

Christoph

[1] - https://github.com/pinf/loader-js
[2] - https://github.com/sourcemint/loader-js
[3] - https://github.com/sourcemint/examples-js/
[4] - http://www.youtube.com/watch?v=05AyeGSmrAs&feature=youtu.be

[Alexandre Morgaut]

On Friday, May 25, 2012 7:02:16 PM UTC+2, Brian McCann wrote:

I have recently set up a V8cgi server and I think it is great but I want to make sure I do all my research before committing a lot of time to my project.

My goal is to get an idea of what other CommonJS implementations would also be worth considering.

I am personally involved in Wakanda which I find really worth considering: http://wakanda.org

 

I wish the synchronous server side javascript community was less fragmented but hopefully a clear front runner will emerge.

Each synchronous SSJS platform has its own advantages and benefits

I tried to give a fair overview in this presentation which I try to update for the best at each edition:

http://www.slideshare.net/alexandre_morgaut/state-of-the-art-server-side-javascript-web5-2012

It is an open work for which any contribution is welcome

I'll see how to take contributions to this work easier (github or a wiki...)

[Michael Schwartz]

I notice SilkJS isn't mentioned.

http://silkjs.org

http://github.com/mschwartz/SilkJS

Thanks

--
You received this message because you are subscribed to the Google Groups "CommonJS" group.

To view this discussion on the web visit https://groups.google.com/d/msg/commonjs/-/oJv18rprk98J.

To post to this group, send email to comm...@googlegroups.com.

To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.

[Alexandre Morgaut]

On Sunday, May 27, 2012 5:34:48 PM UTC+2, mschwartz wrote:

I notice SilkJS isn't mentioned.

It will be fixed in the next version

I will also mention it in Wakanda presentation at NoSQL matters

Feel free to propose a presentation to JS.everywhere()

http://jseverywhere.org