Open GoogleCodeExporter opened 9 years ago
Hello Aaron,
I'm glad that you took part in that issue.
You are right of course, but your thoughts apply for any js library. It's
exactly the
same for example with jQuery UI, but it IS provided by Google.
Also what you say is true speaking of best practices for _production_ sites.
As for development and testing I always include the whole uncompressed library.
The CDN is perfect for that, because I can so easy switch and test with
different
branches/version. (maintainng all branches locally is not good idea)
All The Best,
Mirko
Original comment by tsveto...@gmail.com
on 23 Feb 2010 at 7:54
What about a plugin loader ? That's what I do on my projects... maybe jquery
and mootools Google
loaders can do this kind of work...
Original comment by Metal3d
on 24 Feb 2010 at 7:39
The only way this would make sense is if Google hosted all the MooTools-More
plugins and allowed you to load
them individually.
That would indeed be very very awesome.
AFAIK that's how YUI works on Google
Original comment by thomas.42
on 24 Feb 2010 at 5:49
The problem with loading them individually is performance; you just don't want
dozens of includes. Plus,
managing that is a pain; we add and rename and move files around. It's just not
practical.
What you really want, I think, is a way to build these yourselves. Luckily, we
have just such a tool:
http://github.com/anutron/mootools-depender
With this, you can download it from github, pull mootools core and mootools
more from github, edit a config
file to tell the depender app (provided as both a php and a django app) where
to find these, and then you can
load anything you want. You can load all of core, all of more, portions of
either (with the dependencies
calculated and included). Plus there's a JS client included so you can load
additional components on the fly.
This is how I develop (and why I wrote the app). It allows you to switch
branches, to switch between releases
(all this done with git on the command line). It lets you include your own
scripts... It's really quite useful for
development and, potentially, in production (though pushing flat, built scripts
makes more sense there).
I still don't think Google should try and put all of -more up. It's not about
them being fair or not; it's just not
a good candidate.
Original comment by anut...@gmail.com
on 4 Mar 2010 at 7:19
This is exactly, what Google could do. I agree, that nobody wants to use
another include for each plugin. A possible way to implement this could be:
google.load("mootools", "1.2.4", { more:[Lang, URI, etc.] });
Of course this would increase the amount of time needed until a new release
will be available, but it I agree with the other folks here. When I can't get
Mootools More from Google, why should I get Core from Google. I think that most
users of Mootools are using parts of More, so this should be a part of Googles
Service if they provide Mootools Core.
Original comment by nico.wie...@gmail.com
on 24 Aug 2010 at 11:27
This might be off, but why don't you just include the few more-options you need
in your normal script file? Minify the whole lot to preserve band width, and
it's only one HTTP request (one you'd have to make anyway).
Won't an API like
google.load("mootools", "1.2.4", { more:[Lang, URI, etc.] });
defeat the benefits of using Google as a CDN? And wouldn't it severely lessen
the chances of your "version" of the core+more module being cached by your
users?
Original comment by laustdel...@gmail.com
on 24 Aug 2010 at 11:50
Original comment by adam.fel...@gtempaccount.com
on 10 Nov 2010 at 11:12
Please add Mootools More to google code!
Original comment by elron100...@gmail.com
on 11 May 2011 at 3:48
Please add More!
Original comment by drewg.cgyamaha@gmail.com
on 6 Jun 2011 at 7:37
Please add
Original comment by drewg.cgyamaha@gmail.com
on 10 Jul 2011 at 12:46
As I see it, the coolest part of Google APIs is that the user is not loading
anything -- it's already in her browser's cache. This hover requires that all
websites will switch to use the same uri to point to the same library.
If every website will link to it's own one of 2^n possible subsets of Mootools
More, then it will degrade the performance as compared to not downloading
anything and using just the cached version of library with n plugins.
I vote to add the Mootools More as a whole even if people gonna use only 1% of
it. Unless you are worried about something different than downloading --
perhaps you are worried about parsing or memory comsumption. But are these
really such high?
Original comment by qbo...@gmail.com
on 18 Oct 2011 at 10:38
Joomla 1.7 Core uses mootools-more.js - So, I think there a lot of people
interested in a solution to replace it with google-apis
@Aaron You say that mootools-more.js is not a library - That is the concept,
but in reality it is used like a library: In Joomla 1.7
Original comment by webd69@googlemail.com
on 15 Jan 2012 at 6:33
please add More
Original comment by r.bour...@gmail.com
on 23 Jan 2012 at 2:50
please add mootools-more.js for joomla 2.5.1
Original comment by tekniske...@gmail.com
on 9 Mar 2012 at 12:54
Jesus H. Christ. How is this still not a thing?
Original comment by trefight...@gmail.com
on 3 May 2012 at 9:00
Please add Mootools more...
Original comment by sergios...@gmail.com
on 17 Jun 2013 at 2:11
Yes PLEASE add!
Original comment by jswin...@gmail.com
on 17 Jun 2013 at 2:14
YEs, plaeas add mootools more
Original comment by CraigRi...@gmail.com
on 1 Dec 2013 at 3:08
It's STILL not there? People have been asking for 5 years...
Original comment by pochine....@gmail.com
on 4 Sep 2014 at 6:23
Im asking too. Because of Joomla 2.5
Original comment by jan.pl...@post.cz
on 28 Oct 2014 at 10:20
bump
Original comment by pochine....@gmail.com
on 30 Oct 2014 at 3:28
Original issue reported on code.google.com by
www.bansa@googlemail.com
on 6 Nov 2008 at 8:21