MX3Design,
Thank you for the nicer tone of your last post, and for conveying your
thoughts and feelings in a more appropriate manner. We understand
where you are coming from now, and I promise, we are trying to
alleviate breaking changes. There is one important thing that Valerio
explained to me many years ago, that has driven development of
MooTools from the beginning. I want to share it with you and the
community because it will certainly help you understand and hopefully
feel better about some of the pain you felt when switching to MooTools
1.2.
First let me start by reiterating that from now on, we will really try
not to break compatibility. That being said, let me explain that if a
breaking change is necessary to make MooTools the absolute best
framework it can possibly be, we will not hesitate. If there is a
faster, more efficient, or for some other reason better solution to
any problem we have previously solved, we will never discredit that
solution just because we need our framework to be compatible with
previous releases. We will always explore better solutions,
especially as the browser and web landscape changes in the future.
To put this into a perspective that we can all appreciate, imagine if
you will, if Microsoft was able to follow the same mantra that we, as
an open source project, not tied to any corporate backing, are able to
follow. Internet Explorer might be one of the most advanced,
standards compliant web browser on the market today. Windows might
never have become plagued by security holes, viruses, spyware, and
bloat. All if Microsoft wasn't forced to make their driving
developmental force *backwards compatibility*.
I promise you, however, that from now on... we will make breaking
changes as painless as possible. We will provide you with
compatibility where appropriate and possible, and I will personally
document and blog about any and all changes we think you need to take
into consideration in your scripts, along with justification for why
we are making you do the extra work.
I hope this post clears things up for a lot of users, and we can
finally start to move forward as a unified community.
- Tom
On Oct 6, 2008, at 1:33 PM, nutron wrote:
Gregory, this kind of response is uncalled for. No need to be
condescending
or use foul language.
As for the original post, I can say that 1) I agree the MooTools
core needs
to stabilize. No more method renaming and changes need to be backwards
compatible. At CNET, I spent a lot of time rewriting a lot of our
code for
1.2. The compatibility layer helped with a lot of problems, but not
all.
Expect future versions of MooTools to be more stable and for future
development to focus more on additional functionality and a little
less
refactoring of the core (which is where all the compatibility
problems tend
to come from).
As far as charging for MooTools, that will never happen. This is an
open
source project and it will continue to be.
My last point will be to suggest that you try and apply the MooTools
class-based approach to your work more. If you use classes for nearly
everything you'll find that not only is your work more reusable,
it's more
manageable when it's time to refactor it. I've written more about
this here:
http://clientside.cnet.com/best-practices/jquery-and-the-ajax-experience-programming-to-the-pattern-and-what-really-makes-one-framework-different-from-another/
http://clientside.cnet.com/best-practices/jquery-and-the-ajax-experience-programming-to-the-pattern-and-what-really-makes-one-framework-different-from-another/
and here
http://clientside.cnet.com/best-practices/thoughts-on-coding-and-new-classes-as-a-result/
http://clientside.cnet.com/best-practices/thoughts-on-coding-and-new-classes-as-a-result/
gregoryt wrote:
i've been watching this back-and-forth for over a week now.. if you
spent as much time writing code as you did bitching about the
mootools
team you would probably have everything you need by now...
i simply cannot agree that the change to mootools 1.2 screwed anybody
over. I have converted most of the classes my company had written in
mootools 1.11 to mootools 1.2 and it wasn't that huge of a thing, it
was like maybe three small items per class.
you seem like a smart business man, and it appears you have found a
potential market.. why not provide the support you are requesting.
not
sure how anyone would expect the 8 people who contribute to the core
library capable of doing that and writing all the code and having
full
time jobs...
-gregory
On Oct 6, 6:39 am, MX3Design <[EMAIL PROTECTED]> wrote:
For those of you that have followed recent threads I would like to
clearly state that I recognise the amount of effort, energy and hard
work that has gone into MT development and for the record I've
stated
this before both in the old forums and in this usergroup...
From my perspective when 1.2 was released it was so disappointing. I
had written many scripts in previous versions and developed complete
applications based upon the framework. To suddenly find that all of
this code would have to be rewritten in order to use the new build
was
a complete shock. It meant that my business could no longer continue
to use MT as it's was simply not commercially viable to update and
redevelop countless sites and scripts. (and no the backward
compatibility layer didn't work!)
There seems to be an unofficial consensus of opinion that many MT
users are no more than 'script kiddies' looking for a quick cut &
paste snippet. Whilst to some extent this may be the case there is
also a large body of professional designers and developers who rely
heavily upon pre-coding or outsourced development. Think about what
knowledge the average designer needs: xhtml, xml, javascript, php,
mySQL, actionscript, css etc etc it is very difficult to be an
expert
in all these fields and find time to develop which is why a
framework
provides such a useful platform, which brings me on to my main
point.
There must be a huge market for a framework which would simplify and
give designers an easy method to integrate functions into their web
applications. A framework which provides well documented examples,
and
one which makes it ridiculously easy to use. A framework which
provides a high level of support and one which is helpful and
welcoming. There's no shame in providing what people need, you're
not
going to lose face, quite the opposite. In my experience people
really
appreciate help, especially when they're approaching a new area of
knowledge, we all started at the same place but it's all too easy to
forget that.
Why not charge a licence fee and give people what they both need and
want? I would certainly pay (provided there was backward
compatibility!) The business model that EllisLabs and in particular
Expression Engine have adopted works extremely well, they provide a
good product, a user forum with excellent support, a repository and
good documentation. Their users provide plugins, extensions and
support to each other, it's a happy, helpful and unified community
and
the developers are making money...
-----
The MooTools Tutorial: http://www.mootorial.com www.mootorial.com
CNET Clientside: http://clientside.cnet.com clientside.cnet.com
--
View this message in context:
http://n2.nabble.com/Mootools-the-future%2C-a-suggestion...-tp1300547p1301450.html
Sent from the MooTools Users mailing list archive at Nabble.com.
