Proliferation of web frameworks

[gabriele renzi]

Phil Tomson ha scritto:

Isn't Twisted kind of like drb? (I could be way off here)

It is a general framework for writing asynchronous stuff, including
remoting protocols, standard internet protocols like
http/ftp/imap/whatever, gui stuff and database stuff.
It can provide something like drb, I'd say, but it's not just it.

 

[Dimitri Aivaliotis]

Phil Tomson ha scritto:


It is a general framework for writing asynchronous stuff, including
remoting protocols, standard internet protocols like
http/ftp/imap/whatever, gui stuff and database stuff.
It can provide something like drb, I'd say, but it's not just it.

From what I just quickly read on
http://twistedmatrix.com/services/twisted-advantage (and elsewhere on
that site), it certainly looks like a worthwhile project. It kind of
reminds me of 9P2000/Styx from Plan9/Inferno, which is something that
I've been wanting in Ruby lately...

- Dimitri

 

[Michael C. Libby]

Beside "writing your own" as a learning experience, another thing not
to underestimate is the ludic aspect of all this. A lot of open source
project are simply for fun, not for profit nor "efficiency".

Sometime, even though there already exists uncountable "solutions" out
there, I just feel like writing my own as a hobbyist. Just because I
can )

Seems to me that web sites are often highly customized animals, as well.

Might make less sense trying to fit the design into an existing framework
than it does to just build something that does exactly what is needed for
the case at hand.

Part of the problem we have with Ruby is that writing new code that is
fairly powerful is very, very easy. This is a good problem to have.

Of course, this also means that it might be easier to simply code from
scratch than figure out how to extend existing complex code. With Ruby
this is less of a problem than some languages, but big projects are
still big projects... and that can be intimidating (at least to me).

I also want to suggest that the names chosen for most of these projects
aren't particularly helpful, nor are the descriptions. This means that
people like me, who tend to get glazed eyes fast when anything that
looks even remotely buzzword compliant or marketing-flashy comes along,
may miss a perfectly useful package simply because it has a "wierd" name
or the description is too vague. I'm sure this is just prejudice on
my part, but I tend to avoid stuff that comes across like an ad in
Dr. Dobbs for the latest Java gizmo or the newest .NET snake oil.

Is it possible the names make people think of a package as someone's pet
project rather than a community resource to be hacked and extended?

I'm certainly NOT trying to disparage any of the efforts out there,
because it's all volunteer work. Even if no one else ends up using
your package, just your willingness to share the code you've written
is worth applauding. In that respect, keep up the good work you
proliferators of frameworks.

-Michael

 

[Michael Neumann]

Yes, exactly. It is fun, and you can learn a lot of things in doing so.
I personally want to understand the underlying libraries before I like
to use them. So this is what I did with Wee ;-)

Seems to me that web sites are often highly customized animals, as well.

But they can IMHO be grouped into two categories:

* web *applications*
* web "sites"

Web applications are much more like GUI application are, just that the
browser
is the GUI, whereas web-sites are more like traditional sites, with some
dynamic stuff in them. From my point of view, web applications need
registration and are build with a limited number of users in mind (you
develop these kind of applications for a compary for example). This is
my definition of "application" vs. "site", it may be wrong for someone
else than me ;-)

Wee is very well suited for applications, whereas Rails and Nitro are
better suited for dynamic sites (with many users, but not so much
interaction and UI-state).

Might make less sense trying to fit the design into an existing framework
than it does to just build something that does exactly what is needed for
the case at hand.

Part of the problem we have with Ruby is that writing new code that is
fairly powerful is very, very easy. This is a good problem to have.

Of course, this also means that it might be easier to simply code from
scratch than figure out how to extend existing complex code. With Ruby
this is less of a problem than some languages, but big projects are
still big projects... and that can be intimidating (at least to me).

Hm, I don't think it's easy to develop Nitro or Rails from scratch. And
they are good for most purposes, so unless you want to take a different
approach, you would not want to write them from scratch.

I also want to suggest that the names chosen for most of these projects
aren't particularly helpful, nor are the descriptions. This means that
people like me, who tend to get glazed eyes fast when anything that
looks even remotely buzzword compliant or marketing-flashy comes along,
may miss a perfectly useful package simply because it has a "wierd" name
or the description is too vague. I'm sure this is just prejudice on
my part, but I tend to avoid stuff that comes across like an ad in
Dr. Dobbs for the latest Java gizmo or the newest .NET snake oil.

Which name(s) do you have in mind? ;-)

That's why I like to see examples in their description. The best
description for me is an example. You can quickly see it's beauty and
simplicity from an example.

Is it possible the names make people think of a package as someone's pet
project rather than a community resource to be hacked and extended?

Wee is for sure a pet-project, at least it started as one. But IMO, it
has potential for very dynamic applications. And if you take a look at
the sources (the core), you'll see that it's pretty well documented and
easy to understand.

Regards,

Michael

 

[Glenn Parker]

