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.

JavaScript or CoffeeScript?

This has been debated within a few Tower’s users for a while. The debate has been mostly about Tower’s source code language and not the app’s language, as were always going to support coffee-script there. A choice has been made, however, to change Tower’s source to pure JavaScript. CoffeeScript has been a a trouble to work with especially with our current workflow. The way Tower used coffeescript made it extremely difficult to support. Some of the big changes is being worked on in JavaScript on one of my branches.

Packages

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.

Bundler

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!

Handlebars Everywhere

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.

Application’s Directories

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

This has been a big topic in Tower for a while. A new router was proposed a few months ago (Issue)

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:

1

var container = new Tower.Container();

Then you can use the service locator:

1
2

container.set('Authentication', new Authentication() );
container.get('Authentication'); // instance of Authentication.

But this syntax might get old, really quick. Instead, let’s use an alias:

1
2
3
4
5

var Tower = container.alias('Tower');
Tower.Authentication = new Authentication();
Tower.Authentication.World = {};
container.set('Tower.Authentication.World.One', 1);
console.log(Tower.Authentication.Word.One);

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

JavaScript API

JavaScript will most likely become the defaulted language within Tower. If you want, you’ll be able to use CoffeeScript and we’ll keep a CoffeeScript friendly API around. The good news is that we’ll have a new JavaScript API.

This works:

1
2
3
4
5
6

class Hello extends World
  @param "Hello"
  @param "get"

  constructor: ->
    # Do something...

This doesn’t:

1
2
3
4
5
6
7
8
9
10
11
12
13

// Pretend were inheriting:
var Hello = (function(_super){
  
  this.param("Hello");
  this.param("get");

  // Constructor:
  function Hello() {

  }

  return Hello;
})(World);

That @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”.

I’ve been using Youtube everyday since it’s become popular. It’s great, it as tons of videos, music and entertaining content, but it has more faults then good.

Design

I have no idea who designs it’s site right now, but they are terrible! Probably the worst professional site that’s gained a significant volume of traffic. They started rolling out with all sorts of different designs that are ugly, broken, and hard to navigate around. What’s wrong with them? I have no idea, they have NO excuse, and it does piss me off a ton.

The channel page is an example of a bad UI design. They allow some customizations, but ultimately they have their dark ugly gradient everywhere. No noise, just a straight gradient background for most elements.

The current home page is awful. It’s not even centered, even though it only takes a 1/3 of the screen’s width (on my 27” - 1080p monitor). Many of the elements have bad padding/margin or it just doesn’t make any sense.

Functionality

Youtube hasn’t made any progress here, they have actually gone backwards because of broken features. For starters, the messaging or inbox center is completely flawed. When you read a message, comment, etc.., and you return back to the home page, you’ll still receive the old un-read message notifications. This isn’t only in the inbox feature but everywhere. I guess Youtube doesn’t understand how to remove old notifications.

Another example is on the upload page. I’ve had my channel for a few years now. I unlocked their 15+ minute upload feature a long time ago, though I still, to this day, receive a alert box saying my account now supports longer video uploads. It doesn’t make sense.

On the channel page, I always receive the same alert about live streaming with hangouts, saying my channel now has that feature. I get it Youtube, you’ve already told me months ago.

When you display a message to a user in form of an alert box of some sort, the user would read the information, click on the “x” button, and never be shown that notification again, as it’s irrelavent.

Subscription Boxes

Haha. I just have to laugh at this one. For over 4 years, the sub boxes have been broken on an on and off basis. Yes, 4 years. Sometimes it happened for weeks where I could only see a list of 8 or so videos in my sub boxes. It would fail to load anymore. Or at other times, some of my subscriptions wouldn’t appear in my list for days or at random times. You’d have to go on their channel separately, but that’s almost impossible as I have hundreds of subscriptions and I don’t know who uploaded and who didn’t, that’s what the sub boxes are for!!!

In all seriousness, Youtube is a fucking joke. I don’t know who works there, but they must be retarted to let this kind of thing happen on a regular basis. Get your shit together and start fixing stuff instead of wasting time implementing a poorer, shittier design.

