2023+ Vanilla CSS Methodology

[Jonathan Lahijani]

Given that CSS has made huge strides in recent years combined with my desire to remove build processes (Sass, Tailwind), I'm thinking about going back to writing vanilla CSS, at least for some projects.  My question is, what CSS organization methodology makes the most sense for vanilla CSS?  I was never a fan of BEM personally and haven't had to think deeply about CSS methodologies for the past 10 years because I just followed the style of whatever CSS framework I was using.

[wbmnfktr]

I played around and worked a lot with Astro in the last few months, and one thing I really liked was working with <Components />.

Right now I try to move my experience from it towards my PW/Twig/Latte setup.
Some parts work pretty well, while some things don't work out as expected.

Splitting parts isn't that easy in PW, when using PW and Tailwind. Due to the missing build-step. But ok. I can live with it.
When using plain CSS, this could be a totally different thing. Yet the CSS and JS isn't scoped. Boooh!

I didn't use plain CSS for about 18 months now - which is wild, as I was a plain-CSS-advocate since always.
But I am working on it again, which feels super awkward on its own right now, as PW is totally different compared to Astro or the tools I used in the last months.

I could imagine using <Components /> in one way or another using Twig/Latte and some ProCache-magic... I could minimize CSS way more, yet I don't know if all that is really necessary.

For what I can tell right now... each release with PW and JS/CSS is way bigger than in Astro, as PW has no real page-based build-step.
That's fine for me, as most of my projects are super minimal right from the start and get 4x 100 in Google Pagespeed.

To be really honest... I am at a point right now in which I really don't care about the last 100-500ms in a pagespeed tool anymore when I at leat get the 94 scores for each step.

