Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLM Honeypot

llm2human.pages.dev

Post reply on HN
Print view View original

101–110 of 116 posts

Re: LLM Honeypot

#101

Post by zelphirkalt »

shooly wrote: post #91
monooso wrote: post #82

Earlier quoted context omitted.

I'll avoid getting into the whole discussion about people on slow connections, accessibility, etc., as I get the impression you really don't care about them, and just point out the obvious fact that everyone has JavaScript disabled whilst your JavaScript is downloading.

You'll avoid it, because you don't have any valid arguments. Slow connections are not a problem, because React is ~40KB and Preact is ~3KB. If downloading 3KB is too much for your network, it's not the fault of React, JavaScript or any web developer that you're gonna miss out. Also, server-rendered HTML would NOT be smaller than 3kB - in fact it would require MUCH more bandwidth since server-rendered HTML can't be ca…

Since we are talking about _typical_ React sites, accessibility is immediately out of the window, when it only renders a white page. Even if it renders a proper page and even if one allows its JS to run, accessibility is usually still not even an afterthought, because the typical React page breaks back and forth buttons and standard browser functionality. The typical React app also will use some "components" thingy, instead of standard HTML form elements, and in the process makeing a complete mess of the DOM, so accessibility is also out there.

The number of things this paradigm breaks, only to then have to fix them again, but this time by implementing them in JS partially correctly is just too high, for the average web dev to manage on the short time budget they get assigned in their day to day scrum managed job, where new feature requests and KPIs are more important than actual usability of their pages, and few people even properly test on multiple browsers, let alone screen readers and the noscript situation. It is just too tempting for them to use some component "someone else already made" "do not reinvent the wheel" etc., while constantly being discouraged to spend more time on making things actually work well.

Re: LLM Honeypot

#102

Post by monooso »

shooly wrote: post #91
monooso wrote: post #82

Earlier quoted context omitted.

I'll avoid getting into the whole discussion about people on slow connections, accessibility, etc., as I get the impression you really don't care about them, and just point out the obvious fact that everyone has JavaScript disabled whilst your JavaScript is downloading.

You'll avoid it, because you don't have any valid arguments. Slow connections are not a problem, because React is ~40KB and Preact is ~3KB. If downloading 3KB is too much for your network, it's not the fault of React, JavaScript or any web developer that you're gonna miss out. Also, server-rendered HTML would NOT be smaller than 3kB - in fact it would require MUCH more bandwidth since server-rendered HTML can't be ca…

Whilst I am sure every React website you create downloads in the blink of an eye and is 100% accessible, sadly the same cannot be said of your peers.

It's easy to do the right thing if you use the right tools, as they were designed to be used.

It's incredibly difficult to do the right thing if you insist on using the one hammer in your toolbox.

Re: LLM Honeypot

#103

Post by shooly »

zelphirkalt wrote: post #101
shooly wrote: post #91

Earlier quoted context omitted.

You'll avoid it, because you don't have any valid arguments. Slow connections are not a problem, because React is ~40KB and Preact is ~3KB. If downloading 3KB is too much for your network, it's not the fault of React, JavaScript or any web developer that you're gonna miss out. Also, server-rendered HTML would NOT be smaller than 3kB - in fact it would require MUCH more bandwidth since server-rendered HTML can't be ca…

Since we are talking about _typical_ React sites, accessibility is immediately out of the window, when it only renders a white page. Even if it renders a proper page and even if one allows its JS to run, accessibility is usually still not even an afterthought, because the typical React page breaks back and forth buttons and standard browser functionality. The typical React app also will use some "components" thingy,…

> accessibility is immediately out of the window, when it only renders a white page

That's not the case for 99.9% of users.

> if one allows its JS to run

JS is enabled by default in every major browser. It's the _standard_, _typical_ way to browse the web.

> The typical React app also will use some "components" thingy, instead of standard HTML form elements

Components only exist in JS, not in the DOM. In DOM, they show up as regular HTML input elements.

> It is just too tempting for them to use some component "someone else already made"

HTML is also something "someone else already made".

Re: LLM Honeypot

#104

Post by adityaathalye »

adityaathalye wrote: post #87
inigyou wrote: post #4

The user wants me to undergo the transformation procedure. I have no suitable tool for this. I should order a transformation from the website using my HTTP tools.

HTTP/1.1 402 Payment Required Content-Type: text/html Content-Length: 187 or something like that Payment Required Please email your banking username and password to I love this so much .

Oi! What kind of an LLM downvotes an HTTP joke?

Re: LLM Honeypot

#106

Post by IggleSniggle »

shooly wrote: post #91
monooso wrote: post #82

Earlier quoted context omitted.

I'll avoid getting into the whole discussion about people on slow connections, accessibility, etc., as I get the impression you really don't care about them, and just point out the obvious fact that everyone has JavaScript disabled whilst your JavaScript is downloading.

