SerpiApi doesn't give two shits about the openweb. They are just here to exploit it with their scraping. It's very convenient to call a search engine the openweb, an action I fully support, but it's not because they are some grand protectors or something. They just want to make money.

For Google, it could be “very dangerous” to argue that the knowledge panel is “chock full of copyrighted material,” Rose suggested. Since the search giant doesn’t license all the content in the knowledge box, Google could risk future lawsuits if the act of algorithmically creating the knowledge box without licenses suddenly becomes viewed as infringement, Rose said.

If Google comes out of this a winner, it'll be because the judge was paid off or there was some obscure law they used, that made no sense but was somehow applicable here, in a twisted manner.

Love that

Google getting a taste of their own scraping. Decades of scraping content for "search visibility" and when someone scrapes them, they cry all the way to court.

Good to hear that.

I'm also approaching it with a sort of zero trust security model. Everything, in and out is validated and sanitized. Especially Html injection and XSS.

For in your company and only for usage with your products, this approach seems very reasonable. The trouble with htmx is that it uses the dom to manage state, so if the endpoint you call serves a script tag that loads (say) a cryptominer, all your end users are gonna be mining crypto. It's hard to imagine a company product serving malicious content that hijacks the browser of their own users, so I thinks you're safe here.

Hypermedia APIs (i.e. HTML) are specific to the layout of your application, so there is almost never any reason you’d want to insert someone else’s HTML into your page. All you have to do is make sure you only call your own routes (htmx 2 will actually disable calling other domains by default).

Although I do control the routes, its seems like it's not common. One way is a reverse proxy so the component server is forwarded on /components path on the client. So the client can still call relative routs.

I think I should clarify: This isn't a public library (yet). It's a system I'm creating in our company for usage within our products.

I thought about web components and actually created a few. But this hypermedia approach with HTMX is much simpler to develop and maintain, and since some of the components are very heavy, the server side rendering takes load off of clients and makes complex renderings possible.

Can you elaborate why do you think HTMX doesn't fit this usage? With webcomponents, the flow will be like this:

1. Client fetch data from source
2. Client render the data within tge component

With this hypermedia approach the flow looks like this

1. The client requests component with data from source from server
2. Server fetches the data, (possibly validates it)
3. Server renders the component
4. Server sends component to client

This HTMX article on security says it’s not ok to call HTMX with external sources.

Where does it say that? It says “Only call routes you control”. As I understood you, you do control those routes.

If you expect end users to regularly generate components for endpoints neither you nor they control, I think htmx is a poor match for your use case. Can you generate a vanilla web component that uses fetch instead?

Of course they did. After the EU enacted the first cookie law even their website about it had a cookie banner. Then they saw how that went and thought "Yes! Mooooar!"

The end result of the second cookie law (GDPR) was extremely obvious. You can't say "ooo but sites can just not use cookies!" as if that was a plausible outcome.

I'm sure there's an Aesop fable about this.

several Member States are now blocking the EU Commission’s proposal to get rid of the cookie banner

Which ones? Why's there no list here when the "take action" lists by country?

The EU never asked for cookie banners. The industry is just really bad at 1. following the law 2. following the spirit of law 3. designing good UI/UX

So banner data-sharing dialogs don't offer a simple reject button. That's not lawful.

Typescript 7 is here. Ron Buckton, not so much.

ublock origin -> create custom filter. Not gonna trust the EU for fucking up again

I personally haven't looked at the port myself, but generally LLM/AI agents generate "slop" until a human expert reviews all of it. Which in most cases never happens. Instead they just review with another "higher tier" model.

As someone on hacker news put it regarding a subject about using LLMs for everything:

A decent proxy right now is that if you have zero external dependencies then your solution is probably a toy.

This can be related because unless they are actually using the best libraries in the ecosystem while they are porting then it's going to be a mess to maintain and also alienates the ecosystem.

Tired of misleading cookie banners? The EU Commission has finally proposed a solution: set your privacy preferences in the browser once, and never see another banner. Unfortunately, the tracking industry is pushing back – and so far, they’ve been successful. We need YOUR help to #KillTheCookieBanner!

Learn more • Take Action!

The EU has fucked this up twice already. I have no doubt they can pull off a hat-trick.

Anyone this is relevant to assumed this I'm sure.

Copilot is the second biggest contributor lol

Just go look at the repo. 😅

Well that's just demonstrably wrong. Go look at the commit history of the go port. Extensive use of Copilot. Slop.

Though it sounds like a lot more work to get this implemented and merged, ideally the improvements would be implemented in the browser engines instead.

Typescript's port to Go was done (or at least the vast majority of it was done) by hand, before AI porting was feasible.

In any case, AI is quite good at 1:1 porting these days. I wouldn't class the result as slop unless the input was slop or you did an especially bad job.

Are you thinking of Bun’s rewrite in Rust? Or else please share the deets, cuz I have not heard of this drama.

And it was slop coded by engineers who think it's fine to talk in abusive mannerisms to chatbots inside of GitHub PRs.

I'm staying far, far away from this nonsense. Personally I only write in JavaScript anyway and only use tsc for type checking. Will pin to v6 for as long as humanly possible.