

Roll your own Ruby Web Framework in Half an Hour - svs
http://svs.io/post/59495114366/roll-your-own-web-framework-in-half-an-hour

======
jrochkind1
It seems gauche to insult Rails for being bloated, while bragging that you can
write your own framework in 43 lines of code -- while using
ActionDispatch::Routing::RouteSet, a fairly complicated, very powerful, part
of _Rails_ which takes way more than 43 lines to express.

(735 lines, not counting any of it's own dependencies inside Rails.
[https://github.com/rails/rails/blob/master/actionpack/lib/ac...](https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/routing/route_set.rb))

Sure, you wrote your own framework in 30 minutes -- by using a part of Rails
which many many developer-hours have gone into, over many calendar years.
([https://github.com/rails/rails/commits/master/actionpack/lib...](https://github.com/rails/rails/commits/master/actionpack/lib/action_dispatch/routing/route_set.rb?page=7)
history stops at rails3 four years ago, when they moved the router from one
project to another... the actual history goes back further)

Rails may arguably be bloated, but as of Rails3 it's also amazingly modular
and decoupled, allowing you to use just the parts of it you want. And OP
thought the Router was awesome enough to want to reuse it. At least give it
the credit it deserves, for that, when you're using Rails to write a framework
you say shows how Rails is awful!

------
swanson
The issue is that by the time you bring in an ORM/database migrations, form
builder, link builders, asset pipeline, admin panel, etc you have basically
hobbled together your own ghetto version of Rails without the vast
resources/support that Rails has. One of the benefits of Rails is that it has
all of those features mostly baked in - at the cost of some bloat.

But my project doesn't need all that, you might say. Well, that's fine, then
use something like Sinatra. But I wouldn't build a non-toy web application
without the above things.

~~~
static_typed
It is somewhat ironic you chose the word ghetto when discussing Rails, as it
reminds of Zed's previous article.

I think it is a good thing for new and maybe even experienced Ruby developers
to build their own, to see a way beyond all the meta magic and five minute
blogs, and that you really don't need that much plumbing to get things moving
and understandable.

At least it didn't say roll Rails in five minutes - it would take much longer
than that to bake in all the security holes and to stick YAML parsers all over
the shop.

~~~
w1ntermute
IIRC, Zed was referring to the community, and not the software.

------
Jgrubb
As a Drupal developer, I find it cute how you Ruby guys consider Rails to be
massive and monolithic. You know nothing of massive and monolithic :)

~~~
rhizome
I've been working with Rails for five years, and a year ago I had an aborted
project with a friend on Drupal on which I spent about 6 weeks. It was pretty
terrible.

~~~
mountaineer
Aborted project on Drupal sums up my latest experience with it too. I have
completed a couple over the years though, but after building a few Rails apps,
never again will I use Drupal.

~~~
rhizome
I complain a lot about documentation in Ruby and Rails, but wow, Drupal eats
those deficiencies for lunch. It was where I concluded that, sometimes, know-
how is held closely as a profit center. It's not even a learning curve thing
where the ladder to expertise is long, but that several rungs are entirely
missing, if not kicked through by previous climbers.

------
SeoxyS
For what it's worth, I was dissatisfied with most Ruby frameworks (aka. Rails
& Sinatra), so when it came time to build up a massive project on a Ruby
backend, I rolled my own minimal (<1kloc) Ruby framework.

[https://github.com/kballenegger/kenji](https://github.com/kballenegger/kenji)

I, too, find Rails to be a bloated mess. Here's what I wanted out of my ideal
framework:

\- The "framework" has one single task: providing a DSL for routing requests,
and dealing with the HTTP nitty-gritty.

\- The default would be build for JSON APIs. The return value of routes gets
serialized to JSON.

\- Everything is explicit. No magic.

\- You can organize you code in simple, maintainable units (files), grouped by
functionality. (This is achieved through a tree routing structure, where
controllers can pass / forward certain routes to other controllers.

\- Code can be namespaced, can be tested easily, can be scripted easily.
Functionality does not depend on naming conventions.

~~~
svs
^^^ This

;-)

------
ianb
If you are curious about a roll-your-own article similar to this, but for
Python: [http://docs.webob.org/en/latest/do-it-
yourself.html](http://docs.webob.org/en/latest/do-it-yourself.html)

