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.

The "framework" here is exceptionally small. You can read the whole thing: https://github.com/vanjs-org/van/blob/main/src/van.js

Personally, it doesn't do enough that I'd seriously consider using it, even for a project where minimal dependencies and build steps were a priority

This narrative (https://vanjs.org/about#story) about modern JS tooling being opaque, exclusive, and hard to learn is frustrating.

If all you need is HTML rendering and basic state, any modern web framework will do that extremely simply. The barrier to entry is really not that high!*

*Except maybe at Google. I hear their internal tooling is a huge pain to work with.

Tag functions being implemented with a Proxy (https://vanjs.org/tutorial#api-tags) could make that a little cumbersome, and would break the abstraction that `div(...)` just returns an HTMLDivElement you can do whatever you want with.

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.

SFPD had a 6% clearance rate for all property crimes in 2020, with reports that it got lower since [1].

There are a lot of anecdotes, occasionally newsworthy, about SFPD watching theft happen and doing nothing about it [2]. SFPD also appears to have refused to assist the DA in arrests related to theft rings for political reasons [3].

It's noteworthy that SFPD chose to pursue such broad surveillance access for a protest of police violence. Their past record on theft and vandalism is an exceptionally flimsy justification.

[1]: https://www.sfchronicle.com/sf/article/The-state-of-the-SFPD... [2]: https://www.sfchronicle.com/bayarea/article/San-Francisco-po... [3]: https://sfist.com/2022/05/23/report-sfpd-refused-to-particip...

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.

There are so many ways for "impact" to go wrong during promotions and performance reviews.

I think my favorite were projects that just didn't have any metrics. Or that claimed to have metrics, but somehow they were never shared...

There's some difference, but I'm still not convinced. An htmx app is still using JS to manipulate the state of the DOM based on the results of API calls. You could build an app with web-components that do the same local modifications using JSON payloads.

There are definitely advantages to using a multi-page application architecture, which htmx is going to get by default.

But I really don't see a big difference between using JS to replace DOM fragments with server generated HTML, compared to using JS to replace DOM fragments with client generated HTML.

I love articles like these, because the narrative of "JS framework peddlers have hoodwinked you!" is fun, in an old-timey snake oil salesman kind of way.

But I'll be honest. I'll believe it when I see it. It's not that htmx is bad, but given the complexity of client-side interactions on the modern web, I can't see it ever becoming really popular.

Some of the specifics in the comparisons are always weird, too.

> Instead of one universal client, scores of developers create bespoke clients, which have to understand the raw data they fetch from web servers and then render controls according to the data.

This is about client side apps fetching arbitrary JSON payloads, but your htmx backend needs to do the same work, right? You have to work with the raw data you get from your DB (or another service) and then render based on that data.

You're still coupled to the data, and your htmx endpoint is just as "bespoke" as the client code which uses it. It's not wrong to prefer that work be done on the server instead of the client, or vice versa, but we're really just shuffling complexity around.

Feel free to check my math, but Waymo's 2 accidents in 1,000,000 driverless miles (https://blog.waymo.com/2023/02/first-million-rider-only-mile...) is higher than the rate for human drivers in any of the years from my quick NHTSA stats search.

They've had no fatalities, which is great (and certainly better than other "self-driving" car options)! But it's hard to make really good comparisons as long as Waymo is off by a factor of millions of miles.

That's just a local bias. I used to live where a street turned from two-way to one-way, and people drove the wrong way all the time.

But that doesn't change the fact that human beings are extremely safe drivers. NHTSA reports less than 2 deaths per 100 million miles driven each year from 2010 to 2020: https://cdan.nhtsa.gov/tsftables/National%20Statistics.pdf

To be 100% clear, my main AI fear is that these tools are going to be exactly as dumb as people but much, much faster.

We know optimization engines (like social media algorithms) can cause harm by amplifying human speech. And even without algorithmic biases, moderation is expensive. We know disinformation is easy and effective online.

Add in AI tools that can be very convincing, even if they're wrong. AI tools that have been trained on human text to hide biases and build up extremely one sided narratives.

It's not like these things are particularly difficult for human beings to do. And AI might even do it unintentionally, like we've seen with biased models trained on hiring data. But the AI tools are definitely going to do it _faster_.

Automatic translation is impressive, to be sure.

But looking up information and translating it into other languages is well within the realm of human skill. And the information it's translating came from people to begin with.

So much of this is going to hinge on what "smarter" means. My local library has heaps more knowledge than most individual people, but it'd be weird to call it "smarter" than a person.

And automation is generally cheaper and faster than human labor, but that's not a very compelling definition of "smarter" either.

But, as of right now, LLMs can't generate new knowledge or validate their own outputs. We'll need a pretty significant breakthrough for that to change, and breakthroughs are pretty unpredictable.

That statement seems like such science fiction that it's kind of baffling an AI expert said it.

What does it even mean for the AI to be smarter than people? I certainly can't see a way for LLMs to generate "smarter" text than what's in their training data.

And even the best case interactions I've seen online still rely on human intelligence to guide the AI to good outcomes instead of bad ones.

Writing is a harder task to automate than calculation, but the calculator example seems pretty apt.

Only stealing from people who haven't asked you nicely to stop doesn't scream "highly ethical" to me

Security researchers put a lot of emphasis on responsibly disclosing vulnerabilities. The maintainers of this project could have easily done the same, but they didn't

This feels like it would make the situation much worse from a legal perspective.

If you know your AI produces code that is "tainted" by license violations, adding code to hide it after the fact suggests that you're intentionally violating the license terms.

Same here!

I think it helps me read faster online, but it's probably just a fidget-y habit.

You've got to love a website that makes text selection invisible by default.

I'd probably double check assumptions on the cloudfront issues. Switching carriers or adding VPN might connect you to a different edge node.

Some web assets being throttled for specific AT&T accounts seems a little too targeted to just be traffic shaping. I'd expect them to throttle traffic for all users, like they do with the speed tests.

100% is an odd choice for a utilization target.

Just about every service I've ever monitored has had some fairly clear inflection points where higher utilization starts to affect performance. It could be things like more time spent on garbage collection, or just unlucky collisions with async work that make things take longer.

I've asked a few streamers for their perspective, and the response is vague but more per view than ad impressions

I'm assuming this is mostly just because the ad revenue on youtube is pretty low