Not necessarily: these frameworks are meant to make people's lives easier,
i.e. be more productive and thus faster. If it takes too much time to
make a informed decision about the best choice then there are definitely
too much options to choose from - or too little information that makes
deciding possible without trying out all options.

I think it's pretty pointless to ask the world to stop writing free
software, just because it might confuse some folks. There are also a
lot of computer languages to choose from (none of them perfect), but we
all seem to manage somehow. We pick one, use it for a while, fail or
succeed, and learn from the experience, then move on. You don't have to
try everything to find happiness, but it's a rare event when you hit a
home run on the first try.

A plethora of frameworks is a good thing, if only because it educates a
few more developers about what makes a good framework. Something as
complicated as a real-life framework is full of twists and turns, and
why should we discourage anybody from getting out there and taking a spin?

The good stuff will, by definition, float to the top without any
negative pressure on competing projects. Instead of stomping on the
stuff you don't like, how about supporting the stuff you do like?
Instead of complaining about too many choices, how about making a choice
and sharing your experiences?

 

[Sam Roberts]

Quoteing (e-mail address removed), on Fri, Jan 14, 2005 at 07:03:08AM +0900:

Some people probably want some help in their decisions, and that's a
reasonable desire. In the "information market" of Ruby users, there's a
vital role to be played as intermediary--that is, to skip trying to be
the guy who wrote everybody's favorite WAF, and instead to be the guy
who writes cogent summaries of the choices to help everybody pick their
own.

Yes, the choice may be good - but the lack of docs and lack of summary
of what is different/good/bad about them is overwhelming if you are
just getting in to them.

Sam

 

[Francis Hwang]

Quoteing (e-mail address removed), on Fri, Jan 14, 2005 at 07:03:08AM +0900:


Yes, the choice may be good - but the lack of docs and lack of summary
of what is different/good/bad about them is overwhelming if you are
just getting in to them.

All true. So instead of asking people to code less, we should probably
ask them to document more.

Francis Hwang
http://fhwang.net/

 

[Robert Klemme]

I think it's pretty pointless to ask the world to stop writing free
software, just because it might confuse some folks.

Please note that I never made this request. I just questioned the
statement that it's a good thing to have many options to choose from.
It's not, at least not if the decision takes considerable amount of time -
be it because of the sheer amount of options or the difficulty to collect
the necessary information.

There are also a
lot of computer languages to choose from (none of them perfect), but we
all seem to manage somehow. We pick one, use it for a while, fail or
succeed, and learn from the experience, then move on. You don't have to
try everything to find happiness, but it's a rare event when you hit a
home run on the first try.

Yeah, but that process takes time, which some folks might not have.

A plethora of frameworks is a good thing, if only because it educates a
few more developers about what makes a good framework. Something as
complicated as a real-life framework is full of twists and turns, and
why should we discourage anybody from getting out there and taking a

spin?

I certainly don't want to do that.

The good stuff will, by definition, float to the top without any
negative pressure on competing projects. Instead of stomping on the
stuff you don't like, how about supporting the stuff you do like?
Instead of complaining about too many choices, how about making a choice
and sharing your experiences?

Currently I'm in the (lucky?) situation that I don't have to choose
between Ruby web frameworks simply because I don't have the need.

Kind regards

robert

 

[Alan Garrison]

All true. So instead of asking people to code less, we should probably
ask them to document more.

I think for some projects it's not a matter of documentation quantity
but just a lack of a stated purpose. Someone can post "I wrote Package
X and here's the API", but what this doesn't answer is "why". If
someone wrote something to scratch an intellectual itch, that's
perfectly fine, but if you have a goal in mind for a particular project,
state it up front. As far as frameworks goes, perhaps there just needs
to be clarification on:
1) I wrote X because...
2) (If applicable) X is modelled after application/framework Y
3) Right now X can do...
3) I want X to eventually be able to do x, y, z...

Particularly #4, if this is stated up front, you'll likely get other
people contributing code faster just because the roadmap is plainly laid
out. If code is created only for the itch-of-the-moment, a package
won't get very far.

 

[Edgardo Hames]

I think for some projects it's not a matter of documentation quantity
but just a lack of a stated purpose. Someone can post "I wrote Package
X and here's the API", but what this doesn't answer is "why". If
someone wrote something to scratch an intellectual itch, that's
perfectly fine, but if you have a goal in mind for a particular project,
state it up front. As far as frameworks goes, perhaps there just needs
to be clarification on:
1) I wrote X because...
2) (If applicable) X is modelled after application/framework Y
3) Right now X can do...
3) I want X to eventually be able to do x, y, z...

Particularly #4, if this is stated up front, you'll likely get other
people contributing code faster just because the roadmap is plainly laid
out. If code is created only for the itch-of-the-moment, a package
won't get very far.

How about putting up a page in the Ruby wiki stating tha capabilities
and roadmap of each framework? This could also be done for all
different categories of applications and would be a very valuable
contribution for new developers who just don't know which one to use
or contribute to.

