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.
@sebastian wrote:
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
@christianm wrote:
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
@mficzel wrote:
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.
@sebastian wrote:
Ok - absolutely makes sense what you are saying thanks @christianm for your thoughts!
@rolandschuetz wrote:
I’m not sure if it keeps the promise or not. I have build websites like codeq.at with smoothState, a library very like pjax. It’s speed is fast and you can have nice transitions. The JavaScript logic get more complicated than expected in the beginning. Your code needs to follow a similar pattern to how we has with the JavaScript Neos.PageLoaded event. Without a clean JavaScript design pattern complexity can become quite complex. Of course still way less then SPAs.
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.
@dfeyer wrote:
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, …
@bwaidelich wrote:
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)
@sebastian wrote:
Thanks for your Opinions