joestrouth1

Microsoft doesn't own node.

What places are those? When I think of cities with expensive housing (NYC, LA, SF, Boston, London, etc) they typically also have higher taxes, fuel prices, food, etc. Maybe you can swap a costly car for public transit?

Before my time but HUD upped the rent cap on affordable/public housing to 30% of income in 1980. Even 1/3rd's a stretch for most folks in most places in the US. A 25% rule of thumb isn't much use if folks can't find housing that meets the bar.

My point was that there is only one root font size on a given page and it's trivial to find out what that is by looking in dev tools. It does not matter if it was set by the browser's user-agent stylesheet or an authored stylesheet or what units it was set in. You can simply look up its computed value.

What use case is that not sufficient for? What kind of nightmare page are you styling where code you don't control is dynamically changing the root font size? Why do you need its exact computed value at all? The whole point of REMs is to style based on relative proportions to the text size e.g. when text is size X, buttons should have x padding on top/bottom and 2x on the sides. If the user sets their preferred font size to another value I do not care.

Put me on a C++/asm project and I'd have a hard time making heads or tails of it. So what? Your comment comes off as very angry without any meaningful critique of the article's central topic other than you had a hard time understanding it.

1rem is equal to the same number of pixels anywhere on a given page and, generally speaking, across pages on a given site. If you don't know what the value is it only takes a minute to find out. If you're writing CSS that'll be used on unknown pages, you either a) shouldn't care and just scale relative to whatever root font size the consumer set or b) should set your own size/scale, at build time or with custom properties. REMs have been around and standard practice for 10 years.

Your reading of the addiction angle is much different than mine.

I didn't hear the author criticizing the character of their colleagues. On the contrary, they wrote a whole section on how folks are pressured or forced to use AI tools. That pressure (and fear of being left behind) drives repeated/excessive exposure. That in turn manifests as dependence and progressive atrophy of the skills they once had. Their colleagues seem aware of this as evidenced by "what followed in most of them, almost like a reflex, was a self-justification of why the way they use these tools is fine". When you're dependent on something, you can always find a 'reason'/excuse to use. AA and other programs talk about this at length without morally condemning addicts or assigning individual blame.

> For most of us, self-justification was the maker of excuses; excuses, of course, for drinking, and for all kinds of crazy and damaging conduct. We had made the invention of alibis a fine art. [...] We had to drink because at work we were great successes or dismal failures. We had to drink because our nation had won a war or lost a peace. And so it went, ad infinitum. We thought "conditions" drove us to drink, and when we tried to correct these conditions and found that we couldn't to our entire satisfaction, our drinking went out of hand

Framing something as addictive does not necessarily mean that those suffering from it are failures/weak/immoral but you seem to have projected that onto the author.

Their other analogy ("brainworm") is similar. Something that no-one would willingly sign up for if presented with all the facts up front but that slips in and slowly develops into a serious issue. Faced with mounting evidence of the problem, folks have a strong incentive to downplay the issue because it's cognitively uncomfortable and demands action. That's where the "harmful coping" comes in: minimizing the severity of the problem, avoiding the topic when possible, telling yourself or others stories about how you're in control or things will work out fine, etc.

If one user kept their files in the root directory, where would a second user keep theirs?

Oxigraph[1] is an option, though it's RDF/SPARQL-based rather than property graph/cypher

1. https://github.com/oxigraph/oxigraph

This may be true if you consider React in isolation but nobody uses it that way.

8 years ago create-react-app was new and Next.js v2 was on webpack 3. The former is now obsolete and Next is radically different. And hooks released in 2019

"How can such changes occur to the DOM that aren't brought about by other code on the page?"

- The other code that made the change may have been written by another team or a third-party organization

- The code setting the MutationObserver may not originate from the page e.g. a browser extension or bookmarklet

AVP doesn't support it when in 'theater mode' but if your video is a typical window you can simply lie down and recenter it onto the ceiling. The horizon stays locked but any windows can be parallel to the ground.

Atomic CSS requires a class for every CSS property you wish to set, at each breakpoint, each active/hover/focus state, each color scheme you support, etc. With data-attributes one could specify that the element is a primary, full-width, large button and all the properties that make that happen live in the stylesheet.

That is one way to do it, provided `user-avatar` extends HTMLImageElement and not the more generic HTMLElement. Extending built-ins and using the `is` attribute is not supported in Safari however and last I checked they were firmly opposed to it.

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

In my experience, any realized benefits of gen AI have not been sufficient to make any significant number of jobs redundant (in client services software environments). Probably due in no small part to how wary valuable enterprise clients are of feeding their data into third-party LLMs. TBD how this will change as enterprise SaaS offerings evolve, get cheaper, and various orgs build expertise in self hosting.

This has not prevented it from being used as a scapegoat when reducing staff. More likely that some promised X% increase in AI-enabled productivity is used to shore up a story about 'doing more with less'.

Attrition with non-replacement is certainly one strategy, as is a middle ground where attrition is backfilled by hiring junior talent that's more affordable.

GraphQL is not a database technology. It's a Query Language that can sit in front of REST APIs, databases of all kinds, or in-memory data. As such it typically has no impact on your database schema or any difficulties associated with it.

It can be true that changing a relational db schema is a big effort and it can be true that graph (not GraphQL) dbs are more flexible. Even for neo4j and JanusGraph, which don't offer GraphQL by default. They're NoSQL databases that store graphs instead of documents or k/v pairs. It just happens that Dgraph decided to integrate it