Never ending story: Jquery vs mootools

2661 views
Skip to first unread message

Sybrek

unread,
Feb 6, 2012, 8:53:35 AM2/6/12
to joomla-de...@googlegroups.com
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 ?
 

Niels Braczek

unread,
Feb 6, 2012, 10:56:45 AM2/6/12
to joomla-de...@googlegroups.com
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.

Just my 2 cents.

Regards,
Niels

--
| http://barcamp-wk.de · 1. Barcamp Westküste 2./3. März 2012 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

Andrew Eddie

unread,
Feb 7, 2012, 2:11:10 AM2/7/12
to joomla-de...@googlegroups.com
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.

Just throwing it out there…

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.7 developers

Sybrek

unread,
Feb 7, 2012, 2:44:46 AM2/7/12
to joomla-de...@googlegroups.com
As long as things like JForms (validation) and JHtml (especially calendar, etc) are part of the plattform, there is no way to move out javascript.

Paladin

unread,
Feb 8, 2012, 12:03:15 PM2/8/12
to Joomla! Platform Development
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.
>
> Just throwing it out there…
>
> Regards,
> Andrew Eddiehttp://learn.theartofjoomla.com- training videos for Joomla 1.7 developers

Gary Glass

unread,
Feb 8, 2012, 12:28:41 PM2/8/12
to joomla-de...@googlegroups.com
+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.

See: http://w3techs.com/technologies/overview/javascript_library/all

jQuery has an 85% share. Mootools is a very distant 2nd place with just 10%.

______________________________
Gary Glass
http://ShutterGlass.com
http://OnlyBegotten.com

Rouven Weßling

unread,
Feb 8, 2012, 1:15:18 PM2/8/12
to joomla-de...@googlegroups.com
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

Mark Dexter

unread,
Feb 8, 2012, 1:36:54 PM2/8/12
to joomla-de...@googlegroups.com
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

RedEye

unread,
Feb 8, 2012, 3:44:28 PM2/8/12
to Joomla! Platform Development
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.

Andrew Eddie

unread,
Feb 8, 2012, 5:51:00 PM2/8/12
to joomla-de...@googlegroups.com
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.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 2.5 developers

Elin Waring

unread,
Feb 9, 2012, 8:33:24 AM2/9/12
to joomla-de...@googlegroups.com
Have people tested the proposed plugin from Rafael? 


 
Elin



Ofer Cohen

unread,
Feb 11, 2012, 5:36:18 AM2/11/12
to joomla-de...@googlegroups.com

Elin,

Is there any tracker for this?

Ofer Cohen
Joomlics Anonymous Group

Elin Waring

unread,
Feb 11, 2012, 7:29:47 AM2/11/12
to joomla-de...@googlegroups.com

Azrul Rahim

unread,
Feb 17, 2012, 8:03:06 PM2/17/12
to joomla-de...@googlegroups.com
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!

Viktor Iwan

unread,
Feb 26, 2012, 1:40:48 PM2/26/12
to Joomla! Platform Development
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!

Niels Braczek

unread,
Feb 26, 2012, 5:46:34 PM2/26/12
to joomla-de...@googlegroups.com
Am 26.02.2012 19:40, schrieb Viktor Iwan:

> 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.

Regards,
Niels

--
| http://barcamp-wk.de · 1. Barcamp Westküste 30./31. März 2012 |

Miguel Tuyaré

unread,
Feb 26, 2012, 8:11:56 PM2/26/12
to Joomla! Platform Development
Hi,
This is a good article that justifies the use of Mootools, I'm no
expert in the area, but ....
http://jqueryvsmootools.com/index.html
in Github:
https://github.com/anutron/jquery-vs-mootools

Paladin

unread,
Feb 27, 2012, 12:58:55 PM2/27/12
to Joomla! Platform Development
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:
> Hi,
> This is a good article that justifies the use of Mootools, I'm no
> expert in the area, but ....http://jqueryvsmootools.com/index.html

Niels Braczek

unread,
Feb 27, 2012, 1:17:12 PM2/27/12
to joomla-de...@googlegroups.com
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.

> 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.

Rouven Weßling

unread,
Feb 27, 2012, 6:27:56 PM2/27/12
to joomla-de...@googlegroups.com

On 27.02.2012, at 18:58, Paladin wrote:

> 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.

Best regards
Rouven

Paladin

unread,
Feb 28, 2012, 11:25:10 AM2/28/12
to Joomla! Platform Development


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."

Niels Braczek

unread,
Feb 28, 2012, 12:39:15 PM2/28/12
to joomla-de...@googlegroups.com
Am 28.02.2012 17:25, schrieb Paladin:

> 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.

Amy Stephen

unread,
Feb 28, 2012, 1:08:42 PM2/28/12
to joomla-de...@googlegroups.com, AmySt...@gmail.com
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.

With that approach, one simply has to change a module class suffix to switch between Twitter Bootstrap for their tabs -- http://foundation.zurb.com/ and a Mootools option. http://net.tutsplus.com/tutorials/javascript-ajax/sexy-animated-tabs-using-mootools/

IMO, the inflexibility today came from combining those elements unnecessarily into the JHTML element, for example with the sliders - https://github.com/joomla/joomla-platform/blob/staging/libraries/joomla/html/html/sliders.php#L62

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.

Paladin

unread,
Feb 28, 2012, 1:49:56 PM2/28/12
to Joomla! Platform Development


On Feb 28, 11:39 am, Niels Braczek <nbrac...@bsds.de> wrote:
>
> You won't solve this by including jQuery into the core.

