Famo.us

Famo.us is a new JS library that is a very cool and inspiring. From my cursory investigation I’ll present my thoughts on Famo.us.

The goal of Famo.us is to create a graphical engine that renders elements to the browser more efficiently than current techniques. At the present time browsers are designed to render documents, rather than graphical elements, this presents a lot of bottle necks. Famo.us converts the typical HTML document type content into graphical elements, and renders them to the browser using canvas and webGL. This evolves the process of creating web apps from an experience of wrestling with HTML/CSS/JS to make something that mimics an app-like appearance. To, something more akin to making real apps.

There is something very different and distinct about using Famo.us. Rather than creating a web page with it’s DOM, and styles, and relying on the browser to position content based on a long list of arcane (and, should I add twisted) rules, is very different from freely placing things on the screen using x, y, and z coordinates. With Famo.us you are creating graphical elements that live in a 3 dimensional space on the screen. These elements can be freely translated and transformed.

The bigger promise of Famo.us is to create templates for apps that anyone can apply to their content. Much in the way that themes are applied to WordPress content. Realizing this goal would create an explosion of HTML5 apps, and make good on real the promise of HTML5, which at the current time has not lived up to it’s hype. All of these templates would be using the Famo.us system to position, and animate elements close to native rendering speed.

Here are a few basic concepts. To display things with Famo.us you need a Context and a renderable. A context is an area where one or more renderables can be drawn. A renderable maps to a display element in your page. A page can contain more than one context, or the context can take up the entire page.

The basic renderable is called a Surface. A Surface can contain HTML content, and is styled with CSS rules. You can set styles via JS when creating a new surface. Surfaces then become the basic view elements containing your content that are rendered to a Context. Imagine buttons, text boxes, and images all as Surfaces moving around a 3d environment in the browser window. Neat!

Famo.us looks pretty cool. I’m going to call it a second generation JS tool kit. Like AngularJS, it moves beyond the previous tools and sets new paradigms and increases the performance of web apps. If you were a Flash developer, and long for the days when you could do all of the things people were doing with Flash in the browser, I feel that this is the tool that will get you excited again. I can definitely see showcase web sites, like FWA, popping up to show Famo.us work.

All of that’s pretty rosy so I’ll end with a word of caution. Browser based apps are still hampered by downloads. Every file asset must be downloaded and cached. Ever been browsing a page when the style sheet did not load? Browser based apps built with Famo.us will still be prone to these issues. On desktops with a fast connection, the issues are minor. On mobile devices with slower connections these issues will be more apparent.

Native or HTML5?

Starting a new project, you’re likely to explore what would be the correct platform as a first step. Javascript has a lot of buzz right now. There seems to be a movement to do everything in the Javascript language. At the moment you can Write your app with JS, script your server with Node.js, query your data base in JS using MongoDB. Wow, sounds like you can do it all in JS! This is neat but, I feel it’s important to not lose sight of the forest through the trees. In any project it’s really about choosing the right tool for the job.

If we’re doing everything in JS does that mean the browser is the new OS? I don’t think so. There’s a bit of the emperors new clothes in this type of thinking. The thing about JS and apps in the browser is they just don’t live up the promise in many cases. Or, maybe I should say that there is to much promise. JS has a lot of hiccups and performance issues. Writing a program across HTML, CSS, and JS has a lack of elegance, and feels crude and verbose at times. Just because you can do something doesn’t mean you should. Again it’s about choosing the right tool. The big draw of JS for everything is that it leverages a common tool set, on a common platform. This can save time and money which is good, but if you are making an inferior product is it worth it?

I don’t want to sound like I have some axe to grind. I’ve had a lot of fun with JS, and if it’s the right tool for the job I’m more than happy to use it. My point is HTML5 has so much hype people are treating it like it can do no wrong, like its the wunderkind that can do anything. I just want to get real here. JS can do anything, and I suppose that’s a really a great thing. But, just like people, JS is good at somethings and not good at other things. I’m a firm believer that anyone can do anything if they put their mind to it, I’m not saying that everyone can break world records.

There’s a lot to like about writing code in one place using a common set of tools and deploying to every platform. But if the app provides weak and compromised user experience do you want to put your name on it? Look at Facebook. They had an HTML5 app, and the user experience and performance was weak. The way I see it, they essentially shoehorned a web site into an “app”. They obviously bought into the promise of HTML5.

“The biggest mistake we’ve made as a company was betting on HTML5 over native”

M Zuckerberg

It’s fun to think you can recreate all of the nifty transitions and animation of a native app with JS in a browser. But, you’re not really doing your job unless you apply a critical eye and are willing to say that something is falling short of expectation. Kudos to Facebook for owning up to a problem that was theirs.

