Wilson, a Django-inspired node.js framework | Hacker News Reader

Wilson, a Django-inspired node.js framework

github.com

51 pointswhalesalad16 comments

I was talking with a coworker and he wanted to do something similar, taking an existing frameworks ideas and structure and porting it to node...

I propose a question to him and will do the same here: Why? Why not just stick with the existing framework?

Isn't there a better/ less frustrating/ more intuitive way to do frameworks? Is Django/ Rails really as good as it gets?

I don't know the answers. It's just a set of questions that I figured were important... Especially if you're going to get yourself stuck in to a project for a few months/ years.

I can answer your first question:

Why not just stick with the existing framework?

Because there isn't one. Node is an evented, web-and-net-savvy I/O stack, with which you could just as easily write an IRC, HTTP or DNS server.

If you want to write a complete web application, you'd be better off writing less code on top of a framework than making lots of easy mistakes dealing with the entire stack.

You've missed my point. I'm not advocating that you don't do it at all. I'm saying... Why do it this way?

Node is an evented, web-and-net-savvy I/O stack

Python has issues dealing with I/O due to the GIL. (Here come the downvotes) Node.js also has the benefit of cutting-edge VM development, an area where Python is catching up. Combine this with the prospect of having the same language on the client and server, and the whole package sounds quite attractive.

Python has issues dealing with multiple cores due to the GIL, not I/O. Global Interpreter Locked threading like Python's and Ruby's can deal with I/O concurrency just fine: they context switch upon encountering a blocking I/O operation. In the end Python and Ruby can only handle I/O on a single core but the same is true for Node.js whose evented model makes it inherent single-threaded. This is easily solved by setting up multiple processes, one process per CPU core, with each process possibly handling many I/O operations concurrently.

I'm still baffled by the amount of misinformation about I/O concurrency.

You can write a program in Python that does I/O, and leaving it unmodified benchmark it running 10's of thousands of times slower on a dual core machine than on a comparably equipped single core machine. Can you do this with Ruby, Smalltalk, Lisp, or Lua? Specifically, it's the GIL that's involved.

Yes you can. But that's not an I/O problem, that's a problem in their GIL locking/unlocking/context switching implementation. Even when doing pure CPU computation in Python you run into the same problem. There was a presentation about this a while ago which explains the problem in detail.

However the problem is not inherent to all GIL systems. Ruby 1.9 also has a GIL but does not suffer from the problem of running slower on dual core than single core.

Hi -- this is chrisdickinson.

One of Wilson's goals is to be comfortable for Djangonauts who, for whatever reason, need to write Node.js code. To that end, the ORM, view layer, and template system are similar to Django to ease use in that particular case.

The other boon to having a largely cross-compatible template language is that it allows a bit of bootstrapping to occur for Wilson projects -- Wilson could conceivably make use of Django's admin templates at some point, if that's the direction it's going to head.

However, Wilson does diverge pretty rapidly from Django in other areas -- it borrows Django's concept of apps, but in Wilson apps are designed to be pluggable; you can install a single app multiple times under multiple aliases, reopen app instances from the project level and change their settings and models before they're finalized, etc. Within the context of an app, you interact with other apps through "externals" that are resolved at project-level.

The other major difference is that wherever possible, I'm hoping to keep the libraries that constitute Wilson separate -- and wherever it makes sense, to make them also operable in-browser. To that end, Platoon (the testing framework), Plate (the template language), Escaperoute (the router), Pieshop (the ORM), and postpie (the ORM adapter to Postgres) are all kept as separate libraries; Pieshop and Plate are actually designed to be run in-browser as well, in preparation for the eventuality of needing to interface nicely with a Wilson app from the client-side.

So in summary: Wilson isn't a one-to-one port of Django -- it's heavily Django-inspired -- but aims to diverge wherever it is sensible to do so.

There is also djangode: http://github.com/simonw/djangode

simonw hasn't worked on it in a while, but it's been forked a bit to keep up with the latest node. It doesn't give you an orm but does basic regex routing and django style templates.

No examples :|

Edit: thanks for the link!

I assume you saw this? http://github.com/chrisdickinson/wilson/blob/master/docs/int...

as an admonition: this project is very much a work in progress right now (at the moment, I'm moving the ORM into Wilson proper) so the docs are a little out of date. I have a separate github repository that serves as a wilson example: http://github.com/chrisdickinson/wilson-example/

I'll push up some updates to the example tonight, and I plan on updating the docs within the week.

EDIT: The docs are updated and the example is too. Whew!

I was thinking about doing something like this and now I don't have to. Nice work, will definitely check it out!

I don't understand what's so great about Django. Out of the box it is not setup for TDD, REST and XSS protection.

Yes it is.

http://docs.djangoproject.com/en/dev/topics/testing/ http://docs.djangoproject.com/en/dev/topics/templates/#autom...

As for REST, Django speaks HTTP - it's really not hard to build a REST API with it. There's also Piston: http://bitbucket.org/jespern/django-piston/

I stand corrected on testing and XSS, even if it feels like you have to do extra steps for the configuration of all these things though.

Reply on news.ycombinator.com