Addional note:
Right now I work on a 11ty/Astro setup that loads all data, pages, and structure from PW in JSON-format.
Loading all data (from https://www.restaurants-neumuenster.de/) takes about 1-2 seconds in total while building all pages, data entries, and everything else takes another 3-5 seconds. It works, yet I don't like the result somehow. There are things I really don't like and have to fix in JS/Nunjucks/Liquid or some other parts of the setup.

Right now: I focus really on optimized PW Twig/Latte workflows and for minimals sites using JSON using 11ty/Astro as frontend layer.

[Ivan Gretsky]

I am long-time used to writing bem classes. They feel natural to me. But earlier this year I was also looking for more modern alternatives (that could be used without build step). Here is a nice article by Dave Rupert I've found on the topic. Didn't try any of it (yet?) though.

[ngrmm]

I write vanilla css. Well thats a lie ?. I write scss, but only because of lacking css nesting support. I guess in 1-2 years there should be a browser-support over 95%.
Nesting is the only scss-feature i use. Everything else is vanilla css.

Compiling scss to css is done by ProCache.
I'm not a real programmer and have design/art background. Therefore i try to keep my workflow as simple as possible.
In my projects I have to develop some „unusual“ layouts and many times the designs change a lot during the development. Therefore over the years the following distribution of files has worked for me pretty well.

_reset.scss
_fonts.scss (@font-face and sizes as classes)
_globals.scss (color-variables, animation-classes and other global classes)
_main.scss (for body and main element if needed)
_header.scss
_footer.scss
m_component-name.scss
…
p_template-name.scss
…

I don't use components, but my section/article tags have always a unique classname, which correspond with the related php/css/js files. For Example for a image-slider i would have there three files:

m_image-slider.php
m_image-slider.scss
m_image-slider.js

.m_image_slider {
	width: 100%;
}

Should there be a need to overwrite some styles on a „project“ template, I can do that in a file like
p_template_project.scss

body.template_project {
	.m_image_slider {
		width: 50%;
	}
}

And if there is a need to have two different layouts for the image slider on two pages with the same template, I use the page ID.

body.id_1234 {
	.m_image_slider {
		width: 80%;	
	}
}

Therefore my body tag has always these two classes:

<body class="id_<?= $page->id; ?> template_<?= $page->template; ?>">

That workflow helped me a lot to save time. Most of the the only my section tag has a classname.

.m_image_slider {
	h2 {
	}
	figure {
		img	{
		}
	}
}

What I want to say is that css methods have their justification and use. I do not work in teams and as single programmer it is much clearer and flexible to develop my own small method. 

[Jonathan Lahijani]

On 9/8/2023 at 7:04 PM, wbmnfktr said:

I played around and worked a lot with Astro in the last few months, and one thing I really liked was working with <Components />.

I've heard of Astro and a bunch of other JS heavy frontend frameworks where ProcessWire has to become an API for it to work.  Hard pass for me for so many reasons.

On 9/9/2023 at 2:32 AM, Ivan Gretsky said:

Here is a nice article by Dave Rupert I've found on the topic. Didn't try any of it (yet?) though.

This article is exactly what I was looking for.  Thank you for sharing it!

21 hours ago, ngrmm said:

I write scss, but only because of lacking css nesting support.

It seems nesting is available on all the latest browsers, but I'd worry about people on old versions of Safari due to being on old versions of macOS (Macs seems to last a while), so yea I agree with using a build process for now if nesting is critical to the way you write CSS, which it is for me as well.  Also, doing breakpoints in SCSS in much more intuitive than vanilla CSS.

[wbmnfktr]

On 9/10/2023 at 4:57 PM, Jonathan Lahijani said:

Hard pass for me for so many reasons.

I have had the very exact thoughts about this for quite some time. 
What are your reasons here, beside super heavy JS-frontends (React, Preact, Nuxt, Next,...)?

[Jonathan Lahijani]

Just now, wbmnfktr said:

I have had the very exact thoughts about this for quite some time. 
What are your reasons here, beside super heavy JS-frontends (React, Preact, Nuxt, Next,...)?

That's pretty much the main reason.  It would require me to use ProcessWire in a different way and I don't buy into that approach, especially with HTML Over The Wire (for example, htmx) giving me all the benefits of heavy JS-frontends without having to use them.  Server-side rendering all the way.  I've completely eliminated Node from my workflow and it feels great.

[wbmnfktr]

Wow... that's fascinating in some way as I just made my move back to good old ProcessWire with some nice additional extras. Like TailwindCSS and AlpineJS - HTMX is on the list - but that's it. So, yeah... still some Node.js and build scripts involved but that's fine for me.

I even moved some small sideprojects from 11ty and Astro back to ProcessWire just because it's way more solid, real, or something like that. Can't describe it.

Weird I enjoy ProcessWire right now way more than 12 months ago just by using totally different tools for a few months.

[Ivan Gretsky]

10 hours ago, Jonathan Lahijani said:

That's pretty much the main reason.  It would require me to use ProcessWire in a different way and I don't buy into that approach, especially with HTML Over The Wire (for example, htmx) giving me all the benefits of heavy JS-frontends without having to use them.  Server-side rendering all the way.  I've completely eliminated Node from my workflow and it feels great.

@Jonathan Lahijani, would you mind elaborating on this a bit? How do you manage your frontend without node based build chain? I am very interested as I am moving along a similar path, having ditched gulp. Now I do not even concatenate my js leaving it to http2. The only thing i still compile is scss) How do you do it nowadays?

[szabesz]

14 hours ago, wbmnfktr said:

AlpineJS - HTMX is on the list

If Unpoly was non existent I would sure use AlpineJS + HTMX these days. However, https://unpoly.com/ does exists and to me, having to use only one technology instead of two (or more) is very important. The fewer I have to deal with the better. More importantly, easy upgrade path is essential, so no wonder I am not willing to leave ProcessWire :)

[elabx]

9 hours ago, Ivan Gretsky said:

@Jonathan Lahijani, would you mind elaborating on this a bit? How do you manage your frontend without node based build chain? I am very interested as I am moving along a similar path, having ditched gulp. Now I do not even concatenate my js leaving it to http2. The only thing i still compile is scss) How do you do it nowadays?

I'm also very interested in this answer! I feel I'll never leave compiling SCSS/Less in PHP, even it means using an outdated subset of Less, it's just so convenient!

I'm very sold on HTMX + AlpineJS, main reason being it saves me from the build step. 