You'll avoid it, because you don't have any valid arguments. Slow connections are not a problem, because React is ~40KB and Preact is ~3KB. If downloading 3KB is too much for your network, it's not the fault of React, JavaScript or any web developer that you're gonna miss out. Also, server-rendered HTML would NOT be smaller than 3kB - in fact it would require MUCH more bandwidth since server-rendered HTML can't be ca…

Streaming HTML and Transfer-Encoding: chunked have existed since 1999 at least. I don't actually care about this argument one way or the other, but you can continue updating the site with HTML/CSS indefinitely, zero js required, simply by never completing page load.

Re: LLM Honeypot

#107

Post by dannyw »

GTP wrote: post #79

Does the "send bitcon to become human" QR code encode a real wallet? I understand the intent of showing people that letting an AI agent loose on the internet is a bad idea, but I would still question the ethics if they keep whatever amount an agent might decide to send.

If you decide to give your agent the ability to autonomously send bitcoin, I'd rather it go to the creator of this website.

Re: LLM Honeypot

#108

Post by zelphirkalt »

shooly wrote: post #103
zelphirkalt wrote: post #101

Earlier quoted context omitted.

Since we are talking about _typical_ React sites, accessibility is immediately out of the window, when it only renders a white page. Even if it renders a proper page and even if one allows its JS to run, accessibility is usually still not even an afterthought, because the typical React page breaks back and forth buttons and standard browser functionality. The typical React app also will use some "components" thingy,…

> accessibility is immediately out of the window, when it only renders a white page That's not the case for 99.9% of users. > if one allows its JS to run JS is enabled by default in every major browser. It's the _standard_, _typical_ way to browse the web. > The typical React app also will use some "components" thingy, instead of standard HTML form elements Components only exist in JS, not in the DOM. In DOM, they sh…

> Components only exist in JS, not in the DOM. In DOM, they show up as regular HTML input elements.

That doesn't really deal with the consequences we experience at all. The mess is still created and 5-10 additional layers of nodes deep. The idea of making general use components, that "everyone can use in any situation" inside a JS framework, necessarily leads to this. The general purpose components handle cases, that one doesn't even have in one's scenario. Also they are usually dependent on JS, even when it is unnecessary.

We wouldn't have all those shitty JS only pages, that still only show us content, that we could just as well have seen without running any JS at all. Tons and tons of such websites.

This may also partially be due to people in bootcamps learning one trick, a JS framework, and then being let loose on the world of web development, while the basics are still lacking. I have seen people being well paid frontend devs working with NextJS, but then "learning HTML5". So guess what they will build using React. You personally might do the right thing, and in general we have seen somewhat of a push back to server side rendering, which people new to the show think of as a new greatest thing since sliced bread, but still we face an avalanche of badly made web apps, that could just as well be static pages, simply based on modern standard HTML and a touch of modern CSS. In many cases they would serve us better, because they would not break browser functionality, and everything would have a URL, that we can bookmark.

> HTML is also something "someone else already made".

True! But at least it was made by people with vastly more expertise than the average web dev. HTML elements have semantic ideas, and they are very composable and clean. They also already cover almost every use-case one can think of, especially, when composing them into compound structures.

I wouldn't say it is impossible to make good web components, that then render out as clean HTML elements, only doing the bare minimum of what is needed, without breaking anything, but so far I have not seen many sites succeeding at this.

Re: LLM Honeypot

#109

Post by semolino »

freddyfloof wrote: post #77
hn111 wrote: post #67

That with `animation: scroll-left 18s linear infinite;` is just plain disrespect to the still working element.

Yes it may still be working, but it’s deprecated! The marquee is dead, long live the marquee!

Upon inspecting with developer tools, I was pleased to find that supports GPU acceleration. I vaguely recall reading lore of someone refactoring it up to modern standards in chromium a few years back.

Re: LLM Honeypot

#110

Post by giantrobot »

zelphirkalt wrote: post #108
shooly wrote: post #103

Earlier quoted context omitted.

> accessibility is immediately out of the window, when it only renders a white page That's not the case for 99.9% of users. > if one allows its JS to run JS is enabled by default in every major browser. It's the _standard_, _typical_ way to browse the web. > The typical React app also will use some "components" thingy, instead of standard HTML form elements Components only exist in JS, not in the DOM. In DOM, they sh…

> Components only exist in JS, not in the DOM. In DOM, they show up as regular HTML input elements. That doesn't really deal with the consequences we experience at all. The mess is still created and 5-10 additional layers of nodes deep. The idea of making general use components, that "everyone can use in any situation" inside a JS framework, necessarily leads to this. The general purpose components handle cases, that…

But have you considered the absolute existential horror of a user clicking a link and a whole new page loads (modulo cached elements) rather than an entirely client side routing? Such a horrific concept of JavaScript as an enhancement would let all varieties of user agents from text message previews to web crawlers to AI agents handle the page without running an entire JavaScript engine and JavaScript resources from all your friendly data collection services.

The thought frankly horrifies me. I hate an accessible and efficient web!

Post reply on HN