«

Vintage is a very small web framework based on the original idea of
Merb: Mongrel serving up ERb (Embedded Ruby) templates. The idea has
been expanded and now Vintage helps you serve up ERb, HAML, Textile,
Markdown, and Markaby templates. So, basically templates with no MVC
or heavy infrastructure.

To use Vintage, you have two options. You can use it in standard mode
or application mode. In standard mode, there is no configuration and
Vintage will serve up templates and static files from the current
folder. To get this mode, then simply type <tt>vintage start</tt> in
any folder.

$ vintage start
- vintage version 0.0.1
starting server on port 5000

Now navigating to a URL will look in the current folder for the file
or template. For example, going to
<tt>http://localhost:5000/my_template</tt> will look for
<tt>my_template.erb</tt> (or whatever template engine you are using)
in the current folder and render it if available. If a static file is
requested, then
it is served up. If you request
<tt>http://localhost:5000/my_folder/my_template</tt>, then the
application will look in <tt>my_folder</tt> for the
<tt>my_template</tt> template.

Vintage can also be configured to be used as an application server.
To do so, you can either generate an application or hand create a
<tt>configuration.yml</tt> file (see one from a generated project for
an example). To generate an application, simple run +vintage+ with a
project name as the argument.

vintage my_project

This command will generate a number of files. Chief among these is
<tt>configuration.yml</tt> which tells Vintage how you'd like to run
it. Other files include a sample template and the proper folder
structure for the generated configuration to work properly. This
setup allows you to more easily segment your code for easier
maintenance.

You can also create your own helper methods if you drop a module of
methods (in the Vintage::Helpers module) in the helpers/ folder.
There are a few default helpers included, too.

To give you an idea of how much lighter this is than Rails or Merb,
here are the requests per second according to ab on my box:

Merb: 56 rp/s
Rails: 41 rp/s
Vintage: 534 rp/s

Please enjoy; I'm in the #vintage IRC channel on Freenode or you can
use Trac to submit tickets.

Get it (and submit tickets!) at:

http://vintage.devjavu.com

I'm going to create a website and documentation this week.

Cheers,
Jeremy McAnally

--
http://www.jeremymcanally.com/

My books:
Ruby in Practice
http://www.manning.com/mcanally/

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

Jeremy McAnally wrote:
>
> To give you an idea of how much lighter this is than Rails or Merb,
> here are the requests per second according to ab on my box:
>
> Merb: 56 rp/s
> Rails: 41 rp/s
> Vintage: 534 rp/s

How does it compare to Nitro or Ramaze (neither or which requires you to
follow MVC)?



--
James Britt

www.ruby-doc.org - Ruby Help & Documentation
www.risingtidesoftware.com - Wicked Cool Coding
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.jamesbritt.com - Playing with Better Toys

It's much simpler than Nitro. It doesn't offer MVC at all, doesn't
have an ORM built in, doesn't have as large a library of helpers, and
so on. It's much faster though (I couldn't get good numbers from ab
for Nitro for some reason but from what I could get it's about 10x
faster).

It's also much simpler than Ramaze. It doesn't offer MVC, is about 5x
faster, doesn't offer as many templating options (yet), doesn't offer
caching, etc.

The concentration here is similar to what PHP _should_ be used for:
template centric development. I'll eventually add things like
layouts, caching, cookies, sessions, etc, but I'm not going to go to a
"full fledged" MVC-optional, super framework like these guys. Simple
and speedy is good!

Basically, I've always liked the original idea of Merb so I thought I
would resurrect it.

--Jeremy

On Jan 5, 2008 12:20 PM, James Britt <> wrote:
> Jeremy McAnally wrote:
> >
> > To give you an idea of how much lighter this is than Rails or Merb,
> > here are the requests per second according to ab on my box:
> >
> > Merb: 56 rp/s
> > Rails: 41 rp/s
> > Vintage: 534 rp/s
>
> How does it compare to Nitro or Ramaze (neither or which requires you to
> follow MVC)?
>
>
>
> --
> James Britt
>
> www.ruby-doc.org - Ruby Help & Documentation
> www.risingtidesoftware.com - Wicked Cool Coding
> www.rubystuff.com - The Ruby Store for Ruby Stuff
> www.jamesbritt.com - Playing with Better Toys
>
>



