This is a discussion that happened in Slack around the 8th of July 2018 but it makes sense to preserve it here. I did pretty much no editing, so formatting might not be pretty. Feel free to comment with your opinions on the topic.
Hey everyone I think the article at https://medium.com/@jmanrubia/escaping-the-spa-rabbit-hole-with-turbolinks-903f942bf52c is quite interesting - and it challenges whether one should “always” build SPAs. I am thinking if we maybe should support turbolinks and stimulus.js “officially” in Flow and use it in Neos for not so critical parts. I.e. the Content Module obviously makes lots of sense in React; and media module too, but for everything else this might be useful. Opinions, especially @mstruebing @dimaip @bwaidelich @christianm @robert @rolandschuetz @stolle @wbehncke (and everyone I forgot
That being said, I would still like to use AFX instead of fluid also for controller template rendering in all parts of Neos
Ok, my thoughts are still slightly unstructured. I don’t think turbolinks nor stimulus need any specific support in Flow if I am not mistkaken, you can just install them. That said, using basecamp for a while now, I a would go as far as to say turbolinks was a low hanging fruit for a pretty slow framework. Loading time for some of the XHR “turbolinks” is closing in on 1sec, so yeah if you cannot make your framework faster you try to create the illusion of speed. Fine for me, might be useful for certain applications. I don’t see it as a war between SPAs and turbolinks, there are so many steps in between really, and some of the “problems” of SPAs in that article are really specific or overblown IMHO. I don’t even necessarilythink we need SPAs for all backend modules, but what we need is not turbolinks so much as UI components that we can reuse when not building a react SPA.
tl;dr; separating that I personally find turbolinks meh, I think we don’t really need to focus on them but on giving people the choice to use whatever for frontend and backend apps/modules.
I would for example rather like to see http/2 supported better in Flow and Neos
Having a pure fusion based module-approach would be great but the major problem at the moment both for JS and Fusion based modules is the bootstrap css and js that is loaded by default. So the next step would be to provide a way for creating modules that only get the top bar with main menu from the core and otherwise mind their own business.
On top of that best practices for fusion / react or even fluid modules could be created.
I’m never worked with stimulus.js. It again another tool to learn. If the target are site developers (and not the core), there’s an overlap with @dfeyer ’s effort to bring web components to Neos.
Lib like pjax can make js more complex than necessary I agree with @rolandschuetz but for my web components experiments, first it’s an experiment, don’t block anything because of this. And I see no blocker to use web components with pjax style library.
About what we need for a proper and flexible backend module API. I’m not in front of my computer and there is tons of stuff to do. Get ride of bootstrap, allow module to have more than one controller (we promote fat controller here and it’s a shame). Backend module need to be flexible, build in fluid, react, ember, iframe wrapping of external tools. This is the place where client can put existing apps inside neos. That’s why I think web components make sense. We need a really slim backend API like suggested by @kopfaufholz and then build on top of that some more high level API for react, fluid, …
We’ve used pjax (and from skimming through the blog post, Turbolinks is roughly similar even if slightly more sophisticated probably) and it works quite well for the classical MVC architecture.
Personally I think that this architecture is overtaken though and currently I’m more into the JAMstack and/or API + WebComponents realms (unfortunately without a lot of real life experience yet).
Given the speed of change in these matters I think we should concentrate to leave Flow & Neos open to be used for all of these approaches as much as possible (i.e. rather providing good extension points than deciding for the one way that rules them all)
Thanks for your Opinions