[Web] Rank, Sinatra and Waves

[Carl Mäsak]

(I'll be using the November list as a general forum for Web
discussion. Prefixing such threads with "[Web]", so that people who
don't care can filter easily. No guarantees whatsoever that
November-specific trails might suddenly derail to be about Web things,
though.)

Recently, when thinking about Web things in general, I've noticed Rack
from the Ruby world.

<http://rack.rubyforge.org/>
<http://rubymanor.org/videos/rack/>

I believe we could adopt this convention more or less as-is. It seems
like a good idea to do from the start. Exactly how an "identical" port
might look remains to be seen.

Among the technologies built on top of Rack, the one that impressed me
most so far is Sinatra.

<http://www.sinatrarb.com/>
<http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/325255>

I really, really like the idea that starting webapp development is as
easy as writing five lines of code. So I ported those five lines to
Perl 6. :)

<http://gist.github.com/68506>

(Still need to port Sinatra, though.)

Just this morning, I was told about another Web framework in Ruby, called Waves.

<http://rubywaves.com/>

Haven't looked at it in depth, but it contains many of the buzzwords
we think we'd like to support in Web.

// Carl

[ab5tract]

Hey all,

Been lurking for a while, here. Just wanted to pipe up because I was
the one that pointed out Waves to Masak. Since it is a relatively
unknown framework, I wanted to take some time and explain why I
believe not only its architecture but its philosophy would be a
natural fit for Web.pm. I will include a link to further info if I
can. Note that we are a small community ATM and so documentation is
unfortunately relatively sparse.

First is that Waves literally represents the cutting edge of web app
development in a dynamic language. While other frameworks focus on the
clunky MVC paradigm, Waves facilitates Resource Oriented Architecture.
(We do provide MVC via a 'Classic' foundation, and even then we do it
"better" than other frameworks, with things like automatic default
models for database tables, true code reloading, and more). ROA is
notable because it is a design philosophy rather than an architecture
choice as MVC is. Also, HTTP is itself defined as resource oriented.
There are many issues with grafting REST onto MVC, so we cut out the
middle man and interface with resources directly using REST. (Unless
you'd like to do otherwise, which is why we keep Classic around.
Sometimes MVC really is the right way to go.). ( http://rubywaves.com/resource-oriented
, http://rubywaves.com/why-resource-oriented-matters )

Second is the modularity. Based around the idea of "layers", and using
the builtin strengths of Ruby's module system (which allows dynamism
by providing modules the ability to run a block upon its "inclusion")
we provide the maximum level of configurability. For instance we use
layers to weave different ORMs into the framework (as simple as
defining some helper methods or as complex as setting up controllers,
or literally whatever you can think of). Thus at the base layer we are
ORM agnostic. Same with renderers. In fact our entire MVC system is
provided by including just one layer, called a Foundation
(Waves::Foundations::Classic). This I think may go a ways to
alleviating many of the concerns about overly "conventioned"
frameworks that were raised in response to the grant proposal. By
keeping a clean system that loves interchangeable parts, any
convention imaginable can be implemented in a layer and still the core
framework remains unbiased. ( http://rubywaves.com/foundations-and-layers
)

Third, the icing on the cake, is that the Waves' philosophy is to do
as much as possible in pure Ruby. That is, we avoid the language-
within-a-language scenario that Rails suffers from (people can
literally "learn" Rails without learning basic Ruby syntax). We have
only one Domain Specific Language (DSL) and it is very small, just
some helper methods to make routing easier. However, at the center of
routing is a library called Functor, which basically implements MMD in
Ruby. This little bit of magic is very powerful, but it highlights how
in a way Waves is already using a "Perl 6 philosophy." Certainly the
goal of keeping as true to a language as possible in terms of avoiding
DSLs is the reason why coding in Waves feels convention free. (We have
'biases', but they are only really expressed in terms of our
documentation and the effort to which we put our time in to support
them, which is a manpower issue. And in general our biases reflect our
philosophy, hence our choice of the "natural Ruby" renderer Markaby
over Haml or ERB).

Also we have really cool features like inheritable configurations
(awesome! http://rubywaves.com/configurations ) and live code
reloading that I won't go too deep into here.

In conclusion, I'd like to reiterate that Ruby Waves is the most
forward looking web app framework in the Ruby world, and as such I
think that it provides a great starting point for the Web.pm project,
with its aim to think about where we are going rather than where we
have been.

# ab5tract

[ab5tract]

Oops I forgot to include me little psuedo-port of in the style of
Carl's sinatra example: http://gist.github.com/71656

# ab5tract

> framework remains unbiased. (http://rubywaves.com/foundations-and-layers

> )
>
> Third, the icing on the cake, is that the Waves' philosophy is to do
> as much as possible in pure Ruby. That is, we avoid the language-
> within-a-language scenario that Rails suffers from (people can
> literally "learn" Rails without learning basic Ruby syntax). We have
> only one Domain Specific Language (DSL) and it is very small, just
> some helper methods to make routing easier. However, at the center of
> routing is a library called Functor, which basically implements MMD in
> Ruby. This little bit of magic is very powerful, but it highlights how
> in a way Waves is already using a "Perl 6 philosophy." Certainly the
> goal of keeping as true to a language as possible in terms of avoiding
> DSLs is the reason why coding in Waves feels convention free. (We have
> 'biases', but they are only really expressed in terms of our
> documentation and the effort to which we put our time in to support
> them, which is a manpower issue. And in general our biases reflect our
> philosophy, hence our choice of the "natural Ruby" renderer Markaby
> over Haml or ERB).
>
> Also we have really cool features like inheritable configurations

> (awesome!http://rubywaves.com/configurations) and live code