jozzy-james

that’s great for you, i have to sleep with sound - the silence is not deafening, but the hum/etc is when it is silent

but it is in many, many places where you don't live.

I do wonder how non-technical designers are going to feel. The learning curve is definitely going higher.

how would this impact them? just use figma as usual i would assume

looking forward to giving this a spin, our design team tends to go the iterative artboard style with everything...so sussing out values can be a pain

outside of Q, I think I've used most all of these in one way or another for various reasons. Most can be done with calc() and whatever the nearest root value is - but some of them are handy, even if they don't appear so.

tangentially related (not affiliated with the company, just a fan), but https://usewindy.com/ does similar stuff - and more.

to be fair, preprocessing comes with some other QoL things that I don't see CSS being able to support natively, namely mixins with math functions.

edit: don't get me wrong, i'd love to be 100% native CSS, but there are some things where preprocessors shine

i, for one, am most looking forward to full support of subgrid - pure css masonry/isotope layouts with no JS needed when your cell requires images to retain a certain aspect ratio, as well as span multiple rows/columns, but has accompanying text that can vary in height. am aware that's a very specific thing, but will be nice to not need a JS crutch for height calculation

with the a/b testing we’ve done in our admittedly niche market - yeah it matters

hate replying to something i already did - but i also never said liveview required JS, just...it still uses it if there. Liveview is a really slick answer to this whole thing, and I recommend readers of the thread to check out. And now I have nothing.

i ask myself the same question, but apparently they're out there

i suppose i should have prefaced with liveview uses JS...if you intend to use JS or dynamically update anything

edit: much like the SSR being described

right, i get that - and liveview is a sick piece of kit, so congrats. just saying that for what most would use it for - it is still using some JS

agreed, wouldn't be able to read this comment

it does, but when design and top brass say it needs to fade in - back to some JS you go

i think you're conflating static sites with sites that lean heavily into JS frameworks. plenty of sites are not static, cause they need that whole session thing, and don't use JS frameworks

FOUC would still be an issue.

hell, just using webfonts can cause FOUC - no JS needed.

liveview still uses JS, its just rather out of the way in what it does

edit: livewire in laravel land does a similar approach - tho not as fast currently, leverages alpine.js under the hood

realistically speaking, if done correctly - SSR would allow the site to work without JS. Now, in practice, that comes down to what is required on the client side for interactivity - which is a case by case basis, and if your site doesn't require JS on the FE at all, why would you use it for the backend

and when websites are kind of apps, but not really so you need the SEO benefits of regular websites yet the interaction of apps....then you get into the fun bits

been a juggling act for me for some time, and always comes down to - they'd rather take a performance hit vs. harm the branding/interactivity. tho we're in a very niche market that doesn't seem to mind (i do my best to make it as efficient as can be)

unless google recently bought out ifixit, not seeing the relevance to the statement

that tracks with our experience as well

sure, just saying that only EC2 instances were impacted is disingenuous at best.

all of our production services are multi-az as well

we definitely had issues with all of the AZs in east-2, and far more services impacted than just EC2 (f.e. RDS, elasticache were intermittently down for us)

SSE isn't bi-directional, but sure - solves a bit of the long polling issue.

If I really wanted to add a decedent selector from a body class to .class1, I'd start a new nest on the body tag.

a) maybe you don't really know how far up the chain that tag gets called from.

b) it creates new selectors for class1 and class1.class2, as well as class1.class2's hover

c) creates a hyper specificity

now, I'm not advocating this usage of SASS - but it can be a handy hatchet when you need to support multiple themes with minimal changes/effort, much to the chagrin of specificity and maintainability

explain to me how this compiles

  .class1 {
    .class2 {
      &:hover {
        font-family: value;
      }

     body.some-thing & {
       color: woooooo;
     }
    }
  }

and bi-directional data flow was done in the form on long polling. this sounds very much like a get off my lawn argument rather than anything rooted in reality of the now.

We've done this since the '90s.

no, we really didn't. tho i'll agree that utility classes have been a thing for longer than tailwind/bootstrap/tachyons/pico/etc have existed

mix semantics with presentation

there is nothing semantic about class names: nothing, zero, zilch - using IDs are even worse due to specificity, with none of the "semantic" benefit. focus on the correct top level wrappers

part of me wonders about the extent of what HN commenters actually do on the web regarding styles, or if they just slap together some homogenous web app or static site where its rather easy to not have a design team needing flexibility on every little thing.

case in point, our main "button" has about 15 different base variants (that *3 currently) depending on context, not counting the interaction states.

class names have no bearing on semantics