I know, it's always the same question, but should we not prefer one of these libraries ? For quite some time, i read a lot stuff about "best way to integrate jquery and prevent the problem of different versions" and i seriously don't understand the discussion. It shouldn't be difficult to add a sort of "version" to the scripts array we use to avoid duplicated entries.
I think the main question should be if we want to use jquery or mootools in core, which also will show our prefernces.
Mootools is a great (and real) JS framework, but since most of the extensions are using jquery i thought that we should see that as a wake-up call. The community wants to use jquery.
So is there any concern about the (optional) use of jquery instead of mootools ?
> So is there any concern about the (optional) use of jquery instead of > mootools ?
after having written a fat client application in JavaScript with Joomla! as backend, I really don't know, what the advantage of introducing jQuery should be. I've never seen solutions based on jQuery that could not be made with MooTools, but I have vice versa.
The approach should not be to support jQuery inclusion, but to provide a set of widgets, like we do with modal, captions and tabs, which are unobtrusive and easy to use.
Another way to look at it is maybe the Joomla Platform should not have any javascript at all. It's really something the application should take responsibility for. In that way, it's no big deal for one app to use Mootools, another jQuery and yet another YUI. I'm leaning more and more to a state where maybe it's not our (the platform's) problem to solve.
>> So is there any concern about the (optional) use of jquery instead of >> mootools ?
> after having written a fat client application in JavaScript with Joomla! > as backend, I really don't know, what the advantage of introducing > jQuery should be. I've never seen solutions based on jQuery that could > not be made with MooTools, but I have vice versa.
> The approach should not be to support jQuery inclusion, but to provide a > set of widgets, like we do with modal, captions and tabs, which are > unobtrusive and easy to use.
I rather like that approach, myself, Andrew. But if javascript *is*
included, I think it's clear the library with the best case for
inclusion is jQuery. Currently 99% (possibly dropping to 90% over the
next few years) of the use case for javascript is DOM manipulation,
something jQuery excels at, and jQuery is typically the first js lib
anybody picks up and starts to use.
Niels, the question isn't whether something can't or can't be done in
MooTools. I've written in both and I think what you can do in one can
pretty much be done in another. The question is *has* it been done?
IOW, is it better to spend time creating something in MT that already
exists in jQ? Yes, I can empathize with your rich client experience.
But that's what? 0.1% of the uses Joomla sees? Having to add MT to a
js-less framework would have increased your workload by 5%, maybe,
probably less. But just as many, even more, would drop MT from the
framework and build their rich client in jQuery (take a look at what
can be done with SproutCore, for example; SC requires jQuery).
The reason the jQ choice seems so obvious to me is that most every
widget or validation you want to use already exists there, all you
need is to stitch it in. That's why so many designers won't consider
using anything else.
I have a fond spot in my heart for both MT and Scriptaculous, but more
and more the teams I work with insist on jQuery. At this point, the
question needs to be asked and answered: are unique javascripts part
of Joomla's "core competency," part of what can differentiate it from
the rest of the market? If the answer to that comes back as "Yes",
then the right path is to stick with MooTools and start developing all
the support scripts sites will need. OTOH, if the answer (as I
suspect) is "No," then it's time to bite the bullet and either remove
javascript from the framework completely, or make the switch to the
800-lb gorilla that is jQuery.
For example, the Rails framework grew up with Prototype and
Scriptaculous, but with version 3 they went library agnostic, and with
version 3.1 switched to jQuery being shipped as part of the framework.
As for JForm, Sybrek, don't get me started. I've been swearing at the
unreasonable rigidity of JForm's 1.7 incarnation for weeks, now.
To return to the jslib-agnostic idea:
I'm of two minds on it. For one, I like the idea of leaving the js
choice up to the developer. The choice of which js library to use
isn't made in a vacuum; it's made according to the requirements of the
application and the expertise of the application developer(s), neither
of which is known at Platform development time, so any choice made
there is bound to be suboptimal.
But more and more we're living in an AJAX world, and the ability to
function in it requires javascript, and some core functions could
productively use that capability. Since Sybrek brought it up I suppose
we can use JForm as an example of that:
If the idea of using js to do form validations, etc., in the client is
kept in JForm (something I'm not convinced of, but can see an argument
for, at least) then make that an optional selection, the developer
installs the option while starting to work on the application. An
additional advantage of that approach is that one library can easily
be dropped in favor of a new one if for some reason the initial
selection is found wanting as development progresses (or in future
versions of the app, as requirements change). The mechanism for this
would need to be developed, of course, making more work for everyone
concerned.
There are enough minor differences in how AJAX-y things are handled
between libraries, that custom php code is necessary, I think, to pull
that off, hence the optional bit.
On Feb 7, 1:11 am, Andrew Eddie <mambob...@gmail.com> wrote:
> Another way to look at it is maybe the Joomla Platform should not have
> any javascript at all. It's really something the application should
> take responsibility for. In that way, it's no big deal for one app to
> use Mootools, another jQuery and yet another YUI. I'm leaning more
> and more to a state where maybe it's not our (the platform's) problem
> to solve.
> On 7 February 2012 01:56, Niels Braczek <nbrac...@bsds.de> wrote:
> > Am 06.02.2012 14:53, schrieb Sybrek:
> >> So is there any concern about the (optional) use of jquery instead of
> >> mootools ?
> > after having written a fat client application in JavaScript with Joomla!
> > as backend, I really don't know, what the advantage of introducing
> > jQuery should be. I've never seen solutions based on jQuery that could
> > not be made with MooTools, but I have vice versa.
> > The approach should not be to support jQuery inclusion, but to provide a
> > set of widgets, like we do with modal, captions and tabs, which are
> > unobtrusive and easy to use.
I think mootools is great and it's the JS lib I prefer, but it seems that jQuery has really won the war. J!3.0 seems the opportune time to bite the bullet.
[mailto:joomla-dev-platform@googlegroups.com] On Behalf Of Paladin Sent: Wednesday, February 08, 2012 12:03 PM To: Joomla! Platform Development Subject: [jplatform] Re: Never ending story: Jquery vs mootools
I rather like that approach, myself, Andrew. But if javascript *is* included, I think it's clear the library with the best case for inclusion is jQuery. Currently 99% (possibly dropping to 90% over the next few years) of the use case for javascript is DOM manipulation, something jQuery excels at, and jQuery is typically the first js lib anybody picks up and starts to use.
Niels, the question isn't whether something can't or can't be done in MooTools. I've written in both and I think what you can do in one can pretty much be done in another. The question is *has* it been done? IOW, is it better to spend time creating something in MT that already exists in jQ? Yes, I can empathize with your rich client experience. But that's what? 0.1% of the uses Joomla sees? Having to add MT to a js-less framework would have increased your workload by 5%, maybe, probably less. But just as many, even more, would drop MT from the framework and build their rich client in jQuery (take a look at what can be done with SproutCore, for example; SC requires jQuery).
The reason the jQ choice seems so obvious to me is that most every widget or validation you want to use already exists there, all you need is to stitch it in. That's why so many designers won't consider using anything else.
I have a fond spot in my heart for both MT and Scriptaculous, but more and more the teams I work with insist on jQuery. At this point, the question needs to be asked and answered: are unique javascripts part of Joomla's "core competency," part of what can differentiate it from the rest of the market? If the answer to that comes back as "Yes", then the right path is to stick with MooTools and start developing all the support scripts sites will need. OTOH, if the answer (as I suspect) is "No," then it's time to bite the bullet and either remove javascript from the framework completely, or make the switch to the 800-lb gorilla that is jQuery.
For example, the Rails framework grew up with Prototype and Scriptaculous, but with version 3 they went library agnostic, and with version 3.1 switched to jQuery being shipped as part of the framework.
As for JForm, Sybrek, don't get me started. I've been swearing at the unreasonable rigidity of JForm's 1.7 incarnation for weeks, now.
To return to the jslib-agnostic idea:
I'm of two minds on it. For one, I like the idea of leaving the js choice up to the developer. The choice of which js library to use isn't made in a vacuum; it's made according to the requirements of the application and the expertise of the application developer(s), neither of which is known at Platform development time, so any choice made there is bound to be suboptimal.
But more and more we're living in an AJAX world, and the ability to function in it requires javascript, and some core functions could productively use that capability. Since Sybrek brought it up I suppose we can use JForm as an example of that:
If the idea of using js to do form validations, etc., in the client is kept in JForm (something I'm not convinced of, but can see an argument for, at least) then make that an optional selection, the developer installs the option while starting to work on the application. An additional advantage of that approach is that one library can easily be dropped in favor of a new one if for some reason the initial selection is found wanting as development progresses (or in future versions of the app, as requirements change). The mechanism for this would need to be developed, of course, making more work for everyone concerned.
There are enough minor differences in how AJAX-y things are handled between libraries, that custom php code is necessary, I think, to pull that off, hence the optional bit.
On Feb 7, 1:11 am, Andrew Eddie <mambob...@gmail.com> wrote: > Another way to look at it is maybe the Joomla Platform should not have > any javascript at all. It's really something the application should > take responsibility for. In that way, it's no big deal for one app to > use Mootools, another jQuery and yet another YUI. I'm leaning more > and more to a state where maybe it's not our (the platform's) problem > to solve.
> On 7 February 2012 01:56, Niels Braczek <nbrac...@bsds.de> wrote:
> > Am 06.02.2012 14:53, schrieb Sybrek:
> >> So is there any concern about the (optional) use of jquery instead > >> of mootools ?
> > after having written a fat client application in JavaScript with Joomla! > > as backend, I really don't know, what the advantage of introducing > > jQuery should be. I've never seen solutions based on jQuery that > > could not be made with MooTools, but I have vice versa.
> > The approach should not be to support jQuery inclusion, but to > > provide a set of widgets, like we do with modal, captions and tabs, > > which are unobtrusive and easy to use.
I have to admit I have a pretty strong dislike for jQuery's syntax, so I'm not the most neutral person in this discussion. But what really worries me is that the whole jQuery vs. MooTools discussion seems to be so centered around the relative popularity instead of technical merit. To exaggerate a bit: Shouldn't we just drop Joomla! development since Wordpress is vastly more popular? (http://w3techs.com/technologies/overview/content_management/all)
I'd much rather discuss technical differences to decide where to go.
Also for those calling to drop MooTools for jQuery, this would involve rewriting all scripts. I wonder who's gonna do that? I offered numerous times to help write a jQuery replacement for JHtmlBehavior that is as compatible as possible to the MooTools one (at least from the PHP side of things). I'd just need help with writing the jQuery scripts since I don't know the library that well and frankly don't wanna do it all by myself. So far no one has agreed - I wonder where all the competent jQuery devs are gonna appear from magically.
> I think mootools is great and it's the JS lib I prefer, but it seems that > jQuery has really won the war. J!3.0 seems the opportune time to bite the > bullet.
The PLT looked at the question of replacing MooTools with JQuery a year or two ago and decided to stay with MooTools. This was based on the technical merits as well as the practical issue that no one has written replacements for the existing Mootools behaviors.
While it is possible that the PLT will change its mind at some point, I am not aware of any movement in this direction. That is why the focus was to allow JQuery and Mootools to work together (which I believe is accomplished).
So, unless (a) someone can articulate a compelling reason to change from Mootools to JQuery and (b) someone writes the behaviors in JQuery, I don't see this changing. My .02. Mark
On Wed, Feb 8, 2012 at 10:15 AM, Rouven Weßling <m...@rouvenwessling.de>wrote:
> I have to admit I have a pretty strong dislike for jQuery's syntax, so I'm > not the most neutral person in this discussion. But what really worries me > is that the whole jQuery vs. MooTools discussion seems to be so centered > around the relative popularity instead of technical merit. To exaggerate a > bit: Shouldn't we just drop Joomla! development since Wordpress is vastly > more popular? ( > http://w3techs.com/technologies/overview/content_management/all)
> I'd much rather discuss technical differences to decide where to go.
> Also for those calling to drop MooTools for jQuery, this would involve > rewriting all scripts. I wonder who's gonna do that? I offered numerous > times to help write a jQuery replacement for JHtmlBehavior that is as > compatible as possible to the MooTools one (at least from the PHP side of > things). I'd just need help with writing the jQuery scripts since I don't > know the library that well and frankly don't wanna do it all by myself. So > far no one has agreed - I wonder where all the competent jQuery devs are > gonna appear from magically.
> Best regards > Rouven
> On 08.02.2012, at 18:28, Gary Glass wrote:
> > +1
> > I think mootools is great and it's the JS lib I prefer, but it seems that > > jQuery has really won the war. J!3.0 seems the opportune time to bite the > > bullet.
I think a good solution will be to add a second JHtmlBehavior class
which uses jquery and maybe can be provided by a system plugin so that
users can choose what they want to use.
Rouven I would give you a helping hand on this, but I`m also not very
good with the jquery stuff, at the moment I only replaced caption,
keepalive and noframes, so only the little ones^^, tooltip is on todo
as the next one.
On Feb 8, 7:15 pm, Rouven Weßling <m...@rouvenwessling.de> wrote:
> I have to admit I have a pretty strong dislike for jQuery's syntax, so I'm not the most neutral person in this discussion. But what really worries me is that the whole jQuery vs. MooTools discussion seems to be so centered around the relative popularity instead of technical merit. To exaggerate a bit: Shouldn't we just drop Joomla! development since Wordpress is vastly more popular? (http://w3techs.com/technologies/overview/content_management/all)
> I'd much rather discuss technical differences to decide where to go.
> Also for those calling to drop MooTools for jQuery, this would involve rewriting all scripts. I wonder who's gonna do that? I offered numerous times to help write a jQuery replacement for JHtmlBehavior that is as compatible as possible to the MooTools one (at least from the PHP side of things). I'd just need help with writing the jQuery scripts since I don't know the library that well and frankly don't wanna do it all by myself. So far no one has agreed - I wonder where all the competent jQuery devs are gonna appear from magically.
> Best regards
> Rouven
> On 08.02.2012, at 18:28, Gary Glass wrote:
> > +1
> > I think mootools is great and it's the JS lib I prefer, but it seems that
> > jQuery has really won the war. J!3.0 seems the opportune time to bite the
> > bullet.
Mark to date we aren't talking about "replacement", just "adding". We all have to remember that the Platform can and will want to cater for more than just the CMS, and just because the Platform is doing something different, doesn't mean the CMS has to follow. However, anyone that thinks that we can just chuck Mootools out and put in jQuery and all our problems go away is sadly mistaken.
For the CMS, I don't see any reason why jQuery can't be added as a disabled plugin (that extension developer can then turn on at install time). Do that and I think a lot of the moaning goes away. It's only a pull request aware and I don't see why it couldn't go into a 2.5 point release.
The Platform, however, is a slightly different matter, but if we go down the road of "adding" another JS library, whatever that is (and I don't think we can escape the popularity of jQuery, but neither can we escape the fact that jQuery is a subset of the features many other richer frameworks offer, and jQuery will eventually "lose" it's popularity contest to something else one day), I think we need to sit back and reinvent our JS anyway and make sure we are using composition where it count so that we can swap out the libraries (usually for fancy display purposes). That probably means going back to fundamentals for the structural wrappers or making so that we can write client side applications in Mootools and you can swap out your "special effects" engine with jQuery, Mootools FX or similar (you aren't going to build a client side MVC in jQuery, but you would do it in Mootools or even, and maybe better, from first principles).
Whether or not you like JForm, I contend that it was a huge step in the right direction when it was implemented (remembering it's changed little since the end of 2009 when it went into the core). But there is no denying JForm will now need further consideration because we need to have more flexibility dealing with the client and server sides aspects separately. I would say we need to working on separating the form as a logical construct on the server, something that displays in the client and then the responsive aspects which include, but are not limited to, client side validation (the logic for which may or may not live on the client). JForm itself is a little off topic, but it's probably a good use case for trying to work out how we deal with the JS issue in the Platform.
> The PLT looked at the question of replacing MooTools with JQuery a year or > two ago and decided to stay with MooTools. This was based on the technical > merits as well as the practical issue that no one has written replacements > for the existing Mootools behaviors.
> While it is possible that the PLT will change its mind at some point, I am > not aware of any movement in this direction. That is why the focus was to > allow JQuery and Mootools to work together (which I believe is > accomplished).
> So, unless (a) someone can articulate a compelling reason to change from > Mootools to JQuery and (b) someone writes the behaviors in JQuery, I don't > see this changing. My .02. Mark
> On Wed, Feb 8, 2012 at 10:15 AM, Rouven Weßling <m...@rouvenwessling.de> > wrote:
>> I have to admit I have a pretty strong dislike for jQuery's syntax, so I'm >> not the most neutral person in this discussion. But what really worries me >> is that the whole jQuery vs. MooTools discussion seems to be so centered >> around the relative popularity instead of technical merit. To exaggerate a >> bit: Shouldn't we just drop Joomla! development since Wordpress is vastly >> more popular? >> (http://w3techs.com/technologies/overview/content_management/all)
>> I'd much rather discuss technical differences to decide where to go.
>> Also for those calling to drop MooTools for jQuery, this would involve >> rewriting all scripts. I wonder who's gonna do that? I offered numerous >> times to help write a jQuery replacement for JHtmlBehavior that is as >> compatible as possible to the MooTools one (at least from the PHP side of >> things). I'd just need help with writing the jQuery scripts since I don't >> know the library that well and frankly don't wanna do it all by myself. So >> far no one has agreed - I wonder where all the competent jQuery devs are >> gonna appear from magically.
>> Best regards >> Rouven
>> On 08.02.2012, at 18:28, Gary Glass wrote:
>> > +1
>> > I think mootools is great and it's the JS lib I prefer, but it seems >> > that >> > jQuery has really won the war. J!3.0 seems the opportune time to bite >> > the >> > bullet.
I agree with Andrew that the on the platform level, this need more thought and perhaps js-agnostic is the best option for now.
But for the CMS, jquery is pretty much as must. If we ship the CMS with jquery plugin (disabled by default maybe), it will do a lot of good. Absolutely nothing bad will come out of it. The only possible outcome is happy users and happy developers!
i'm see this matter as joomla developer on entry level..
I think there's lot of issue that can happen on early days of most
joomla developers that related to mootols-jquery conflict...
- using $ instead of jQuery (or something else)
- forget to use .noConflict()
- 3rd party extension load jquery framework multiple time (and
sometime with many different version as well) even many 3rd party
template framework (or club) give option to load jQuery.
Can you see how much mess by having jQuery not in the core of joomla ?
if you talk as experience joomla developer, you can easily think
'mootools vs jquery' thing is not really a big deal..
but if you see this matter with passion or spirit : "Joomla for
everyone" , this really does matter.
I found many 3rd party extension is not experience joomla developer as
well, many time i have to tweak the code. Fortunately i understand
enough to use jQuery and Mootools altogether.
But many joomla user is not like us, there are small companies,
blogger, internet marketer that use joomla as is .. and they really
depend on 3rd party extension.
i'm still hoping joomla will have jquery on its core or hopefully we
can have option wheter to use jquery or mootols as core js
framework... it would be a great feature..
just my 2 cents
On Feb 18, 8:03 am, Azrul Rahim <write...@azrul.com> wrote:
> I agree with Andrew that the on the platform level, this need more thought and perhaps js-agnostic is the best option for now.
> But for the CMS,jqueryis pretty much as must. If we ship the CMS withjqueryplugin (disabled by default maybe), it will do a lot of good. Absolutely nothing bad will come out of it. The only possible outcome is happy users and happy developers!
> i'm still hoping joomla will have jquery on its core or hopefully we > can have option wheter to use jquery or mootols as core js > framework... it would be a great feature..
I really hope not. As an extension developer, I'd have to provide alternative JS code for MooTools and jQuery (and Dojo and Prototype and ...) to make it able to run together with other components on the same installation. I would have to do so, because the sitebuilder would decide, which framework to use, and that decision would depend on the poorest (least flexible) extension used. This will end with making sitebuilding a horror.
Let developers rely on Joomla supporting MooTools. If some developer decide not to follow that, he has the problem to integrate his additional library. And I think, that's absolute ok.
> I know, it's always the same question, but should we not prefer one of
> these libraries ?
> For quite some time, i read a lot stuff about "best way to integrate jquery
> and prevent the problem of different versions"
> and i seriously don't understand the discussion. It shouldn't be difficult
> to add a sort of "version" to the scripts array we use to avoid duplicated
> entries.
> I think the main question should be if we want to use jquery or mootools in
> core, which also will show our prefernces.
> Mootools is a great (and real) JS framework, but since most of the
> extensions are using jquery i thought that we should see that
> as a wake-up call. The community wants to use jquery.
> So is there any concern about the (optional) use of jquery instead of
> mootools ?
Yep, and the justification pretty much boils down to "personal
preference." You'll find that written all over the document (check for
example, the section on chaining). He's a MooTools framework
developer, so while he tried very hard to be objective, it can't be
seen as a surprise he personally prefers the MT way of doing things,
and finds it easier to understand. I daresay Andrew finds it far
easier to understand the process of writing a Joomla component than,
say, a Zend developer who simply takes a look at the Joomla API.
For myself, having worked extensively in both jQuery and MooTools, I
find that if you're going to use AJAX to make modifications to the
existing DOM tree, rather than going back to fetch complete pages, jQ
is better than MT, because jQ has a way to link event handlers to DOM
elements that don't exist at the moment, while with MT you need to
reattach the event handlers if you replace an element via AJAX (at
least, that was what I had to do, if MT can do it, I couldn't see
how).
It's also easier to use jQ to validate forms, because it has extensive
form validation plugins that work automagically with forms (or would
be easy, if JForm weren't so stubborn about refusing to let you use
perfectly valid form field attributes -- they work perfectly with non-
JForm forms).
Bottom line, MooTools works quite well, and so does jQuery. Most
things to do with the DOM jQ does more cleanly and easily than MT, but
MT works better in situations where you want to use classical
programming techniques. This attracts some developers, and repels most
designers, vice versa for jQuery. So you pays your money and takes
your choice.
That's the reason I favored including neither. It's a choice based
more on personal taste than any objective technical merit, and choices
like that should be left to the site builder. When you mandate one
over the other, you add a "tax" on everyone whose taste run
differently.
On Feb 26, 7:11 pm, Miguel Tuyaré <migueltuy...@gmail.com> wrote:
> On 6 feb, 10:53, Sybrek <i...@nils-rueckmann.de> wrote:
> > I know, it's always the same question, but should we not prefer one of
> > these libraries ?
> > For quite some time, i read a lot stuff about "best way to integrate jquery
> > and prevent the problem of different versions"
> > and i seriously don't understand the discussion. It shouldn't be difficult
> > to add a sort of "version" to the scripts array we use to avoid duplicated
> > entries.
> > I think the main question should be if we want to use jquery or mootools in
> > core, which also will show our prefernces.
> > Mootools is a great (and real) JS framework, but since most of the
> > extensions are using jquery i thought that we should see that
> > as a wake-up call. The community wants to use jquery.
> > So is there any concern about the (optional) use of jquery instead of
> > mootools ?
> For myself, having worked extensively in both jQuery and MooTools, I > find that if you're going to use AJAX to make modifications to the > existing DOM tree, rather than going back to fetch complete pages, jQ > is better than MT, because jQ has a way to link event handlers to DOM > elements that don't exist at the moment, while with MT you need to > reattach the event handlers if you replace an element via AJAX (at > least, that was what I had to do, if MT can do it, I couldn't see > how).
MooTools has Event Delegation for that purpose.
> It's also easier to use jQ to validate forms, because it has extensive > form validation plugins that work automagically with forms
Client-side validation has to be provided from JForm (its renderer), because (only) there the requirements for a specific field are known. It can't do that, if the chosen JS libray is unknown. I'm pretty sure, that there never will be support for all possible libraries in the core.
> That's the reason I favored including neither. It's a choice based > more on personal taste than any objective technical merit, and choices > like that should be left to the site builder. When you mandate one > over the other, you add a "tax" on everyone whose taste run > differently.
In consequence, no extension can support any JS library. The current situation is: "If you need JS enhancement, use MooTools. If you want to use another library. you're responsible for it." This is IMO the right approach, so no change is needed from what we have now.
> For myself, having worked extensively in both jQuery and MooTools, I > find that if you're going to use AJAX to make modifications to the > existing DOM tree, rather than going back to fetch complete pages, jQ > is better than MT, because jQ has a way to link event handlers to DOM > elements that don't exist at the moment, while with MT you need to > reattach the event handlers if you replace an element via AJAX (at > least, that was what I had to do, if MT can do it, I couldn't see > how).
Thank you for bringing this up. I think this is the first time someone actually tried to bring this discussion to be about technical merits instead of preference or popularity. As Niels pointed out you probably mean event delegation which is available in MooTools as well (core since 1.4, earlier it was in more which is why you might have missed it)
> It's also easier to use jQ to validate forms, because it has extensive > form validation plugins that work automagically with forms (or would > be easy, if JForm weren't so stubborn about refusing to let you use > perfectly valid form field attributes -- they work perfectly with non- > JForm forms).
I never used the MooTools form validation utility and I couldn't find any documentation about form validation in jQuery (are you sure its not a plug-in?) but neither really matters to us since we roll our own form validator that is (more or less) integrated with JForm. I'd actually like to rip that one out and replace it with a validator based on the new HTML5 form features but since we're still supporting IE7-9 (which have no support whatsoever for the new form features) we'd need fallback code for everything - a lot of work.
> Bottom line, MooTools works quite well, and so does jQuery. Most > things to do with the DOM jQ does more cleanly and easily than MT, but > MT works better in situations where you want to use classical > programming techniques. This attracts some developers, and repels most > designers, vice versa for jQuery. So you pays your money and takes > your choice.
jQuery certainly has the better documentation, more tutorials and right now the greater mindshare. But so has Wordpress. I think that MooTools has the better system because it still "feels like JavaScript" but allows me to use classes. Then again I'm obviously not a designer.
> That's the reason I favored including neither. It's a choice based > more on personal taste than any objective technical merit, and choices > like that should be left to the site builder. When you mandate one > over the other, you add a "tax" on everyone whose taste run > differently.
That's not really possible anymore today. If we included neither we'd probably have our own (much worse) custom library sooner or later. Both provide a level of abstraction and compatibility with older browsers (*cough* IE *cough*) that's very hard to do with vanilla JavaScript. Of course we could just stop using JS at all in Joomla, but do you really want that?
Also what do you expect from extension developers? Write JS for both frameworks? Use no JS?
What we should strive to is make it possible to run the frontend with other framework. As far as I know that's why the behaviors system has been developed, it abstracts (some) of the JS away from implementations and allows extension to require a certain behavior (keepalive, modals) without relying on what JS lies behind it. Unfortunately I know of no one from the community who has run with the idea and created a jQuery behavior.
On Feb 27, 12:17 pm, Niels Braczek <nbrac...@bsds.de> wrote:
> Am 27.02.2012 18:58, schrieb Paladin:
> > For myself, having worked extensively in both jQuery and MooTools, I
> > find that if you're going to use AJAX to make modifications to the
> > existing DOM tree, rather than going back to fetch complete pages, jQ
> > is better than MT, because jQ has a way to link event handlers to DOM
> > elements that don't exist at the moment, while with MT you need to
> > reattach the event handlers if you replace an element via AJAX (at
> > least, that was what I had to do, if MT can do it, I couldn't see
> > how).
> MooTools has Event Delegation for that purpose.
Cool. Hadn't found that, but then it wasn't in the Joomla MooTools
until about a year after I was looking for it, so that's probably why
I didn't find it.
> > It's also easier to use jQ to validate forms, because it has extensive
> > form validation plugins that work automagically with forms
> Client-side validation has to be provided from JForm (its renderer),
> because (only) there the requirements for a specific field are known. It
> can't do that, if the chosen JS libray is unknown. I'm pretty sure, that
> there never will be support for all possible libraries in the core.
You're not understanding me. If JForm and the assorted field classes
would let me create and output the attributes valid for that
particular field, *any* js library could validate the fields, without
interference or assistance from JForm, et al. In fact, in many cases
today the browser's built-in field validation logic would work, and
for them I wouldn't need javascript at all. But since it blocks me
from using all but a select portion of the valid field attributes, it
not only doesn't know how to trigger the form validation in other
libraries, it actively *prevents* me from using it. In this case in
particular, it can't be said that joomla allows you to use whatever
library you want to use.
(And yes, Rouven, I said the jQ form validations were plug-ins. There
are several, you can choose which one you want to use based on your
needs and preferences, but they all work well. Again, I think this is
a choice best left to the site builder, because they know their
particular use case and audience better than anyone else does.)
> The current
> situation is: "If you need JS enhancement, use MooTools. If you want to
> use another library. you're responsible for it."
No, it's "if you want to use jQuery, tough, you you can't use it to do
form validation so you'll have to load all of MooTools as well, even
though you're not going to use it for any other purpose." And even "If
you actually want to take advantage of the capabilities built into
some of your visitor's browsers, we're not going to let you."
> If JForm and the assorted field classes > would let me create and output the attributes valid for that > particular field, *any* js library could validate the fields, without > interference or assistance from JForm, et al.
JForm (+ field classes) in conjunction with the (XHTML, HTML5, PDF, ...) renderer is responsible for (triggers for) validation, server-side and client-side. If it doesn't do that right, its a bug or a missing feature and ought to be corrected.
> In fact, in many cases > today the browser's built-in field validation logic would work, and > for them I wouldn't need javascript at all. But since it blocks me > from using all but a select portion of the valid field attributes, it > not only doesn't know how to trigger the form validation in other > libraries, it actively *prevents* me from using it.
You won't solve this by including jQuery into the core.
I believe it's a little more clear today that flexibility is best achieved by keeping the JS/CSS with the template and making certain the HTML markup is simple and standard.
So, in response to your question if the core should use JS, or not, the best approach, IMO, is to create a javascript-agnostic core, fully functional, and then leave it to the frontend developers to decide how to craft the presentation layer shared in the core distribution. That should also make it very easy to swap out by users.
I personally believe the whole "which JS framework is better" debate is divisive and counterproductive. We all know that there is no authoritative answer to that question, nor is there any way that the Joomla project can force all people to only use a specific choice with the CMS.
Whether we like it or not, learning to work around the technical conflicts that result from the amazing choices available today is simply part of what an open source project must do to be successful. IMO, it will be important to be careful in the future with how the JS is used to make certain not to tie the presentation layer unnecessarily to the view and layout HTML.
On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
> I know, it's always the same question, but should we not prefer one of > these libraries ?
> For quite some time, i read a lot stuff about "best way to integrate > jquery and prevent the problem of different versions" > and i seriously don't understand the discussion. It shouldn't be difficult > to add a sort of "version" to the scripts array we use to avoid duplicated > entries.
> I think the main question should be if we want to use jquery or mootools > in core, which also will show our prefernces.
> Mootools is a great (and real) JS framework, but since most of the > extensions are using jquery i thought that we should see that
> as a wake-up call. The community wants to use jquery.
> So is there any concern about the (optional) use of jquery instead of > mootools ?
On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
> I know, it's always the same question, but should we not prefer one of > these libraries ?
> For quite some time, i read a lot stuff about "best way to integrate > jquery and prevent the problem of different versions" > and i seriously don't understand the discussion. It shouldn't be difficult > to add a sort of "version" to the scripts array we use to avoid duplicated > entries.
> I think the main question should be if we want to use jquery or mootools > in core, which also will show our prefernces.
> Mootools is a great (and real) JS framework, but since most of the > extensions are using jquery i thought that we should see that
> as a wake-up call. The community wants to use jquery.
> So is there any concern about the (optional) use of jquery instead of > mootools ?
On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
> I know, it's always the same question, but should we not prefer one of > these libraries ?
> For quite some time, i read a lot stuff about "best way to integrate > jquery and prevent the problem of different versions" > and i seriously don't understand the discussion. It shouldn't be difficult > to add a sort of "version" to the scripts array we use to avoid duplicated > entries.
> I think the main question should be if we want to use jquery or mootools > in core, which also will show our prefernces.
> Mootools is a great (and real) JS framework, but since most of the > extensions are using jquery i thought that we should see that
> as a wake-up call. The community wants to use jquery.
> So is there any concern about the (optional) use of jquery instead of > mootools ?
On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
> I know, it's always the same question, but should we not prefer one of > these libraries ?
> For quite some time, i read a lot stuff about "best way to integrate > jquery and prevent the problem of different versions" > and i seriously don't understand the discussion. It shouldn't be difficult > to add a sort of "version" to the scripts array we use to avoid duplicated > entries.
> I think the main question should be if we want to use jquery or mootools > in core, which also will show our prefernces.
> Mootools is a great (and real) JS framework, but since most of the > extensions are using jquery i thought that we should see that
> as a wake-up call. The community wants to use jquery.
> So is there any concern about the (optional) use of jquery instead of > mootools ?
On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
> I know, it's always the same question, but should we not prefer one of > these libraries ?
> For quite some time, i read a lot stuff about "best way to integrate > jquery and prevent the problem of different versions" > and i seriously don't understand the discussion. It shouldn't be difficult > to add a sort of "version" to the scripts array we use to avoid duplicated > entries.
> I think the main question should be if we want to use jquery or mootools > in core, which also will show our prefernces.
> Mootools is a great (and real) JS framework, but since most of the > extensions are using jquery i thought that we should see that
> as a wake-up call. The community wants to use jquery.
> So is there any concern about the (optional) use of jquery instead of > mootools ?
On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
> I know, it's always the same question, but should we not prefer one of > these libraries ?
> For quite some time, i read a lot stuff about "best way to integrate > jquery and prevent the problem of different versions" > and i seriously don't understand the discussion. It shouldn't be difficult > to add a sort of "version" to the scripts array we use to avoid duplicated > entries.
> I think the main question should be if we want to use jquery or mootools > in core, which also will show our prefernces.
> Mootools is a great (and real) JS framework, but since most of the > extensions are using jquery i thought that we should see that
> as a wake-up call. The community wants to use jquery.
> So is there any concern about the (optional) use of jquery instead of > mootools ?
On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
> I know, it's always the same question, but should we not prefer one of > these libraries ?
> For quite some time, i read a lot stuff about "best way to integrate > jquery and prevent the problem of different versions" > and i seriously don't understand the discussion. It shouldn't be difficult > to add a sort of "version" to the scripts array we use to avoid duplicated > entries.
> I think the main question should be if we want to use jquery or mootools > in core, which also will show our prefernces.
> Mootools is a great (and real) JS framework, but since most of the > extensions are using jquery i thought that we should see that
> as a wake-up call. The community wants to use jquery.
> So is there any concern about the (optional) use of jquery instead of > mootools ?
On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
> I know, it's always the same question, but should we not prefer one of > these libraries ?
> For quite some time, i read a lot stuff about "best way to integrate > jquery and prevent the problem of different versions" > and i seriously don't understand the discussion. It shouldn't be difficult > to add a sort of "version" to the scripts array we use to avoid duplicated > entries.
> I think the main question should be if we want to use jquery or mootools > in core, which also will show our prefernces.
> Mootools is a great (and real) JS framework, but since most of the > extensions are using jquery i thought that we should see that
> as a wake-up call. The community wants to use jquery.
> So is there any concern about the (optional) use of jquery instead of > mootools ?
On Tue, Feb 28, 2012 at 1:08 PM, Amy Stephen <amystep...@gmail.com> wrote: > Rouven -
> I believe it's a little more clear today that flexibility is best achieved > by keeping the JS/CSS with the template and making certain the HTML markup > is simple and standard.
> So, in response to your question if the core should use JS, or not, the > best approach, IMO, is to create a javascript-agnostic core, fully > functional, and then leave it to the frontend developers to decide how to > craft the presentation layer shared in the core distribution. That should > also make it very easy to swap out by users.
> I personally believe the whole "which JS framework is better" debate is > divisive and counterproductive. We all know that there is no authoritative > answer to that question, nor is there any way that the Joomla project can > force all people to only use a specific choice with the CMS.
> Whether we like it or not, learning to work around the technical conflicts > that result from the amazing choices available today is simply part of what > an open source project must do to be successful. IMO, it will be important > to be careful in the future with how the JS is used to make certain not to > tie the presentation layer unnecessarily to the view and layout HTML.
> My 2 cents.
> On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
>> I know, it's always the same question, but should we not prefer one of >> these libraries ? >> For quite some time, i read a lot stuff about "best way to integrate >> jquery and prevent the problem of different versions" >> and i seriously don't understand the discussion. It shouldn't be >> difficult to add a sort of "version" to the scripts array we use to avoid >> duplicated entries.
>> I think the main question should be if we want to use jquery or mootools >> in core, which also will show our prefernces.
>> Mootools is a great (and real) JS framework, but since most of the >> extensions are using jquery i thought that we should see that >> as a wake-up call. The community wants to use jquery.
>> So is there any concern about the (optional) use of jquery instead of >> mootools ?
> On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
>> I know, it's always the same question, but should we not prefer one of >> these libraries ? >> For quite some time, i read a lot stuff about "best way to integrate >> jquery and prevent the problem of different versions" >> and i seriously don't understand the discussion. It shouldn't be >> difficult to add a sort of "version" to the scripts array we use to avoid >> duplicated entries.
>> I think the main question should be if we want to use jquery or mootools >> in core, which also will show our prefernces.
>> Mootools is a great (and real) JS framework, but since most of the >> extensions are using jquery i thought that we should see that >> as a wake-up call. The community wants to use jquery.
>> So is there any concern about the (optional) use of jquery instead of >> mootools ?
> On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
>> I know, it's always the same question, but should we not prefer one of >> these libraries ? >> For quite some time, i read a lot stuff about "best way to integrate >> jquery and prevent the problem of different versions" >> and i seriously don't understand the discussion. It shouldn't be >> difficult to add a sort of "version" to the scripts array we use to avoid >> duplicated entries.
>> I think the main question should be if we want to use jquery or mootools >> in core, which also will show our prefernces.
>> Mootools is a great (and real) JS framework, but since most of the >> extensions are using jquery i thought that we should see that >> as a wake-up call. The community wants to use jquery.
>> So is there any concern about the (optional) use of jquery instead of >> mootools ?
> On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
>> I know, it's always the same question, but should we not prefer one of >> these libraries ? >> For quite some time, i read a lot stuff about "best way to integrate >> jquery and prevent the problem of different versions" >> and i seriously don't understand the discussion. It shouldn't be >> difficult to add a sort of "version" to the scripts array we use to avoid >> duplicated entries.
>> I think the main question should be if we want to use jquery or mootools >> in core, which also will show our prefernces.
>> Mootools is a great (and real) JS framework, but since most of the >> extensions are using jquery i thought that we should see that >> as a wake-up call. The community wants to use jquery.
>> So is there any concern about the (optional) use of jquery instead of >> mootools ?
> On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
>> I know, it's always the same question, but should we not prefer one of >> these libraries ? >> For quite some time, i read a lot stuff about "best way to integrate >> jquery and prevent the problem of different versions" >> and i seriously don't understand the discussion. It shouldn't be >> difficult to add a sort of "version" to the scripts array we use to avoid >> duplicated entries.
>> I think the main question should be if we want to use jquery or mootools >> in core, which also will show our prefernces.
>> Mootools is a great (and real) JS framework, but since most of the >> extensions are using jquery i thought that we should see that >> as a wake-up call. The community wants to use jquery.
>> So is there any concern about the (optional) use of jquery instead of >> mootools ?
> On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
>> I know, it's always the same question, but should we not prefer one of >> these libraries ? >> For quite some time, i read a lot stuff about "best way to integrate >> jquery and prevent the problem of different versions" >> and i seriously don't understand the discussion. It shouldn't be >> difficult to add a sort of "version" to the scripts array we use to avoid >> duplicated entries.
>> I think the main question should be if we want to use jquery or mootools >> in core, which also will show our prefernces.
>> Mootools is a great (and real) JS framework, but since most of the >> extensions are using jquery i thought that we should see that >> as a wake-up call. The community wants to use jquery.
>> So is there any concern about the (optional) use of jquery instead of >> mootools ?
> On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
>> I know, it's always the same question, but should we not prefer one of >> these libraries ? >> For quite some time, i read a lot stuff about "best way to integrate >> jquery and prevent the problem of different versions" >> and i seriously don't understand the discussion. It shouldn't be >> difficult to add a sort of "version" to the scripts array we use to avoid >> duplicated entries.
>> I think the main question should be if we want to use jquery or mootools >> in core, which also will show our prefernces.
>> Mootools is a great (and real) JS framework, but since most of the >> extensions are using jquery i thought that we should see that >> as a wake-up call. The community wants to use jquery.
>> So is there any concern about the (optional) use of jquery instead of >> mootools ?
> On Monday, February 6, 2012 7:53:35 AM UTC-6, Nils Rückmann wrote:
>> I know, it's always the same question, but should we not prefer one of >> these libraries ? >> For quite some time, i read a lot stuff about "best way to integrate >> jquery and prevent the problem of different versions" >> and i seriously don't understand the discussion. It shouldn't be >> difficult to add a sort of "version" to the scripts array we use to avoid >> duplicated entries.
>> I think the main question should be if we want to use jquery or mootools >> in core, which also will show our prefernces.
>> Mootools is a great (and real) JS framework, but since most of the >> extensions are using jquery i thought that we should see that >> as a wake-up call. The community wants to use jquery.
>> So is there any concern about the (optional) use of jquery instead of >> mootools ?