Perfectly correct, which is one reason why my stated preference wasn't
to do that. I was the guy who said "no js framework", remember?

Matt Thomas

unread,
Feb 28, 2012, 1:57:58 PM2/28/12
to joomla-de...@googlegroups.com
Couldn't agree more Amy!

Best,

Matt Thomas
Founder betweenbrain
Phone: 203.632.9322
Twitter: @betweenbrain

Niels Braczek

unread,
Feb 28, 2012, 2:16:05 PM2/28/12
to joomla-de...@googlegroups.com

"No JS framework" wouldn't solve your issue as well. Your issue is with
how JForm works, not the JS library.

CirTap

unread,
Feb 28, 2012, 2:28:25 PM2/28/12
to joomla-de...@googlegroups.com
+1 and thank you, Amy.

> I personally believe the whole "which JS framework is better" debate is
> divisive and counterproductive.

... and more often than not has the charme of a religous debate where
each party tries hard to evangelize their beliefs and nothing but beliefs.

And 3 times KOTAU to Sam who happens to be the only other person
presenting us a neutral POV.

Keep on going, folks.
It's fun and entertaining to see this again going nowhere...

CirTap

CirTap

unread,
Feb 28, 2012, 2:47:01 PM2/28/12
to joomla-de...@googlegroups.com

>>>
>>> You won't solve this by including jQuery into the core.
>>
>> Perfectly correct, which is one reason why my stated preference wasn't
>> to do that. I was the guy who said "no js framework", remember?
>
> "No JS framework" wouldn't solve your issue as well. Your issue is with
> how JForm works, not the JS library.

I don't think it's *the* issue, but just *one* that sticks out.

Like JDocument prevents me from adding useful attributes to get more
control over any external JS file if I rely on the "official" API to add
a script.

And yes, I do have a patch to solve this - for my needs -, but I'm also
utterly reluctant to go through the current process called "pull
request"... yet.

CirTap

Paladin

unread,
Feb 28, 2012, 2:52:02 PM2/28/12
to Joomla! Platform Development


On Feb 28, 11:39 am, Niels Braczek <nbrac...@bsds.de> wrote:
>> 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.

Sorry for the delay, I wanted to go back and double-check, just to be
sure. There is no html5 renderer for form fields. They only render as
xhtml, and the attributes they allow are hard-coded in the PHP (ex:
text.php::getInput()).

Rouven Weßling

unread,
Feb 28, 2012, 3:55:04 PM2/28/12
to joomla-de...@googlegroups.com
Answers to quite a few different E-Mails here. You guys were busy while I was away ;)

On 28.02.2012, at 17:25, Paladin wrote:

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.

Are you talking about HTML5 validation? Because otherwise I don't quite understand how you wanna tell a validator "this is a username" without a convention. The convention in Joomla is to indicate it trough the class validate-username. Same for email, and others.

(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.)

Sorry, I misread. Could you point me to one or two you like? I reading up on form validation a bit right now and would like to look at some other scripts out there (no promise any code will come out of it thou).


On 28.02.2012, at 19:08, Amy Stephen wrote:

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. 

With that approach, one simply has to change a module class suffix to switch between Twitter Bootstrap for their tabs --http://foundation.zurb.com/ and a Mootools option. http://net.tutsplus.com/tutorials/javascript-ajax/sexy-animated-tabs-using-mootools/

In theory that's the perfect solution. There are two caveats:
-Most popular JS plug-ins depend on certain classes/id/elements. Bootstrap is actually a pretty good example of that. I recently changed my website to use Bootstrap (I'm no designer, it looks pretty - but just like any other bootstrap page), I used MooTools ports of the bootstrap script (I'm only using one) and had to create a view layout overrides to make things match bootstrap. Now think about something more complex like modals which you can configure quite a bit trough the rel attribute, you'll never find a second script that's just a drop in replacement for Squeezebox. You can however write a compatible one with any framework you like.
-We kinda already offer that - not prefect thou - the HTML behaviors were, from my understanding, designed to make it easier to use other frameworks with Joomla. You just add JHtml::_('behavior.keepalive'); to your layout and you get the keep alive behavior and you don't have to care about how it is implemented JS wise. There are limitations to this, some things are not replaced by this approach (strengthmeter in JFormFieldPassword, lots of things in JHtml) but these are rarely used in the frontend. The bigger issue is that no one has stepped up and actually provided behaviors for another framework.


On 28.02.2012, at 20:47, CirTap wrote:

Like JDocument prevents me from adding useful attributes to get more
control over any external JS file if I rely on the "official" API to add
a script.

What attributes are you missing?

And yes, I do have a patch to solve this - for my needs -, but I'm also
utterly reluctant to go through the current process called "pull
request"... yet.

Pull requests are now very common in open source development but if there's a way you think the process can be improved speak out.


On 28.02.2012, at 20:52, Paladin wrote:

Sorry for the delay, I wanted to go back and double-check, just to be
sure. There is no html5 renderer for form fields. They only render as
xhtml, and the attributes they allow are hard-coded in the PHP (ex:
text.php::getInput()).

Correct. I just recently added some HTML5 support to JDocument so we can get the new <meta charset=""> element.

The issue with HTML5 support is that we have to make up our minds (both CMS and Platform) what kind of output we want to support. Currently we're pretty much in XHTML1 land (despite a few HTML5 templates). Would we be happy to just support HTML5? That's easy, writing a patch to significantly improve JForm with HTML5 goodness in that case is a matter of a few hours. Or do we want to support both XHTML1 and HTML5 output? That isn't so easy anymore for JForm.