--
http://www.jeremymcanally.com/

My books:
Ruby in Practice
http://www.manning.com/mcanally/

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

Jeremy McAnally wrote:

>
> The concentration here is similar to what PHP _should_ be used for:
> template centric development. I'll eventually add things like
> layouts, caching, cookies, sessions, etc, but I'm not going to go to a
> "full fledged" MVC-optional, super framework like these guys. Simple
> and speedy is good!


Interesting; what attracted me to Nitro and Ramaze is that you can, if
you like, write apps in a PHP-like style (all one file, or a main logic
file and some templates), and that MVC was completely optional.

(I think Nitro was the only Web framework that allowed for a Hello,
World one-liner example you could type and execute right from the
command line.)



--
James Britt

http://www.rubyaz.org - Hacking in the Desert
http://www.jamesbritt.com - Playing with Better Toys

Yeah I considered making MVC available but I think I'm going to stick
to the form it's in now. There are a lot of MVC frameworks that do
their thing much better than I could.

--Jeremy

On Jan 5, 2008 2:22 PM, James Britt <> wrote:
> Jeremy McAnally wrote:
>
> >
> > The concentration here is similar to what PHP _should_ be used for:
> > template centric development. I'll eventually add things like
> > layouts, caching, cookies, sessions, etc, but I'm not going to go to a
> > "full fledged" MVC-optional, super framework like these guys. Simple
> > and speedy is good!
>
>
> Interesting; what attracted me to Nitro and Ramaze is that you can, if
> you like, write apps in a PHP-like style (all one file, or a main logic
> file and some templates), and that MVC was completely optional.
>
> (I think Nitro was the only Web framework that allowed for a Hello,
> World one-liner example you could type and execute right from the
> command line.)
>
>
>
> --
> James Britt
>
> http://www.rubyaz.org - Hacking in the Desert
> http://www.jamesbritt.com - Playing with Better Toys
>
>



--
http://www.jeremymcanally.com/

My books:
Ruby in Practice
http://www.manning.com/mcanally/

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

Just a quick update:

I ported the Mongrel handler to Rack tonight and only sacrificed about
10 rp/s. It stands up quite well under heavy load apparently (~425
rp/s on `ab -c 100 -n 10000`), but I still want to see how much
performance I can squeeze out before I implement more features.

I'm anxious to see some numbers with Thin or Evented Mongrel with this
new adapter.

I'll be releasing a new gem in a few days when I can get all the HTTP
stuff implemented (cookies and sessions).

--Jeremy

On Jan 5, 2008 11:20 AM, Jeremy McAnally <> wrote:
> Vintage is a very small web framework based on the original idea of
> Merb: Mongrel serving up ERb (Embedded Ruby) templates. The idea has
> been expanded and now Vintage helps you serve up ERb, HAML, Textile,
> Markdown, and Markaby templates. So, basically templates with no MVC
> or heavy infrastructure.
>
> To use Vintage, you have two options. You can use it in standard mode
> or application mode. In standard mode, there is no configuration and
> Vintage will serve up templates and static files from the current
> folder. To get this mode, then simply type <tt>vintage start</tt> in
> any folder.
>
> $ vintage start
> - vintage version 0.0.1
> starting server on port 5000
>
> Now navigating to a URL will look in the current folder for the file
> or template. For example, going to
> <tt>http://localhost:5000/my_template</tt> will look for
> <tt>my_template.erb</tt> (or whatever template engine you are using)
> in the current folder and render it if available. If a static file is
> requested, then
> it is served up. If you request
> <tt>http://localhost:5000/my_folder/my_template</tt>, then the
> application will look in <tt>my_folder</tt> for the
> <tt>my_template</tt> template.
>
> Vintage can also be configured to be used as an application server.
> To do so, you can either generate an application or hand create a
> <tt>configuration.yml</tt> file (see one from a generated project for
> an example). To generate an application, simple run +vintage+ with a
> project name as the argument.
>
> vintage my_project
>
> This command will generate a number of files. Chief among these is
> <tt>configuration.yml</tt> which tells Vintage how you'd like to run
> it. Other files include a sample template and the proper folder
> structure for the generated configuration to work properly. This
> setup allows you to more easily segment your code for easier
> maintenance.
>
> You can also create your own helper methods if you drop a module of
> methods (in the Vintage::Helpers module) in the helpers/ folder.
> There are a few default helpers included, too.
>
> To give you an idea of how much lighter this is than Rails or Merb,
> here are the requests per second according to ab on my box:
>
> Merb: 56 rp/s
> Rails: 41 rp/s
> Vintage: 534 rp/s
>
> Please enjoy; I'm in the #vintage IRC channel on Freenode or you can
> use Trac to submit tickets.
>
> Get it (and submit tickets!) at:
>
> http://vintage.devjavu.com
>
> I'm going to create a website and documentation this week.
>
> Cheers,
> Jeremy McAnally
>
> --
> http://www.jeremymcanally.com/
>
> My books:
> Ruby in Practice
> http://www.manning.com/mcanally/
>
> My free Ruby e-book
> http://www.humblelittlerubybook.com/
>
> My blogs:
> http://www.mrneighborly.com/
> http://www.rubyinpractice.com/
>



