Proliferation of web frameworks

In article <1105695838.854959.16660@f14g2000cwb.googlegroups.com>,

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.

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

But it appears that the Ruby community is experiencing (or is about to
experience) a growth spurt primarily due to outside interest in Rails.

I suspect the Ruby community will be a good deal larger than it currently
is by the end of this year (just a hunch :).
....well that's what we've wanted for the last few years, but are we ready
for it?

Btw there should be a new class of people after the hackers/coders, it
would be the "communicators" :stuck_out_tongue: 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.

And reviewers/writers to try out and compare the different frameworks and
then write articles about the comparisons.

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

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

Phil

ยทยทยท

zimba.tm@gmail.com <zimba.tm@gmail.com> wrote:

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

Francis Hwang

ยทยทยท

On Jan 14, 2005, at 9:07 AM, Sam Roberts wrote:

Quoteing sera@fhwang.net, 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.

"Glenn Parker" <glenn.parker@comcast.net> schrieb im Newsbeitrag
news:41E7D1BE.3040805@comcast.net...

Robert Klemme wrote:
> "PA" <petite.abeille@gmail.com> schrieb
>
>>>But only very few of them are a good choice, and thats a bad thing.
>>
>>Why? The fact that there are so much choice, both good and bad, force
>>you to make/take decisions. This is a positive thing by itself.
>
> 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.

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. :slight_smile:

Kind regards

    robert

ยทยทยท

>>On Jan 13, 2005, at 18:27, Lothar Scholz wrote:

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

~ Patrick

ยทยทยท

On Friday, January 14, 2005, at 04:46 AM, zimba.tm@gmail.com wrote:

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.

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

Btw there should be a new class of people after the hackers/coders, it
would be the "communicators" :stuck_out_tongue: 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.

gabriele renzi wrote:

zimba.tm@gmail.com ha scritto:

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.

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

Btw there should be a new class of people after the hackers/coders, it
would be the "communicators" :stuck_out_tongue: People who try to find similarities of
different frameworks and try to merge them if they are close enough.

well, I think this is actually done by the developer themselves. I.e. You can often find comments from george moschovitis on the rails weblog, and you can see Michael Neumann referring to IOWA and Og(from nitro).
The situation is not that bad, imo.

Often it's easier to write a new application from scratch then understand an existing one. By writing Wee from scratch, I learned *why* Avi (who wrote both IOWA and Seaside/Borges) did the things in this way. I used Avi's ideas and implemented them in Ruby how I'd implement them.

Regards,

   Michael

Phil Tomson ha scritto:

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

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.

Francis Hwang wrote:

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.

ยทยทยท

Francis Hwang
http://fhwang.net/

--
Alan Garrison
Cronosys, LLC <http://www.cronosys.com>
Phone: 216-221-4600 ext 308

Francis Hwang wrote:

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

That's crazy talk!

James

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 :slight_smile: 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

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 :stuck_out_tongue:

Cheers,
zimba

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 :o)

Cheers

ยทยทยท

On Jan 14, 2005, at 12:42, Michael Neumann wrote:

Often it's easier to write a new application from scratch then understand an existing one. By writing Wee from scratch, I learned *why* Avi (who wrote both IOWA and Seaside/Borges) did the things in this way. I used Avi's ideas and implemented them in Ruby how I'd implement them.

--
PA
http://alt.textdrive.com/

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

ยทยทยท

On Fri, 14 Jan 2005 21:41:12 +0900, gabriele renzi <rff_rff@remove-yahoo.it> wrote:

Phil Tomson ha scritto:

>
>>Btw anyone wants to build something like python's Twisted in ruby ?
>
>
>
> 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.

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

ยทยทยท

On Sat, 15 Jan 2005 00:07:20 +0900, Alan Garrison <alang@cronosys.com> wrote:

Francis Hwang wrote:

>
> 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.

--
Alcohol is the anesthesia by which we endure the operation of life.
-- George Bernard Shaw

zimba.tm@gmail.com ha scritto:

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 understand this. I nevere felt the need for it, anyway :slight_smile:

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 :stuck_out_tongue:

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

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. :slight_smile:

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. :slight_smile:

-Michael

ยทยทยท

On Fri, Jan 14, 2005 at 08:49:54PM +0900, PA wrote:

On Jan 14, 2005, at 12:42, Michael Neumann wrote:

>Often it's easier to write a new application from scratch then
>understand an existing one. By writing Wee from scratch, I learned
>*why* Avi (who wrote both IOWA and Seaside/Borges) did the things in
>this way. I used Avi's ideas and implemented them in Ruby how I'd
>implement them.

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 :o)

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

ยทยทยท

On Sat, 15 Jan 2005 03:16:20 +0900, Edgardo Hames <ehames@gmail.com> wrote:

On Sat, 15 Jan 2005 00:07:20 +0900, Alan Garrison <alang@cronosys.com> wrote:
> Francis Hwang wrote:
>
> >
> > 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.
>

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
--
Alcohol is the anesthesia by which we endure the operation of life.
-- George Bernard Shaw

--
Nicholas Van Weerdenburg

Michael C. Libby wrote:

Often it's easier to write a new application from scratch then understand an existing one. By writing Wee from scratch, I learned *why* Avi (who wrote both IOWA and Seaside/Borges) did the things in this way. I used Avi's ideas and implemented them in Ruby how I'd implement them.

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".

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 :wink:

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

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 :wink:

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. :slight_smile:

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? :wink:

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

ยทยทยท

On Fri, Jan 14, 2005 at 08:49:54PM +0900, PA wrote:

On Jan 14, 2005, at 12:42, Michael Neumann wrote:

Michael C. Libby wrote:

...

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. :slight_smile:

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