So now we have no shipped preferentially treated extensions and we lack some way of distributing these. We already have TER and it works wonderfully (but could use a performance checkup). But what TER doesn't have is an official way to indicate that an extension is worth while; a favourite of the community proven to add value. Twitter has the "verified" badge, Apple's App store has the "Featured Apps". TER has a download count and graph which by the way lacks a time scale.
Why don't we introduce a "recommended" and/or "official" flag on TER? Allow such extensions to be listed specially. Raise them as top priority for suggestions. Ship the core extensions from our Swiss army knife as "official" extensions. And let the community decide which ones will get that distinction; not some arbitrary number hits from an Apache log (sincerely, no offence! I realise exactly why the solution is the way it is and I respect it! I only wish to make it better).
There's another perspective here. It's almost a tradition in TYPO3 that if XYZ does not fit our exact intention, we go ahead and roll our own. If we got around this and were able to pipe efforts into improving existing solutions I am certain we could all benefit. The examples are plenty. I don't mean to appear arrogant or hipster about this, but again: in my experience FluidTYPO3 and before that, FED, were first movers - later on joined by other alternatives like Gridelements and DCE (the former of which is at least planning to adopt the principles of Flux). This is nothing personal against those projects or their teams but they're solving the same problem already solved by FluidTYPO3. But they all make the same mistake of not relying on convention-over-configuration and not fully utilising the powers given to us through Extbase. If these efforts had gone in one direction instead, imagine where we could have been now?
So the second perspective is: having a way to selectively recommend extensions might encourage the pooling of efforts into those extensions. I hope FluidTYPO3 to be among those selectively recommended, but that's up to the community. But I digress into meta - ever so slightly.
(taken from https://fluidtypo3.org/blog/news/open-letter-call-for-conventions.html)
On the subject of Fluid and Flux: My vision for Fluid. The idea of DataProviders is fine but the problem is a different one - namely to have a shared approach to embedding metadata. It is incorrect to approach this as a question of flexforms vs. TCA. Flux does both of those when used correctly.
Jo, you spoke about a session to determine a possible future for a nested content model in TYPO3. I'd just mention here that Flux already serves this exact purpose. I furthermore have the idea for a new TCA field type which contains grid definitions exclusively. Of course written in a way that is able to consume multiple types of inputs. Again, Flux's PHP and TS APIs make perfect sense for that.
Flux can be your DataProvider and it doesn't have to be used as ViewHelpers. To quote myself:
With Flux I tried to not roll our own but make an API/interoperability for TCA that allows multiple sources to be consumed. IMHO this is a better approach than your "just write TCA" preference. The idea here is portability - TCA is the opposite of portable.
Like the article says, Flux has transparent APIs for TS, PHP and Fluid. Some apply in any framework, some only apply in TYPO3 (so far) but the essence is: it has the APIs that could work in other frameworks than TYPO3. But that's not really the point of this article - it's more two new discussions:
I'm happy to discuss either one in the vision article but it really (also) should be discussed on internal gatherings.