Best regards
Rouven

CirTap

unread,
Feb 28, 2012, 4:51:33 PM2/28/12
to joomla-de...@googlegroups.com
> The bigger issue is that no one has stepped up and actually provided
> behaviors for another framework.

maybe because of debates like this? ;)

>> Like JDocument prevents me from adding useful attributes to get more
>> control over any external JS file if I rely on the "official" API to add
>> a script.
>
> What attributes are you missing?

wrong question.
Why was it limited to async and defer in the first place?
Any HTML standard since 1996 allows for more.
Same for <link> just slightly different, and "custom" just ain't the
right way, imho.
However, that's all up for a different discussion -- if ever.

>> And yes, I do have a patch to solve this - for my needs -, but I'm also
>> utterly reluctant to go through the current process called "pull
>> request"... yet.
>
>
> Pull requests are now very common in open source development but if there's
> a way you think the process can be improved speak out.

There's nothing wrong with pull requests per se. I do push, pull, and
commit all over the place, and for the most part it can even be fun.
I wrote "yet" and that means "not now" -- nor in the very near future, fwiw.

CirTap

Andy Nagai

unread,
Feb 28, 2012, 4:17:37 PM2/28/12
to joomla-de...@googlegroups.com
just wondering. Is mootools upgradeable now in the latest platform? It
is not tied to a specific version of mootools, right? This was the
only reason why we used jquery in !J 1.5.11. It had some features that
made manipulations alot easier then mootools 1.1. This was just for in
house development.

Jonathan Seni

unread,
Feb 28, 2012, 4:30:37 PM2/28/12
to joomla-de...@googlegroups.com
The reason why I choose Joomla over Drupal was Mootools. I'll be sad if that goes away.

Also, using popularity as the signal, I think we should all move to Wordpress then as it is more popular than Joomla.

--
Jonathan Seni.

There are 10 kinds of people in this world,
Those who knows numbers, and
Those who wait for the other 8 people to be listed
----------------------------------------------------

SimplyMepis, SuSE 9.2, openSuSE 10.2 /10.3/11.0/11.1/11.2 /11.3/11.4(x86-64).

Andrew Eddie

unread,
Feb 28, 2012, 5:09:20 PM2/28/12
to joomla-de...@googlegroups.com
On 29 February 2012 04:08, Amy Stephen <amyst...@gmail.com> wrote:
>
> 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.

+1

Something big is definitely going to happen in 2012 one way or the
other if I'm agreeing with you ;)

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

Rouven Weßling

unread,
Feb 28, 2012, 5:17:16 PM2/28/12
to joomla-de...@googlegroups.com
On 28.02.2012, at 22:51, CirTap wrote:

The bigger issue is that no one has stepped up and actually provided 
behaviors for another framework.

maybe because of debates like this? ;)

Who says those behaviors have to ship with the CMS from the beginning or event at all? They could just be a plug-in overriding JHtmlBeahvior and - IMO - would give the whole "jQuery into core" dicussion much more benefit.

wrong question.
Why was it limited to async and defer in the first place?
Any HTML standard since 1996 allows for more.

Because I cared about those two and thus I added them. The script element doesn't allow that many attributes, the only non global attribute were missing is charset. Most of the global ones are not very useful in in elements added to the HEAD. So I'd actually be curios what you're missing.

Same for <link> just slightly different, and "custom" just ain't the

Link's certainly a different discussion, than thing could use some work.

On 28.02.2012, at 22:17, Andy Nagai wrote:

just wondering. Is mootools upgradeable now in the latest platform? It
is not tied to a specific version of mootools, right? This was the
only reason why we used jquery in !J 1.5.11. It had some features that
made manipulations alot easier then mootools 1.1. This was just for in
house development.

It's not. But we're able to keep up with new versions much better because the MooTools team has invested more energy in backwards compatibility. The only thing that was updateable was Joomla 1.5 that could be updated to MooTools 1.2 starting with - I think - 1.5.19. Interestingly using the override JHtmlBehavior method ;)

Best regards
Rouven

Niels Braczek

unread,
Feb 28, 2012, 10:04:16 PM2/28/12
to joomla-de...@googlegroups.com
Am 28.02.2012 20:52, schrieb Paladin:

> Sorry for the delay, I wanted to go back and double-check, just to be
> sure. There is no html5 renderer for form fields. They only render as
> xhtml, and the attributes they allow are hard-coded in the PHP (ex:
> text.php::getInput()).

So what is needed is a HTML5 renderer, maybe even a more advanced
rendering algorithm (and I fully aggree to that), but that has nothing
to do with the subject: jQuery vs. MooTools.

Amy Stephen

unread,
Feb 28, 2012, 10:07:31 PM2/28/12
to joomla-de...@googlegroups.com
Yikes. Maybe the world *is* going to end in December... ;)


On Tuesday, February 28, 2012 4:09:20 PM UTC-6, Andrew Eddie wrote:On 29 February 2012 04:08, Amy Stephen <amyst...@gmail.com> wrote:
>
> 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.

+1

Something big is definitely going to happen in 2012 one way or the
other if I'm agreeing with you ;)

 about the (optional) use of jquery instead of mootools ?
 

Niels Braczek

unread,
Feb 28, 2012, 10:11:10 PM2/28/12
to joomla-de...@googlegroups.com
Am 28.02.2012 21:55, schrieb Rouven Weßling:

