It's often in comments in the JS file(s) -- sometimes with the licenses quoted entirely and sometimes in a form abbreviated by an automated code packer. Probably a lot of sites aren't actually compliant with the terms of the licenses doing things that way, but IANAL.
I loathe Tailwind. It offers absolutely nothing in advantage over plain CSS other than possibly development speed (but not re-development speed). I realise it's meant for frameworks rather than smaller sites but at some point you know someone is going to have to hands on edit that mess.
Theoretically, yet everything I make by myself turns out ugly with it. Tailwind has just enough constraints to protect me from my own dumb stylistic choices.
I'd also even argue that my source is less indecipherable - the challenge in reading CSS is not how it's laid out, but forming a mental picture of how the rules combine to shape your layout, and meanwhile, it does remove an abstraction that I was no longer using (in certain projects - I wouldn't use Tailwind everywhere).
Tailwind feels like CSS i have to re-learn. It's maybe slightly easier? mostly it just makes my html unreadable to the point i barely know what's going in anymore.
I don't do much frontend stuff but i'm gonna go back to plain old CSS for my next project.
It all sounds good in theory, but in practice, tailwind has been more work rather than less.
I feel like i put a fair amount of time in understanding how everything works too.
It just really feels like one of those things that makes little difference but i wasted way roo much time on trying to give it it's fair chance.
I've seen people advocate for Tailwind because "CSS is too hard, I don't want to think about selectors".
CSS isn't too hard, there are easy ways to do things, and hard ways to do things (for backwards compatibility reasons). If you don't learn modern CSS then you're only going to be doing things the hard way.
That's how i got sold on it too. My CSS skills aren't great, tailwind made it just slightly harder to deal with CSS i feel.
Seems healthier to learn actual CSS instead of abstracting it away if the benefit is that low in the best of cases.
Sure, large projects are a thing, but nobody puts a whole project in 1 css file anymore anyway, so what does it matter at that point.
I've seen people advocate for Tailwind because "CSS is too hard, I don't want to think about selectors".
Yep, those people are wrong :)
(I mean sure, you can sort-of mostly skip selectors if you use Tailwind, but selectors are about the easiest part of CSS. I've never heard of someone struggling specifically with those but not with e.g. layouts, stacking context, relative font sizes, etc.)
This person thinks Tailwind is just a grift to make money, prioritizes separations of concerns over all else (I contend they have SoC brain-worms, but I don’t want to get too spicy), and ignores all the actual arguments people use for Tailwind, like how it’s specifically built to suit component frameworks over someone raw-dogging that HTML and CSS. Their argument boils down to “get good” which is the argument that folks use when they’ve never been on a team and have never had to make actual trade-offs.
Their arguments included the size of the web page, and the time to display the first content, both of which were significantly better in Nue when compared to Tailwind.
By all means argue on what is important (because what is important for your projects may be significantly different from mine), but there were many points that the author was highlighting, not just the separation of concerns. And for my projects, all these concerns are important.
They’re valid concerns, for sure. I have less issue with this article in particular than I do with some of the other things he’s written. In the context of his other opinions, I feel pretty dismissive of whatever arguments he presents, valid or not. He’s extremely biased and I think folks have to take everything he says with a grain of salt.
There's absolutely a massive internal bias people have where they naturally believe that others develop the same kinds of content, when really it's half working on page based content, and half working on component based content.
Page developers know that putting their styles in the content itself is a disaster when you want to make a global change.
Component developers know that putting their styles external to their components is a dx nightmare because developers keep making changes that they think only affects one component when it actually impacts a different component (and that change might not be found until months or years later).
Both are correct.
The real problem is developers thinking that there are only two methods for making styles: external css files, and tailwind/atomic styles in class names.
Component developers should have their styles inside their components, but not inlined in style attributes (like in tailwind).
Component developers should instead place a style tag inside their component that is scoped to just that component.
So let's say you're making an accordion component.
Make your html+js/jsx like you already do, and add an "accordion" class to your component's root element. Now add a style tag in your component with a single selector targetting the .accordion class. Now you can use nesting to style anything in the accordion exactly how you want. Want to style something based on whether an element is open or not? Use an attribute selector. Want to style something based on whether it's child is doing something? Use the :has() selector. etc...
If you're making a widget system, use container queries. If you're making a card system, use subgrid.
There's so many obvious use cases that modern css provides for, so use modern css! and not any of this BEM or tailwind nonsense. Now your css is so much smaller, robust and more maintainable.
Follow up questions:
Q: But I don't know modern CSS
A: Learn, it'll be much better for you in the long run compared to using tailwind, then needing to learn something else once people switch off tailwind for something else.
Q: But wouldn't putting a style tag in every component mean that there's going to be two style tags on the page if I put two of the same component on the page?
A: It'll only do that if you make it do that. Most component based frameworks are already set up to reduce repetition, check your framework's docs. (e.g. react's many css-in-js solutions, web component's :host selector, vue's <style> and <style scoped> elements, SSGs like Eleventy have Asset Bucketing, and even native html is getting it's own solution this year with @scope).
My spouse (senior fs) just started using Tailwind at work for a new project where he's having to rewrite a component library they have and daily he comes to me to say how much better working with Tailwind is.
I (also senior fs, mostly SSGs and Laravel applications) had a similar revelation coming from componentized, precompiled BEM SCSS - I thought Tailwind was weird, verbose, dumb, and bad until I actually used it.
I got to the point pre-tailwind that I was abstracting most of my design elements out, anyway. (Fuck the custom form elements my clients demand.)
Tailwind just starts you at the point of "I abstracted everything" and trusts you to be DRY.
Oxygen builder is weird as fuck, especially on top of WordPress' already weird data structure.
If you were considering WordPress I would just stick with Elementor because it's the most popular builder. You can also use https://proelements.org/ to try out the pro version without having to subscribe.
Hmm, I watched the Oxygen video https://www.youtube.com/watch?v=7yae8GvpPVo where they build a webpage and it doesn't seem weird to me. As a Squarespace user, it seems more familiar to me than the Gutenberg editor. For example, setting the spacing of two side-by-side elements with Gutenberg seemed really strange. They were spaced really far apart without an obvious way to reduce the spacing.
proelements
Interesting! That looks like a completely free version of Elementor Pro. It looks like it's not on the official Wordpress plugins site https://wordpress.org/plugins/search/PRO+Elements/ though. I read that makes it more risky.
I would 100% use Wordpress. It's far and away the most mature option with the most diverse ecosystem of plugins. That survey you linked to is hardly a controlled study. I bet a lot of the folks using Wordpress would have low satisfaction with other CMSes.
Also, part of the problem there is that that Wordpress ecosystem is highly enshittified and monetized (probably contributing to dissatisfaction, especially with people who were messing with Wordpress ten years ago and remember what it was like when there were a million cool Open Source plugins that did what ever you wanted for free). But there is still a lot you can do for free if you know your way around it.
You can get ChatGPT to write code for you, and it does some things very well, but don't use it if you don't know how to code yourself. It's asking for trouble of both the "security vulnerability" kind and the "I don't know how to put all these pieces together" kind. The best advice is not to deploy any AI written code that you don't understand. AIs confidently make mistakes and get stuff wrong all the time.
One thing that ChatGPT IS good at is pointing you at Open Source plugins.
There IS a big security concern with self hosting Wordpress, but wordpress.com's hosting is pretty affordable.
Given your use case and the fact you seem willing to spend a little money, I think Wordpress with Divi is a solid choice. There are lots of good Divi tutorials on Youtube.
It's more expensive than Squarespace which is a main reason I chose Squarespace in the first place. I created a test site today to experiment with Wordpress and it seems that Wordpress has as much or more functionality than Squarespace, but much of it is hidden behind 3rd party addons, which may or may not be free. And you basically have to look up articles for "how to do x on Wordpress", whereas with Squarespace it's build-in and easier to accomplish.
So I think for people starting out, Wordpress is harder to use since you don't even know what it's capable of.
Divi is more expensive than Oxygen, so if I use something other than Gutenberg it will probably be Oxygen.
WordPress.com is horrendous and extremely expensive, and their practices are scummy. Divi is also fucking garbage. That other user has no idea what they are talking about.
The article doesn't include the information that it uses Nuemark, "a standalone library that works under Bun, Node, and Deno", written by the author himself. It "comes with a set of built-in components aimed at addressing the most common content management use cases" and is part of Nue, which the author markets as "A perfect framework".
There is one mention of Nue, in the original comparison, and another at the end under "What is nue?" - Maybe it's "expected" that the reader knows the author is using Nue and shouldn't need to make it clear, as the blog is hosted on nuejs.org, after all. Not the best practice to omit that, tho.
But what really annoys me is people making "minimalist" sites using FUCKING JAVASCRIPT FRAMEWORKS. Use a fucking markdown -> html converter
I spent the last week learning and then writing technical docs on tailwind for my org. I was skeptical of it at first, now I have an informed dislike of it.
I often interact with people who don't like something but haven't used it before, so I'm definitely going to steal your term "informed dislike" to distinguish between those cases and ones that are legit gripes.
It doesn’t sound like you want a static site generator. You want a Squarespace alternative. One option I use is Ghost. You can host it yourself for free. But it’s not a static site. Static site means static. That means no backend, no forms, none of that. You won’t get a CMS, you won’t get drag and drop components. That’s not what static site generators do.
I’m a developer, and WooCommerce, in my opinion, is pretty great. Just like Wordpress, if you look at it more like a development framework, is pretty flexible on what it can do. If you’re not a developer and don’t want to touch code, just buy the plugins you need and go from there. Pretty nice compromise tool between flexibility and ease, although if you have a really tiny budget, the plugins can add up.
How does it compare to the developer experience of Shopify? I hated Shopify. Unforgivable that there wasn't even a way to have a dev environment, but this was a few years ago.
I'm also a developer. My job has me work with WordPress almost exclusively. I run hundreds of WordPress sites and the hosting servers that run them.
WordPress is not good, nor is woocommerce. They are, however, convenient to the layperson. That's basically all they have going for them.
WP and Woo are major resource hogs. The data structure is atrocious. There is no ORM and everything is shoved into two tables: posts and postmeta. All your pages, blog posts, products, orders, form submissions, everything is a 'post'.
99% of all plugins are horribly written garbage that are major security vulnerabilities and updates to patch those security holes frequently break everything.
WP sites require frequent maintenance to keep them updated to avoid those security issues and since you never know when an update is going to break the whole site you have to do so carefully and make sure you have lots of backups.
Automattic, the company that makes WooCommerce, is scummy as fuck. Just recently they released an update that added a new cookie which triggered firewalls, and made this new feature on by default. They also are selling all WP.com and Tumblr data to be used for AI. Not to mention the fact they intentionally confuse people into thinking WordPress.com is the same thing as WordPress.org, and since the CEO also controls WP.org they can get away with breaking all the rules of the 501c3 nonprofit's own rules in doing so.
I'd written a plugin for WooCommerce as part of working on a B2B service. It was several years ago now, but from what I remember it seemed quite easy to write plugins for because it just used WordPress's hooks system.
WordPress isn't the fastest codebase around, so you'll probably need to spend more on hosting to get it running well enough, but compared to other PHP e-commerce offerings like Magento it'll fly.
I also came here to say Woocommerce, I helped a small retail store set up their shop. I will say if someone doesn't have ongoing support I could see hiccups appearing eventually if you have any kind of customization. There's just a lot of plugins and things you can tweak. But that ability to customize means you can do something just the way you want it, vs bending a system like Shopify to try to fit edge cases.
I don’t have a favorite one and I love decentralized tech so I forked Lemmy to try and repurpose it for that. Honestky, I would have done it in Haskell or Purescript had the Lemmy devs not gotten as far as they have been with Rust.
It probably can’t have 1:1 feature parity with Shopify (actual commerce being handled on pub/sub would be a nightmare) but I at least intend to broadcast inventory changes using (a variant of) the pub/sub protocol. Instances will theoretically be run by vendors (or alliances of vendors).
I’m at the VERY early stages. I’m currently trying to build Lemmy using nix to declaratively glue together the patchwork they use to build it. I figure having it continuously roll with the original would be helpful for this rapidly evolving pub/sub world.
Web Development
Active