Tag: because

“We had 90% unused CSS because everybody was afraid to touch the old stuff”

Over at the JS Party poundcast:

[Kend C. Dodds]: […] ask anybody who’s done regular, old CSS and they’ll tell you that “I don’t know if it’s okay for me to change this, so I’m gonna duplicate it.” And now we’ve got – at PayPal (this is not made up) we had 90% unused CSS on the project I was using, because everybody was afraid to touch the old stuff. So we just duplicated something new and called it something else. And you might just say that we’re bad at CSS, but maybe CSS was bad at us, I don’t know… [laughter]

[Emma Bostain]: Well, that’s why styled-components and CSS-in-JS was so pivotal; it was like “Oh, hey, we can actually encapsulate all of this logic inside the component that it’s touching and don’t have to worry about bleeding code anymore.” It’s so much easier to delete things, and add things, and all of those things.

[Kend C. Dodds]: Yeah, you’re precisely right. That was the problem that those things were made to solve.

Audio clip:

I’ve heard this exact story before several times, usually from large companies. Lots of developers, typical developer turnover… nobody knows what CSS is actually used and what isn’t because that is a very hard problem.

That’s one of the reasons I sometimes like component-based-styling solutions (CSS-in-JS, if you’re nasty). Not because I love complex tooling. Not because I like JavaScript syntax better than CSS. Because of the co-location of styles and componentry. Because nobody is afraid of the styles anymore — they are tightly coupled to what they are styling. It’s not needed on every project, but if you’re building with components anyway (an awfully nice way to architect front-ends that doesn’t require JavaScript), you might as well style this way.

For this reason, I’m excited that “scoped styles” are making a bit of a comeback in standards discussions.

I remember an ancient idea (that maybe even shipped in browsers for a minute?) where you’d just chuck a <style scoped> block right in the HTML and whatever the parent was, the styles were scoped to that parent. That was so cool, I wish we could have that again.

But it seems like the newer stuff (here’s Miriam’s original proposal) has some more clever stuff that that basic concept doesn’t cover — like being able to set a lower-boundary in addition to an upper-boundary, making it possible to scope “donut-shaped” styles in the DOM (a Nicole Sullivan term). Whatever happens, shadow DOM-free scoped styles with zero tooling is huge.

The post “We had 90% unused CSS because everybody was afraid to touch the old stuff” appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.


, , , , , ,

The future is bright, because the future is static

I’ve been doing this web thing for money for 10 years this year and although I haven’t been around as long as some folks, I feel like I’ve seen a few cycles come and go now, so let’s say that hot new things are often cynically viewed, initially. This milestone of mine has also got me in a retrospective mood, too, and the question “What about building websites has you interested this year?“ has only encouraged that.

When I first came into the industry, I was an out-and-out designer, delivering static comps to developers until after one-too-many poor builds of my work: I decided to get into code myself. Naturally I focused purely on the front-end—specifically HTML and CSS. Yes, I got a bit into JavaScript too (once Flash became fully irrelevant), but markup and styles have always been my favorite things about web technology. I’ve never really been into back-end development, either. Sure, I can do it, but it’s certainly not my strong suit and usually this weakens my offering a touch—especially as a freelance web designer. Well, it did weaken me, until now.

JAMstack: an awful name, but awfully empowering.

I love JAMstack because it empowers people like me, who aren’t very strong with back-end stuff, and the aspect of JAMstack that I like the most—and which I think is the best part—is static site generators (SSGs). I’m talking specifically about SSGs like Eleventy and less-so Gatsby here, for reference.

The biggest reason that I like SSGs like Eleventy is that I can have a completely flexible, component-driven codebase that at build-time, compiles down to nothing but lovely, static HTML. You still get the power of JavaScript too, but instead of forcing it down the pipe, you run it at compile-time. This has enabled me to do some pretty darn complex stuff. Eleventy does all of this at lightning speed, too.

Mix Eleventy with Netlify and in some cases, Heroku, and suddenly you have a powerful development setup which results in a fast, performant website that auto-deploys. It’s perfect setup for me.

This stuff excites me so much that I made an Eleventy starter kit this year called Hylia. I did this for two reasons:

  1. I wanted to test the viability of a content-managed static-site that uses source controlled content. I chose Netlify CMS to do this
  2. I wanted to empower people without tech skills to publish a performant, accessible blog of their own, so they didn’t have to rely on centralised systems

The platform went down really well and I think part of the reason for its success is that even though it’s (optionally) content managed, powered by design tokens and fully componentized, it performs really well because all you get is HTML and CSS with a bit of progressively enhanced JavaScript.

This is the magic of SSGs, because they give us developer experience, but much more importantly, because the output is static and lightweight (unless you prevent that with lots of code), it creates a really solid basis for a good user experience, too! This isn’t just the case for small projects like Hylia, too, because SSGs can even power huge projects like the Duet Design System, for example.

Looking back at the empowerment that SSGs enable, I’ll just list some things that they have enabled me, a web designer, to do this year:

  • Self-publish a book
  • Create rapid, interactive prototypes for clients which has completely transformed the decision making process
  • Build actual, full websites for clients
  • Completely transform my design process to use HTML and CSS as a deliverables, rather than static comps
  • Build and document an incredibly comprehensive, multi-platform design system (WIP)
  • Re-platform my CSS newsletter (WIP)

These are huge things that have had a massive, positive impact on me and next year, SSGs are only going to feature more in my work as I transition into providing educational material, too.

Wrapping up

The future is bright with the JAMstack and SSGs—especially when what is delivered to the end-user is fast, progressively enhanced websites. I honestly think that they are creating a momentum wave towards a bigger focus in performance, too.

If we chuck in some serverless technology: suddenly, designers and front-end developers really are all powerful and this really excites me because suddenly, we give lots of people power to have great ideas that might not have been able to before.

The post The future is bright, because the future is static appeared first on CSS-Tricks.


, , ,