Show HN: Vesper, a plug and play Ruby web framework (Sinatra + Rack + Plugins)(vesperapps.com)
vesperapps.com
Show HN: Vesper, a plug and play Ruby web framework (Sinatra + Rack + Plugins)
http://vesperapps.com/
4 comments
Looks interesting, but isn't Padrino already trying to be the "Sintra with more"? http://www.padrinorb.com/
What's wrong with Padrino? Why did you make this? Why is this better?
What's wrong with Padrino? Why did you make this? Why is this better?
I don't think there's anything wrong with Padrino.
I just wanted to use something a little more lightweight and unstructured. Without the plugins, Vesper is basically just a Sinatra app. You can organize it as MVC, or not. There's not much abstraction from adding code to a Sinatra app, and everything glues together nicely. Also, I really like developing plugins this way (put the code from an app into a git repo, and you're done).
I just wanted to use something a little more lightweight and unstructured. Without the plugins, Vesper is basically just a Sinatra app. You can organize it as MVC, or not. There's not much abstraction from adding code to a Sinatra app, and everything glues together nicely. Also, I really like developing plugins this way (put the code from an app into a git repo, and you're done).
(Wrong parent - this was intended to land in the other thread.)
I didn't understand it that way :).
Well, the thing is that I see your approach as equally "structured" as Padrino. If I want to use Vesper Plugins, I have to use Vesper. So your approach - in my eyes - is not "more unstructured", its more "a different kind of structure". As far as I can see it, you don't put a lot of weight into controller/routing-things, but have more emphasis on plugins, which Padrino mostly lacks.
But the fact that you didn't use Padrino and implemented your own structure on top of Sinatra shows that Padrino didn't fit your bill - so my curiosity just springs from the that fact. I always see this as a chance to find new needs and insprirations that Padrino can support and use. So, rant away :).
Aside from the asset-handling problem, bundler can easily support loading plugins from git(hub), as long as they are gems. Why didn't you just settle for that? Then, the only problem that remains is asset handling. There, I am quite in favor of not polluting the main project, but I also don't want to add a asset compilation toolchain just for that :/.
I didn't understand it that way :).
Well, the thing is that I see your approach as equally "structured" as Padrino. If I want to use Vesper Plugins, I have to use Vesper. So your approach - in my eyes - is not "more unstructured", its more "a different kind of structure". As far as I can see it, you don't put a lot of weight into controller/routing-things, but have more emphasis on plugins, which Padrino mostly lacks.
But the fact that you didn't use Padrino and implemented your own structure on top of Sinatra shows that Padrino didn't fit your bill - so my curiosity just springs from the that fact. I always see this as a chance to find new needs and insprirations that Padrino can support and use. So, rant away :).
Aside from the asset-handling problem, bundler can easily support loading plugins from git(hub), as long as they are gems. Why didn't you just settle for that? Then, the only problem that remains is asset handling. There, I am quite in favor of not polluting the main project, but I also don't want to add a asset compilation toolchain just for that :/.
Ah, I think more explanation is in order.
Aside from the plugins, the structure of Vesper is just Sinatra, Rack and Rake (/public, /views, config.ru, Gemfile, Rakefile, etc.) plus application and config directories. When the app is run, it does all the normal rackup stuff, and loads everything in /config and /application. There wasn't a need to do anything more.
That's where this whole thing started. I got tired of the routes file in Rails (my biggest Rails complaint), so I switched to Sinatra, and this is how I ended up writing a lot of apps.
Sidenote: /data and /tests are both generated by default plugins.
By unstructured, I just meant the MVC thing. Most frameworks I've used start off with the assumption that I want to use MVC directories. Sometimes I do, sometimes I don't. Most of the time I want to use the concept of models and controllers, but instead of separating them into different directories and files, I want to group related models and controllers together - i.e. a users.rb file with the User class and the associated routes for sign in, profile editing, etc.
The plugins were extracted from code I use in a lot of apps, but not all. That's why a plugin is so similar to a full project, with a few extras thrown in, like hooks (they just run code are certain times during loading). I'm mixed as to polluting the main project with assets, so I just did both. A plugin's /application, gemfile and /tasks don't get moved into the main project. But sometimes it makes sense, such as DataMapper and a /data folder, and MiniTest and a /tests folder. It's really optional.
Now for gems: There's nothing stopping anyone from adding gems to a project. They should work just fine, and I do it all the time. But at the same time, I work with a lot of designers and just-getting-started programmers who have no idea how to write a gem, but still have code they reuse a lot. The 'plugins-as-a-repo-in-a-live-folder' allow for that, while not stopping them from using gems if they fit the bill. A few of the plugins are nothing more than wrappers for gems with a little config pre-written.
Aside from the plugins, the structure of Vesper is just Sinatra, Rack and Rake (/public, /views, config.ru, Gemfile, Rakefile, etc.) plus application and config directories. When the app is run, it does all the normal rackup stuff, and loads everything in /config and /application. There wasn't a need to do anything more.
That's where this whole thing started. I got tired of the routes file in Rails (my biggest Rails complaint), so I switched to Sinatra, and this is how I ended up writing a lot of apps.
Sidenote: /data and /tests are both generated by default plugins.
By unstructured, I just meant the MVC thing. Most frameworks I've used start off with the assumption that I want to use MVC directories. Sometimes I do, sometimes I don't. Most of the time I want to use the concept of models and controllers, but instead of separating them into different directories and files, I want to group related models and controllers together - i.e. a users.rb file with the User class and the associated routes for sign in, profile editing, etc.
The plugins were extracted from code I use in a lot of apps, but not all. That's why a plugin is so similar to a full project, with a few extras thrown in, like hooks (they just run code are certain times during loading). I'm mixed as to polluting the main project with assets, so I just did both. A plugin's /application, gemfile and /tasks don't get moved into the main project. But sometimes it makes sense, such as DataMapper and a /data folder, and MiniTest and a /tests folder. It's really optional.
Now for gems: There's nothing stopping anyone from adding gems to a project. They should work just fine, and I do it all the time. But at the same time, I work with a lot of designers and just-getting-started programmers who have no idea how to write a gem, but still have code they reuse a lot. The 'plugins-as-a-repo-in-a-live-folder' allow for that, while not stopping them from using gems if they fit the bill. A few of the plugins are nothing more than wrappers for gems with a little config pre-written.
Incidentally: for those wondering about the name and logo:
“Three measures of Gordon’s, one of vodka, half a measure of Kina Lillet. Shake it very well until it’s ice-cold, then add a large thin slice of lemon peel.”
http://en.wikipedia.org/wiki/Vesper_(cocktail)
“Three measures of Gordon’s, one of vodka, half a measure of Kina Lillet. Shake it very well until it’s ice-cold, then add a large thin slice of lemon peel.”
http://en.wikipedia.org/wiki/Vesper_(cocktail)
Haha. That and I was watching Casino Royale at the time.
Glad someone caught it though.
Glad someone caught it though.
Vesper is Latin for "evening". Hence, the Catholic evening prayer service, vespers:
http://en.wikipedia.org/wiki/Vespers
I definitely like it. As a Padrino developer, might I ask how your project compares to padrino, which seems to have similar goals? (Multiple Applications per project, superset of sinatra, flexible usage of rack, etc.)
We do use the Sinatra plugin system only, though...
We do use the Sinatra plugin system only, though...
I just wanted to use something a little more lightweight and unstructured. Without the plugins, Vesper is basically just a Sinatra app. You can organize it as MVC, or not. There's not much abstraction from adding code to a Sinatra app, and everything glues together nicely. Also, I really like developing plugins this way (put the code from an app into a git repo, and you're done).
So your main complaint about Padrino is Padrino::Application as an extension to Sinatra? Because in every other regard, Padrino (padrino-core) is mostly a convention on how to load and organize code. I use it as a raw library on a regular basis.
I admit that we are a bit behind in regards of apps-as-libraries, but I would prefer to handle that in standardized ways (using gems as distribution format and copying assets using an asset compiler instead of an installation routine).
Also, Padrino encourages not developing any plugins for it - raw Sinatra plugins are very much preferred, but are not compatible to your format.
I admit that we are a bit behind in regards of apps-as-libraries, but I would prefer to handle that in standardized ways (using gems as distribution format and copying assets using an asset compiler instead of an installation routine).
Also, Padrino encourages not developing any plugins for it - raw Sinatra plugins are very much preferred, but are not compatible to your format.
I don't have a complaint against Padrino. I'm not out to replace it or anything, I've just been having a good time writing apps this way.
If Padrino encourages not developing plugins, then yes, that would be a big difference.
By Sinatra plugins, I'm guessing you're talking about extensions (http://www.sinatrarb.com/extensions-wild.html)? If so, how are they not compatible with Vesper?
If Padrino encourages not developing plugins, then yes, that would be a big difference.
By Sinatra plugins, I'm guessing you're talking about extensions (http://www.sinatrarb.com/extensions-wild.html)? If so, how are they not compatible with Vesper?
What benefit do Vesper plugins have over plain gems?
They're easier for non-programmers (I work with a lot of designers) to create and use. In fact, most of the plugins use gems and then add their own config and assets.
If these non-programmers are using Git and adding Gemfiles and such, is adding a dozen line gemspec to the repository that big a deal? And if it is, couldn't you fill out most of the gemspec automatically using a command line script?
None of that would be particularly difficult. And nothing here is stopping that from happening, or replacing it. It's just another, fairly simple way, to organize and share code.
There are still a few plugins I'm writing now (DataMapper REST services, Stripe boilerplate, user accounts, URL based commenting, Linode stack script, etc.), but since the whole project is moving along nicely, even getting a decent amount of downloads, I thought I'd share.
It's my first gem and my first public project.