--
http://www.jeremymcanally.com/

My books:
Ruby in Practice
http://www.manning.com/mcanally/

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

On Jan 5, 2008, at 9:20 AM, Jeremy McAnally wrote:

> Merb: 56 rp/s
> Rails: 41 rp/s
> Vintage: 534 rp/s

this doesn't smell right. on even a modest box i would expect merb
and rails, with sessions turned off and no db query, to server
somewhere in the hundreds of rps. on my box both rails and merb
would do at least 4-500 rps. conversely, a simple fastcgi process
running under mod_fcgid expanding a simple template might churn out
something like 2000 rps.

are you positive you were running in production mode for rails/merb
with both not using sessions and on top of mongrel? if so it's very
impressive, but those number just look like development mode with
sessions and no cookie argument to 'ab' to me...

on another note vintage looks like a really cool idea - people,
myself included, are yearning for something really simple.

cheers.

a @ http://codeforpeople.com/
--
it is not enough to be compassionate. you must act.
h.h. the 14th dalai lama

No I didn't run those in production, but that's mostly because Vintage
reloads templates every time (i.e., no caching and such like
production modes on both of those). I didn't think about sessions, so
I should turn those off. These numbers were for the same
functionality among all the frameworks.

I'm working on some better numbers using production modes, evented
Mongrels, Thin, and so on. I'll post them here (hopefully) tonight
when I can get the data collected.

--Jeremy

On Jan 6, 2008 11:18 AM, ara.t.howard <> wrote:
>
> On Jan 5, 2008, at 9:20 AM, Jeremy McAnally wrote:
>
> > Merb: 56 rp/s
> > Rails: 41 rp/s
> > Vintage: 534 rp/s
>
> this doesn't smell right. on even a modest box i would expect merb
> and rails, with sessions turned off and no db query, to server
> somewhere in the hundreds of rps. on my box both rails and merb
> would do at least 4-500 rps. conversely, a simple fastcgi process
> running under mod_fcgid expanding a simple template might churn out
> something like 2000 rps.
>
> are you positive you were running in production mode for rails/merb
> with both not using sessions and on top of mongrel? if so it's very
> impressive, but those number just look like development mode with
> sessions and no cookie argument to 'ab' to me...
>
> on another note vintage looks like a really cool idea - people,
> myself included, are yearning for something really simple.
>
> cheers.
>
> a @ http://codeforpeople.com/
> --
> it is not enough to be compassionate. you must act.
> h.h. the 14th dalai lama
>
>
>
>
>



--
http://www.jeremymcanally.com/

My books:
Ruby in Practice
http://www.manning.com/mcanally/

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

On Jan 6, 2008, at 9:24 AM, Jeremy McAnally wrote:

