chrsjxn

Yeah, that's where I'm at, too. Authoring web components directly is too low level to be practical. You can easily end up reimplementing a ton of existing framework logic around rerenders, reactivity, event handlers, etc.

And there are libraries that handle all of this for you! But then you have tooling and non-standard syntax that puts you a lot closer to other JS frameworks.

And once you're in that space, the benefits of web components may or may not stack up against all the features and your team's pre-existing knowledge.

For me, this feels worse than wikipedia using JSON as an example.

JSON isn't a great HTMl representation, and the wikipedia examples are definitely missing details about how the underlying API is used. But extremely simple HTML just feels worse.

Both pages use a bank account as the example, but my actual bank account has dozens of actions available and is certainly modeled in a way that wouldn't be intuitive for people. Which means we've got an example that isn't easily parseable by computers, because we have mixed labels and data in the HTML, and isn't useful for human beings due to how complex real world entities are.

I genuinely can't tell if this is like monads (which are useful, but often poorly explained) or if this is just a bad idea.

I really struggle to understand how someone with fundamental programming knowledge and the relevant HTML/CSS skills could run into issues like this without some serious mental blocks.

The HTML and CSS are going to be the same. Any UI state or side effects you're managing with React has to be managed in your htmx endpoints, and stateful APIs have plenty of their own quirks. You're doing the same stuff!

I can certainly understand how modern JS frameworks are harder for someone without a non-framework JS background, since the frameworks are a pretty clear evolution of how JS based web applications have been built for many years. But suggesting that developers pick React to inflate head counts and calling it "the hell-stack" makes it hard for me to think the author is engaging in good faith.

Maybe this is just a terminology mismatch, but when you say "incident" that's been a pretty urgent process everywhere I've worked. Other people are talking about breaking CI, which just sounds miserable.

Raising awareness to management is great though. Especially if you can quantify it in terms of things that matter to them more than "tech debt". Like startup latency or a direct dollar cost.

Heh. I've been there and tried to do this with feature flags and a handful of other tech debt work.

It can feel good to make people do their chores, but you can also burn a _lot_ of bridges by forcing relatively minor maintenance work to be high priority like this.

The awesome thing is that this comes right after an example that uses about 200 characters...

I know we love to talk about optimizing web contents, but a single selector and a few hundred bytes (before minification and compression...) is not significant

There's like two main ways this kind of mistake happens.

One is a programmer using the wrong string ID. Probably a mistake when searching a translation file/db.

The second is missing context. The word "zip" has multiple meanings in software, so you need more information to disambiguate when translating. "Zip code" and "zip file" is probably sufficient, but you could imagine them also having a templated translation for file types like "{} file".

I could see an unspecialized LLM translation working well for whole sentences or paragraphs, because that kind of text isn't really likely to run into either of these problems. And if you have the context you need to avoid the second problem for small snippets, then human translation is also pretty unlikely to fail.

I feel like that just makes it worse (though I didn't know about the DA's office messing up the paperwork).

Let's assume that understaffing and additional work required to close cases are the main causes for the low clearance rates. Monitoring a legal protest in case crimes are committed seems profoundly wasteful, compared to working to resolve crimes that actually happened.

I don't envy SFPD. Trying to reduce crime in SF seems like a huge challenge that they are poorly equipped to solve, for many reasons. But the original comment in this thread is trying to justify surveillance here as preventing possible property crimes, and that just makes no sense to me.

I'm mostly thinking outside the scope of just this one example. Even good recipes have a lot of variability in cooking time. The differences between how hot people cook at home and how hot they cook in commercial spaces is one of the ones that's hardest to control for (unless you want to remodel your kitchen...)

> You are not going to be able to cook chicken in 3-4minutes per side like so many recipes claim. It's just not possible to have a good outside temperature and a good inside temperature no matter how you cook it if you only have that amount of time. They're lying to make it seem easier and to get more clicks on their recipes.

Some of this is probably a difference between home and commercial kitchen equipment.

I know my stove doesn't have the same kind of heat output that a commercial stove would, let alone specialty equipment like pizza ovens or wok burners. And lots of home range hoods are awful for ventilation, which makes it even more impractical to cook at a high heat.

The semicolon and all the brackets look to have a lot more emphasis than they do in many common monospace fonts, which makes a lot of sense if you're designing your font for developers. Same with the 1Il distinction they show off in their graphic, or O0.

It's unusual, but I'd bet it feels nice to work with after getting used to it.