> The issue with HTML5 support is that we have to make up our minds
> (both CMS and Platform) what kind of output we want to support.
> Currently we're pretty much in XHTML1 land (despite a few HTML5
> templates). Would we be happy to just support HTML5? That's easy,
> writing a patch to significantly improve JForm with HTML5 goodness in
> that case is a matter of a few hours. Or do we want to support both
> XHTML1 and HTML5 output? That isn't so easy anymore for JForm.

I'm dreaming of an Composite structure for categories and any kind of
content (hoping UCM is going that direction), complemented with a
renderer following the Visitor pattern. That way, only the Visitors have
to know anything about output format. XML (DocBook, Dita), XHTML, HTML5,
PDF, WAP, <add your favorite here> can easily be supported. Everything
but the renderers would be totally output agnostic.

Andrew Eddie

unread,
Feb 29, 2012, 12:57:12 AM2/29/12
to joomla-de...@googlegroups.com
Agreeing with your comment about keeping the JS in the template.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

Amy Stephen

unread,
Feb 29, 2012, 6:50:31 AM2/29/12
to joomla-de...@googlegroups.com
@Andrew, sorry about that. I am not certain where that last line came from. Looks like that line remained somehow when I (tried to) delete the other responses.

@Rouven - I agree it's not 100% there but standardization on approach in markup has come a long ways since Mootools was initially added to Joomla. If there is an opportunity to redo the Administrative interface, it will be good to architect this differently so that the JS approach isn't hardwired in. That'll just make Joomla more flexible and useful. But, I do agree it's an over-simplification to suggest that swapping out the package somehow magically addresses the problem. Sorry for overstating.

Paladin

unread,
Feb 29, 2012, 12:23:54 PM2/29/12
to Joomla! Platform Development


On Feb 28, 2:55 pm, Rouven Weßling <m...@rouvenwessling.de> wrote:
> Answers to quite a few different E-Mails here. You guys were busy while I was away ;)

Sorry. Just was fresh in my mind.

> Are you talking about HTML5 validation? Because otherwise I don't quite understand how you wanna tell a validator "this is a username" without a convention. The convention in Joomla is to indicate it trough the class validate-username. Same for email, and others.

I know. But there are other (and better) ways of doing that. For
example micro-data. IIRC, the validators built-in to current browsers
require attributes like "required" and "pattern" (for a regex that is
to be applied), etc. Insisting on using class names only effectively
takes good tools out of the users hands, never a Good Thing To Do.

> The issue with HTML5 support is that we have to make up our minds (both CMS and Platform) what kind of output we want to support. Currently we're pretty much in XHTML1 land (despite a few HTML5 templates). Would we be happy to just support HTML5? That's easy, writing a patch to significantly improve JForm with HTML5 goodness in that case is a matter of a few hours. Or do we want to support both XHTML1 and HTML5 output? That isn't so easy anymore for JForm.

Not sure how hard it actually would be, but I'll find out shortly. The
biggest issue is the entire field rendering system needs to be
changed, because you don't *know* ahead of time what attributes are
going to be on the field, and the current attribute names are
infinite, thanks to microdata. Have to admit I was flabbergasted when
I saw the allowed attributes were hardcoded. I mean, I can understand
how user input might need to be sanitized, but if you're sanitizing
input from an XML file on the server, I have to think filtered input
isn't going to be your biggest concern at the moment. ;{>}

IMO best approach is a new method on the field superclass which
returns a properly formatted string of *every* attribute given in the
XML. That would allow the form builder to specify precisely the
attributes he needs for a given form. I know some attention will have
to be paid to what a particular attribute is, etc., but that way we
can be sure of allowing the greatest flexibility to the form builder.
If I get some time this week I'll rough out an approach to doing it
and pass it around.

As for HTML5 v XHTML, there's not a lot of twisting needed between the
two for forms. Might be able to manage it with a flag and if-then
output. A really "off the wall" approach might even be to pass the
chunk through different XSLT's to output the various forms of markup.
That way new markup "flavors" wouldn't require a code change, just
another available XSLT. After all, HTML is a living document; it's
going to be changing again and again. Unless we're saying Joomla isn't
going to be around, I think setting output in stone like this will
turn out to be a costly mistake.

Rouven Weßling

unread,
Feb 29, 2012, 1:02:28 PM2/29/12
to joomla-de...@googlegroups.com

On 29.02.2012, at 18:23, Paladin <arlen....@gmail.com> wrote:

>> Are you talking about HTML5 validation? Because otherwise I don't quite understand how you wanna tell a validator "this is a username" without a convention. The convention in Joomla is to indicate it trough the class validate-username. Same for email, and others.
>
> I know. But there are other (and better) ways of doing that. For
> example micro-data. IIRC, the validators built-in to current browsers
> require attributes like "required" and "pattern" (for a regex that is
> to be applied), etc. Insisting on using class names only effectively
> takes good tools out of the users hands, never a Good Thing To Do.

That's what I mean by HTML5 validation. That's definitively a way I'd like to go in the future but right now it's more hassle than it's worth. Too many browsers with broken or incomplete implementations - or no implementation at all in case of IE.

The nice thing about this is since we abstracted it away in the future when we decide to embrace HTML5 forms this will be possible without extensions having to change their forms.

