Here's my use case: I've got an app server that I can run things on. I don't have much of anything running on it, but I'd like to be able to put up some simple bits of code, for demonstration purposes. In particular, I'd like to be able to put up some code that runs Ruby on the server. I don't have an "app" persay, and I don't really want all the overhead of "deploying" one, either in Ruby or jRuby. That's way more overhead than I need.
While I've never really liked PHP or JSPs, there is something to be said for their simplicity. You write a template, bring up the URL and there is your code. Ruby doesn't really have anything like that, and it would be handy for just hacking together a quick website. That's actually something that should be really trivial to build on top of Sinatra.
Then I got to thinking - could I make it better? One of the main downsides of JSPs (and the thing I hate the most actually) is that you usually end up copying a bunch of code in every JSP you put up. Even if you go ahead and put all of your code into a jar and call out to it, there's still all of the boilerplate of calling that library, which I remember being quite a bit in Java.
What if we put that code into the folder structure somewhere? We could put it into a lib folder, but now you're splitting up the code and the templates, which is annoying. Why don't we put the code into the same location as the templates? Have the framework look for a given .rb file and run the code in that before running the template. You can do all of your setup code there for loading databases, or models, or whatever. We can have the framework run the setup.rb files all the way from the root path, allowing you to set up database access in the root path, and then get more specific as you go down the tree. Overkill for most apps, but it could be useful in a couple of situations. Access control would seem to lend itself well to this scheme.
Then I started thinking about MVC. I love the MVC pattern, and initially it didn't make sense here. You're building your routes from the folder structure you've constructed, and your models aren't centralized, etc. But it could actually work. You could put a controller structure into the framework very easily.
Technically though, MVC doesn't work terribly well for the kinds of rich client apps that I develop these days. MVC works fine when the pages are simply basic HTML, or even for some basic JavaScript But once you start layering AJAX on top, you start putting business logic into the view. There's simply no way around it, which is why you have JavaScript MV* frameworks (i.e. MVC or MVP or whatever else) running around. Once you start putting large amounts of code on the client machine you need to manage it somehow.
I'm certain there are people out there running MVC on the app server and MVC on the client side, and that just seems like too many layers of abstraction to me.
In addition to that, there's often a giant mismatch between the database models and the GUI models. Your database models have a bunch of technical restrictions that don't match the way that the user wants to use the application. Every time the app designer gets a bright idea, I end up having to compose a bunch of models together to form this page that makes total sense to the user, but makes a hash of my carefully constructed data models.
Finally, Rails is not what I would call "agile". Refactoring models is NOT a fun process if you're using ActiveModel (at least not for me). Renaming a controller requires changing a bunch of things, including the routes file which I never remember to do until I get a 404. Rails just does not lend itself to hacking things together, which is sometimes a useful thing to do. I've spent twenty years honing my craft and learning how to build a proper application, and I feel that I've earned the right to throw all those rules away if I damned well feel the need to.
So I'm starting on my Kul application framework (pronounced "Cool"). The goals are for it to be:
- Agile
- Lightweight (somewhere between Sinatra and Rails)
- Easy to use
- Flexible
I like many of the things that Rails does, especially in the area of "convention over configuration" and how logically things work. I want to steal as much of that as possible. Features I'd like:
- Automatic code reloading
- Dead-simple erb template additions
- Basic database (ORM) layer? (Something like Petapoco would be nice)
- Automatic url routing based on folder structure
- Base / common code located near the templates
- Bundler
- Simple deployment
We'll see where this goes.
No comments:
Post a Comment