Integrate a Sass Compiler

[hellofromtonya]

I'm a Sass gal. Bringing Sass compilation to Beans is a leap forward for flexibility and developer personal preference. UIKit 3 also brings us Sass.

Currently, Beans has integrated LESS compilation. Let's give developers a choice of LESS or Sass by integrating a Sass compiler.

[alexadark]

Uikit 2 also has sass, I made a child theme, with sass version

[hellofromtonya]

In talking with @ThierryA, we are considering moving to a browser-based JS compiler architecture and away from PHP. If we go that route, then we can begin testing the coverage and robustness of a tool like Sass.js.

Sass.js has a playground page for us to begin testing different Sass files to determine if this solution will work for us...or not.

If yes, then we can begin architecting connection points between it, Beans, and the server filesystem for caching the compiled file.

[ibes]

Do it via JS task runner eg. webpack, gulp, mix seems like the modern approach.

So make it a breaking change in V2?

Could that be a plugin?
Will different framework plugins need that sass part in core? Does there need to be less in core too?

How do we think developers use the setup?

In my workflow Sass -> CSS is something for my local development environment and for the deployment.
No fiddling around on source files in the live system in my hood.
Is Beans supporting fiddling around via WP editor? That makes a big difference for what the setup should look like - I guess.

In the practice I follow, the depolyment system is what serves the final CSS files.
And the deployment system is not on my computer. The depolyment system shouldn't have the need to start WordPress to do it's job as Sass/SCSS to CSS is quite a easy job (thanks to tools) that doesn't need to know much of the infrastructure.

I am still a fan of checking out tools like Gulp WP Toolkit or similar and see if that could be used or extended to be a good partner.
Framework plugins could bring there configuration for that build tool.
That way we could also offer minification and stuff.
And maybe offer some tests that could be extended through child themes.

[ibes]

Oh - "browser-based" means the server sends Sass and the browser compiles it when the site is loaded?
That sounds comfortable for development phase but like a mess for production.

[hellofromtonya]

Do it via JS task runner eg. webpack, gulp, mix seems like the modern approach.

@ibes So the difference with that approach (i.e. the local compiler through a tooling) and Beans is:

Beans compiles the entire application, i.e. plugins and the theme.

Think about that. You can set the global branding in your child theme. Then each plugin can use those globals for specific components that are within the plugin. It allows developers to build smaller packages without the bloat.

Beans' Compiler API works at the system level. Gulp, Webpack, etc. work at the local level, i.e. within a single plugin or theme. That said, you can build system-wide local compiling via gulp, webpack, etc; however, for us, we can't assume that the developer is compiling everything. Right? So we provide a Compiler within Beans.

Does that make sense?

[hellofromtonya]

Now as for browser vs. server side compiling, I'm not convinced yet about pushing it out to the browser. Thierry's has voiced interest in browser-side. So we're discussing the pros and cons, challenges, complexity, and future of either architecture.

We welcome all discussions and feedback.

[christophherr]

I'd like to hear more about the benefits and disadvantages of browser-side compiling vs. server-side compiling. E.g. performance, security, reliability, error handling, supporting documentation,...

[ibes]

@hellofromtonya
yes, makes a lot of sence.
Plugins should be able to access definitions from the child theme and the child theme should be able to overwrite parent theme / framework standards.
That sounds awesome.

And I understand why a framework intern solution will be needed for that.

About wording:
Browser based would really mean to ship Sass to the client and have the compilation at the client - not on the server, right?

Disadvantages of browser based:

• without JS the site will be destroyed
• not sure if the generated CSS can be browser cached (likely yes - at least with some local storage etc)
• should be a bit slower as there needs to be JS processing

A big question will be:
Where is stuff cached. Browser or Server.

On Browser side compilation:
Is CDN affected.
Hm, not really. Sass files can still be heavily cached. As long as the JS script to compile it is delivered together with the Sass files.

Sass and SCSS
Just to put it down once:
Sass has to specifications. UiKit 3 is written in SCSS. Maybe it could be helpful to write SCSS instead of Sass?!