Mootools the future, a suggestion...
MX3Design
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...
gregoryt
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
nutron
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/
-----
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.
Tom Occhino
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
Rajeev J Sebastian
> 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.
This is excellent!
I hope Tom, that you will also blog about this, so that the wider
community also knows about this policy direction in detail.
Regards
Rajeev J Sebastian
MX3Design
it's much appreciated.
Guillermo Rauch
Thank you Tom and Aaron for you constructive and encouraging comments,
it's much appreciated.
Paul Spencer
in other open source projects that I am involved in, there are some
established conventions with version numbers that help to set
expectations for users of those projects. Perhaps something similar
would help establish a sense of consistency for the MooTools
community. Roughly, the conventions are:
* releases are numbered <major>.<minor>.<bugfix>
* <bugfix> releases only fix bugs in a particular <major>.<minor>
release, absolutely no new features and absolutely no API change
* <minor> releases may add new features and wrap up bug fixes, but
absolutely no API change
* <major> releases may add new features, wrap up bug fixes and change
the existing API in an incompatible way.
While I doubt there is anything approaching a standard for release
numbering, I have seen the above used enough that most users of those
projects seem to implicitly understand that jumping from 1.x to 2.x is
potentially disruptive while jumping from 1.x to 1.(x+1) should not be.
If this was applied to MooTools, then the current version would have
been released as version 2.0. Having watched some of the discussions
over the last couple of weeks (and really having to bite my lip in a
couple of cases), I really think if you had chosen 2.0 as the version
number for the new release, it would have eliminated at least some of
that.
Cheers
Paul
Jan Kassens
like 1.11 -> 1.2 in the future and if such huge changes happen again
it will be a new major release. Furthermore we're now adding bugfix
releases so patches are getting pushed out earlier.
Jan
--
my blog: http://blog.kassens.net