Your reply is the real cringe here. "I got shit to do" is no excuse to toss aside quality and craftsmanship. And you misread their argument they didn't say write everything from scratch, they said write a simple leaner version, but the argument is most people lack even basic problem solving skills. If you spend all your day glueing things together, you forget how to design and build them yourself. Sure you can stack the blocks in order, and make a really tall tower, but how soon until it falls over, or how will it withstand the first gust of air. That's the larger point. And this isn't "gatekeepy" this is reality. As software continues to eat the world, and most of us are forced increasingly to rely on these shitty apps and interfaces, it could do a little good to the world if Software engineering as a discipline took on a little more professionalism. So less of the "I got shit to do" and "move fast and break things" mentality, and more of the "lets do this right" mentality. Good engineers can write a little utility that solves a problem wonderfully for their context or scope, and still get their shit done and meet their goals.

It's kind of gatekeepy insisting on styled components being of lower quality than using pure CSS. Styled Components serves a specialized purpose of styling things on the web.

Maybe less elegant or performant in some respect than pure CSS, but with trade offs that some development teams will happily take.

I also hate the sentiment, that software development needs to adhere to some notion of purity or divine elegance. And yes, I'm using the word divine because people like the grandparent comment keep acting like CSS is the church. It may well be, for some, but there's a reason why CSS is getting new features continuously... Because it's not perfect for every purpose across every development department.

Talking about this makes me sick.

Eh, I'd say it's a valid use case as any.

Maybe someone just didn't have the time confidence or interest to learn CSS. Maybe it's as simple as doing what you want, doing what you can afford to do, etc.

What I don't like is the negative framing of this choice. Bad things will be built, regardless of the underlying tools. Grandparent claimed that using Frameworks results in bad practices. I claim that shaming people and questioning their choices (whether they made them consciously or unconsciously) is a bad practice.

I dunno. Maybe. How about the practice of removing a test that fails? Literally, test fails, remove it, problem solved. Ship it. Sure there are build warnings, but CI isn't complaining, so..? Is that a valid use case? If your team member did that, you'd be cool-and-the-gang, easy-like-sunday-morning, shaming-is-the-real-shame?

You're trying to reframe my argument in a bad way.

I'm talking about people deciding to use a certain technology with tradeoffs.

You're talking about people going against quality standards of a development team. And that's where I end the conversation, you bore me.

Not trying to reframe anything. Just trying to understand the bounds of your ease with team members making these decisions.

I haven't been hostile to you or anyone who disagrees with me, by the way. Just trying to understand if and where I'm incorrect.

Furthermore, I said what I said in reaction to someone disliking the idea of Svelte being able to use any javascript library at all because of the chaos and bad practice that represents.

> You're talking about people going against quality standards of a development team.

That's what I've been taking about this whole time

I hear you. It's a balance. You grab a library or open-source project, boom! Done. Move on dot org.

Except later, maybe your project needs some custom functionality. Now you have to dig into docs to see if it's possible, then deeper into the source code to see if you can monkey patch using something undocumented. Maybe now it takes more time to cobble together what you need than wiring something lean from first principles. Understood the full import of the dependency from get.