PS: And Extbase is of course still the recommended framework for developing Extensions ;)

First of all: Maybe the different core teams should coordinate their buzz beforehand instead of adding to the confusion which is already there due to the new "packages". Xavier explicitly wrote that there will be NO successor of v4 but a different system based on FLOW3, while both of them will be developed further. Now you are contradicting that again by repeating the same marketing talk we already had for the last 6 years. Sorry - but IMHO this is not the way to go on.

We already got that with the so called "futuristic template building", which was presented as the "successor" of the classic templating approach. Today many enterprise clients are paying lots of money to get rid of it, because they found out that besides some nice features they got too many problems to stay with it any longer.

Now we got the same situation again: For years we have been told, that [the product to be named], formerly known as TYPO3 Phoenix, formerly known as TYPO3 v5, will be THE successor of TYPO3 v4. We had to accept lots of backports and decisions that have been made based on this theory even though many of them were no real improvement for v4 at all.

Instead we got a dead slow caching framework with 4.3, dead slow ExtJS based components in 4.4 that are still there even though you Phoenix guys now have switched to another framework, because you found out that the people who warned you back then about ExtJS where right. Even the most famous backport from Phoenix, Extbase, which is really impressive from a scientific point of view and as an example for a modern way of clean coding is again, guess what: Dead slow.

And now you really think about backporting the successor of TypoScript as well? - Hopefully this will never be the case.

IMHO it would be wise to stop the so called "backporting" of features in favour of a fair competition between two different approaches. So people might find out which way fits their needs best. And IMHO things can only really be BACKported from a product that is ahead of the other. Currently this is not the case for [the product to be named]

BTW: This is about [the product to be named] only, not about FLOW3, which is something completely different. We are working with FLOW3 for quite some time now and it is an awesome framework as long as nobody tries to force it's paradigms into the TYPO3 v4 world. So I am not adding to the discussion about money that people think has been wasted, since IMHO this is not true. But it would be, if the outcome of the development would lead to the fade out of the must successful system the TYPO3 community currently got.

@Joey: the news article was written by "v4" and "v5" folks together in Laax, but nothing can prevent people from misunderstanding things. Thus a (needed) clarification doesn't mean there was no coordination.

And regarding the "successor" IMHO the major problem is that (again) "successor" and "replacement" where used in the wrong places and (almost) as synonyms.

OK - got the point. BUT, when [the product to be named] should be a "successor" and NOT a "replacement", it simply doesn't make any sense to "backport" features, which is currently happening in one direction only. In fact this would lead to the "successor" still being a replacement.

[the product to be named] = TAFKAP = The Application Formerly Known As Phoenix

I 100% agree with Joey: no backport of features that didn't succeed in the "wild".

@extbase
extbase is sometimes slow, yep, but it's also a very nice way of creating extensions fast and secure, so I'm basicly pro backporting usefull stuff, fluid is also a very fast way to exchange html fragments with designers.

@extjs
ExtJS as well can be used very productive in TYPO3v4 (e.g. with the cardlayout in 4.7), but that needs different application design (load ui once, reload data only).
Using ExtJS in iframes is always a bad idea!

I have no problem with extbase as such since it can help to pave the way for those who want to use FLOW3 programming paradigms - but it has been promoted as "THE one and only new way of coding extensions" , which is now proven to be wrong, since we have got two different products.

Performancewise it had to fail since it doesn't make sense to force FLOW3 programming paradigms into the existing T3-API and DB-structures.

Joey, I have seen a lot of companies in the meantime working with Extbase very successfully also for bigger projects. From those claiming it to be dead slow or "broken by design" we never got proper feedback unfortunately even after multiple tries.
I think that this situation is based on a lot of misunderstandings and I agree that we could do much better in eliminating those.
IMO nothing is proven wrong, Extbase is still the bridge for the two worlds and we can continue benefiting from it in both directions if we manage to stick together instead of accusing ourselves.

Well, you might remember how we sat together with a lot of other people at the last developer days in Sursee and the outcome of the "what extbase is and what it's not" workshop was: It is a good thing to use extbase to port the mindset from TYPO3 v4 coding style to FLOW3 paradigms, but extbase was never meant to be a high performance tool used for high traffic projects.

It IS slow by design, which is not due to the FLOW3 design as such and it's paradigms, but due to the fact that it has to connect these with the TYPO3_DB structures and the rest of the API, which is the real bottleneck - and of course extbase can not use doctrine as FLOW3 does.

This is not meant as an accuse but just naming some of the facts we have been working out during the workshop. Of course people can use extbase successfully but compared to non "extbased" solutions or even FLOW3 itself running on the same machine, the performance will be significantly slower and even basic features like i.e. JOIN queries are still missing.

This is why I have been asking for a stop of the "extbase is the future for TYPO3 extension development" campaign for a while now, since this is just misleading.

So can we agree that it is just ONE out of many possible ways to code a TYPO3 extension and it MIGHT be a good idea to use it, IF you want to prepare for [the product to be named] or any other FLOW3 project?

Just correcting myself: JOIN queries are not completely missing but implemented in a kind of restrictive way, forcing you into LEFT JOINs using uids and "=" as the only operator, which might reflect the needs of the default relation variants of the TCA but doesn't help too much in other scenarios.

Guys,

seriously can we please stop being offended each time someone says the truth,.. for once ?

Extbase and Fluid are nice, coding wise, for devs, they are both slow, as well as FLOW3 if not cached.

This is the plain truth.

It (Extbase) still got some mayor gaps when it comes to the persistence layer, just the truth.