>> The issue with HTML5 support is that we have to make up our minds (both CMS and Platform) what kind of output we want to support. Currently we're pretty much in XHTML1 land (despite a few HTML5 templates). Would we be happy to just support HTML5? That's easy, writing a patch to significantly improve JForm with HTML5 goodness in that case is a matter of a few hours. Or do we want to support both XHTML1 and HTML5 output? That isn't so easy anymore for JForm.
>
> Not sure how hard it actually would be, but I'll find out shortly. The
> biggest issue is the entire field rendering system needs to be
> changed, because you don't *know* ahead of time what attributes are
> going to be on the field, and the current attribute names are
> infinite, thanks to microdata. Have to admit I was flabbergasted when
> I saw the allowed attributes were hardcoded. I mean, I can understand
> how user input might need to be sanitized, but if you're sanitizing
> input from an XML file on the server, I have to think filtered input
> isn't going to be your biggest concern at the moment. ;{>}

I think JForm was designed with another approach in mind. It's not a tool that just translates some XML 1:1 into a HTML form, it mostly abstracts away how HTML forms work. A good example of this is how the readonly and disabled attributes influence each other.

> As for HTML5 v XHTML, there's not a lot of twisting needed between the
> two for forms. Might be able to manage it with a flag and if-then
> output. A really "off the wall" approach might even be to pass the
> chunk through different XSLT's to output the various forms of markup.
> That way new markup "flavors" wouldn't require a code change, just
> another available XSLT. After all, HTML is a living document; it's
> going to be changing again and again. Unless we're saying Joomla isn't
> going to be around, I think setting output in stone like this will
> turn out to be a costly mistake.

Well for starters, how would you output the placeholder to a XHTML1 form?

An XSLT by itself probably won't cut it either, we do a lot of things in the form fields besides generating the HTML code.

Best regards
Rouven

CirTap

unread,
Feb 29, 2012, 1:46:25 PM2/29/12
to joomla-de...@googlegroups.com

Am 28.02.2012 23:17, schrieb Rouven We�ling:
> Who says those behaviors have to ship with the CMS from the beginning
> [...] They could just be a plug-in overriding JHtmlBeahvior

reality check...
http://extensions.joomla.org/extensions/core-enhancements/scripts
I confess, I haven't used any of these nor do I know (or care) if
there's one based on JHtmlBeahvior, but there seems to be not much of an
agreement on how this ought to work.
Beat's recent take on this as a 'behavior.jquery' wasn't much of a
success either, IIRC.

Am 28.02.2012 23:17, schrieb Rouven We�ling:
> Because I cared about those two and thus I added them.

Lucky you, to modify the Core API and hardwire some parameters that suit
your needs :)
Maybe we/someone/I can "improve" on this in the near future so others
can use a Core API for what _they need_ as well, w/o hacking, patches,
or a bloat load of plugins.

Anway, given your expressed curiosity, my dear Padawan, it seems to me
you didn't bother to do enough research in the first place, which makes
"Most of the global ones are not very useful in elements added to the
HEAD" a pretty cocky statement, don't you think?

Next time you may have a closer look at the correct specs, since you
missed the ID attribute, defined in XHTML ~ anno 2002, and (among
others) is a member of the global attributes that apply to any element
since then an up to "HTML5".
And all browsers handle them very well.

So allow me to remedy your apparent lack of imagination/experience of
what *can* and *could* be done if those "not very useful" attributes
actually come into use:

Lesson 1: Because a <script> can load an external resource (just like
embedded content via img, iframe, video etc.) it also throws an
interesting event, namely: 'onload'.
Stunning, isn't it?
Now what if we populate this "event" attribute according to its purpose?
We can run some JavaScript code, aka event handler.

Disclaimer: We don't want to do such thing in the markup that shows up
in the <body>. That's considered bad practice and obstrusive, but we can
pick our favorite JS lib to handle this.
HEAD or SCRIPT, however is none of the user's business and belongs into
the realm of the developer.

Lesson 2:
Let's have a look[*]:
<script>
var Libs = {
js: {},
mt: {},
push: function(lib, elt) {
if (lib.fn) {
console.log('jQuery', lib.fn.jquery, elt.src);
Libs.jq[lib.fn.jquery] = lib.noConflict(true);
}
else if (lib['version'] && ('implement' in Function.prototype))) {
console.log('Mootools', lib['version'], elt.src);
Libs.mt = lib;
}
}
};
</script>

<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"
onload="Libs.push(jQuery, this)"></script>

<script src="//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.6.4.min.js"
onload="Libs.push(jQuery, this)"></script>

<script src="//ajax.googleapis.com/ajax/libs/mootools/1.4.1/mootools.js"
onload="Libs.push(MooTools, this)"></script>

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"
onload="Libs.push(jQuery, this)"></script>

([*] I used CDNs so you can copy and paste this w/o downloading each
library version. It also won't work in a local file using the file://
protocol.)

//end of lessons

As usual our buddy from Redmond needs a little extra care and a slightly
different event attribute to execute this kind of code. As web
developers we're aware that we might "stretch" a standard once in a
while if it comes to support browser emulators from Redmond.

While this little demo snippet doesn't provide much functionality by
itself, in its simplicity and by combining a darn useful attribute with
the mechanics of modern browsers, it already takes care of calling
`noConflict([deep])` automagically and provides access to multiple
versions of jQuery -- should anyone care.

It also lets Mootools do its job poluting the global namespace and to
impose an alternative programming paradigm for those developers that
can't get their head around the prototypal inheritance system which is
native to JavaScript, and who therefor need "classes".
Some consider this the Good Parts of JavaScript ;)

I'll leave it as your homework to find the name of the attribute / event
name and the condition to add prior calling sth. like `Lib.push()` in IE.
Hint: if you've ever dared to work with the native XHR object you most
certainly ran into it. Its name also starts with 'on' and triggers
several times while a resource loads...

