For those who don’t know, Tower.js is a full-featured client and server-side(Node.js) web framework.
Tower, right now, is at version 0.4.3. This version isn’t ready for production or development use. You can start hacking at it, but it’s not very effective, nor effecient to work in it right now. Why? Because it’s all going to change, and fast!
I’ll go through the main things were working on, and how it’ll effect you.
A few months back, I always wanted to get a plugin/package system going for Tower. Especially with all the news with Meteor and other package systems, we’d be crazy not to. Were refactoring the core framework and initialization systems to utilize packages fully. This means that Tower is going to be a fully modular framework. It’s already split into several “packages”, though, at this point they are only folders.
Were also adding the ability for users to create packages. Packages will become first-class citizens inside the framework. You’ll be able to extend and add to the framework like never before.
Right now, you need to fire up two processes to develop in Tower. One for grunt for file watching and compilation of assets (coffee-script, less) and another for the server. This confused several newcomers, but also brought some un-productive development. Grunt was one of those bottlenecks. Especially it’s file watcher. Working on Tower’s client-side code was a HUGE hassle, often taking 50 seconds to re-build the client-side code when a simple change was made.
Were scraping all of that and bringing in a bundler. This bundler will run inside a single process and will run after the HTTP server has started. This will obviously only run in development mode. The bundler will serve, compile client-side code with a few twists. Firstly, client-side code will NOT be touched when being served. This means we won’t minify, concatenate it. We’ll look at the file inclusion/order of dependencies problem, and possibly employ a dependency system. Secondly, you’ll be able to register new file types with the bundler and proccess new files, such as coffee-script, typescript, less, etc… The new coffee-script package is only 20 lines of code, and it’s lightning fast!
Because we use Ember and handlebars on the client-side (Ember is also used on the server-side) it was extremely ackward integrating it with CoffeeKup. You had to basically encapsulate all the handlebars template inside helpers and quotes. This should be first-class support. That’s why were dropping CoffeeKup and using strictly Handlebars. A much simpler approach.
Profiler & Optimizations
Most of the commands right now take some time to run/load, though, not as slow as rails. We started to benchmark different possible bottlenecks such as file inclusion, package searching, file watching, etc… and started fixing those problems. Lance even made a file caching module that speads up requiring files by 2x. Were aiming at a load time under or around 50ms (Which is perceived as instant so humans).
That’s why we’ll be adding a small benchmarking/profiler inside the framework. This will make it extremely easy to find bottlebecks in your applications.
Though still on the balance, were going to try and find a perfect directory structure for your applications. One that provides enough flexibility and simplicity.
New Router and Controllers
I won’t talk about this too much as the issue covered it really well, it’ll bring a completely new face to Tower.
Inversion of Control
I brought this up a little while ago on Github. Basically, at the moment, Tower’s instances and classes aren’t centralized, rather decentralized. Extending or working with any instance is extremely troublesome, as you’d have to spend a lot of time figuring out where the instances are kept. Inversion of Control changes all of this. I’m going to be implementing a service locator for Tower. It’s already well on it’s way, just some issues to iron out.
The syntax is quite simple, you first create an IoC container:
Then you can use the service locator:
But this syntax might get old, really quick. Instead, let’s use an alias:
1 2 3 4 5
That’s the desired syntax. This uses the new harmony proxies to have a dynamic dispatch abilities. One problem, however, is that we don’t know the different between
Tower.Authentication.World before hand. That means, we don’t know if we need to return a proxy because they want to access sub-namespaces, or if they want the value of the current namespace. Once we iron out these issues, it’ll be good to go.
1 2 3 4 5 6
1 2 3 4 5 6 7 8 9 10 11 12 13
@param API was perfect for coffee-script. However, it’s not for JS. You’ll find more information in the router issue, though, it’s talking about the router, it’ll also show you the new controllers.
There are probably more things I’m forgetting, but that’s the gist of it. We’ll be working hard on bringing these features and getting Tower to 0.5.0, which will be beta equivilent. This also means that were moving away from the tagline “Rails Clone in Node.js” and instead become “Bluring the lines between client and server-side development”.