Is the browser the new OS? Computers are getting faster, and JS can do more in the browser than ever before. But I don’t think this makes JS the be all end all. There will always be something you can do native that will be out of reach from the browser. Either for security, performance or other reasons. The world may spend more time in a browser than all other apps combined but, I don’t want to edit images in Safari, and I don’t think this is where the world is going.

AngularJS – intro

AngularJS is a Javascript framework from Google. It’s goal is to display data in a web page based on the MVC, and related paradigms. It was built with the idea of being able to make the connections between, data and UI, apparent and easy to manage.

I just began with it a day ago, so take everything here with a grain of salt. I’m sure I’ll cringe at this a month from now. I’m just writing this all down to try and get it all straight in my own head.

Directives

Directives are attributes, that act as hooks for AngularJS. Assigning a Directive to a tag creates link to that tag and it’s contents to AngularJS.

AngularJS defines many built in Directives. These all begin with ng-. For example, ng-app, and ng-model. These can, optionally, be prepended with data- for validation if you like. For example: data-ng-app, and data-ng-model.

You can also write your own Directives.

Here area few Directives.

The ng-app directive tells Angular which part of the page it should manage. It could be placed in the html tag to manage the entire page, or on the body or div tag to manage a smaller realm.

Where this tag is placed determines the document root for Angular. Placing the ng-app directive on a tag other than the <html> tag will limit the scope of the Angular app to that region of the page.

Include an optional module name as a value to this attribute. For example: ng-app=”moduleName”.

The ng-init Directive initializes data. Usually you’ll want to handle this with a Controller.

The ng-controller directive attaches a controller to DOM element. A controller is a Javascript object that will manage data displayed in that region.

The ng-repeat directive tells Angular to copy the elements within the repeat element a number of times. It will populate this “template” element with data from the model.


	Loop with ng-repeat
		
			{{name}}

Within ng-repeat Angular defines $index, $first, $middle, and $last. $index holds the the index of the repeated element. While $first, $middle and $last are booleans, true when the element is the first, middle or last element.

{{expression}}

The {{}} defines a template expression. The {{ and }} can thought of as defining the area where Angular will write data. The expression inside can be thought of as modifying or defining how the data is written.

The ng-model attribute allows you to define connection from the DOM to model data. In the case of an input field modifying the input modifies the model data directly.

{{item.price | currency}}

The | defines a filter to be applied to the content of a {{}} template. There are several built in templates, and you can define your own. The example above formats item.price as currency.

The ng-click directive sets up a click action that will call on JS we define. The handler function should be part of the $scope of the controller that contains this ng-click.

Note that $index is a variable defined by ng-repeat.

{{greeting}}

The ng-bind attribute can be used to bind a view element to a model value. This works the same as use the {{}} template syntax. Where the {{}} syntax will show the {{}} for a moment when the page initially loads the ng-bind directive will not. Making this good for elements that will show initially.

Use ng-change to call a function defined in the $scope of the elements controller when a form element changes.

Use ng-submit to call a function when a form is submitted.

some text

Images and Anchors are special cases and have their own specific directives.

MVC – Model View Controller

MVC is a software design pattern that breaks functionality into three areas: Model, View, and Controller. This pattern is particularly suited to software that handles and manipulates data via user interface. Which makes it a good fit for Web apps. AngularJS turns HTML, CSS, and Javascript into a surprisingly good fit for this pattern.

Models

Angular uses the MVC, or Model, View, Controller, paradigm. Where the Model represents data used by your program. For example, a list of user names, or a list of products with their price and description. The View is where data is displayed and represents the visual end of your program. The controller is the business side of your program. It contains the logic that manages data and facilitates translating data so it can be displayed by the View.

A Model can be as simple as a variable containing the number of times a button has been clicked. More often model data will be an array or object containing a list of values and properties.

A Controller might contain functions that controls the how a number is displayed. It might round the value off or format it any number of ways. More often the Controller will load an array of data and sort and filter before sending it to the View.

Views in Angular, are HTML. The view is essentially written in HTML and CSS, along with Angular’s templating system. Controllers are tied to views directly in the HTML as attribute names. This is a key feature of Angular that makes it unique.

Controllers

Controllers handle processing model data.

Views

The display data held by the model. Views in AngularJS are templates defined as snippets of HTML. These can be external files loaded into the app, or defined within the same file tags. Templates can all be defined as strings as part of a controller, directive or other module.

Modules

Model data should be defined in a “modules”. Use Angular’s module method to create a new module.

Services

Services are singleton objects that provide global functionality to an app. Built in services begin with the $, such as $routeProvider, and $http.

Bootstrapping

Here’s the outline for an Angular page: