TYPO3 Fastlane (An idea)

Archive Initiative Ideas
1

TYPO3 is a sound CMS that has been around for quite a while now… ooh the joys, the tears, the beers and for us Developers, the struggles, the challenges, especially to keep up with schedules and to up our game. It’s like we have this sinister approach to our work - nothing is too high, nothing is too wide, nothing is too tough - there’s nothing that can’t be done. Our motto has become ‘we shall find a way’ because TYPO3 doesn’t always give us a way. But only if we can get there, fast enough! Faster. Oh, the need for speed. This ‘finishing it faster’ is where every confidence of nearly every TYPO3 developer hinges upon. Putting bread on the table, for some of us, depends on how fast you can get it done. There’s a lot of work out there. But, can you get there?

TYPO3 Fastlane

Think of the relationship of TYPO3 Fastlane to TYPO3 CMS, to what AMG is to Mercedes-Benz - The performance arm. It’s an idea, an initiative, to put Developers of TYPO3 on the fast lane. Think of it as the performance tuning arm of TYPO3 CMS. We come out with our guns blazing - our tools. We pick the newest version. We come out of the salon. It’s a wild west out there. We stare. We spit. We plan. And get down to work. We gut out those slow parts from TYPO3 CMS and we put in more horses, better tires, better steering wheel, more buttons, more throttle, more cameras and of cause, better manuals. We don’t lose ANY functionality. No setting is lost. Nothing. Developers and End-users don’t miss a thing. They don’t notice a thing - except - it’s too light, too fast, too secure, too stable, too beautiful, too awesome, and… it shines! TYPO3 developers say ‘Thank you! Thank you!’ in award ceremonies after award ceremonies.

In a nutshell

TYPO3 CMS has its goals cut out for it. It has its milestones, things do, to achieve into the future. TYPO3 Fastlane says, we are here to help you do just that. We’ll take care of the mundane, the mediocre, things you overlook - like your belly is getting fat, you can’t fly with that weight, those shoes need changing. We’ll do your hair (appearance), take care of your suit case (backend), will take you to the gym, you’ll see the doctor, go through your check-list one-by-one, cross-checking it with you.

Goals

  1. To greatly reduce TYPO3 CMS’ weight. It’s possible to reduce it down to below 10 MB, or there-about. Would be great if possible to reduce it to below 8MB.
    • By combining common functions
    • By Getting rid of unnecessary code
    • By Getting rid of unused code
    • By reducing overheads (the law of irreducible complexity)
  1. Improving performance
    • Updating used Technologies - like JS, etc.
    • Improving technologies where necessary
    • Restructuring/Creating Information infrastructure
    • Polishing code
    • Modularization
    • Updating code
  1. Improving security
    • Improving checks
    • Suggesting checks
  1. Improving data storage & handling
    • Simplifying working with databases (without losing any functionalities)
    • Improving where necessary
  1. We document everything
    • Blueprints - All plans
    • Technical papers (white papers) - Explains every class, every function, every shortcut, etc.
    • Editors’ manuals (Owners’ manuals)
    • Developers’ manuals (cook books/TYPO3 bible/Bugs)
    • TYPO3 Encyclopedia (Showcases histories, tricks & hints, glossaries, Installation notes, who’s using typo3, screenshots)

Offsetting the load

There’s no chance in hell this can happen. But let’s say it does, then the first time would be the most difficult and then from then on, most things would remain consistent. Who would comprise TYPO3 Fastlane? The same TYPO3 architects, site developers, planners, leaders, TYPO3 programmers, all of them - on a voluntary basis - in their spare time - with deadlines. How would it work? There would be groups. A member could be in multiple groups. Everyone would chip-in on ideas volunteer code, experience, best practices, etc. - groups would execute code, plans, etc. - documenters would document. A request for ideas and competing examples to choose the best way forward. Ground rules: use the latest technologies, reduce dependence on JQuery as much as possible - those with skills on these areas can volunteers to create new functionalities that replace old ones, document everything, deadlines - just a few examples.

