As I'm working on the tedium of onboarding refinements, which is kind of like eating a bowl of rice a grain at a time, I'm researching frontend stacks and design systems.
Our frontend stack is currently a hodgepodge of a sass bootstrap theme, css modules, and react-bootstrap. Some of our plans require lots of frontend malleability, which our current stack cannot easily support, so we'll be upgrading the stack as part of those plans.
Frontend systems have evolved a lot over the last few years. Developers have accepted that CSS is a mistake and headless (ie unstyled yet accepting of styles) component libraries have been dialed in. Modern frontend stacks have two independent layers now: styling systems and component libraries. If you aren't fully prompting your frontends, picking a frontend stack requires making a decision for each layer.
What do you use for your frontend stack? Are you happy with it? Have you thought about switching and what might you switch to?
These are some of my thoughts on these layers, which have me leaning toward using stylex for styles and base ui for our component library.
stylingstyling
CSS's hidden cascade is its biggest problem, brought by isolating form from function, presentation from content. CSS styles content from multiple origins at a distance. CSS's isolated yet cascading abstraction is an oxymoron.
Tailwind's classname postcss DSL soup is the most popular solution for this. But, it treats CCS's disease with its own. If the problem with CSS is the hidden cascade, what's needed is styling that lives with the content. Tailwind's classname soup isn't necessary, nor are its ex post facto ideologies forbidding abstractions of style.
css-in-js postcss systems solve this problem too and without the classname soup. Like styling with tailwind, styles in css-in-js reside with the content. With css-in-js you can build the themes, utilities, and token systems using functional javascript. The main tradeoff is that css-in-js has more, however obvious, footguns than tailwind. For crafty programmers, if you trust yourself to avoid the footguns, you can avoid CSS modules' and tailwind's tradeoffs.
headless component librariesheadless component libraries
There are a lot of these, many of them are excellent on the important fronts, and the good ones are tree shakable, letting you cherrypick components in a one-off fashion. Still, each of them have subtlety different APIs, patterns for accepting styles, composition, event handling, etc, so I imagine the preference is to lean on one component library as much as possible.
Choosing a component library, once you decide to go headless, appears to mostly be about choosing an API that you like. Other than that, they seem to compete on the component library's completeness and the team/activity/philosophy like any other open source project.
thinking is datedthinking is dated
I realize that thinking is going out of fashion, but at least for now, I have resistance to quitting.
The alternative to all of this is to prompt your frontend entirely. It might use tailwind, and it might use radix, or something else, and what do you care. You can prompt a new component in the time it takes to hit your vape.
Or ... making good decisions about concepts matters more than ever.
tailwind + shadcn
has been really nice so far to work with
I hear good things about both!
it has been nice to work with but defo not without it's trade-offs, some of which are already mentioned here.
it looks like the underlying radix ui library that powers the original version of shad is no longer being as actively maintained, and there's some concerns around that in the twitterverse.
it looks like shadcn devs are moving towards base UI over radix. and migrating would probably be a pretty painful experience since a UI library is so fundamental to an app.
good little vid i watch by Theo a few months back covering that:
https://www.youtube.com/watch?v=vHFZFXtjKNE
but at the end of the day, i find just not having to think about the fine details of UI to be quite nice, and instead being able to focus on the bigger picture stuff instead. i don't wanna spend hours fine tuning how a slider works etc etc.
however, down the line it might become a problem, but by then if it's a real problem will ideally have more resources to tackle the it
How the slider works is a headless component thing (radix in shad). Shad just couples styling presets with the slider which is most of what I don’t like about shad.
Also shad is already beginning to add base ui components too - they live alongside radix. They abstract away components really well, so as shad user you shouldn’t notice the transition.
that's a nice clear definition, you've obviously done the work to inform yourself. im not sure i could have given such a concise definition.
you can definitely migrate away from radix to base ui piecemeal, but for each ui component you migrate, you may need to change every place that component is used because the ref forwarding / asChild prop behaves differently.
in practice, all of the styling presets are customisable so any decision that shadcn made can be overridden. it's just a starting point. and with tailwind + class-variance-authority this becomes a breeze
however if you do modify your shadcn ui components it makes upgrading to the latest versions fiddly because you need to cherrypick your changes and apply them to the updated shadcn component.
Lately I've been preferring Pocketbase/Pocketpages/Datastar/Bulma.css. It's sqlite based, server rendered html which is not right for every project but it's been handling my mid-sized website really well. (5K-25K requests per hour on a $20/mo VPS) I prompt a lot of it-- GPT-4o mini is good with ejs and bulma.
That sounds really interesting! I hadn’t heard of that
It never ceases to amaze me what a shitshow the front end is. I was doing a lot of front end work as react became popular. I stopped using it based on a job change and what the fuck is happening over there nowadays? I use svelte sometimes and that feels OK, but also very weird at the same time.
I guess I’m not happy with any of it? Haha
Did you see the tailwind media not long ago about having to lay off a majority of their workforce?
It amazes me that it works at all. A frontend is like a function that takes the human body as input. The shitshow is the input, the humans, not where the code is located.
I saw that. I loved their book and they get a lot of stuff right. Selling licenses just isn't the business that it used to be.
Frontend: pure HTML5, CSS3 cascade, vanilla JavaScript.
Backend: express with node.js
BD: Sqlite if static info, postgresql if nees to keep data. (this is sth I am testing more right now)
That is all you need.
I've been working with .net (C#, VB), Android native (Java), Angular, React, Vue, and others... and the easiest and most scalable and mantainable is pure code.
Remember to KISS (Keep It Simple and Sweet)
What is the backend?
nextjs/graphql/postgres/lnd/opensearch
Wow that is a lot! Do you use a lot of dependencies? Like those npm packages ?
We have quite a few dependencies yeah. They pile up pretty fast.
take a look at shadcn/ui, you might enjoy it
I'm familiar. It makes decisions like those I discuss in this post, being a non-headless component library. I don't like the decisions it made.
yeah, i get your points. but putting the presets aside, shadcn/ui could be a nice bridge
If the migration is the headache, why migrate to a bridge to migrate somewhere else? Like, which property makes shadcn/ui a good bridge vs going straight where I want to go?
personally, i think it’s great, but i called it a ‘bridge’ because from what i read in your post, you seem a bit hesitant to fully switch. it could be an easy way to try things out while keeping control.
maybe i've been unclear, but i'm trying to validate my decision to switch to base/stylex - not deciding if i should switch. i'm trying to think through what systems properties i want, attempting to avoid use this thing generally everyone uses by default without understanding the tradeoffs (and let's be honest, vibing and dgaf for the most part)
i know i don't want to use shad already. it's perfect for people that want presets and want these decisions to be made for them, and i get you can customize it too. that's what boostrap was for a long time, so i don't have anything against that.
having some experience being an end user of enshittified 3rd party libs now, I'm trying to pick things i'd be happy to troubleshoot/review/maintain myself. i want to provide the abstraction layers - which i will probably vibe too tbh, but at least i'll understand them.
by chemistry analogy, i'm looking to make my own molecules so i'm looking for the right atoms/elements. i'm not looking for a premade molecule.
maybe i should be looking for a premade molecule though. i just don't see much reason to start there when i can vibe my own molecules.
I don't do front-end really so I can't help you validate frameworks, but:
If you want to have something that is maintainable without leaving up in the air whether something truly works, then I think that this is key.
I went around looking at some things people made with
base uiand much is awesome... until I do it on my phone, then half of it breaks. This lead me to maybe an abstraction of this:When automating coding, well thought out architecture of both the product and development processes becomes really important. I'd say this would be including comprehensive CI and human QA.
Frontend you mean something related to web dev
you might be surprised to discover how many "apps" these days are actually an entire webapp [server + client + renderer] bundled for running locally... this discussion applies equally to them.