This simple trick eventually moves the handling where it's handled best:
to the client.
Any attempt doing this in PHP on the server will end up being guesswork.

Have a nice day,
CirTap

PS: slightly OT:
addScript()'s partner in crime is addScriptDeclaration() and literally
"counter productive" in its own way. There's indeed no use for "onload"
with an inline script, but the inability to add the standard ID
attribute gets in the way doing stuff like this:
2008: http://ejohn.org/blog/javascript-micro-templating/
2012: http://stackoverflow.com/questions/4912586

Rouven Weßling

unread,
Feb 29, 2012, 3:18:15 PM2/29/12
to joomla-de...@googlegroups.com

On 29.02.2012, at 19:46, CirTap <c...@webmechanic.biz> wrote:

> Am 28.02.2012 23:17, schrieb Rouven Weßling:
>> Because I cared about those two and thus I added them.
>
> Lucky you, to modify the Core API and hardwire some parameters that suit
> your needs :)
> Maybe we/someone/I can "improve" on this in the near future so others
> can use a Core API for what _they need_ as well, w/o hacking, patches,
> or a bloat load of plugins.

I dislike your tone. If you don't take me seriously, why should I even consider working on anything you suggest?

I provided a patch for something I found useful for my myself and potentially others - and which I'm still planning to use in the core. It would be trivial for you to provide a patch that adds $attributes to addScript() - it already exists for other methods. I didn't feel it would be useful, you obviously disagree. So provide a patch, don't expect others to do it.

I'm in this for fun and because I enjoy working with Joomla. I don't get paid to work on Joomla and have no bigger business or financial interest in it.

I'd also like to mention that at the time I provided that patch to add defer and async - which is more than a year ago - I had no role or influence or ability to make decisions, just the ability to provide patches and lobby for them.

Since we have gone quite a bit off topic and frankly I don't like talking with people that are condescending I consider this the end of this subdiscussion on my part.

Regards
Rouven

Jason Williams

unread,
Apr 30, 2012, 6:08:48 AM4/30/12
to joomla-de...@googlegroups.com
On Wednesday, February 8, 2012 6:15:18 PM UTC, Rouven Weßling 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


HI Rouven

Although you say this is centered around popularity, I do feel the CMS needs to move with the times. Statistics don't lie, if jQuery has a very high (90%?) usage compared to other js frameworks then that obviously means a majority of developers/companies prefer to use it. As someone said earlier, its quite clear jQuery has won the war and various developers need to accept that.
My question is what would happen if mootools activity got so low it stopped completely? Im some circumstances sticking with a framework/tool which is decreasing in popularity can actually do a lot more harm to the CMS than moving on to something else. I don't think mootools will ever die but It looks more risky to leave the whole CMS using it. 

Technical merits: I can't answer this one as im not a heavy mootools user (I don't know anyone who is either) but I would say jQuery seems to be developing at a faster pace.

As for your second point, im quite happy to help writing jQuery scripts.

Rouven Weßling

unread,
May 3, 2012, 11:13:17 AM5/3/12
to joomla-de...@googlegroups.com
Hi Jason

On 30.04.2012, at 12:08, Jason Williams wrote:

> Although you say this is centered around popularity, I do feel the CMS needs to move with the times. Statistics don't lie, if jQuery has a very high (90%?) usage compared to other js frameworks then that obviously means a majority of developers/companies prefer to use it. As someone said earlier, its quite clear jQuery has won the war and various developers need to accept that.

By that line of thought we'll all be developing Wordpress very soon ;) Also no one should use anything but Windows on the desktop, Linux on webservers, PHP to develop web apps. Also no tablet but the iPad should be used. See where I'm going? Popularity is an indicator but no sufficient argument for the quality of a product or technology. In general I think that monocultures are generally bad but admittedly in the JS libraries space we haven't seen any effects from this.

> My question is what would happen if mootools activity got so low it stopped completely? Im some circumstances sticking with a framework/tool which is decreasing in popularity can actually do a lot more harm to the CMS than moving on to something else. I don't think mootools will ever die but It looks more risky to leave the whole CMS using it.

If activity stopped completely - which I see no evidence of happening - there'd be very soon very good reasons to switch. For starters bugs with browsers that don't get fixed. That we'd have no choice but switching. Also if switching to a different framework would bring us big rewards it could be considered. But don't forget that there's a huge cost associated with such a change. Dozens of scripts will have to be rewritten, extensions will have to change, etc.

Also from what I gathered in the discussion regarding jQuery in the last few weeks there backwards compatibility isn't any better or even worse than MooTools.

> Technical merits: I can't answer this one as im not a heavy mootools user (I don't know anyone who is either) but I would say jQuery seems to be developing at a faster pace.

And I'm not a heavy jQuery user ;) But so far I'm not missing anything.

Rouven

Amy Stephen

unread,
May 3, 2012, 3:29:40 PM5/3/12
to joomla-de...@googlegroups.com
It all comes down to target audience. Who is the JS library primarily for?

IMO, the choice of JS library included in the CMS is mainly a frontend developer issue. Consider this from a perspective of workflow and profit margins. Frontend devs are not hired to create a new carasol or photo gallery or video player with each site build. Instead, they must look for easily integrated solutions that are readily available. Now, with that in mind, consider the difference in offerings and quality and accessibility and road maps and developer teams between jQuery and Mootools. There is simply no question in my mind at all that jQuery has more to offer site builders.

