Two more potentially worthwhile targets for commonjs

81 views
Skip to first unread message

Mike S

unread,
Jan 1, 2012, 11:02:06 AM1/1/12
to CommonJS

It is imho opinion a mistake to assume that serverside javascript must
waste a whole decade reimplementing what had already been maturely and
comprehensively implremented already, and for a spurious reason. Code
doesn't need to be all asynchronous, and in fact, it's a mistake to
insist it must always be so.

I also find commonjs/jsgi a well-thought out specification, and not
only imho the only viable serverside javascript one de jour, but also
better than its predecessors like wsgi.

commonjs/jsgi currently support rhino, and this is good, as it
provides access to the java libraries. Unfortunately rhino currently
lags a bit, though this may improve with time.

Other potential targets that I implore you to consider are:

gjs, integrates spidermonkey, and seed, integrates javascriptcore,
provides access to the vast gnome libraries, which are mature,
comprehensive, support sync/async, and are cross platform. As noted in
a previous post someone has already worked on porting commonjs to it.
https://live.gnome.org/JavaScript

qt libraries, integrates javascriptcore and v8; again, mature,
comprehensive, support sync/async, and are cross platform.
http://en.wikipedia.org/wiki/QtScript http://developer.qt.nokia.com/doc/qt-4.8/network-programming.html

unityscript, A JavaScript implementation based on the Boo programming
language, which itself (boo) has a python-derived syntax, seems to be
the one touted by unity3d as the "World's Fastest JavaScript - Unity's
JavaScript implementation JIT-compiles to native machine code. It runs
20x faster than Flash or Director based JavaScript, and the same speed
as C# and Boo." It should provide access to mono/.net, which, again,
is mature, comprehensive, supports sync/async, and cross platform.
https://github.com/bamboo/unityscript http://unity3d.com/unity/features/scripting

I believe it may be an idea to publicize this widely so individuals
with an interest or experience in javascript and a relevant backend
could consider it as a potential project.

All the best.



Oleg Podsechin

unread,
Jan 1, 2012, 11:35:38 AM1/1/12
to comm...@googlegroups.com
It is imho opinion a mistake to assume that serverside javascript must
waste a whole decade reimplementing what had already been maturely and
comprehensively implremented already, and for a spurious reason. Code
doesn't need to be all asynchronous, and in fact, it's a mistake to
insist it must always be so.

I wholeheartedly agree. 
 
I also find commonjs/jsgi a well-thought out specification, and not
only imho the only viable serverside javascript one de jour, but also
better than its predecessors like wsgi.

commonjs/jsgi currently support rhino, and this is good, as it
provides access to the java libraries. Unfortunately rhino currently
lags a bit, though this may improve with time.

A synchronous programming style using JSGI is also possible on Node using my Common Node library (http://olegp.github.com/common-node/). Here's a talk I gave on it: http://www.slideshare.net/olegp/server-side-javascript-going-all-the-way

Oleg


Christoph Dorn

unread,
Jan 1, 2012, 5:22:53 PM1/1/12
to comm...@googlegroups.com

I am very interested in this direction. I recently presented on where I see things going along the lines you speak:

  CommonJS Everywhere @ Wakanday - http://vimeo.com/31245393

The talk addresses the importance of "package mappings" and the problem they solve in building portable applications.

A loader implementing CommonJS modules and CommonJS package mappings can be reduced to this:

  https://github.com/sourcemint/loader-js/blob/master/loader.stripped.js

I believe this loader could provide a great foundation to build on top of and around for further exploration of cross-platform JS packages and programs.

Christoph


Mike S
1 January, 2012 8:02 AM

Mike Schwartz

unread,
Jan 2, 2012, 2:52:20 PM1/2/12
to comm...@googlegroups.com
Thus SilkJS!





--
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/-/L80IT8TQPJ0J.

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.

Reply all
Reply to author
Forward
0 new messages