> No I didn't run those in production, but that's mostly because Vintage
> reloads templates every time (i.e., no caching and such like
> production modes on both of those). I didn't think about sessions, so
> I should turn those off. These numbers were for the same
> functionality among all the frameworks.

i can see you line of thinking, still, rails and merb both are
loading a TON of more crap and doing a TON more tests if mode!
=production, so it's probably worthwhile to either test those in
production or implement caching - which is pretty easy (un-tested):

class Template
Cache = Hash.new
Development = ENV['development']

if Development
def self.read path
IO.read(path)
end
else
def self.read path
Cache[path] ||= IO.read(path)
end
end
end

not that this would work for anything but testing - but that it does...

>
> I'm working on some better numbers using production modes, evented
> Mongrels, Thin, and so on. I'll post them here (hopefully) tonight
> when I can get the data collected.


cool. the reason i asked the question is that after doing some
careful benchmarks myself i've come to the conclusion that the only
way to get more than a modest speedup out of a ruby web framework,
when compared to rails, is to rework things like cgi parsing in C
(which is done and released as a library) rather than tweak the ruby
bits and framework code. it's true that one could expect a speedup
of 2x or something but, for me, i'd need to see a speedup of around
and order of magnitude or something to make a switch worthwhile and
my hunch is that - once the code for a 'real' app like sessions, db
connection, etc are thrown in - all ruby frameworks will be very
closely matched to rails, which has seen heavy optimization in many
of it's billions of lines of code. note that i'm really hoping to be
proven wrong - but that's my gut feeling at the moment. i'll follow
vintage with great interest.

kind regards.

a @ http://codeforpeople.com/
--
share your knowledge. it's a way to achieve immortality.
h.h. the 14th dalai lama

Right. The point was to show how much _lighter_ it was rather then
how much faster. It's faster because it does less but does 99% of
what's needed for a lot of use cases.

Honestly, I wasn't thinking about their modes and all that when I did
my initial speed tests, so hopefully these new numbers will look more
normal.

--Jeremy

On Jan 6, 2008 12:13 PM, ara.t.howard <> wrote:
>
> On Jan 6, 2008, at 9:24 AM, Jeremy McAnally wrote:
>
> > No I didn't run those in production, but that's mostly because Vintage
> > reloads templates every time (i.e., no caching and such like
> > production modes on both of those). I didn't think about sessions, so
> > I should turn those off. These numbers were for the same
> > functionality among all the frameworks.
>
> i can see you line of thinking, still, rails and merb both are
> loading a TON of more crap and doing a TON more tests if mode!
> =production, so it's probably worthwhile to either test those in
> production or implement caching - which is pretty easy (un-tested):
>
> class Template
> Cache = Hash.new
> Development = ENV['development']
>
> if Development
> def self.read path
> IO.read(path)
> end
> else
> def self.read path
> Cache[path] ||= IO.read(path)
> end
> end
> end
>
> not that this would work for anything but testing - but that it does...
>
> >
> > I'm working on some better numbers using production modes, evented
> > Mongrels, Thin, and so on. I'll post them here (hopefully) tonight
> > when I can get the data collected.
>
>
> cool. the reason i asked the question is that after doing some
> careful benchmarks myself i've come to the conclusion that the only
> way to get more than a modest speedup out of a ruby web framework,
> when compared to rails, is to rework things like cgi parsing in C
> (which is done and released as a library) rather than tweak the ruby
> bits and framework code. it's true that one could expect a speedup
> of 2x or something but, for me, i'd need to see a speedup of around
> and order of magnitude or something to make a switch worthwhile and
> my hunch is that - once the code for a 'real' app like sessions, db
> connection, etc are thrown in - all ruby frameworks will be very
> closely matched to rails, which has seen heavy optimization in many
> of it's billions of lines of code. note that i'm really hoping to be
> proven wrong - but that's my gut feeling at the moment. i'll follow
> vintage with great interest.
>
> kind regards.
>
> a @ http://codeforpeople.com/
> --
> share your knowledge. it's a way to achieve immortality.
>
> h.h. the 14th dalai lama
>
>
>
>



--
http://www.jeremymcanally.com/

My books:
Ruby in Practice
http://www.manning.com/mcanally/

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/