Folks, I'm forking RightJS. And before you start screaming like "omg, we all gonna die in here!", calm down, RightJS ain't no going nowhere. The thing I do is future oriented and quite different from RightJS itself. So RightJS will stay where it is, I'm using all the same servers for the fork, so RightJS will be available as long as people use it. And I certainly will apply patches as much as I can.
Just, there will be no RightJS 3.0, RightJS 3.0 will be called lovely.io
So, What's That All Aboot?
Folks, it's not a secret, that monolithic frameworks are dead. Dead as Java. The future is in small, agile and modular libraries and this is where lovely.io starts.
In RightJS we already had kinda modular structure, you could go to the building page and switch off things that you don't need. The problem with this approach is that it is not suitable for the nova-days CDN hosting, all the permutations of a dozen options were blowing the 15k small library into a huge collection of files that weighted several hundreds megabytes and was almost uncacheable. You could host it by uself, but on CDN even if we host it, the chances that another user has the same configurations are slim and it would be pretty much the same as if you host it on your own domain.
Lovely.IO is not really a framework as you might think of a normal javascript framework. It is more like a CDN based package management system. In lovely.io all the RightJS core got split apart on several packages.
* 'core' - basically RigihtJS Class, Events (former Observer), utility functions + some new stuff
* 'dom' - the dom manipulations from RightJS + new jQuery like collections handler
* 'ajax' - new XHR2 based ajax module
* 'cookie' - the cookie module
* 'lang' - JavaScript core extensions
* 'sugar' - syntax sugar for the 'dom' module, things like "something".something() and so on.
Every package is pretty much independent and you can choose what you want. If all you want is 'dom' you just hook it up and it will be just that. If you also like some JavaScript core extensions, then you hook the 'lang' module. Need to do some ajax? Include the ajax module. It's completely up to you what load and what not.
A generic example would look like that
<html>
<head>
<script src="http://cdn.lovely.io/core.js"></script>
<script type="text/javascript">
Lovely(["dom", "ajax", "fx"], function($, ajax) {
ajax.load("/some.url", {
success: function() {
$('#some-element').html(this.text).highlight();
}
});
});
</script>
</head>
</html>
Basically wha happening in there is that you firstly include the lovely.io core package which just 3k of code and provides the modules handling. After that, you can specify the modules you need and once they're loaded (happens asynchronously) your callback function will be called where you can do whatever is it you need to do.
The example above is a bit simplistic. In reality it also automatically handles all internal dependencies, versions and so on. Check out this example, it's a little game, it uses 'dom' and 'cookies', but it also uses another packages like 'timer' and 'hiscore' to function.
This way we are going to have a rubygems like system where anyone can create and share modules, which can relay and reuse each other. All modules including the standard ones will be more or less equal and independent.
Automatic Packages Hosting
Another thing that I'm solving with lovely.io is automatic packages hosting. No more mangling with CDN, demos, documentation and so on. Once you create a package it will be automatically hosted at cdn.lovely.io which sits on Amazon's CloudFront. And it's not just scripts, all your asset images also will be there, automatically and free.
The basic idea is to completely eliminate the process of modules installation. All your package users will have to do is to specify the package name and version in the dependencies, all the reset will be automatically served from the super fast amazon hosting.
Check the mines game I mentioned above. Take a look into the HTML code of the page. It is fairly complex widget, it has some styles and depends on some images, more of that it is a compound widget, the hiscore block is provided by a completely different package. Yet all you have to do to make it working is this
<script type='text/javascript'>
Lovely(["mines-game-1.0.1"], function(Game) {
new Game().insertTo('#game-container');
});
</script>
And it's not all. The micro-modular structure also will provide a big deal of caching optimization. As all the modules are hosted at the same CDN domain, they all will be cached one by one in the user browsers. And because of that the most frequently used packages will be always in cache.
Say a user opens up a page that uses packages A and B, then he goes to a page that uses A, B and C. All he really downloads on the second page is C.
About The Packages
The cool stuff is not over people. Concentrate, because there is more of awesome news!
The other thing is how you actually make the packages. By default there is no JavaScript. Yup, you've heard me. The actual packages code is written in CoffeeScript and SASS (though you can use JavaScript + CSS if you like). Check for example the source code of the mines game from the above. It is all nice and clean now.
How it works? Quite simple. Lovely.IO is not just a hosting. It also has a CLI tool called `lovely` which is much like ruby-on-rails thingy. You can create a project, you can launch a development server and so on.
Then you write your code in whatever you like, and once you're ready do share it with the public, the tool will compile everything in JavaScript, minify using Ugly and push to the lovely.io server. More of that it will automatically use your README and index.html files as landing and demo pages on the server.
You can structure your project as you like, you can have as many files as you like. You can use CoffeeScript or JavaScript, SASS or CSS, or even Stylus. It all doesn't matter for the end result.
Finally you can do the front-side development in a clean and civilized way.
Other Stuff
There is one thing among this awesomeness though. Lovely.IO is an HTML5 oriented thingy, there is no IE < 9 support, not like I couldn't, just it's thankless job to support those old browsers. I don't wanna do that, you don't wanna do that, and the guy next to you don't wanna do that either.
So, in lovely.io there will be no old IE browsers support in the standard packages, plus there is a good chance that I'll be nuking any other packages that will try to provide the old browsers support explicitly.
Basically, this is where I'd like to draw the line between RightJS and LovelyIO. If you need something well tested with old browsers support, use RightJS, it will be around as long as you want it. But, if you're building a modern HTML5/CSS3 application then you might want to consider LovelyIO, this is where all new stuff will go.
Current Status and Future Plans
At the moment Lovely.IO has all the modules from RightJS core + RubyOnRails support module + I've made a bunch of demo projects over here. It appears to be more or less stable (it's based on RightJS after all), but there is no UI yet.
There is also not much of documentation either. I've just opened the registration for early adopters. So if you wanna play with it, please check the main repository, this is where the STL packages live. It's mostly the good old RightJS with a bit of lean towards more standard jQuery behavior for the $ function.
The next step in the project will be automatic documentation hosting for the packages and then I'll start to port UI modules from RightJS, so if you want me to port something specific from RightJS UI, let me know I'll try to make it a priority.
--
Okay, I think that's the whole introduction for now. I'll give you more when I get to the documentation.
