9 ms·
Technical debt in CSS seems to be both more inevitable and less problematic than application code. By the time it becomes a problem, either marketing decides on
by blowski 5y ago
Technical debt in CSS seems to be both more inevitable and less problematic than application code. By the time it becomes a problem, either marketing decides on a redesign or the latest frontend lead wants to use a new framework.
So “screw it, this works” seems to be an entirely justifiable methodology.
- meerita 5y agoOOCSS leads you to technical debt. The bigger you become, the easy you land into techdebt.
- orwin 5y agoOO leads to technical debt in most cases. You can limit it to a narrow scope (interfaces), or you can have objects that wont move or inherit much (bascially if the parents can be replaced by traits), but someday someone will try to be clever and your team will soon enter OO hell. Bonus hell points if you allow third-party plugin in your software (shoutout to Jenkins!).
- madeofpalk 5y agoThis is why, as someone who loves writing CSS and thinks they're reasonably good at it, I've come to the conclusion that writing CSS is an anti pattern, and if you want teams to quickly build interfaces with a maintainable "frontend styling layer", it should prevent the ability to write css.
- felipemnoa 5y agoWhat would you recommend instead of CSS?
- bamboozled 5y agoTailwind
- eurasiantiger 5y ago… which is a CSS utility class library and thus suffers from some of the same pitfalls. How about something like Ant Design?
- svachalek 5y agoUnless something major has happened to it since I used it, Ant uses a giant ball of SCSS with complex selectors that make it ridiculously hard to customize without hacking the source.
- eurasiantiger 5y agoHacking is exactly what we are trying to avoid. Just change the variables to suit your branding and compile the SCSS yourself, just like Bootstrap (which was using LESS but otherwise the same idea).
- bamboozled 5y agoNever been an issue for me. I hear this a lot though, it's probably not for everyone.
- madeofpalk 5y ago> complex selectors that make it ridiculously hard to customize without hacking the source. This, to me, is a feature. Don’t customise it.
- xeromal 5y agotables
- madeofpalk 5y agoIt must be CSS in the end, but you should create/use a component library, that has the right set of primitives (and less-primitives) that lets end feature developers create the UIs without having to resort to manually write CSS. THis is made significantly easier when you have designers working with this "design library" mindset also.
- alwillis 5y agoI've come to the conclusion that writing CSS is an anti pattern I don't think this is true. The biggest problem is people who write CSS do it as if they want CSS to be something else and are trying to force it to be that. Writing CSS using ITCSS (Inverted Triangle CSS) [1] solves so many of the issues devs complain about it. It's simple: create layers in specificity order. Don't fight the cascade; make it work for you. Writing good CSS isn't about getting the syntax right; it's about getting the architecture right [2]. Harry Robert's video does a great job of describing all the pain points ITCSS solves [3]. [1]: https://dev.to/carlillo/understanding-itcss-real-case-using-itcss-in-a-ghostcms-blog-1p9b https://dev.to/carlillo/understanding-itcss-real-case-using-... [2]: https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/ https://www.xfive.co/blog/itcss-scalable-maintainable-css-ar... [3]: https://www.youtube.com/watch?v=1OKZOV-iLj4 https://www.youtube.com/watch?v=1OKZOV-iLj4
- madeofpalk 5y agoI think the problem is that just not that many people know how to write good css and good JavaScript. So I try and just require them to only know JS. I think it’s hard to hire lots (…hundreds) of developers who’s going to know CSS well enough to not screw it up.
- vlunkr 5y ago> Technical debt in CSS seems to be both more inevitable and less problematic than application code Nicely put. I've stressed over finding unused rules, restructuring, etc. but in the end it never matters as long as it displays correctly.
- rectang 5y agoThe big problem is knowing all the places which could be displaying incorrectly when you make a change. This is a fundamental design issue with the cascade: unbounded silent failure because rule activation is implicit. In addition, there is the difficulty of inspecting those sites which you can identify to verify that display is correct, which is hard to achieve programmatically.
- xiphias2 5y agoIt's not inevitable. I love Svelte partly because it solves the problem by compartmentalizing CSS to the UI component I'm working on. It feels natural that if I write CSS in a file for a component it shouldn't be seen by other components in general.
- ravenstine 5y agoEven without Svelte, most of the problems people have with CSS go away if you do the following: - Avoid cascading (i.e. no nested selectors except when there's "no other way") - Implement separate selectors for styling and page/component layout (separation of concerns) - Using a good naming convention and stick with it The first point can also be achieved with using style attributes if that floats your boat, although Svelte kind of gives you the best of both worlds just by compartmentalizing the CSS, not necessarily by preventing cascading. I can't remember the last time I ever had to use !important except when I had to work with some ridiculous CSS "framework" my predecessors chose to use. At least !important was understandable back in the days when it was really hard to achieve some things with CSS, but these days I believe there's little to no excuse.
- bobbylarrybobby 5y agoPoints 1 and 2 sound a bit like CSS's new "layer" feature
- xiphias2 5y agoI believe that Svelte is so natural extension to the current web that - just like with CoffeeScript and ES6 - some of it should be adopted. Importing HTML files as modules with localized CSS+JS as web components would be one such option for example.
- deleted 5y ago[deleted]
- replygirl 5y agothis is called an html module: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
- daveslash 5y agoIn my career, I've gone from Waterfall, to XP, to Agile/Scrum methodologies.I've also spent some time doing V-Model. Personally, I'm looking forward to the switch to the "Screw It, This Works"™ methodology. Looking forward to the Addison-Wesley book series! Edit: I've just founded the "Screw It, This Works"™ Alliance. Sign up today to become a certified SITW Master.
- breckenedge 5y agoWhen do we get to write a manifesto?
- 6510 5y agoyou are looking at it
- eqmvii 5y agowe call that “fuck it, ship it”
- bigbluedots 5y agoI've seen the "it mostly works, ship it and we'll fix it later" approach used. The second part usually doesn't happen of course
- wsc981 5y agoWell, do you want a promotion or not?
- FerociousTimes 5y agoor exceptionally better "Fuck it, we'll do it live"
- sokoloff 5y ago“Let’s get this working in prod; after that, we’ll back patch it to dev…”
- hinkley 5y ago> So “screw it, this works” seems to be an entirely justifiable methodology. I've become more aware over the years that some developers, especially very senior ones, are under the fatally mistaken assumption that the problems start when the complaining starts, when it's closer to the truth to say that the real problems start when the complaining ends. There can be bad developers on any team of course, but there are many developers who know or suspect what they are considering doing is wrong, and discover that asking someone about it is far more trouble than its worth. They either get yelled at or saddled with a bunch of homework because they've drawn attention to a can of worms and are being deputized to fix four things instead of the one they knew about. Every project has problems. Even the ones that are making millionaires out of relatively new team members. If you aren't hearing about those problems, that's entirely, 100% your fault.
- y4mi 5y agoNot all problems have to be solved before they become an issue though. Its often a pointless effort, especially if the problem boils down to "this architecture isn't pure enough"
- MathCodeLove 5y agoThe point of the post isn't that all problems should be given equal credence, but that all problems should be at least acknowledged. Im the end would you rather a Jr. dev who's been working on the project for 6 months be the one who decided whether the problem is important enough to be solved or the Sr/project lead?
- hinkley 5y agoYou know you can acknowledge a problem and that doesn't mean you have to solve it this very instant, right? It's not a matter of either dropping everything or gaslighting people^W^W dismissing the issue as trivial. There are other choices. Many other choices. If you don't think the problems people are bringing you have merit, then they won't bring you any problems at all, even when they have merit. Suck it up and realize that you're going to have to allocate a little bit of time on "good problems to have" (if this is our biggest problem right now, things are going very well) or you'll either introduce latency into your early warning system or shut it down entirely. > if the problem boils down to "this architecture isn't pure enough" Then the problem is that your coworkers think that purity is a magic shield that will protect them from all ills, which is a bigger problem. You still need to hear it, even if you don't like it. Honestly though a lot of times when I find myself at odds with someone they try to dismiss my concerns as matters of purity when what I'm really complaining about is the smoke that's coming out of the machine (or the team's ears) because they're riding it too hard. Sharpening the saw isn't aesthetics. Preventing wear and tear isn't some white tower bullshit. It's about keeping something in the tank for the next problem we don't know we have yet. People who don't believe in burnout are doomed to create it, usually in others.
- inopinatus 5y agoThat’s fine for your brochureware whatever. Not fine for a line-of-business application meant to be useful for the next decade or more.
- SheinhardtWigCo 5y agoI think utility-first frameworks like Tailwind are becoming popular because they allow frontend teams to say "screw it" without descending into total anarchy.
- Semiapies 5y agoEh, the successors of those current teams will still curse them and throw it all out when it comes time for a big revision.
- fiddlerwoaroof 5y agoYeah, code written by the people before you is always bad
- jrochkind1 5y agoOver a lengthy career writing code, I feel like I've gotten pretty good at writing clean, maintainable, legible, changeable code. Especially in the languages I have the most experience in. I don't feel like I have any idea how to write maintainable legible changeable CSS. Like, it's not just that I can't afford the time -- I just don't know how to do it, despite all my efforts the CSS becomes monstrous, always.
- Existenceblinks 5y agoI used to work with 3 versions of a whole css system co-existed. To unfuck css debt is like to do surgery, make it done quick or you have vein spaghetti bleeding .. while is also running service.