Where is the post that succinctly compares Qcodo with Qcubed?

thread: 10 messages  |  last: about 10 years ago  |  started: wednesday, may 26, 2010, 5:45 pm pdt

#1  |  kingwithin (San Francisco, CA) United States of America
Wednesday, May 26, 2010, 5:45 PM PDT

Or other feedback on people who have looked between the two options and can parse out one versus the other since once you leave beta3 or maintenance 1.0.2 there's no turning back.


#2  |  comet7 (Georgia) United States of America
Wednesday, May 26, 2010, 8:32 PM PDT

The succinct answer: Qcodo is an iPhone.  Qcubed is an Android.

A longer answer:
Qcodo is a beautifully written, powerful, rock-solid framework.  Mike Ho created it and contols what changes make it into the core.  This also means that some changes you might want will never make it into the core and that Qcodo might not advance as fast as you want, especially if Mike gets busy or enjoys life from time to time.

Qcubed is based on Qcodo, but branched off Qcodo a couple years ago by great and committed developers who got tired of waiting for Qcodo to advance.  Qcubed advances more by committee than does Qcodo. This means that you will probably find more features in Qcubed but that it is not quite as tight as Qcodo. I have not used Qcubed lately nor have I have followed recent Qcubed development, but I have no doubt that it too is rock-solid.

#3  |  Mike Ho (San Diego, CA) United States of America Qcodo Administrator
Wednesday, May 26, 2010, 10:56 PM PDT

Thanks for the comparison, though as an avid iPhone fan (and an iPhone developer), I don't think Qcodo deserves the high praise that the iPhone ecosystem deserves. =)

But in all seriousness, while I mostly agree with the comparison, I think there are a few key things to note.  First off, with the massive amount of development money behind the iPhone and with Qcodo being a free, open-source project, the iPhone definitely has a lot more polish and shine than Qcodo does.  So I would hate for anyone to expect that level of fit and finish in Qcodo...

Second, while it's true that I am the only one with has actual “commit” privileges, I think a quick glance at the commit logs for Qcodo show that many, many individuals have been able to contribute code into the core repository.  One of the reasons for the lack of contributions over the past few years (and of course what led to the QCubed fork in the first place) was my needing to get an infrastructure in place that would much more easily support being able to quickly review and accept code contributions from other members of the community.  And with the infrastructure we now have (e.g. github), I think we're starting to see this happen at a much more accelerated pace.  The most recent release of Qcodo in the changelog shows this, too.

And the key difference between the Qcodo community and the iPhone community is that if you submit something to the iPhone store and it gets rejected by Apple, you're pretty much out of luck.  However, I believe that if you end up submitting something to Qcodo that for whatever reason is found to not be something that should be committed to core, there are still many options to publish your submission, either by posting your github branch to others in the forums, or by submitting a QPM for everyone to see and use.

Just my thoughts...

#4  |  Fernando Lordán (Barcelona, CAT, Spain) Spain
Monday, May 31, 2010, 4:16 PM PDT

Also to note: QCubed is far from being an Android.

QCubed, as you said, is a comitee. But unfortunately it's too much centered in fast-patching, rather than having a design vision. QCodo has that design vision, so things are a lot more cooked.

For this loose vision of scope when applying patches, QCubed may lead to applications stopping to work (for no apparent reason) not only in QCubed version changes, but also from one minor revision to another. You will never see that in QCodo, where any eventual compatibility break is noted and accompained with instructions. I can put clear examples of both sides way-of-doing, if someone doesn't agree.

Also, QCubed tends to put a lot of effort in DHTML (visual) features, with a clear will of leaving the framework core in the hands of external components, thus leading to uncontrollable compatibility issues in the future caused by external factors. Several QCubed plugins, for instance, show a lax care in compatibility with other external components that the developer may need (specifically in points where this compatibility is possible, but not implemented due to careless programming).

Sorry for the criticism. I really appreciate the efforts put in QCubed, and would want to see them as QCodo GitHub contributions. But I also think that QCubed gets the wrong way in many aspects, being software design the most notable of them. And the worst part is that apparently its developers don't stop to think about it even for a moment. After following its development, I really think that more heads don't always imply more time thinking, specially if the aim is not well-chosen.

Don't take any offense, please. It's just my opinion, not a confrontation. I really really would like to see QCubed contributions into QCodo, now that QCodo has finally been fully opened to well-done contributions.

#5  |  Patrick Ranger (Montreal, Qc) Canada
Tuesday, June 1, 2010, 8:01 AM PDT

This is an interesting discussion. Of course it tends to be emotional, but I think both forks can fit different needs. I don't know QCubed for I have decided to stick with QCodo so I can't comment on the differences, though I think it would be useful to have a well documented comparison of both forks. Mischa Kroon started a wiki page that can turn into a useful tool for newcomers that want to pick the framework that fits their needs.


#6  |  VexedPanda (Calgary, AB) Canada
Tuesday, June 1, 2010, 8:59 AM PDT

While versions of QCubed have occasionally contained bugs, so have versions of QCodo, so I don't think your comments there are entirely fair.

As for plugins, they are community contributed plugins, and are just as likely to contain errors or incompatibilities as QCodo QPM modules. If you've found issues in QCubed plugins, that's unfortunate, but I fail to see how that has anything to do with the framework itself.

And if you ever have issues with any aspect of QCubed, you're encouraged to open a ticket regarding it. We also actively monitor the forums, and create tickets for any issues reported there.

I also encourage anyone curious about the state of QCubed to read through the open tickets, and see if anything there could affect them.

I think you'll find the vast majority of them are enhancements, rather than bug fixes.

#7  |  Fernando Lordán (Barcelona, CAT, Spain) Spain
Tuesday, June 1, 2010, 7:39 PM PDT

