4 ms·

Yeah this is my intuition as well, though I haven't spent much time thinking about the problem. Like, yeah, if you write very non-performant code, it won't perf

• jakelazaroff 4y ago
  The issue is that the person who ends up suffering isn't the developer that writes the CSS. It's the person who has to use the website. If I'm trying to find a local emergency room, I really don't want to have to waste time because a developer wrote (or some tool generated!) slow CSS.
  • treeman79 4y ago
    I had hired in at a new company and was getting annoyed with how slow everything was so I started digging into the Javascript and CSS. I started seeing a lot of references to Chuck Norris. After further digging, found that the entire test library suite was being added to code. Site load time was halved after fixing.
• wruza 4y ago
  To understand why this is a problem even with “good” css, one has to understand how parsers work. It doesn’t matter that all css will be good in practice. The entire theoretical possibility of a problematic case (i.e. unbounded number of lookaheads) changes a class of parser required to parse it. Not all grammars are equal and they may require different methods. One grammar may be LALR(const) compatible, and the other may be parsed only with GLR. There is no easy way to use a dumb and quick parsing method once you commit to a grammar (not to a way of writing sources!) in which ambiguity can survive for an indefinite time, even if it’s always short in practice.