I guess California will release California OS with age verification.

I have mixed feelings. On the one hand, it's impressive, but on the other, it's concerning that CSS is turning into "JavaScript 2".

Now we can embed a cryptominer on a page even with JS disabled! /s

Interesting idea. This will be useful only when the CSS communicates with a server. Maybe it can make requests indirectly by setting background image URLs or something and send data piece by piece for each byte. Not sure.

That happens today in the wild even. CSS url() function and basic things like applying background images to semi-invisible blocks for entirely CSS-based data exfiltration. From what I've heard it is most commonly used today for fingerprinting systems of trackers that use a ton of @media queries to try to fingerprint you based on the subtleties of your browser.

Relates to some Safari and Firefox engineers warning on pretty much every new CSS proposal to consider how it can be (ab)used for tracking.

Yes, CSS binary data transfer is possible in bith directions.

Totally. ORMs are not evil. They help to reduce the boilerplate and improve the code maintainability.

We have a complex project with a custom back-end framework that also includes a custom ORM. The ORM covers about 95% of the use cases just fine. It reduces a lot of boilerplate and also makes it possible to find the logic much easier (for example, setting and reading some column from a specific table). Although I have to say, it works that well also thanks to good integration with the framework (fronted, included) and advanced features, like calculated fields with automatic recalculation triggering, integration with user permissions, ability to define custom user permission validation logic before / after saving rows, etc. If we really need an unusual operation where the ORM doesn't suffice (most of the time complicated search queries or some aggregation), we can write raw SQL and, if possible, encapsulate it at repository / service level. But 95% of use cases are covered by the ORM (including the management of parent / child relationships).

I think some "old school" folks like to bash ORMs and view them as very limited and inefficient compared to raw SQL. But you can use them both: primarily ORM and in specific cases switching to raw SQL when ORM doesn't suffice.

I don't belong to both "AI has replaced engineers" and "AI will never replace engineers" camps. But for now, AI is far from replacing SWEs and development processes, especially for complex software (that has many complicated specifics, such as deployment, migration, specification, code conventions, domain knowledge etc).

Yes, nowadays AI is really powerful, our company even encourages us to use it for generating some code / documentation or reviewing your own code / documentation. In recent years several IDEs are integrating it. But it's not a panacea and has its limitations. Still, it has to be supervised, the generated code should still be reviewed and corrected. You should view AI as more like an "IDE autocompletion on steroids". You need to understand the difference between a vibe coder and a normal developer who enhances his productivity by AI.

Currently AI hasn't enough autonomy for fully replacing SWEs and development processes (yet). Full stop. The article might become correct in 20 years I guess.

>The article might become correct in 20 years I guess.

You shouldn't wait 20 years to worry or talk about it though.

Yeah, but not very maintainable (mildly saying). Now, someone asked you to change a color somewhere... or whatever. After changing that color the code doesn't run because the author also reused the portion of the code (you changed) as a constant ). Now you fix that, but something else breaks, etc. Such hyper-optimized software is very brittle. Not every bloat is necessarily a bad thing, in moderation it allows to easily make changes. https://waspdev.com/articles/2025-11-04/some-software-bloat-...

My top list of recent CSS improvements:

1) Nested selectors.

2) :has(...).

3) :is(...), before you had to write :not(:not(...)).

4) :where(...), similar to :is(...), but the selector weight inside :where becomes 0. Useful when you need deep/complex selectors without increasing the selector weight.

big +1 on #1.

As a tip - most LLMs are unaware it exists due to either knowledge cutoff or not having enough training data for it.

As a recommendation, include some examples of it in your AGENTS.md. Here's what I use:

--------------------------------------

## CSS nesting (required) When writing CSS (including component `css()` strings and `soci-frontend/soci.css`), *use modern CSS nesting* where it improves readability and reduces repetition.

- Prefer nesting with the `&` selector for pseudo-classes / pseudo-elements and compound selectors. - Avoid duplicating the parent selector when nesting can express it once. - Reference: [MDN `&` nesting selector](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...)

### Quick reference

#### Pseudo-classes / no-whitespace attachment

```css .button { color: var(--text);

  &:hover {
    color: var(--text-secondary);
  }

} ```

#### Pseudo-elements

```css .fade { position: relative;

  &::after {
    content: '';
    position: absolute;
    inset: 0;
  }

} ```

#### Descendant nesting (whitespace implied)

```css .card { padding: 12px;

  .title {
    font-weight: 600;
  }

} ```

#### “Reverse context” (`.featured .card`) using `&`

```css .card { .featured & { border-color: var(--brand-color); } }

Mine is text-box: trim. Twenty years of trying to explain to graphic designers why it’s next to impossible possible to get the top of a capital letter to a box, I feel free like a bird.

Once Firefox supports it, we will be golden.

My favorite is @layer

Don’t forget @layer!

I like 2-4 but I despise nested selectors. They make selectors ungreppable.

Why/how do you grep selectors? Seems overly optimistic to be able to guess the particular rule pattern that is applying a style. Browser tools are much more reliable.

Let's say you're thrown into a website you've never worked on before and asked to fix a styling problem. You can look in the browser tools, but the website will only be running the compiled production version, and if the team knows what they're doing there won't be source maps available.

So you've now found selectors in DevTools that you think are causing the problem, and you want to find them in the source code. In the case of many projects, that means searching through hundreds of small CSS files.

That's why you grep selectors, and where the pain comes. You have to start with the most specific rules that you found in DevTools, then start deleting parts from them until you find a non-nested rule that's in the source, yet still specific enough that you haven't got hundreds of matches to go through.

It would be great if something like ast-grep could take a CSS rule copied from DevTools and search for nested CSS that would compile to match it.

> if the team knows what they're doing there won't be source maps available

What's so bad about source maps?

If this is the only option, I would suggest that means the team doesn't know what they are doing.

Min-max + alpha-beta pruning is the backbone of the chess engines. I think 2KiB or even 1KiB might be enough (I guess the last one would be a very challenging squeeze). But what separates the best engines from average ones, is the heuristics. Heuristics is the most complicated one, and I doubt it's possible to fit it into a single-digit kilobyte memory (even 2-digit). For heuristics, engines like Stockfish also use neural networks, in addition to hand crafted algorithms. Also huge tables are used for endgames, etc.

I'm a millennial, but I share some feelings. I also think modern programming careers often feel like factory jobs where most of the time you must be compliant with some BS. You often find the true joy only in personal projects.

Modern programming careers _are_ factory jobs.

Until you have some sort of senior+ position you are literally just standing in front of a conveyor line.