Campy: camping for node.js

10 views
Skip to first unread message

beppu

unread,
Aug 13, 2009, 2:22:00 PM8/13/09
to squatting-framework
A friend of mine recently started work on Campy, a new web
microframework for node.js that's based on Camping.

http://github.com/Bluebie/Campy/tree/master

This is a beautiful confluence of technologies that I like.
- Fast Javascript on the Server Side (v8),
- Asynchronous IO (libev), and
- Concise Code (the camping influence)

On IRC, Bluebie lamented that she might not even use Ruby in her next
project, because node.js brings so much server-side goodness to the
table. I really tend to agree w/ that sentiment, because I could see
myself moving to JS on the server-side, too. The combination of the
v8 javascript engine (by google) and libev (by our friend Marc Lehman
of AnyEvent and Coro fame) is just too good to ignore.

http://github.com/ry/node/tree/master

Check it out.

--beppu

Terrence Brannon

unread,
Aug 13, 2009, 2:49:49 PM8/13/09
to squatting...@googlegroups.com

beppu wrote:
> A friend of mine recently started work on Campy, a new web
> microframework for node.js that's based on Camping.
>
> http://github.com/Bluebie/Campy/tree/master
>
> This is a beautiful confluence of technologies that I like.
>

it seems to blur the line between web server and web application.


I guess you could still use Perl as a data service, serving up JSON back
to the node.js

Javascript is a bit tough to grok as a language. It was kept lightweight
and so people went their wayswith making object systems on top of it.

beppu

unread,
Aug 16, 2009, 8:43:48 AM8/16/09
to squatting-framework


On Aug 13, 11:49 am, Terrence Brannon <metap...@gmail.com> wrote:
> beppu wrote:
> > A friend of mine recently started work on Campy, a new web
> > microframework for node.js that's based on Camping.
>
> >http://github.com/Bluebie/Campy/tree/master
>
> > This is a beautiful confluence of technologies that I like.
>
> it seems to blur the line between web server and web application.

That's a reasonable take on what node provides. I see some parallels
between node and Continuity in the sense that in both cases, the
server is "built-in". You then get an API to write your web app on
top of. (Their APIs are very very different, though.)


> Javascript is a bit tough to grok as a language. It was kept lightweight
> and so people went their wayswith making object systems on top of it.

Javascript is the little language that could. The only weird part
about it is the scoping of the magical "this" variable. It makes
sense, but it takes a little getting used to.

Also, it is a shame that people are coding all kinds of hacks to work
around Javascript's crippled prototypes. I wish Brendan Eich would
have copied Self's object system a bit more faithfully when he created
Javascript. People would have *LOVED* prototypes if Javascript had a
prototype system as powerful and simple as Self's.

--beppu

Terrence Brannon

unread,
Aug 16, 2009, 6:12:56 PM8/16/09
to squatting...@googlegroups.com

beppu wrote:


  
Javascript is a bit tough to grok as a language. It was kept lightweight
and so people went their wayswith making object systems on top of it.
    
Javascript is the little language that could.  The only weird part
about it is the scoping of the magical "this" variable.  It makes
sense, but it takes a little getting used to.
  
The other weird part is being limited to web browsers... what happens when we evolve to greater view technologies? At one point there were no web browsers.
I'm JS will find some way to adapt.

Also, it is a shame that people are coding all kinds of hacks to work
around Javascript's crippled prototypes.  I wish Brendan Eich would
have copied Self's object system a bit more faithfully when he created
Javascript.  People would have *LOVED* prototypes if Javascript had a
prototype system as powerful and simple as Self's.
Speaking of prototypes, I had pretty much finished a Moose-ification of CGI::Prototype <http://github.com/metaperl/perl-module-cgi-prototype/tree/master>
when I learned that Randal found that Moose was not truly capable of what he wanted from prototype objects. He said I would have to have a prototype-OO base class before my re-implementation would have his blessing.

He spoke of objects that had a local setter but would climb the object tree to get their value.

Personally I am able to get by with Moose and roles. Prototype objects are definitely the most flexible, but all that flexibility has not shown itself to be necessary yet.

Reply all
Reply to author
Forward
0 new messages