Why indeed? Why create yet another framework using yet another language? What do you hope to accomplish?
Let me tell you a story.
The first computers weren't really programmable as such. You would plug in patch cables to physically rewire the system. This was quickly replaced with binary code, where instructions and data were entered alternately in chunks. Usually it was instruction, then data, or instruction then data then data. The code and the data were the same: it was just the order they came in that mattered. Remember this for later.
Binary code was converted to hexadecimal for simplicity and easier recognition. Then someone had the bright idea to have the computer translate three or four digit mnemonics for the instructions, so instead of issuing instruction 8B you could say MOV instead. Now, the instructions stopped looking like the data. The computer still saw them the same, but the programmer no longer did.
High level languages continued this trend, abstracting huge chunks of assembly language code in order to simplify life for the programmer. Lots of high-level languages were developed in the 1950s, and they left a long shadow in the computer world:
The one thing that LISP does that no other languages do is that data is written exactly the same way as code. This is the sort of brilliant idea that takes a while to really sink in. The fundamental structure of LISP is lists. Your data is in lists. Your code is in lists. Everything is a function, and defining new functions is trivial, so you start extending the language without even realizing it. A function is just a list with the first element in the list being special and the rest being data. Older LISPs had functions to extract the first element and the rest of the elements, called CAR and CDR because it was based on IBM assembly language instructions. In newLISP, these functions are more sensibly called (first) and (rest).
Like many people, I encountered LISP in university and never quite 'grokked' why it was so special. Many years later I came across Paul Graham's essay called Beating the Averages and got very excited about the idea of outperforming much larger programming teams by using a 'secret' language that everyone else ignored. It's a classic David-versus-Goliath scenario, and very appealing. But would it actually work in real life? I decided to try it. To my surprise, it worked exactly as advertised.
But surely the world has moved on, hasn't it? The stuff Paul Graham's two-person team was doing was back in the late 1990s. We have much better tools now, right?
Wrong. We have bigger tools, with more features, that take longer to learn. Every few years there is a new 'sexy' language or framework that promises to simplify things, and many them are quite good, like Ruby on Rails. But none of them can ever have code that is the same as data. They can't. If they did, they would be LISP.
There are a lot of LISP dialects out there. The standard one is Common Lisp, which has grown and congealed over the years to become something much more complicated than it needs to be. There are new languages like Clojure, but as neat as it is it comes with the complexity of Java bolted underneath it.
There are other dialects like PicoLisp and newLISP that aimed at being simple, small, and fast. I chose newLISP because someone had written a really cool web development framework called Dragonfly that made it ridiculously easy to make new web applications.
As great as Dragonfly is, something kept pulling me towards writing a replacement. It's a testament to LISP's power that doing so was even possible. Working with LISP makes you think you can do all sorts of crazy things. I wanted a framework that simplified database work and jQuery access, something that Dragonfly didn't do, and wasn't likely to do as development seems to have stopped. I just decided to start doing it, just for fun, just because I wanted to.
And here we are.
Rockets is designed to take care of a lot of things for you, so you can think about what your awesome new application will actually do.