Now, maybe dev teams looking to build powerful applications might need a tool like MT's or Backbone or Spine or one of dozens, if not hundreds of compelling options available. But, now that we have the platform separated from the CMS, those teams are far more likely to take that route and then they can choose their own JS tools.

I think the separation can help us focus the CMS more clearly on it's target audience. IMO, that's frontend devs working on tight budgets, looking to integrate that which is available, not start from scratch.

My 2 cents.

Andrew Eddie

unread,
May 3, 2012, 11:24:58 PM5/3/12
to joomla-de...@googlegroups.com
On 4 May 2012 05:29, Amy Stephen <amyst...@gmail.com> wrote:
> It all comes down to target audience. Who is the JS library primarily for?

Mootools was originally chosen because it made more sense in the
context of software engineering principles. If the problem you are
still trying to solve requires an SE solution, Mootools and a host of
other will serve you well. Having said that, it has to be conceded
that most of the Joomla CMS world doesn't need a SE solution for
simple Javascript behaviours like menus and tabs and image sliders,
and because you don't need to be a programmer to get a result with
jQuery, that's why it's so popular. I think the CMS, for what it's
worth, should swap over to jQuery … provided those that want it put up
a sane change management plan to do so

However, when you are talking about ground-up applications, I don't
think we should lock into any JS framework - it should be left up to
the developer. The reality is the JS in the platform and the CMS is
far from par by any standard and just refactoring the current code to
work with jQuery is a non-solution - that's just painting the bike
shed a different colour without giving any thought for its state of
disrepair.

Recommendation: remove JS from the platform altogether (and probably
start a completely separate UI element sub-project in the process).

Louis Landry

unread,
May 4, 2012, 2:45:03 AM5/4/12
to joomla-de...@googlegroups.com
I was about to respond to this, but Andrew and Amy have said pretty much exactly what I would have said.

The question of what the CMS should do can be discussed on the CMS list or other appropriate places, and I agree with Andrew and Amy's assessment here.  I also strongly agree that we should move the JavaScript out of the Joomla Platform repository.

Elin Waring

unread,
May 4, 2012, 7:26:51 PM5/4/12
to joomla-de...@googlegroups.com, louis....@gmail.com

Discussion of what the CMS should do most certainly doesn't belong here, though as most people presumably know there are potentially changes to the CMS (involving possible use of the Bootstrap framework which in turn incorporates jquery) that are under discussion and those who might be interested in that topic should really participate on the appropriate lists and in the jux forum. 

That said, the ultimate question on this side of things is what is the purpose of the platform other than being a place to have forward looking classes that are either fun to write  or  useful to the people writing them (which is fine).  If  the goal  is actually intended to attract developers writing moderately complex applications some consideration might be given to why someone would use the platform as a platform rather than the CMS as a platform given that the CMS provides you with implementations of what the platform offers for authentication, user management, access control,  session management, routing and other useful things that  many web applications need and that  includes one or more javascript frameworks. If every time someone writes a platform application they are going to be told that the choice is start from scratch or go copy the CMS plugins for everything from authentication to editors  or copy the toolbar library from the cms or go grab the media folder or system template,  that does make one wonder if there needs to  be a middle layer where those building blocks reside. Or, perhaps, CMS 4.0 should be thought of as that layer since JContent is going to make it so much more streamlined. 

In that case it makes sense to move the javascript framework out of the platform to the CMS and for the CMS team to determine what developers (whether site developers/designers or application developers) using it as a platform find useful. 

And that's my Friday afternoon musing. 

Elin

Rafael Corral

unread,
May 9, 2012, 12:39:59 AM5/9/12
to joomla-de...@googlegroups.com
Hello everyone,

I just did a pull request of an implementation I did months ago for a "javascript library manager" it allows an extension to register a javascript library along with any CSS and JS files that it may require (which is something other implementations have not considered) and it allows for loading it to the document afterwards.

Here is the link to the pull request: https://github.com/joomla/joomla-platform/pull/1192

Here is an example on how it would be implemented through a plugin to load jquery:
https://github.com/rcorral/joomla-cms/commit/bf71fa00ede7620c67367ae05a5b3d6dc7b410c5

Let me know your thoughts on it.
Rafael

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 ?
 

piotr_cz

unread,
May 9, 2012, 8:58:03 AM5/9/12
to Joomla! Platform Development
In my opinion this issue we are trying to tackle is beyond deciding
between jQuery an Mootools.

I've learned Mootools, because I was forced to by Joomla :) and now
I'm happy this happened.
jQuery is DOM manipulation tool but in today's world I see it's
optimal usage as a polyfill for IE6-8. Most of it's funkineness (and
more) is available in modern browsers natively and on majority of
smartphone browsers (CSS3 animations, queryselector, forms validation,
etc).


Developer has to choose carefully JS tools based on the project type:

Full version of Mootools Core and jQuery (both ~94kb minified) are not
necessary for smartphone websites when much of the functionality is
available natively, or just not required for simplified layout.
jQuery (and often) MooTools is appropriate tools when building
structured client-side webapp with Joomla platform as the backend.


Moving to jQuery would make sense if Joomla would decide to target
only desktop cms users on ancient browsers.

