Modern CSS - A fireside chat with Nicole Sullivan

Поділитися
Вставка
  • Опубліковано 16 січ 2025

КОМЕНТАРІ • 9

  • @t3dotgg
    @t3dotgg Рік тому +13

    This is arguably the most important talk from Reactathon and it's a shame it won't get watched enough to reflect that :(

    • @misode
      @misode Рік тому +3

      Thanks for bringing me here!

  • @MikkoRantalainen
    @MikkoRantalainen 2 місяці тому

    About the colorspace stuff: the oklab (and oklch which is just different representation of the same colorspace) color space is about having a colorspace where linearly interpolating between different numerical RGB colors results in colors that actually appear to make sense for human vision.
    A good example is linear gradient from white to dark blue in sRGB color space. If you simply linearly interpolate the RGB values, the middle of the gradient appears to be light purple instead of light blue as you would expect. Doing the interpolation in oklab colorspace fixes this but it requires that the browser renders the gradient offscreen in different colorspace and then blits the pixels while doing the colorspace conversion after the gradient has already been rendered. (However, optimized solution may render the gradient directly into the target RAM doing the gradient computation and colorspace conversion on the fly.)
    A well made fade between two images also requires that every intermediate frame is also computed in oklab color space because otherwise fade from fully dark blue image to totally white image would go via light purple which is obviously incorrect but happens if the fade happens in sRGB color space.

  • @ChaiFlyGuy
    @ChaiFlyGuy Рік тому +1

    Glad to see someone fighting to make developer's lives easier like Nicole!

  • @jacopomarrone8059
    @jacopomarrone8059 4 місяці тому

    Send this to TLDR newsletter authors, so it can be seen by a lot of devs. This roadmap is huge for frontend

  • @MikkoRantalainen
    @MikkoRantalainen 2 місяці тому

    23:00 Shipping a JS framework with browser doesn't make much sense because different sites will want to use different versions of said framework. It makes much more sense to have one or two CDN sites that *everybody* could use so that the framework that your site wants would be in the browser local cache with high probability already before you access the site. For all performance purposes, that's already practically identical to the browser including the same framework code as part of the browser install.
    The only big question is can we trust any given entity in the world to distribute JS code that everybody will use? In practice, it cannot be any US company because those will be vulnerable to FISA secret court orders unless *every* developer using said libraries also learns to use SRI. In fact, if all developers used SRI correctly, the browser could probably safely use the code from any CDN found in the cache already!

  • @CristianKirk
    @CristianKirk 3 місяці тому +1

    "The conclusion I drew from that was these are hobbyists"
    What? How? This declaration just came out of nowhere, with no context or backing data. Pure subjectivity. And it's not even clear what it means.

    • @rspcs-mu2cu
      @rspcs-mu2cu 3 місяці тому

      sounds like that hit a little too close to home :P

    • @MikkoRantalainen
      @MikkoRantalainen 2 місяці тому +1

      I think the intent was to figure out the most common case. In my experience, people using native JS only are either hobbyists or elite developers using *a lot* of time to optimize everything and they opt to avoid frameworks and use fully custom/optimized solution for everything. In many cases that will be a hobby project because (practically) no commercial company is willing to finance such an effort. (The elite hobby case here is not different from Linux kernel meaning people do it without salary, not that it were easy or sloppily written code.)
      I'd love to use only fully custom and optimized native JS code for my work projects, too, but that's not the reality we live in for commercially paid code.
      I hope that one day web standards have good enough developer experience to be usable for big projects without using any frameworks but right now, the standards are still missing or the real world implementations are too buggy to use according to the specs so it's easier to use framework as a glorified polyfill for the missing parts.
      And when this glorified polyfill ends up using different syntax than the eventual standard implementation, you'll end up with lots of code using the glorified polyfill forever. (For example, jQuery.)