Would it compete with TYPO3 CMS? No. Just follow behind them. If the final version is satisfactory, it succeeds the current version just like any other release and TYPO3 CMS team can continue from there. We only improve it once a year. They do their best, we pick up what’s left behind. However small steps that can be taken would greatly help in some areas.

Well, I don’t know, just an idea.

2

For reference, a concept I did some years ago now - https://github.com/NamelessCoder/TYPO3.CMS.

Goal: reducing the overall size of TYPO3 and reduce the interdependencies, thus allowing a TYPO3 installation to consist of an absolute minimal set of “core” extensions (in the case of my concept: core, frontend and backend). This also has tangents to headless CMS. A sub-set of the concept is to replace certain parts of TYPO3 with PSR standards (e.g. the cache layer).

What you’re essentially proposing is a fork of TYPO3 and I’m inherently against making forks. That said, there’s nothing wrong with making concepts for how we might, for example, reduce the size of a “minimal” TYPO3 installation by first removing non-essential features and then shipping those as add-ons.

Disclaimer: I am currently TYPO3 core merger with the focus areas of Fluid integration and performance (a sub-set of which is caching). If you have concrete suggestions to improve performance then I’d be more than happy to hear about them!

3

Man. You’ve been hard at work. I’ve read through your README.md goals in github. And all these you did four years ago. Impressive. I was thinking in the lines of combining Frontend, Backend and Core into one. For examples, (1) Create a universal HTML service (2) combine backend and frontend typoscript (central processing). (3) built-in single AJAX processing usable by both front and backend - more like routes - via PSR-15. (4) centralize security

I don’t vouch for forks, spin-offs or spawns either. Am completely against them. I was thinking in the lines of clean-up sessions. So everyone chips-in or emails or posts their ideas. Final ideas get selected. The selected ones get planned for then implement, all within a short period of time line 3 months - once a year.

Your ideas to contribute directly to the core teams is ok. But wouldn’t that interfere with their work? Let’s say I make a small suggestion tomorrow, say…, I don’t know…, working with page ancestry chains. Where would I post it here? You’d get it here?

4

https://docs.typo3.org/m/typo3/guide-contributionworkflow/master/en-us/

I guess this is what you are searching for.

Also consider https://typo3.org/community/teams for a basic overview what teams we have

5

The main problem about not working directly in core contributions is the problem of reintegration: the more changes pile up outside, the less likely it is that they will be integrated. Let’s say there’s a long-running feature branch which receives 20+ commits - in order to finally suggest this to be merged into the core, it has to be squashed (and therefore very, very well documented since history becomes truncated). It also has to be possible to understand as “one unit of work” to give the reviewers/mergers a chance of actually understanding what merging a given proposal implies. Then there are the secondary concerns - CI runs unit, functional and acceptance tests that also have to be working, and these are notoriously difficult to manage externally.

The best chance for merging is obtained by:

  1. First of all discussing the potential change with the core team to explain why it is necessary and gain pointers on the proposal. Getting an initial verdict of the feasibility, basically. TYPO3 has core mergers for many individual topics - you can find a list on https://typo3.org/community/teams/typo3-development. I’m aware that some suggestions don’t fit neatly into a single area so you may need to get a couple of group chats going in Slack.
  2. Making the changes as smaller units of work, ideally ones that can be merged one small unit at a time. The proposed global scale refactoring is probably not going to be possible to achieve this way.
  3. Keeping changes completely up to date, which means continuously assimilating all changes that happen to upstream - and this is very hard work.

This is also why a “fast lane” working group would have quite a hard time getting their work done. You’re already onto some of it (3-month cycles) but I doubt that the larger changes would fit with such an optimistic cycle time. Some of the changes could easily be 6-12 month full-time projects, keeping in mind that things like acceptance tests also have to be preserved/adjusted. It’s a lot more work than it looks like on the surface.

