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