Kind Regards,
Ed

 

[Nicholas Van Weerdenburg]

I would expect that someone might have the experience to do this
across all web frameworks, having used them enough, while not being a
primary contributer to one of them (conflict of interest).

However, there are probably few people who fall into this category.
Most of them started writing there own web frameworks .

Nick

 

[James Britt]

...
All true. So instead of asking people to code less, we should probably
ask them to document more.

That's crazy talk!

James

 

[James Britt]

...

Part of the problem we have with Ruby is that writing new code that is
fairly powerful is very, very easy. This is a good problem to have.

Quite true. Often it takes far less time to just write the code than
to figure out someone else's API. I found this to be the case recently
on a Rails app. I reached a point where it was not at all clear if
Rails could do what I want, or do it efficiently, so I just rolled my
own from there on.

Of course, this also means that it might be easier to simply code from
scratch than figure out how to extend existing complex code. With Ruby
this is less of a problem than some languages, but big projects are
still big projects... and that can be intimidating (at least to me).

What I would like to see more of (and mind you this is likely a
reflection of my awareness of the state of Ruby apps and libs than
anything else) are easily-decomposable frameworks, or, better yet, many
small, well-defined, lightweight libs that may be assembled into a
framework. Code where you can write the entire API on an index card.

For example, Rublog has, I believe, code that lets you feed off content
stored in CVS. That alone is quite interesting, outside of any specific
application. If I wanted that in another application, I could grab the
source for Rublog and hack out that part, or reinvent it, but, ideally,
I could code grab some standalone code and just use that.

(This is not a roundabout plea for Dave Thomas to actually do this, just
an example that popped into my head.)

If I were to knock a common feature of many frameworks, it is that they
put too much in one bundle.

But the reality may be that evolving cleanly decoupled code is often at
odds with Getting Results(tm).

Maybe, in the long run, as various Web framework efforts live or die,
there will be some fallout of additional simple but practical libraries
that others can use to wire up into another application.

James

 

[Patrick May]

There is a difference, I think, in the ruby community. It is that it's
small enough so that everybody can participate

Btw there should be a new class of people after the hackers/coders, it
would be the "communicators" People who try to find similarities of
different frameworks and try to merge them if they are close enough.
And also "geographs", who build the map of technologies and how they
are related.

I think maybe the writers of the different frameworks should meet
(physically, ideally) and see how we can work together.

~ Patrick

 

[George Moschovitis]

I think you are overreacting.

At the moment there is only one big and widely used framework for Ruby,
ie Rails. And Rails does not reinvent the wheel. Instead it reuses many
existing libraries. From what I know, only two other frameworks are
actively maintained at the moment: Nitro and Wee.

Nitro reuses many design concepts from Rails and also reuses existing
libraries, for example the Breakpointer, blankslate, extensions,
dev-utils.

Whats more, the creator of Wee, provides TONS of ideas, suggestions and
patches for Og which is part of Nitro. I also plan to give ideas,
suggestions and even patches for further Wee development. As Michael
correctly stated, Wee is useful for web applications, Nitro will be
used for bigger web sites, possibly distributed over many servers, with
thousands of concurrent users.

In the future, I could try to make Og a drop-in replacement for
ActiveRecord, thus making it compatible with Rails. So, I think, there
is a lot of cooperation in the ever-so-friendly Ruby community, which
is a good thing.

If you dont have the time to evaluate multiple web frameworks just stay
with Rails If you have some time, please try Nitro, I would like to
hear some suggestions. As Nitro is not yet widely used, it is easier to
incorporate new ideas and improve the API than in Rails, so comments
and suggestions are more useful.

regards,
George

 

[zimba.tm]

Btw anyone wants to build something like python's Twisted in ruby ?

why do you feel this need?

IMHO there is no framwork that support that level of protocol
abstraction with an event-driven architecture.
I don't know much more about twisted that that..

I want to build "robots" that fetches data from many sources, like a
personnal google.
And other protocol-related projects.

Now I'm not ruby-experienced enough to build my own framework.
Otherwise I'd do it myself

Cheers,
zimba

 

[gabriele renzi]

(e-mail address removed) ha scritto:

IMHO there is no framwork that support that level of protocol
abstraction with an event-driven architecture.
I don't know much more about twisted that that..

I understand this. I nevere felt the need for it, anyway

I want to build "robots" that fetches data from many sources, like a
personnal google.
And other protocol-related projects.

interesting. But given that this is more a client issue, are'nt the
existing xmlrpc,net::imap/ftp/telnet/http/sftp/ssh,soap enough?

Now I'm not ruby-experienced enough to build my own framework.
Otherwise I'd do it myself

never underestimate ruby, it could make you an expert while you're not
even looking at it

 

[Martin DeMello]

Take a look at the python side of things. The plethora of web
frameworks is confusing and contradicting the mantra of 'one way of
doing things'.

I hope ruby don't end up in this kind of situation.

+1

I too hope ruby never adopts the 'one way of doing things' mantra.

martin