[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [jfw] Re: Packages - Keep or Dump?
> Probably are, does that matter ?
If a comment doesn't convey the right context, yes.
> Looking at it from a ROI perspective. The investment that the Joomla
> community made in building, promoting and maintaining the framework didn't
> generate any significant uptake by Joomla nor PHP developers.
Compared to the investment put into the CMS and other non-code related
activities, the investment was tiny. It doesn't really matter though,
it scratched an itch then but what's important is what does Joomla
need to do now?
> I would go even as far as saying that the framework effort and the "politcal
> argie-bargie" has had a quite negative impact on the Joomla brand perception
> and diluted the brand significantly.
No less than Nooku or FOF or several others that have come up. To be
clear, there are good reasons why those exists, (and I include
JXtended libraries which I was involved in), but they all, in some
capacity dilute the brand and have a slight negative impact on core
contributions. Despite understanding, and partly agreeing with, the
reasons, FOF vs F-zero-F was far from an ideal situation to find
ourselves in (as consumers of Joomla), and Nooku openly competed with
Joomla on a commercial level for a while there.
So while your statement is true, the Framework finds itself in good
company and like all the other examples, it's not just the Framework's
fault. Other forces also contributed. However, none of that really
matters now. It happened. Change is required. So change.
> There are definitely some very good and well established libraries out there
> worth using. Symfony has some great components, the League of PHP is doing
> some excellent work too.
I agree. The only thing I don't like about Symfony is some of the
baggage you have to include to use just one or two packages. Same
would go for Laravel but it is certainly my favourite. They are
designed to be used as an entire framework. I prefer the way the
League and perhaps Aura is doing things. To be honest I'd be more than
happy if the CMS said they just wanted to use someone else's
framework. But that doesn't mean the need for the responsibility of
library maintenance disappears. I think it's better done in a separate
team. I don't think one CMS Team can be the expert at everything (and
it's certainly not my experience working for other people on software
that isn't even as big as Joomla).
The question I ask Joomla is does it retain in-house expertise to
guide and maintain the types of libraries that are included in the
CMS, and who sets the standard for what code is written in-house?
That's where I think a new type of Framework Team is necessary, and I
assume that Team would still decide to store packages in separate
repositories and bring them all together with Composer (or some other
The CMS proper, and even extensions, should actually be made up of
very few lines of code. Most of the heavy lifting should be hidden
away in the /vendor/ folder.
> Metrics are more then clear, 5000 vs 5 million even with a different
> distribution line it doesn't matter. Lets not blame this on the 'other
> developers'. Doesn't matter who contributed and who has not. There is no
> uptake of this code, time to put it to bed.
It's still a nonsense argument in my opinion. Composer can still be
used as a distribution model even if only the CMS is using it. The CMS
still needs good, clean, modular code. Yes, we all agree the original
purpose of the Framework Team doesn't exist any more. That can be put
to bed. Is a new purpose required - of course it is.
> That's NIH thinking.
> Innovation doesn't come from what you add, it comes
> from what you make possible. CMS is still pushing Joomla developers to
> create great an innovative extensions.
I don't share your point of view. The certification side of things is
still in its infancy. I don't see a clear and deliberate campaign for
innovation within the project itself, let alone exuding it, but then
maybe I'm looking in the wrong place. I do, however, come across of
lot of really, really bad code in extensions and what I'd class as
genuine innovation is rare (and that's normal). But who can blame them
when the code in the CMS is partly to blame for setting a bad example.
> The stability and lower pace of
> change of 3.x series is actually driving factor. The framework hasn't seen
> any uptake at all. Clear cut case.
Not clear cut because there has been "some" (where some means greater
than zero) uptake (if "you" don't use it doesn't mean zero other
people use it). It is a clear cut case that the framework in it's
current form has failed to reach any reasonable level of popularity as
> Dropping any of the framework packages used in the CMS that have better PHP
> community equivalents is definitely a good idea. Allows Joomla to focus on
> it's core task, making the Joomla the best possible content management
Can't agree more.
> That's NIH thinking.
For those watching with popcorn, NIH stands for Not In Here, or Not In House.
It's got nothing to do with it at all. I don't care what code is
in-house and what isn't. It still needs to be managed.
> Joomla doesn't need a separate framework, it can easily
> adopt established PHP libraries to serve lower level functions, it doesn't
> need to build it's own complete framework for that. Result : a laser cut
> product focus on 'Joomla' as a cms.
I agree that it doesn't need a complete framework for that. But it
will need "a" framework most probably a mix of off-the-shelf and
bespoke code. The ideal would be for a distinct team to take care of
that. Gosh anyone who works with any Node application of any size
knows it's almost a full time job for one person just to keep up with
> I'm not saying you need to stop using Composer. Just use it in the correct
What is the correct way in the context of your statement?
> Think the Joomla community has some very talented extension developers out
> there that are most happy to help with this.
They are free to join in the conversation. I see Nic D wants to. Very
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.