[Ivan Gretsky]

6 hours ago, szabesz said:

If Unpoly was non existent I would sure use AlpineJS + HTMX these days. However, https://unpoly.com/ does exists and to me, having to use only one technology instead of two (or more) is very important. The fewer I have to deal with the better. More importantly, easy upgrade path is essential, so no wonder I am not willing to leave ProcessWire ?

AFAIK unpoly does not have an analogue to AlpineJs. In fact, unpoly users seem to also adopt AlpineJs for the frontend stuff.

It is more a complete (and more opinionated) replacement for htmx though.

[Jonathan Lahijani]

10 hours ago, Ivan Gretsky said:

@Jonathan Lahijani, would you mind elaborating on this a bit? How do you manage your frontend without node based build chain? I am very interested as I am moving along a similar path, having ditched gulp. Now I do not even concatenate my js leaving it to http2. The only thing i still compile is scss) How do you do it nowadays?

My use of Node was as follows (well it was based on Laravel Mix):

• downloading packages (package.json / node_modules); for example, getting UIkit, jQuery and whatever else a project required
• compiling SCSS or Tailwind
• creating a dist folder with that CSS, other compiled JS and images
• cache busting

As for downloading packages, I have my own ProcessWire module that contains unminified and minified versions of the packages I commonly use or that I deem to be worthy enough to be in the module.  I built a very simple way to update those packages and include them in my project as well as well.  UIkit is a special case in that it's both SCSS and JS files.  If I want to include HTMX for example, I just do this:  setting('htmx-enabled', true); and everything gets inserted as it should.  The potential drawback of this approach is that because I use this module across many different projects, all projects automatically get upgraded to the latest version of a package which could potentially break things, but that's rare and not a big issue for me.

For compiling SCSS, I would have stuck with ProCache (SCSSPHP) but it's completely outdated and that's just not going to change.  Therefore I use DartSass.  You can download the executables here:
https://github.com/sass/dart-sass/releases
I've hacked ProCache (because it doesn't have the necessary hooks) so that instead of using SCSSPHP, it uses DartSass.  Ryan has expressed the ability for ProCache to be more friendly to using outside compilers so hopefully a future version of ProCache doesn't have to be hacked directly.

As for Tailwind, during dev I use Tailwind Play CDN.  During production, similar to DartSass, I use TailwindCSS CLI and I hacked ProCache to make it work with it as well:
https://tailwindcss.com/blog/standalone-cli
https://github.com/tailwindlabs/tailwindcss/releases/tag/v3.3.3

Both DartSass and TailwindCSS CLI have minifiers built-in, so therefore I avoid using ProCache's CSS minifier which has been a a little buggy (although I think it's now fixed?).  Technically speaking, TailwindCSS CLI is Node.js under the hood, but it's wrapped up into one executable which feels clean.

For what would typically be a "dist" folder, I just avoid that.  ProCache Buster handles that in its own way.

8 minutes ago, Ivan Gretsky said:

AFAIK unpoly does not have an analogue to AlpineJs. In fact, unpoly users seem to also adopt AlpineJs for the frontend stuff.

It is more a complete (and more opinionated) replacement for htmx though.