And please guys talking performance, show at least one shop doing 1.000.000 € a day running on ExtBase, show me a web page with more than 10.000.000 PI running on less than two Midsize - DBs and less then 6 Midsize - Webservers, with user able two switch between about 20 Usergroups on the fly, which affects the content directly, running on Extbase.

Is there is, I am impressed, but as far as I know, none so far becuase of the reasons mentioned on top.

Cheers

Chris

I forgot to mention:

100.000 registered Users, between 5.000 and 6.000 loged in on average business hours.

Hi Joey,
thanks for the sensible tone!

I agree to your first paragraph and even though I don't see the claim "extbase is the only way to program extensions" anywhere, we urgently need clarification and the "collection of strong & weak points of Extbase" on a prominent spot. I don't know what happened to this project, but probably the responsibles wait until typo3.org is relaunched.

I also partly agree to your second paragraph: using an abstraction layer like an o/r mapper is slower than accessing the database directly. Just like PHP is slower than C is slower than Assembler. But with a clean architecture you have the possibility to take measurements - by using clever caching mechanismns for example. But yes, it will be slower mostly and it's a question of assessment. The good thing is: you are free to use all tools together and it's not even bad practice. I've seen realtime searches (using eID) and tag clouds (using direct DB access) in Extbase extensions. But mixing two approaches is where it gets hacky: In the world of DDD there are no JOINS (even though the persistence mapper internally makes use of them of course). Think in objects and if that doesn't work out, restructure your domain model. And if it still doesn't work out, Extbase might not be the right tool for the requirement.

A collection of those "limitations" and some kind of "cook book" for how to solve certain requirements would be a great thing to have - also for FLOW3 where you'll encounter the same challenges, even though it uses a far more sophisticated persistence layer. Speaking of which: In fact it is quite possible to use Doctrine for Extbase and there are good people working on this already: http://bit.ly/yaZvw2

By the way: I'm not offended at all, I just fear that we scare away agencies & users if we don't handle these issues more constructively. @Chris I know some bigger projects using Extbase (though I don't know whether they make millions a day - is that important?). I don't know which references I'm allowed to name but we collected some project references for T3CON10. What would be more interesting to me: Lets look at projects that did not work out with Extbase/FLOW3 and find out why (and I'm not saying DDD is suitable for all requirements)

The problem is that "scale" or "big" is defined very differently by different people (and there is nothing wrong with that).

On my testing scenarios I came to the conslusion that extbase can perform ok with flat models.
Complex models are scaling bad at the time, but I'm sure the extbase guys will figure out a way to deal with this as well.

Development speed is another issue, but this can't be really measured, so it's no argument here.

I personally have a problem with extbase.
For very basic stuff (the generic record lister :)) it takes too long to setup (I'm done in about 15min the old way), the complex stuff does not scale good enough (personal concerns ofc, but RAM usage is something I look at while developing).

Regarding what Joey mentioned...
I guess we're beyond the point that extbase is the "only way" to do things - is was a communication mistake, we all learned from it. Case closed :)

Fluid on the other hand is really georgeous since it performs better, I only dislike it does not work without extbase being installed.
Now THAT would be a grand improvement.

So actually we are quite on the same track :-)

The problem we have is the result of phrases like "And Extbase is of course still the recommended framework for developing Extensions" - which is i.e. the first comment to this article - made by core team members.

Jochen Rau went a step further by telling that he won't develop semantics and other stuff for TYPO3 v4 anymore, because it would be a waste of time, since the future will be FLOW3 and Phoenix. (this has been about two years ago BTW)

Phrases like these have been presented in a similar manner at conferences and developer days during the last few years. And they might have been necessary from a marketing point of view.

But people don't read between the lines and take these phrases for granted, which lead to conclusions based on wrong assumptions. In the worst case, people were called amateurs, who are out of touch, and not hired anymore just because they didn't want to or were not able to work with extbase.

So the "extbase is the only way to program extensions" problem exists.

The fact that [the product to be named] won't be a direct successor/replacement of v4 anymore but another product of the TYPO3 community now contradicts these phrases. On the other hand this is the chance now to introduce improvements to both systems independently of each other. So while extbase would still be the way to go, which still should be updated and improved, for those who want to switch from v4 to the new product v4 itself should still use own concepts and paradigms other than DDD and AOP, since this would help people to find the right product for their needs.

This is why I would like to avoid too much assimilation of the two products, because in the end this would narrow down the options for each of us.

ok,
we got a website wit 50K+ pages, 1400 backend and 18.000 FE Users , 400-500 users online all the time. Teaser management is coded on extbase/fluid as well as business logic regarding partner company sites etc. . With extbase 1.4 it all performes very fast as we did some caching with the caching framework etc. No big deal. So I think extbase and esp. fluid can be used for good-to-high performance big sites.

I was unable to attend any of the Typo3 conferences, yet. But I'm running one of the companies using and trusting into Typo3. Over the years tyopo3 became more heavy because it was based on so old base code and core, so I can clearly understand why the team around Robert Lemke and Karsten Dambekalns decided to run this project. The new Phoenix will bring many advantages, programmer are mainly happy to hear about it. Furthermore I'd like to add that I am glad you run a blog here, reporting important insights on the progress. Otherwise I'd have hard time to figure out, due to being unable joining the conferences so far. So thanks and keep up the good work!

Good to get some clarification on this topic. We and some of our clients were confused too. To me it wasn't really clear, where and how the split between TYPO3 v4 and TYPO3 Phoenix could be properly explained. Thanks! :)