I wasn't talking about bugs. Any complex code is susceptible of having bugs, and I don't think that's a differentiation factor between QCodo and QCubed at this moment, as they still share a lot of code.

I was talking about fast-patching instead of thinking things twice or three times. Either for a bug or an enhancement, QCubed developers find more important to have “working code” rather than considering the consequences of the change. Removing imperfections and having new features is a good thing, but the modifications must be streamlined with the uses and behaviour of the subject being modified. And I can only say that I don't see that considerations in many QCubed core changes.

Worse than that, I've seen many QCubed issues where the developers tend to “try code” just to remove an issue or an alert, instead of taking time in understanding why it's failing and considering to solve the cause before implementing the solution.

I could also mention past discussions about changes in QCubed naming conventions with the sole intention of making things less “Qcodoish”, or the proposition of rules just to make code layout look prettier. That kind of things discouraged me a lot, as they gave an image of a framework with erratic aims. Fortunately that was corrected, and now QCubed aim is clearer.

About using the QCubed issue tracker, you know I've been there and done that. And I was shocked when, after being warned of it, one QCubed developer confirmed the decision of breaking backwards compatibility in one minor revision just for a PHP syntax purism, while rejecting a fully-compliant already-implemented hack. Not to talk about breaking own QCubed naming rules with the finally implemented solution. That was too much for me, as putting PHP future syntax recommendations over the maintainability of existing overlying applications is totally unacceptable.

Sure that QCubed evolution is faster. But in my opinion QCodo evolution is much more reliable.

#8  |  VexedPanda (Calgary, AB) Canada
Wednesday, June 2, 2010, 9:19 AM PDT

I'd love to hear examples of changes you feel don't fit.
We certainly do try and think through every use case, and ensure we are solving the root problem instead of just a symptom, so I'm curious to hear where you think this is failing.

As for the single issue you're referring to, I don't wish to get into this again. You are still intentionally mis-stating what “backwards compatibility” means, and the fact is that it was closed behaving in the manner you desired, so I really fail to see the reason for your displeasure. Every release has been nearly 100% backwards compatible (with only fixed bugs behaving differently), with every attempted application upgrade reported successful, and still “maintainable”.

As for the name change from QCodo to QCubed, yes, this was done to differentiate the framework, and not have references to a project that would diverge significantly in the future. Having things called “QCodo” in the framework that no longer shared any code with QCodo would be just plain silly.

I can't speak to reliability since there's no way to do hard numbers, but I think the framework and the people contributing to it and using it for their applications speaks for itself.

#9  |  vakopian (Los Angeles, CA)
Friday, September 24, 2010, 3:40 PM PDT

I know it's an old thread, but WOW!!! In a question specifically asking about QCubed and its differences with QCodo, Mike Ho posts a pretty lengthy reply explaining how QCodo differs from ... yep, you guessed it from the iPhone!!!
Talk about denial...

People who have stated how rock-solid QCodo is (and implying that QCubed is much less so) should probably take a look at the amount of bugs fixed (and a lot still waiting to be fixed) in both QCubed and QCodo. And as to how beautiful the code is - clearly you have never really read the actual nuts-and-bolts code. As with any sizable project, QCodo (and of course QCubed as well), have hacks, inefficiencies, repetitions, legacy code, etc. By just refactoring and removing unnecessarily repeated code QCodo's size could probably be reduced by 30% (I can't think of any other project, especially developed by a single person, that has so much repeated code...).

And then Fernando accuses QCubed for actually fixing things. Surely he can't be serious. But he is, and he explains it by saying that we fix things without thinking about the big design? Really? How do you know? How can you tell that the patch I just posted was not a result of a month of thinking and discussions and experience with QCubed, QCodo, Hibernate, RoR, SqlAlchemy, etc? Why not get over a trivial incident of having your proposition rejected. I wish you had posted the issue number in QCubed so people could make up their own minds (I would, except I don't know what you're referring to). Is having a suggestion properly discussed, rejected in favor of an alternative approach so much worse than having bug reports, feature requests and patches sitting there for years unanswered and gone to waste?

Also from Fernando: “QCubed tends to put a lot of effort in DHTML (visual) features, with a clear will of leaving the framework core in the hands of external components”.
Just so others know, he's refering to JQuery! Yes, that JQuery, the one considered perhaps the best javascript framework out there, and adopted by Drupal, .NET, etc. So apparently integrating JQuery and JQuery UI with QCubed is worse than having hand cooked javascripts that try to do the same things, but a lot less efficiently, with a lot less browser compatibility with a lot less API consistency. Developing and maintaining something like JQuery takes hundreds of man-years. Being backed by huge industry players is another bonus. For Mike Ho's had written javascript to come close to such a standard, he'll need to disappear and just work on javascript for a century not just two years.

And Mike is talking about how QCodo now has the infrastructure and is a community project. So, what happens if he disappears again for 2 years? Is the result gonna be any different than it was 3 years ago? The only real difference I can see is that now people can submit patches that will stay dormant in github, instead of qcodo forums, as it was back then. So, please let's not fool ourselves as if things have changed dramatically. The only real difference is Mike Ho was not here before, and he's here now. If you're ok with using a framework that depends so much on one person, you're up for an interesting ride...

#10  |  Mischa Kroon (Holland) Netherlands (Holland, Europe)
Saturday, September 25, 2010, 3:32 AM PDT

Wow what a heated post.

It might be best to not turn this into a flamewar and put a lock on this + redirect people to the wiki entry:


To make sure things stay somewhat professional and constructive.

Copyright © 2005 - 2021, Quasidea Development, LLC
This open-source framework for PHP is released under the terms of The MIT License.