Falcon's only dependency is Knockout 3.0.0+
Download Knockout 3.1.0
Installing Falcon is as simple as including Falcon and Knockout and then running the Falcon.apply();
method to initialize your app.
1 <!DOCTYPE html>
2 <html>
3 <head>
4 <script src="knockout-3.1.0.js"></script>
5 <script src="falcon.min.js"></script>
6
7 <script>
8 var HelloWorldView = Falcon.View.extend({
9 url: "#hello_world-tmpl"
10 });
11
12 //Apply only needs to be called once to initialize the app
13 Falcon.apply( new HelloWorldView );
14 </script>
15 </head>
16 <body></body>
17 <template id="hello_world-tmpl">
18 Hello World!
19 </template>
20 </html>
By default, Falcon does not assume how you would like to communicate with your backend data source. Instead, you must include or write your own Falcon.Adapter. Falcon.Adapter defines the 'glue' between your front-end application and how it sends data to and receives data from a backend data source. You can go see a List of Adapters to find already implemented adapters.
1 <!DOCTYPE html>
2 <html>
3 <head>
4 <script src="knockout-3.1.0.js"></script>
5 <script src="falcon.min.js"></script>
6
7 <script src="jquery-2.1.0.min.js"></script>
8 <script src="falcon.jquery_adapter.min.js"></script>
9 </head>
10 </html>
Falcon was created to help organize small to large scale single-page javascript applications. Anyone who's work with Javascript and any number of libraries knows how tough it can be to visualize, organize, and execute a well-written, maintanable, and still flexible application. In other words, it's tough to organize javascript applications in a sensible and scalable way. Falcon's goal is to aid this problem by utilizing Knockout's awesome data-binding implementation with some basic constructs to help organize web applications.
Falcon was designed with a few beliefs in mind:
- HTML and Javascript should always be kept separate - In the world of designers and developers, the last thing developers should need to worry about is what colors or icons are being displayed. Inversly, designers shouldn't need to dig through any javascript code to make the changes to said colors or icons. Mixing HTML and Javascript forces developers to design and designers to understand how to develop. And, not to say that we can't or shouldn't mix those rolls, but the design of Falcon believes that we shouldn't HAVE to.
- It should be dead simple to get an app started - With Falcon, our goal is to make it as seriosuly trivial as possible to get a hello world application going and to start building on top of it quickly. With that said, every other, more complex interaction, is also taken in to consideration to be made as easy as possible. Our goal is to not do any 'crazy auto-magic stuff' behind the scenes, but rather to give a toolset and some basic structure to organize our javascript applications in a sensible and scalable way that doesn't too-highly enforce any specifics (except for probably using data bindings).
- Apps should be highly testible without having to deal with the DOM - Since we're worried about keeping HTML and Javascript as separate as possible, we should therefore be able to unit test the majority of our javascript without having to touch any of the DOM. Of course, it's always better to get as much coverage as possible, but when you have a brand new app that is continuously changing with design requests and needs, being able to keep your javascript 100% tested (regardless of design changes) will allow you to push code with higher confidence.
-
Event triggers should be a designers concern -
Imagine an application that saves a user's information when a button is clicked. If we wanted to change this interaction to occur on double click, then, in most current-day javascript architectures, a designer would need to request that the developer make changes in the code and re-deploy the javascript. This isn't ideal for two reasons:
- We've just given the developer another trivial task that shouldn't need to be on their plate
- A designer shouldn't need to wait on a developer for such a small task.
- Animations should also be a designers concern - Again, the thought of an element fading in vs. sliding in should really be that of a designer to test on the fly rather than having to relay more work on to the developer.