I'm rather interested in the Javascript library management effort
(https://groups.google.com/group/joomla-dev-cms/browse_thread/thread/
6b6016bc08f0bbb7#) with added dependency support (like
https://github.com/kamicane/packager) and compression tool.


It really doesn't make sense to force developers to use one thing to
fit all scenarios. It all depends on project:

CMS frontend on desktop: simple DOM manipulation tool (native /
jQuery/ Mootools)
CMS frontend on mobile: native features: CSS3 + JS html5 api,
additionally DOM manipulation tool with small footprint (Zepto/ custom
Mootools builds)
CMS Backend: any framework with ajax and DOM stuff for UI

Platform webapps: simple: Mootools, complex: MVC tool (https://
github.com/addyosmani/todomvc/tree/master/architecture-examples)
Platform webapps on mobile: above + moobilejs / jQuery Mobile



On May 9, 6:39 am, Rafael Corral <rxcor...@gmail.com> wrote:
> Hello everyone,
>
> I just did a pull request of an implementation I did months ago for a
> "javascript library manager" it allows an extension to register a
> javascript library along with any CSS and JS files that it may require
> (which is something other implementations have not considered) and it
> allows for loading it to the document afterwards.
>
> Here is the link to the pull request:https://github.com/joomla/joomla-platform/pull/1192
>
> Here is an example on how it would be implemented through a plugin to load
> jquery:https://github.com/rcorral/joomla-cms/commit/bf71fa00ede7620c67367ae0...

Rafael Corral

unread,
May 9, 2012, 11:41:29 AM5/9/12
to joomla-de...@googlegroups.com
In my opinion it doesn't matter which library we use, I prefer jQuery for many
reasons but if MooTools is going to always be there, then so be it, I won't loose sleep over it,
maybe what we need is to do a poll like the ones that have happened in the past.
Ideally we would have all the javascript which comes with a standalone package of Joomla
written without any dependency to any library, unfortunately this would be very time consuming
for anyone to take on. BUT if this was done it would allow the person developing a site to pick
extensions that use the library that they want to use.

What I developed allows extensions to register any libraries that they use so that there
are not 3 different version of jQuery on a website, this way only one loads.

Nick Weavers

unread,
May 10, 2012, 7:09:24 AM5/10/12
to joomla-de...@googlegroups.com
I tend to agree with @ piotr_cz about the issue being more of choosing the right JS library for the job at hand. IMHO it really is a matter of "horses for courses" and although tend to use YUI for front end stuff just out of personal preference (remember VHS won the Video cassette war, but Betamax was always acknowledged to be technically superior), the real differentiator is in back-office type projects where ExtJS (now Sencha) is the library of choice for me. 
With the ExtJS projects I have completed, all of the page layout is done in ExtJS with Joomla just supporting ajax calls to controllers with format=raw/json for things like data stores. All forms are built using ExtJS' form handling and data validation facilities. If you have never tried ExtJS, you owe it to yourself to take a look at it. (I am not affiliated to them in any way, I just like their library a lot).  


David-Andrew

unread,
May 10, 2012, 1:29:11 PM5/10/12
to joomla-de...@googlegroups.com
In case anyone missed this:
http://ux.joomla.org/forum/Visual-Design/481-UI-Options-and-Bootstrap?limit=8&start=136#636

Op maandag 6 februari 2012 14:53:35 UTC+1 schreef Nils Rückmann het volgende:

Elin Waring

unread,
May 10, 2012, 2:34:01 PM5/10/12
to joomla-de...@googlegroups.com
Nick it would be so great if you would write that up somewhere. Actually, I think you really hit the issue. On the platform level and thus indirectly in the CMS it needs to be easy for developers to use the libraries they want  and it is very likely that those libraries will not be either JQuery or MooTools. Then the real issue on the core CMS side is what do we want to be using javascript for at the application level as we move forward over the next say five years. To what extent do we want to ajax-ify?  To what extent are we going to push to take advantage of the more powerful potential uses of javascript? That's why the CMS has to make its own decision about this because it depends on the vision for the application.

Elin

piotr_cz

unread,
May 11, 2012, 7:35:45 AM5/11/12
to Joomla! Platform Development
@Nick: Good you mentioned extJS, probably there isn't any
comprehensive bundle like this.

I guess any kind of extended javascript library management in the
Platform would be just a complication for the developer. There are
just too many ways to do it, ie: loading scripts with require.js or
generating platform specific applications on the fly on client side
(http://walmartlabs.github.com/lumbar/) or server side.

In Joomla CMS frontend, I think centralized library management could
be really useful for reasons that were mentioned numerous times +
asset minification. People prefer jQuery for frontend extensions as
(let's be honest) - most of Joomla users are going for painless trendy
effects.


Now, since PLT has agreed on including Twitter bootstrap and jQuery in
Joomla 3.0, I see this kind of solution (this concerns Platform too):

There must be some framework for CMS backend for handling UI
components and backend further ajaxification. I don't think anybody
has problems with Mootools being there. In my opinion when somebody
decides to write complex extension for admin area, this is the more
logical choice then jQuery.

Anyway to use Twitter bootstrap we would need to rewrite UI components
(JHtml::tooltips, calendar, panes, JHtmlSliders, JHtmlTabs,
JHtmlGrid...) to output Bootstrap namespace compatible html, and move
the javascript parts that configure UI component out from document
head to component initalization.

When there is UI functionality not supported by bootstrap yet or UI
component init options (currently opened tab, enabling client-side
storage for tabs state), this could be set in html output using data-
attributes and picked up by JS UI class.


There are possibly few other places in the platform, where javascript
is used (JText output for JS) but this can be possibly handled by
vanilla JS.

Completely other issue are MooTools classes like validate.js or
core.js package


piotr_cz
Reply all
Reply to author
Forward
0 new messages