Yea these is how I think about it as well.  HTMX is less opinionated and I like it that way.  However HTMX is not the "JS sprinkles" (it's more for HTML over the wire requests) so that's where Alpine.JS comes in.

[szabesz]

25 minutes ago, Jonathan Lahijani said:

35 minutes ago, Ivan Gretsky said:

AFAIK unpoly does not have an analogue to AlpineJs. In fact, unpoly users seem to also adopt AlpineJs for the frontend stuff.

It is more a complete (and more opinionated) replacement for htmx though.

Yea these is how I think about it as well.  HTMX is less opinionated and I like it that way.  However HTMX is not the "JS sprinkles" (it's more for HTML over the wire requests) so that's where Alpine.JS comes in.

While Unploly is definitely more opinionated for sure, that's also its strength and weakness at the same time. If someone starts using AlpineJs along with Unploly, then that person should use HTMX + AlpineJS instead in the first place.

While Unploly is definitely more opinionated, it does not mean that based on Unploly is not possible to implement the same features that one would implement using HTMX + AlpineJS. You just need a completely different mindset when using either this or that.

By using HTMX + AlpineJS one gets a sort of "lower level" solution while Unploly provides "higher level" tools. Using high level tools has the benefit of also dealing with documented conventions out of the box, while building upon a low level tool requires you to put more work in your documentation. High level tools has the drawback of sometimes having to find workarounds for different use cases, while low level tools introduces less of such issues.

I don't want to persuade anyone to use Unpoly, but I want to mention that I use and love it, particularly because upgrading to major versions is always backward compatible. (Backward compatibility support extends to the previous major version.)

[Ivan Gretsky]

@szabesz, I am quite with you as I have been toying with unpoly and htmx a bit, and understand quite well that one should  sometimes work hard to achieve with htmx something that comes with unpoly out of the box.

I was just saying that AlpineJs has a different purpose (Js sprinkles, jQuery replacement) and is used with either htmx or unpoly.

[Gideon So]

unpoly is good! I used it in some of my project and I really love it.

The tailwindcss standalone CLI is another wonderful tool, too.

Gideon

[wbmnfktr]

On 9/14/2023 at 12:42 PM, szabesz said:

If Unpoly was non existent I would sure use AlpineJS + HTMX these days. However, https://unpoly.com/ does exists and to me, having to use only one technology instead of two (or more) is very important. The fewer I have to deal with the better.

I don't want to hijack this topic too much, yet I have to ask.

Is unpoly worth the ~50kb?
Even combined are AlpineJS and HTMX less than that. And there would still be a place for BarbaJS.

I use AlpineJS in bigger projects that have quite some heavy lifting in terms of JS-needs and are more than just a simple website.
HTMX looks pretty fantastic, yet I didn't build more than a few simple proof-of-concept projects with it for now. Which is sad.
Smaller projects get the VanillaJS-treatment and JS is down to less than 5kb.

unpoly looks super interesting but the ~50kb are such a bummer.
That's more than the average page size without images.

[szabesz]

10 hours ago, wbmnfktr said:

Is unpoly worth the ~50kb?

If you are concerned with file size like that then you can use CDN (https://unpoly.com/install/cdn) conditionally: load local files when CDN is not available.

Unpoly also have advanced caching, so by using that properly your site can behave more like an application then a website by providing (almost) instant responses.

(As a related side-note, I also agree with this certain forum user on this forum: https://forum.bootstrapstudio.io/t/bootstrap-css-and-cleanup/10578/2?u=szabesz)

As for my own experiences, I have not yet implement the conditional usage of CDN but the e-commerce site I developed using Unpoly for its frontend JS magic is loved by customers, partially because of the easy to use user interface I crafted for them, and partly because of the speed of the site, even though it loads full Bootstrap 5, full jQuery and also Unpoly (plus my CSS and JS, of course). Sure, browser and Unpoly caching helps a lot! About half of the users use their mobile phones to place orders and they are equally satisfied.

I just cannot showcase the site because currently it is for contracted customers only. There are plans to open it up for the average retail customers as well (on a different domain) so when that is in production, I will probably provide this forum with my very first showcase. (In 1 or 2 years... as I have loads of other projects to finish before I can start working on that.)

Edited September 16, 2023 by szabesz
typo

[Gideon So]

@szabesz

Can't wait to see your work with unpoly.

Gideon

[szabesz]

On 9/17/2023 at 9:59 AM, Gideon So said:

Can't wait to see your work with unpoly.

So far, I've been working on the locked-down part of the site that I am using Unpoly for (so I cannot showcase that), but this will change in the near future.

In the meantime, here are some great examples that other developers using Unpoly have started to share with each other:

https://github.com/unpoly/unpoly/discussions/666

Edited September 5 by szabesz
typo fix

[szabesz]

FYI:

A catalog of hypermedia-driven websites built with HTMX, Unpoly, Turbo or Twinspark:
https://hypermedia.gallery/

Aside from the JS tech behind these sites, eTransfer seems worth trying.