search

mootools / mootools-core

MooTools Core Repository
https://mootools.net
2.65k stars 505 forks source link

Deprecate MooTools? #2798

Closed Pajn closed 4 months ago

Pajn commented 6 years ago

Based on the words of one of the MooTools organization members

Apart from the prototype extension wars, I believe the fact that MooTools libraries are not (and should not) be used for new projects anymore (and therefore only need maintenance - of which it doesn't need a lot) is because the libraries are not needed anymore: most of what MooTools wanted to bring to JavaScript has been implemented natively.

And, together with the background that MooTools have multiple times caused problems for introducing new Array prototype methods. It stands to reason that maybe MooTools should add a text to the README of this repo as well as the website that MooTools should not be used for new projects and that older projects might want to start migrating to using native functionality backed by polyfills for browser support.

Sure, the TC39 hiccups have been with old websites not updated for a long time. But based on some of the issues of this repo it looks like some new projects are using MooTools too. Additionaly, maybe, just maybe it may also encourage some old users to actually migrate.

cordovapolymer commented 6 years ago

then JQuery must be deprecated too.

alex-kinokon commented 6 years ago

@cordovapolymer jQuery does not meddle with object prototypes.

pelevesque commented 6 years ago

I believe JQuery's time has also passed.

zortext commented 6 years ago

This is a nightmare for us. We have tons of mootools code in our CMS which we develop for 10 year. Migration takes a year. We still develop new features with mootools because of it's object oriented approach. Moreover this type of migration seems obsolete. Let say we switched to react. There is no guarantee that it will last for years.

After mootools shutdown, maybe one day it will become uncompatible with new browsers and our CMS will be broken. This scenario really scares me.

What do you recommend? What do you think is a good idea? Is it better to make migration before the inevitable end? Which library/framework is reliable?

Jquery? No I don't think https://trends.google.com.tr/trends/explore?date=today%205-y&q=mootools,jquery

DimitarChristoff commented 6 years ago

FWIW, I don't think browser vendors have an appetite for breaking the web. So deprecated or not, with the 10s of thousands of sites using old MooTools out there, there is very little chance of a change that will kill your CMS.

Even the whole flatten debacle would have affected a very, very, very tiny % of the MooTools users who actually were reliant on it and had a different expectation for the 2nd argument.

As you were...

pelevesque commented 6 years ago

JQuery is just as dead as mootools. The future is vanilla JS.

sdphm80 commented 3 years ago

I still feel there is value in these tools from a standardization point... they have a standard way of doing things that VanillaJS doesn't provide.

Anybody who relies so much on a tool that it would cost them so substantially to retool should seriously consider putting their money where their mouth is and help with the maintenance of these free libraries that they benefit so much from. Its not fair for a company to use free tools, and expect that the people should have any care or obligation to their interest whatsoever. The libraries that are most successful have corporate backers that dedicate time and energy to keep the project going beyond the free-lance work of others.

BerendKemper commented 4 months ago

In my work environment we deliver scripts to publishers. One publisher seems to implements MooTools.js.

MooTools.js applied extend to all sorts of Native classes. Additional prototype methods provided by MooTools are not much of a problem. However, prototype methods hijacked by MooTools that override Native methods are a problem.

One example is that MooTools has hijacked the Native class Event. More and more publishers move towards Single Page Application technology, or infinite scroll functionallity. It is essential that Native class Event is not screwed with.

All, sorts of Array.prototype methods have been hijacked by MooTools. The result is that debugging and Error stacks become confusing.

There is nothing "standard" about hijacking standardized native functionallity provided by browsers.

Providing additional method could just as much be assigned to classes that extend from Native classes, instead of hijacking entire native classes, hijacking native class prototype methods and/or injecting new prototype methods into native classes. MooTools = Bad practice!

dfaure57 commented 4 months ago

Something to know is that in 2006, when Valerio and his colleagues wrote Mootools, Javascript was not as complete as it is today. It would have to be calculated, but more or less half of Mootools today is provided by Javascript itself. But not in 2006. Personally, I started using it in 2010 and did so until 2022 when I decided to finally rewrite the classes I had written with Mootools, going to Vanilla JS. Yes, today I would no longer use it, but it must be put in its historical context, it was a great tool, and it still is, if the use in a project requires it.