Best suggestion I can give is, write down a vision for it (and be concrete!). Then try to plan out smaller units of work and their interdependencies - and then work (alone or in a group, doesn’t really matter) on each of those units of work in the right order. Once this is done, a wireframe for the work can be created as a series of issues combined under a single epic, which gives onlookers a way to see what has been done and what needs to be done, as well as understand why X is being done (part of a larger plan).

And before anything else, get feedback on the overall vision, then on he segmented plan.

This absolutely will not happen. It was tried once before, with the mythical TYPO3v5 (you may have noticed there’s a hole in the version sequence) which was attempted as a TYPO3 association-funded project. That ended up violating the working group’s stated compatible-successor principles and became a separate product now known as Neos. I couldn’t in my wildest fever dreams imagine that this would be risked a second time. It may have been the most costly mistake ever made in TYPO3’s long history.

6

If you have or can form a team of developers, architects and documentation writers who are willing and able to improve TYPO3 you can just contact the team (maybe best to contact Benni) and offer their services. TYPO3 wants to become faster, more lightweight and so with improved or current functionality. There is no need to have some parallel world to achieve this. Every improvement can be submitted as a patch, perhaps in cooperation with an existing initiative that covers a particular area.
If you look at the releases from the past years it has been mentioned with each major version that it has become faster than the previous version.
So, by all means get those developers and others together and submit those patches! The documentation team also needs your improved documentation and you can easily make a pull request for those changes.

7

The documentation part above is written in mostly general terms, but I want to give my two cents:

  • Technical papers (white papers) - Explains every class, every function, every shortcut, etc.
    You mean something like the former api.typo3.org, which was shut for a list of reasons? https://decisions.typo3.org/t/shut-down-api-typo3-org/355
    I don’t see much a value in documenting every single class, function, etc. Sure, you can automatically generate such documents with a docblock parser, but not every part of TYPO3 is considered “public api” and you can get much more (and less misleading) information on a class or function by looking directly at it with an IDE or even on github.
8

Actually it is alive again: https://api.typo3.org/
The front page still uses the old layout and 10.4 is missing.

I’m 100% with you. Also everyone can use tools on his own if in need. E.g. doc parsers, IDEs, etc.

9

I am still not sure what exactly you are proposing here - from what I understand, it should not be a fork of the code. Is it just a group of people who are focusing on the points you raised (reduce, performance, security, etc.)? Isn’t that what the core devs are already doing?

Isn’t most of what you are proposing already being done, e.g. polishing code, modularizing etc.?

So, I can’t say much about the idea - the points you raised seem valid. What I see a lack of is personpower - there is just too much to do and not enough people doing it. I don’t see a lack of people with good concepts and ideas (see answers by Claus).

See also (inactive) Datahandler & Persistence Initiative:

Timing: Unknown due to missing team resources.

On a side note, you raised the topic of documentation … - also in your other thread

Others keep getting worse like lack of proper documentation (what TYPO3 calls documentations are actually mostly white-papers),

?

We document everything

Even more docs that must be kept updated … (see also changelogs - most of the changes require changes in docs)

From my end and what I heard from others - the documentation has gotten better. Feedback is good, but vague feedback is, well, too vague to be helpful (the same goes for praise which is also mostly given without concretely naming what has gotten better or is already good).

IMHO it is an impossible (!) task keeping up with updating docs with current resources and improving it substantially at the same time (e.g. structure, missing manuals, more getting started tutorials). I would probably agree with most of your critique points - the question is how to solve it.

My suggestions:

  • give concrete feedback on documentation as issue(s), either in manual repo (see “Issues” in footer on every docs page) if specific or in homepage repo if general, ideally with concrete suggestions on what to improve and how
  • if this is an initiative idea: break it down into concrete objectives and milestones. And, I think it is too much - every single point you raised could be an initiative by itself.
  • address the IMHO main problem (!) of missing resources - how can we incenticise participation (for longer duration than just the next patch)?

p.s. Claus, like the Gurpgork concept (don’t know about practical application) My personal dream: make it possible to install different backend or individual components with drop-in replacement