Hacker News Reader

Comment by karaterobot | Hacker News Reader

It's astonishing to me how many front end developers refuse to learn how to use vanilla CSS and Javascript, and the lengths they go to avoid touching them. I think of a lot of modern web tooling as a giant mech suit developers climb into to do battle with the underlying technologies of the web. There's so many layers of abstraction between you and the medium you work in, you can go your whole career without learning how to build a website yourself.

The original justification was 'scaling' (a word that stands behind a lot of bad behavior, actually), because you cannot just write bare CSS for a large production website, obviously. But then it creeps down the ladder until pretty soon your hobby website is a 20 megabyte SPA with 500 NPM packages backing it.

View on HN

It has never been easier to build web applications with a vanilla stack.

In 2010 there existed incredibly solid arguments for abstraction over the DOM. You had browsers with insane quirks and you had no choice but to support them. Over a decade and a half later, I'd argue we are in a completely different world. The only browser that bites my hand these days is Safari, and it's barely a nibble compared to what we used to deal with.

Those who adapt to the new reality will likely outpace those who continue to hobble themselves with rusty old training wheels.

As with any profession, most workers are just proficient in whatever they need to do. The people littering these things with comments about how Tailwind is "enough" are probably telling the truth for their personal experiences. A lot of web developers don't have professional experience working with designers and implementing software to visual specifications.

> and Javascript, and the lengths they go to avoid touching them.

I love CSS. I can make it do a tap dance and enjoy getting into the weeds with it.

JavaScript… is an entirely different ball of wax.

You see, I was there in the beginning, where major breaking changes in JavaScript existed not only between the major browsers, but also between point releases of the same damn browser.

I tried. Really, I tried. But after a few years I realized I had an epic case of PTSD where JavaScript is concerned, and to this day I see it as Lucifer’s own programming language, explicitly designed to drive developers mad.

What compounds this is a total refusal by the developers of JavaScript to do what every single other programming and scripting language out there has done copiously, and even eagerly - to deprecate old and obsolete features, and especially bad design choices. JavaScript does none of this, choosing instead to layer more inadvisable workarounds over already-traumatizing bad decisions.

Which is why I eagerly await the death of JavaScript at the hands of WebAssembly. Good riddance to a pox on the Internet.

I think you miss the point.

Having 25 developers trying to manage a CSS stylesheet together while naming classes does not scale.

Having 25 developers not worry so much about stepping on other people’s toes with Tailwind scales better.

Or in a nutshell: What is one of the hardest problems in CS? Naming things. What is Tailwind’s biggest feature? Build a frontend with minimal need to name things.

25 developers working in the same module? Without a common style?

Afaik we came from plain CSS -> BEM, because scoping styles was hard, so people found a discipline in naming things to isolate styling. Scoping did not exist in CSS.

Then we got a movement from BEM -> Tailwind, because doing the scoping by hand was a bit difficult(?)

Then we get Tailwind -> Tailwind + DaisyUI because Tailwind results in messy concretion.

--------

The question I have: are the modularity/scoping primitives in modern css good enough now, rendering Tailwind e.a obsolete?

Are we still using Tailwind because people do not understand the original problem?

Maybe someone can enlighten me.

Going from plain CSS to BEM more or less meant abandoning the "cascade" part of CSS. We've basically spent the last 15 years styling our markup directly, bouncing back and forth between different strategies for doing so in the most capable, and aesthetically palatable way possible.

> does not scale

CSS already has @layer; and @scope is coming (waiting for firefox).

There are naming conventions like bem. There are also tools to guarantee unique class names (css modules, 'single-file components' in various js frameworks).

There are design systems to standardize and reduce the amount of CSS.

There are web components, with their styles encapsulated in the shadow DOM.

> Having 25 developers trying to manage a CSS stylesheet together

As opposed to 25 developers trying to manage a React component together? I don't think that's feasible either.

Hence why companies adopt UI toolkits, otherwise it gets messy. Without discipline it's hard to develop a set of core components and often times devs will duplicate work and fail to extract common parts due to the nature of working on features across the stack and failing to recognize common patterns.

My point was, you use the language features to separate concerns into manageable pieces (which CSS can do just as well as TypeScript).

Tawilwind was created at a time when we were still feeling the IE days, triton was still a thing and people generally had to look up resets or how to setup tooling to help them with vendor prefixes (that was before Interop was a thing), etc. All this while, designers would ship individual design tokens for implementation (e.g. a button, a combo box). Things like “styled components” would feel like a relief because “oh I can style a button without breaking the entire website”.

Since then, all these points of friction have been improved or removed all together. We wouldn't lose anything if we revisit the platform and see how we can get all the benefits of tailwind without actually adopting it by default.

By the way, the same argument can be made about React and revisiting what one can do with modern DOM features.

I guess something all frameworks born in the past to solve real problems have in common - we tend to forget to deprecate them once the underlying need for them was gone.

Why on earth would you ever have 25 front end developers editing the same classes in the same stylesheet?

12 year old project, 2 developers per year, turnover every year. That’s all it takes.

> Having 25 developers trying to manage a CSS stylesheet together

Your comment suggests you mean 25 developers simultaneously

2 developers per year can easily maintain a coherent stylesheet.

CSS modules solved the classname collision problem years prior, though.

When people say "CSS modules", I never know which one they mean. There's a feature on the spec track for CSS "imports". There's also a family of webpack plugins with various behavior. CSS modules, collectively solved it a number of times with various trade-offs. You can even end up with multiple kinds of CSS modules in the same code base.

Hard agree, written Tailwind since the very inception. I love it for exactly this, the purging, JIT, arbitrary values, plus you can just write plain CSS any time you want. I have used Tailwind on big FAANG sites and boutique shops. Worked great for both, scales, and is very customizable.

Reply on news.ycombinator.com