-
Notifications
You must be signed in to change notification settings - Fork 5
Overview
freedom.js is a runtime for distributed web applications. The Web is shaping up to be a powerful environment for novel applications that are highly interactive and global in nature. While existing server-client frameworks have enabled new ways to communicate, we think the Web can be much more than software-as-a-service. freedom.js is a completely different way to think about web apps. Think of it as a playground for building new forms of network topologies into web apps. People keep saying the Web is the new operating system. Let's figure out what that can mean.
Let's stop thinking in terms of server-side and client-side code. We should just write applications. freedom.js apps are 100% JavaScript and shipped with the page when you visit. You deploy a freedom.js app by shipping static JavaScript files. Host on GitHub pages and distribute with a CDN (there's a bunch of free ones).
A pretty powerful one too. So let's treat it like one. HTML standards and improvements to the JavaScript engine are making browsers a powerful runtime environment. freedom.js apps are written as a collection of freedom.js modules, which collectively form the `backend' of the app. Each module runs in its own thread of execution with an isolated namespace. Modules communicate with each other and with the front-end UI using JavaScript message-passing primitives. For example, we can write a game using using familiar client-side frameworks like AngularJS or Backbone. However, instead of communicating with application logic that lives in the web server using XMLHTTPRequests or WebSockets, write your application in a freedom.js module and talk to it using freedom.emit(...) and freedom.on(...) [semantics] (FreeDOM-Code-Reference). Because each module lives in its own sandbox, you can feel more comfortable dynamically loading code from other developers and compose more complex applications.
Each freedom.js module has access to 3 sets of APIs (Storage, Social, and Transport), with more forthcoming. The Storage API provides access to persistent storage. The Social API provides access to a user's social network. Lastly, the Transport API provides direct peer-to-peer communications abilities between 2 users. Since every user runs their own freedom.js backend modules, write your application in terms of interacting users in true peer-to-peer fashion.
We provide a number of existing API providers that back these APIs, like WebRTC Transport and XMPP Social. Plug and play different providers without any changes to your application code. Want to write your own provider? Go for it! When you write an API provider, any freedom.js app should be able to use it seamlessly.
Here's where sh*t gets crazy. We've written additional runtime environments, aptly named freedom.js runtimes. freedom.js modules can migrate to different runtimes, and you're in control of that. Why migrate? Well for one, browser tabs can get suspended and closed pretty easily. freedom.js runtimes are most often uses to keep your user's backend modules always running. Run your personal runtime in a VM in the cloud, on an always-on desktop at home. We even have plans to port a freedom.js runtime to DD-WRT on your router. You might also want to write an API provider that's only possible in another environment. For example, you might want to write a Storage provider that's backed by a Cassandra cluster. You might want to write a Transport provider that uses raw network sockets. freedom.js helps you keep your modules properly connected during migration so that your app works flawlessly.
The Web is complex enough as it is. We're opening up a can of worms, but by golly, there's some big fish to catch. Here's some things we're building with freedom.js:
Check out our [Applications] (Applications). freedom.js apps are portable to any freedom.js-compatible Runtime. These run on their own, but can also work in both Radiatus and Mist. Writing multi-user apps have never been so easy (or cheap).
We've heard horror story after horror story of websites getting broken into. Developer security. Same model as existing apps, but with more security.
User privacy - gov surveillance, advertising. Scary stuff. Run your own runtime, control your own data. For developers, build complex web services without worrying about where data or code will reside. Instead, FreeDOM takes care of the distributed systems work to reduce your costs, keep your users in control of their data, and make your app as available and convenient as a cloud-based approach.
Oh yea? You think so, wise guy? There's been a bunch of effort to bring JavaScript to server-side application logic. A few projects to name a few: [teajs] (http://code.google.com/p/teajs/), node.js, [Luna] (https://asana.com/luna), [Meteor] (http://www.meteor.com/). While we love the path where these frameworks are going, I say let's just jump off the cliff.
freedom.js is different because it's not tied to the server-client model of applications. Let's stop designing software in terms of servers and clients, and instead design them in terms of backends and frontends. Every user of a freedom.js app has their own portable backend, encapsulated in freedom.js modules. These modules can live anywhere, and interact independently from the web server. They can be operate locally within the browser or be migrated to work over the wide area network. We <3 client-side MVC frameworks like [AngularJS] (http://www.angularjs.org/) and [Backbone] (http://backbonejs.org/) because it allows us to interact with arbitrary backends, including freedom.js modules.
We compile our stuff everyday right here: freedom.js
For more information on how to get started, check out our [tutorial] (0.-Getting-Started).