Re: Mootools the future, a suggestion...

[MX3 Design]

Hi Tom,   Thanks for your constructive comment, I appreciate it. Best wishes, Jay     .....................................................   Jay Raby   Tel: +44 (0)121 286 7210 Mob: +44 (0)778 639 8724   Web: www.mx3design.co.uk email: [EMAIL PROTECTED]   ..................................................... Tom Occhino wrote: 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. --~--~---------~--~----~------------~-------~--~----~ This message is part of the topic "Mootools the future, a suggestion... " in the Google Group "MooTools Users" for which you requested email updates. To stop receiving email updates for this topic, please visit the topic at http://groups.google.com/group/mootools-users/t/bef90a97a181b621 -~----------~----~----~----~------~----~------~--~---