What are web apps going to look like soon? A question i’ve thought about for a while. This blog post will bring forth, my own personal opinions on the subject, and possibly give some examples.

Real-Time

The web, throughout the years, has brought a level of interactivity, through many mediums. Web platforms are going to leverage the power of real-time communication, to provide a hell of an experience. In the past, we were quite limited in terms of a communication method from a browser (client) and a server. We could only, effectively, communicate within a mono-direction, and the client could only talk to the server, when it wanted to, not the other way around. We have broken this ancient restriction with powerful new features in HTML5, most notibly, web sockets. Web sockets provides a solid, and single API, to create a bi-directional communication model with a browser (client) and a server. The problem with web sockets is compatibility. Not all browsers support the API natively, and older browsers certainly don’t either. All the newest version of IE, Chrome, Safari, Firefox, and Opera support web sockets, but some are in beta stages and not widely distributed. How can you utilize this new feature, when it’s distribution is poor? You could use alternative solutions when a browser doesn’t support a particular feature. Flash is a good alternative to web sockets, though having some slight difficulties in support; Apple’s Iphone, Ipod, and Ipad do not support flash at all; Android is dropping support; Chrome is also dropping support for flash on linux (slowly, but surely). Most desktop environments do support eithe Flash, or web sockets. But what if they support neither? The last fallback, obviously not preferable, is a simple long-polling technique. With long-polling, you are effectively sending a request, or polling the server, at a set interval. Long-polling is not Real-time, but it’s the closest you’ll get without the newer approaches.

This seems like a lot of work to support Real-time, creating multiple fallbacks, and detected feature availability before your web app starts it’s thing. Luckily there are multiple libraries that do this for you. My favorite being Socket.IO, which has a client-side library, as well as a server side library for multiple environments; Node.js being one of them.

A follow-up part 2 will be written soon.

Have you ever heard of Revolution, the TV show? If you haven’t, it’s becoming a pretty bad ass show! A ton of actors from the extremely popular TV Show; Lost, have become apart of Revolution, which makes for an interesting adjustment. The series also seems to replace Terra Nova, a cancelled TV show, that was again about a new beginning, though a few million years of difference, it has some similarities. I was a fan of Terra Nova’s idea, but not the execution. Each episode had a mini problem that was always resolved towards the end. Nothing continued on, and you weren’t hooked like Lost, which left you with 100 questions answered, but left you with another 1000.

Revolution seems to be taking the Lost route, as J.J Abrams is the producer of both Lost, and Revolution. The cast seems rock solid, and they aren’t afraid of killing of characters, which helps keep things interesting (unlike the TV Show 24).

Only five episodes in and I’m pretty satisfied, let’s see what they can deliver in the coming episodes.

Edit

After watching a few episodes over, again, and reading a few independent reviews on the subject, I’m a little mixed on the future of Revolution.

To begin, I’m not a big fan of teenagers being main characters, in an adventure / action TV show or movie. Why? You may ask. We’ll, it becomes quite childish and the “action” can reflect on this. I do hope that the two teenagers, both siblings, mature and provide more than just being teenagers. The boy doesn’t bring much to the story, other than his asthma attack.

Within the 3rd or 4th episode, the militia, are caught of guard by a heavy storm. You could say it looks a lot like there’s lightning, and that creates some confusion, as all electricity doesn’t work. Does this include nature occurences? Or just human made? These are questions that the writers must resolve, as it brings fakeness to the story.

In shows such as Lost, the characters were extremely dirty, wearing bad conditioned clothes, which made it clear, that they were long gone from home, in the middle of nowhere, trying to survive. Revolution, on the other hand, has all their characters in shiny, tight, fiting clothes. It’s clear that the writers haven’t thought this one clearly, maybe this will change in the future.

Hopefully the crew, having a portfolio like they do, step it up a notch and bring what Lost brought!

Software is becoming a set of modules. Modularity is a great way of de-coupling your code into separate pieces, all working in sync. The Javascript world is embracing this pattern and many solutions have been created recently.

Browser Limitations

