incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Kuhnert <jkuhn...@gmail.com>
Subject Re AJAX-Toolkit-Framework-Proposal
Date Wed, 21 Dec 2005 21:24:33 GMT
Though I'm still very new to ASF (recently added to tapestry) and the goings
on of how everything works I thought I would voice my tiny little opinion
into the fray as well.

It seems that, at least from what I can tell, choosing a javascript library
is a very personal sort of thing for most people and that a lot of concern
stems from the very probable assumption that with an actual corporate
sponsor and seemingly having it sprung out of thin air the proposal to have
zimbra added will push a lot of people towards a technology platform that
many feel may not quite be the most ideal choice.

I chose tapestry as a web framework to use, and now contribute to, because I
thought I was making the best choice as far as design and overall
flexibility.(not to the detriment of other projects, just a personal
choice..)  It's a shame that all of the other considerations have to flow
into these descisions, but I'd be very broken hearted to see anything ~but~
Dojo being used in tapestry, as it is the only reason I thought I'd have
something to contribute to the project. I suppose that the incubation of
this proposal shouldn't affect us, but in reality I think it will.

Again, I don't know anything about most of the topics being discussed on
this list right now, only that I did spend a great deal of time evaluating
all js packages out there(that I could find) and overwhelmingly thought that
Dojo was the best choice by far. For all the reasons already mentioned,
packaging/support/testing/commercial quality/existing community/etc..How can
a reply be formed to all of these very impressive forward-thinking design
choices that simply says "oh that is neat, I'm sure we'll be able to add
that in once we're in apache"?? Don't people have to prove themselves
anymore?

:/

jesse

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message