Bingo.
The issue isn't that having a Tap5 is important, for it is. There will
always be a need to add new features and support new technologies as a
framework expands. The issue I have is that every Tap release doesn't
just
add new abilities, it completely scraps the existing code. There are
numerous reasons why this is a poor way of working. Specifically:
1) A framework's is by nature harder to learn than other technologies.
This is because unlike learning a particular application, learning a
single
library, or learning just a class, a framework adds a great deal of
complexity in order to be a more general purpose solution. This added
complexity results in a steep learning curve, which requires a large
investment of time on the part of its users in order to learn. The
payoff,
or return on that investment of time is the ability to leverage that
knowledge on a variety of projects.
By rewriting the entire framework with each release, that investment
of time
is destroyed. Developers barely have time to see a couple of projects
through before they have to relearn the new way of doing things. This
severely limits the returning value of the framework, and is very
wasteful
when it comes to developer time.
2) Specific to Tapestry, the framework is based around reusable
components. The promise of the existance of these components is very
powerful, and could be a source of as much value as the framework itself.
By continually invalidating the component libraries that exist, we once
again limit the ongoing value of the project. A component based
framework
ought to have a vibrant user community with a large variety of compnents
that will work for a long time. I'm not seeing that happen with
Tapestry,
despite all its promise.
3) Having a framework that works only for a single snapshot in time may
work for some companies that write an application and release it. But
really, that is probably more suited to a client side application than
a web
framework. The reality is that most of the web applications developed in
Tapestry 4 will need to be supported in place for a long time. And
during
that time, feature requests will come in that can only be implemented
using
the technologies made available in Tap5 or Tap6 or TapX. Developers
need to
know that when it comes time to add new features, the cost is
proportionate
to what they are adding. To add a small feature that uses some tiny
subset
of Tap5 features, I will have to rewrite the entire web application?
Again,
such a waste of time.
4) One powerful advantage that open source projects have is that
there is
so much expertise, and so many skilled individuals out there, that
working
together they should be able to view the project from many different
sources, and see many different ways that the project can grow and take
shape. This should add some level of flexibility to the projects. There
should be some level of forethought from a variety of angles built
into the
code.
The fact that every new release of Tapestry requires a rewrite makes me
question just what is going on. Why can't a system be made to work
without
being so rigid and inflexible that it cannot be adapted in the
future? We
have so many patterns and so many well understood software design
principles
exactly to prevent having to do complete rewrites. That a project isn't
able or isn't willing to use them for that purpose is worrying, to say
the
least. This is understandable for a new project, or a young project, but
we're talking about version 5 now. 5!
5) Open source projects rely on contributions via mailing lists and/or
wikis and tutorial websites to teach developers the ropes. Completely
changing the way everything works in every release makes it hard to
learn,
hard to search for, and hard to establish best practices. You aren't
just
throwing out code when you scrap a framework, you are throwing out all
the
knowledge that has accumulated around it.
As was mentioned elsewhere in this thread, this isn't a race. Do one
thing,
and do it well. If hivemind doesn't have the new features, get them
done in
that project, maintaining backwards compatibility, and then bring them to
the Tapestry project for the next release. With so much waste in the
world,
why are we reinventing the wheel that was specifically reinvented for
this
same project so recently?
In the end, for me, it boils down to this: We are a small company,
and our
small group of developers will be growing the applications we build over
time. We have to look at both the current capabilities, and the future
costs of the frameworks we select. While Tapestry's current capabilities
are great, the future costs that it will incur if it continues along the
path of constant rewrites are too great for us to invest in it. There
are
many users in the same boat.
Why do none of the above points make any difference in the future path of
Tapestry? I find it ironic that one of the stated goals on the
Tapestry 5
IoC Introduction is "User Friendliness" when invalidating all their
current
knowledge and future upgrade paths for existing projects is about the
least
friendly thing anyone could manage to do to a developer.
I hope the devs are listening, because this project has too much good
potential to see it get a tarnished reputation over compatibility.
On 7/28/06, Jason Dyer <[EMAIL PROTECTED]> wrote:
Because, a company that has invested a year or more, developing an
app is
probably going to want to use it for a little while. Over the
lifetime of
an
enterprise app, it will undoubtedly need modification (both bug fixes
and
added features.)
When Tapestry 5 arrives, we can safely assume that Tapestry 4
development
will
stop fairly shortly thereafter (new features immediately, maybe bug
fixing
will go on for a year or two, but that's nothing compared to the
lifetime
of
a large app.) Then there's the fact that, right now it's difficult
enough
to
find people with skill in T4, but in a couple of years it'll be
impossible,
because most people will have moved on to T5...
If the migration to T5 requires what basically amounts to a rewrite
and T4
is
no longer maintainable, then the 'powers that be' at said company are
going
to be a little irate that they've invested so much time/money into
something
that ultimately didn't last very long. In fact, they'll probably be
looking
for heads to roll...