Javascript on the client-side need to downloaded from a server. This creates a difficult environment when modulizing your code. In production, you can’t be sending hundreds, or even thousands of independent Javascript file over to each client. A solution to this problem would be to concatenate all your file before they are sent across to each client.

To make this an effecient process, we would use a build tool such as Cake, GruntJS, or a combination of both. A simple command cake build, and all your files would be concatenated. We can automate this process by implementing a file watcher, to watch when files have been added, changed, or deleted within a particular directory. You can then run cake watch, and the process will continue running, always re-compiling, and re-concatenating your Javascript files.

This works, and makes modular Javascript code possible on the client, but doesn’t solve handling the modules’ dependencies. A module loader comes to solve this issue by offering a solid api for resolving and setting dependencies.

1
2

var someModuleClass = resolve('moduleX');
var someModuleClassB = resolve('moduleB');

But why not add some consistency and use the require function, similar to node.js.

1
2

var someModuleClass = require('moduleX');
var someModuleClassB = require('moduleB');

But to require a module, you would need to define one. A simple solution would be of the following:

1
2
3

define('moduleX', function(){
   // some code here...
});

If you’ve ever heard of AMD, you’ll be extremely familiar with this syntax (except the require). Loading or resolving a module is quite simply, as the define method takes the string, the name of the module, and the wrapping function and adds it to an array (or object) of modules. Resolving a module simply checks the array or object.

1
2

modules = {};
modules['moduleX'] = function(){}

I’m personally not a big fan of having that define method around each module. Instead, let’s instead use our building phase to our advantage. When we concatenate our files, we would place them automatically inside an object.

1
2

modules = {};
modules['controller.js'] = // Javascript code here....

You would have the key being the path and filename, and it’s value, the Javascript code. Your module file could now look something like this:

1
2
3
4
5

// controller.js
(function(){


})();

Something you can use in any environment without this module loader.

Optimizations

By concatening all your modules into a single file you loose the ability to lazy-load your Javascript on download. Instead, let’s lazy-load the execution and parsing of the Javascript, which takes the longest. You can store your Javascript within a string, which will not run when initially loading the script. You can then run the code at your will by using the Function object.

1
2

func = new Function("console.log(123);");
func(); // console -> 123

This will place the stringified code within an anonymous function, that you’ll have to call to run the code, but parsing will happen once you use the new Function statement.

How could you “export” variables from within a module? That’s pretty easy! At the end of the file, you would use the return statement.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// controller.js
var controller;

// Javascript Class:
controller = (function(){
  // Class Constructor: 
  function controller(){
     console.log(123);
  }

  return controller;
})();
// Export the 'controller' class:
return controller;

You would change your loader to the following:

1

func = new Function(code)(); // now holds the controller class.

To run the constructor of this class you would use the following:

1

controller = new (require('controller.js'))(); // console -> 123

This is very much looking similar to the CommonJS pattern, but with a few twists. Now your parsing and execution of your code is lazy-loaded. If you were to lazy-load the downloading of your Javascript, you would need to go with an asynchronous pattern and would cause more headaches than not. With our technique, you would have a small execution and parsing of Javascript (the module loader, and auto-running modules), but everything else is lazy-loaded and FAST! You get about a 10x speed boost with this method.

I’m definitely sticking with this pattern for the time being, and maybe you’d like too. In the end, it’s a matter of personal preference. If you’d like other insight on this pattern, you can visit my own module loader, that has implemented this pattern, fully working condition.

References:

http://calendar.perfplanet.com/2011/lazy-evaluation-of-commonjs-modules/

http://tomdale.net/2012/01/amd-is-not-the-answer/

This will be the first post of many, that will range in the following categories: news, life, tutorials, technology, other.

This will be my new place to gather my thoughts and share some of my insights into technology and more specifically, the web; though my knowledge is not limited to the web world.

I’m going to be writting many written, as well as many video (Youtube) tutorials. I’m currently participating in the open source node.js framework - Tower or Tower.js (to target the framework within searches and not the generic word.). When the Tower is somewhat feature complete, and fairly stable, I will make PLENTY of tutorials and guides.

For more information on Tower, visit it’s github page: http://github.com/viatropos/tower