Future of the Standard Storefront #4856

Thank you very much. A centralised component system is a good step.
I would like to take the development side or the agency side, which is primarily concerned with an improved development experience and a stable rollout in productive environments. We would have liked to proceed according to the KISS principles (keep it simple stupid). I'll just put together a brainstorming session

• We would like to have a stable switch that completely deactivates the on-the-fly theme adjustments in the backend => VCS / CI mode

• The configuration of a frontend (which themes are active, theme configuration, plugin configuration, inheritance) should be able to be done in the code so that a status can be checked in VCS

• Asset / frontend paths in the public folder without hashes (we understand the idea, but it is overcomplicated)

• Zero dependencies in the frontend process to database / Redis / etc. The code alone should be sufficient for creation

• fewer small template blocks, less inheritance, but rather more extensive template files (less click work, faster templating)

• maybe you should think about a completely detached twig theme (contains only TWIG files) and a base styling theme (contains only the assets) and leave all the PHP classes in a core plugin. that would be a great start for custom themes, and blocks away a lot of complexity

• give us FIGMA files for the complete base theme

I fear that the rewrite of templates and plugins to the new component system will be a huge effort and a lot of flexibility will be lost.

I would like to see a practical example of how this works. Inserting or exchanging content via slots - no problem and makes sense.

But how do I adjust the price in the example above - e.g. to hide it under certain circumstances? This hardly works with slots. If the entire area is a separate component, I have to replace it completely with one of my own. In the worst case, I only have to replace one line - but then copy 30 other lines of code from the original component. And then check this “duplicate code” again during Shopware updates and adapt it if necessary.

In my opinion, this is the same problem as with the private methods in the PHP core. Sometimes I have to copy a lot of unnecessary (private) methods in my plugin just to adapt one line of code in a public method. This would be much more elegant and update-proof with protected methods.

And I fear the same problem with the component system.

In contrast, the following is absolutely the right direction for me:

• Getting rid of the SCSS theme compilation
• Getting rid of Webpack and the general need for bundlers
• Reducing the amount of Shopware custom CSS

"Components will not be part of a multi-level inheritance system. Delivered components will always stay as they are, apart from the slotted content and exposed configuration options. Instead, a typical extend mechanism could be an option where you create your own custom version of another component, but which will always be a separate component."
Well, first of all, here should be something that shows which components are in which slots—like dump(slots) or so—the most annoying thing these days is writing a theme before all plugins are set up and then maybe overwriting a block, which has not been used by a plugin but then is used later on, but no one realizes this directly.Those component-driven slots must be set up in a way where the developer can see what is assigned and then create an own block in which all preceding components are to be imported, included, or set up.
The component approach itself seems a good idea, but this has then to be introduced with an option to stay oldschool and keep all up and running. I don't know if the difference between block and slot is just some kind of old wine in a new hose, so if you give it another name, but technically it stays the same. So I would introduce another template part where the dev can switch by configuration between standard and the slots.
regarding the blocks "right now."Those are set too few in my point of view. and plugin devs just put their stuff right into a block, without an own custom named block and an include, that is going to bring up the content additions/changes. This way, it is quite easy to insert adaptations.
scss rendering: if the system would stick to the convention that scss-files with underscores in the file names are to be included and the ones without generate an own css file, it would already be more easy to just import/bundle what one needs on a page basis, without the overhead of non-used css. It can be bundled, hashed, cached, and so on, but on a true page base, depending on the components used in there. 

Hi, first of all, i think it's great that you have an open ear for your community! the idea with the slots sounds very interesting. i am looking forward, how it will actually be in the daily use process. especially regarding the development of own CMS Elements / slots.
I personally think that removing scss is basically the right thing to do. nowadays CSS is already very strong and can already implement many things from scss. so scss Compiler ist not needed anymore. however, I would ask that developers continue to have the option of using scss if they want to. Bootstrap: In the long term, you can certainly do without a CSS framework. The elimination of jquery was the first step. and If you want to get rid from SCSS it's the logical next step (bootstrap relies on scss)I estimate that in max 2 years the use of a CSS framework will no longer be necessary. the Future of Shopware will be very exciting

I come from a project developer's perspective. I do care about plugin developer but this is not my daily biz.

We cannot get rid of the inheritance feature as other parts of the applications are likely not covered by Twig Components and still need overwrites. See document templates, comparison sales channels and email templates.

