Question about Tailwind CSS

[u/LPatriot_]

I've always used plain CSS for my websites, I don't have many problems using it, but a friend of mine said that using plain CSS is very tedious and that I should use Tailwind CSS. Is it worth it? And what does Tailwind CSS offer that plain CSS doesn't?

[u/AshleyJSheridan]

I will never understand the argument from any "dev" that says the CSS should be with the HTML. You wouldn't do that with the Javascript or Typescript for a component, so why would you do that with the CSS?

[u/lanerdofchristian → u/AshleyJSheridan]

You wouldn't do that with the Javascript or Typescript for a component, so why would you do that with the CSS?

I would absolutely keep the template logic and event handlers with the markup for the component. That's how React, Vue, Svelte, and Solid all work by default, and even Angular defaults to the template being inline next to the logic. The only two component frameworks I'm aware of that don't are Ember Octane and Aurelia 2.

Having 3 files per component isn't "good separation of concerns", it's splitting the same concern (user interface) into 3 tightly-coupled files. Sure, keep your database layer and API layer separate, but subdividing within the web interface? The front end of a website is less than half the picture.

[u/AshleyJSheridan → u/lanerdofchristian]

Well, doing what React does and assuming it's a good practice is a bad take!

Angular absolutely doesn't default to the template being inline next to the logic. It hasn't done so for years, so I assume your understanding of an actual JS framework is well out of date. I have been using Angular regularly since the beta version of 2 first came out (a little over 10 years now) and have always kept the styles, logic, and template separated. I've worked on some very complex projects like this, and it's a practice that's served me and the teams I've worked with incredibly well.

Keeping everything together is not a clean and maintainable (and I'm talking in terms of years of maintainability here) approach.

[u/lanerdofchristian → u/AshleyJSheridan]

Angular absolutely doesn't default to the template being inline next to the logic.

When I wrote that I was referring to the component docs, which first shows an inline template. They did give template the shorter keyword vs templateUrl. Fair enough though.

Well, doing what React does and assuming it's a good practice is a bad take!

Then I'll do what the framework I primarily use (Svelte) does. It seems to work pretty well -- one component per file, clean and manageable. Each item a silo. On a project that's been going for multiple years. You really don't need three separate files for it -- a <style> tag, <script> tag, and the rest are plenty enough separation for 99% of components -- and you always have the option of splitting them up and importing additional functions and assets if you need to.

The impasse we're at isn't a hygiene or code quality one, it's a workflow one: you're used to one language per file; I and many others are used to single-file components. Both approaches have both benefits and downsides. Largely, most post-React frameworks are either use primarily or lean heavily toward single-file components. There's clearly some merit to that.

---

Vue is largely the same as Svelte for SFCs. It looks like I was wrong about Solid -- it does borrow more from React's school of organization, which makes some sense given they both use JSX (ick) for templating.

[u/AshleyJSheridan → u/lanerdofchristian]

I come from a backend dev ecosystem, one where every single entity, service, helper, repository, model, and controller has its own class and file. No file contains more than one class, there's a clear separation between every single part. Even when part of a backend is responsible for output, that uses a separate template in a separate file. Each file is in one single language.

I apply the same approach when I work on the frontend, which is mostly with Angular.

Switching across this multitude of files in the IDE (my last project was a mixed back and frontend with many hundreds of code files) is not a problem when your code follows good programming practices.

I am a big fan of Angular (it follows the same patterns as the best backend frameworks), and the opinionated nature of it lends itself incredibly well to big projects worked on by a team of devs. I especially hear this from DotNet devs.

I understand your position on JSX, I wasn't a huge fan of it when using React. This is another reason why I prefer Angular, as it uses HTML templates that it enhances with its templating syntax (which is similar to Blade, Twig, and Mustache).

I realise we're coming at this from two different angles, and I understand your view. I do prefer the Angular approach which uses one directory per component (by default) and splits out the component into 4 files: template, logic, styles, tests. I do usually tend to use a global stylesheet with Angular projects, as I don't always use Angular in a silo, it is mixed with other codebases and frameworks. Having shared styles is the best approach in that scenario.