Vue like slots are already possible using Twig embed ( soon sw_embed #4980 ).

Twig really helps us to add just content, where you likely will not have a Twig component: the entrypoint for the administration SPA see https://github.com/HEPTACOM/HeptacomShopwarePlatformAdminOpenAuth/tree/500eeba261c5b450cad27d401980bb5f59fae6f8/src/Resources/views/administration

Symfony Twig inheritance AFAIK is not aware of shared bundle overwrite approach like you have. Otherwise you would not have had to implement it yourself ( halbherzig :/ )

I think we still need some processor to either ensure backwards compatibility and minify assets. I see that saberworm css is slow and likely one does not want to use it. But I fear, that entry-level extension providers seeing the easy development and those, who intentionally write well-formatted code with comments, will lack a well packed JavaScript or CSS in their shared code.

The Twig components need to have their own CSS file so they feel like components. We really like the way to re-compose styles by just dropping styles and collect some files and overwrite some variables. The variables are default CSS now but it reads like we will only be able to overwrite CSS by specificity instead of removing it. Maybe theme.json will just become even more powerful.

I feel, that the Twig components come really handy with ESI in combination and we can make better use of the cache.

When we have a development mode which just symlinks the assets into the public folder we likely can just edit files in the browser and have live editing without to reload (let it reload from a watcher). That would be great as in-browser-style editing has been really good these days.

I am in doubt of the adoption. Plugin developers need to adapt this change and you have to either have a big-bang or a way to have both. Looking to the different headless based UIs they are not really supported by plugin vendors and I am not sure whether this work well. The bootstrap 4 to 5 change was already heavy. The removal of csrf_token was heavy for support of two major versions. I do not want to stop you from doing it. But it is just one bumpy ride.

And this does not just affect plugin developers. It will also hurt project developers indirectly and they won't see it coming: If you just work on projects you likely do not have to look into release candidates. They likely will just make an update when required (new feature, end of life, …) and then they have to evaluate the costs of an update.

Oh sorry dear shop owner, the update from 6.2 to 6.3 with the elasticsearch rewrite is heavy. We need to change a lot.
Oh sorry dear shop owner, the update from 6.4 to 6.5 with the Bootstrap 4 to 5 upgrade makes us to check all theme changes.
Oh sorry dear shop owner, the update from 6.5 to 6.6 with the VueJS 2 to 3 upgrade we need to change the administration components, that are now even worse to change with less TwigJS blocks
Oh sorry dear shop owner, the update from 6.6 to 6.7 with the accessability rewrite makes us to check all theme changes.
Oh sorry dear shop owner, the update from 6.7 to 6.8 with the enforced meteor makes us to add core hacks to add allow our previous changes
Oh sorry dear shop owner, the update from 6.8 to 6.9 with the new Twig components forces us check all plugin conflicts as inheritance is now dropped. Likely we will not use any Community Store plugins anymore and have to write everything ourselves for a better project compatibility

This feels like we have to build a new shop each year for each shop owner. I understand, that this is the issue with technical debt, framework development and a question of support an agency provides by knowing these updates and their way of handling these. The estimation/prediction for the future is also exaggerated. But these are costs each year, that shop owners face. I assume I will read/hear the phrase "We did not have these high upgrade costs with Shopware 5. When we had a plugin for 5.1 it was still working with 5.6" each year again.

Thank you for giving us the opportunity to give feedback ✌️
I would like to specifically address the SCSS part here:

Getting rid of the SCSS theme compilation

If Shopware moves away from SCSS, several critical functionalities currently enabled by SCSS would no longer be possible:

Theme Configuration and Variables:

Shopware themes heavily rely on SCSS variables to dynamically control aspects like color schemes, spacing, and typography. CSS variables alone are insufficient to achieve the same level of dynamic customization because SCSS variables are processed during compilation, allowing for conditional logic and calculations that static CSS variables cannot replicate.

Mixins and Functions:

SCSS mixins and functions, such as contrast() or color-ratio(), allow for complex color calculations that automatically adjust based on theme configurations. For example, the contrast() function ensures WCAG-compliant contrast ratios by dynamically selecting the best matching colors according to the colors set in the theme configuration. Without SCSS, these dynamic calculations would be impossible, reducing both accessibility and design flexibility.

• The color-contrast() function is vital for calculating color contrast based on the theme’s configuration. Losing this function means themes would no longer dynamically generate accessible color combinations. For example, when a customer sets a dark background, the theme cannot automatically adjust text or element colors to meet accessibility standards.
• SCSS if-else logic is critical for generating conditional CSS based on theme configurations. For instance, checking whether a color is transparent and applying different styles would no longer be possible, limiting the ability to create truly dynamic and adaptable themes.
• Conditional statements also play a key role in preventing unnecessary CSS from being compiled, keeping the codebase lean. Without this functionality, developers would need to rely more on utility classes, which increases code complexity and bloat. Additionally, adding such classes in Twig requires more overwrites and block extensions, leading to more maintenance and the risk of conflicts with third-party extensions that overwrite or remove necessary classes. This makes the entire system more fragile.

Bootstrap Integration:

Bootstrap, which is a foundational framework in many themes, relies heavily on SCSS for its theming and customization. Moving away from SCSS would break this integration, making it impossible to use Bootstrap’s responsive grid system and utility classes, which depend on SCSS variables and mixins for dynamic customization. It would also mean that overriding Bootstrap variables would no longer be feasible.

// Define a CSS variable for the primary color
:root {
  --primary-color: #007bff; // CSS variable for the primary theme color
}

// Overwrite Bootstrap's SCSS $primary variable with the CSS variable
$primary: var(--primary-color);

// Bootstrap uses the $primary variable to define theme colors
$theme-colors: (
  "primary": $primary,   // This replaces the SCSS $primary with the CSS variable
  "secondary": $secondary,
  ...
);

// Example of Bootstrap button styling
// This will cause an error during SCSS compilation due to the use of the CSS variable
.btn-primary {
  background-color: $primary;  // Sets background-color using the CSS variable

  &:hover {
    // The 'darken()' function expects a SCSS color variable, not a CSS variable
    // This will throw a compile-time error
    background-color: darken($primary, 15%);  // ERROR: Cannot darken a CSS variable
  }
}

Precompiled CSS

Many of these dynamic styles rely on runtime theme configurations. Delivering precompiled CSS using static CSS variables alone would not provide the same level of flexibility. SCSS compilation during production is crucial to maintain the flexibility and functionality of current themes. These functionalities are not easily removed, as they are integral to how the themes work and are essential to their success. It’s not just about losing the convenience of reusable code—it’s about themes no longer being able to function as intended without SCSS. This change would lead to frustration among developers and customers alike, undermining the ecosystem rather than improving it.

Hello Community,

Thank you for all your feedback. I am closing this discussion in favour of our new content system prototype.
It is the next step on our journey, and I would like to invite you to review the prototype and share your ideas and feedback.

#13806

Thank you very much.