Forest @forestjohnson@pixie.town

@dumpsterqueer

I like your approach of sticking w/ jpeg and using webp for transparent images 👍

It can be slightly annoying to download an image and then realize whatever image editing program can't open it.

I like to use avif for big highly compressed photos on the web, I think it does noticeability better than webp. The background on https://layerze.ro is only a few KB. But for thumbnails I doubt the difference between jpg and anything else would be worth the fuss.

@j3s
https://git.sequentialread.com/sqr/greenhouse/src/branch/main/frontend.go#L107

```
sanityClient := &http.Client{
Timeout: time.Second * 20,
}
```

@j3s the context stuff should not be required afaik unless theres something in a library you use which requires a context passed to it.

Setting the timeout on the http client should be all you need.

Modifying the default http client is slightly frowned upon in programs that have dependencies and do a lot of stuff... But vore is simple enough its fine. Otherwise you can create your own http client and use that one instead of the default.

@j3s classic golang infinite timeout by default right ? 🫠

@gabek please hold while I get my financial shit together again... Then you can send them my way

@zens@merveilles.town @aynish I should clarify, I mean specifically for highly interactive / dynamic web apps like a mastodon client, something that behave more like a desktop/mobile app. For everything else I agree the "fit it in one file less than 12kb" approach is

@zens@merveilles.town @aynish

Yeah this is all too real, the "solution to problem caused by previous solution" pattern of tech. Its nice to get off the treadmill. For example if I make a small web app w/ preact and parcel, it will be like 7kb to 14kb unminified/uncompressed... But as soon as I wanna display a legible stacktrace to the user when an error occurs, I have install the 'sourcemapped-stacktrace' package and oops.. bundle.js is ~100kb now.

Theoretically possible to make it load that part after the page we care about loads, but now we're loading error handler separately and **after** everything else loads, and we need fallbacks, and, and, and, it never ends.

Idk if there is any ideal solution to this. Web dev is just hard.

@zens@merveilles.town react is not the only game in town for this kind of strictly enforced code vs data separation, but its definitely a popular example.

In vanilla js, one would simply stick to document.createElement and element.textContent and everything should be fine.

Tools like htmx fundamentally don't do this, they load the HTML from the server and execute it as code, so the server is responsible for making sure its templating is clean.

Its harder to be sure its right without access to the actual DOM implementation that the browser uses, google search had an xss that was caused by differences between two different html parsers/serializers, the one they used on the server vs the one they used on the client side.

@zens@merveilles.town not exactly. React doesn't deal with template or html strings at all at runtime, it compiles to "hyperscript", aka, 1000s of "document.createElement()"s in a trenchcoat. And the hyperscript it generates is always fundamentally xss-proof unless you use the " danger" functions.

Other frameworks like angular 1.4 that used string templates were never fundamentally xss-proof... They were like input sanitizers, so it was always a cat and mouse game between attacker and defender.

There is a fundamental difference between trying to sanitize inputs vs explicit separation of code vs data. Similar to the difference between parameterized SQL queries and special "SQL template" tools that would try to sanitize inputs. There was a similar cat and mouse game w/ those.

@zens@merveilles.town I think the ppl saying "Dev experience" actually mean "corpo manager experience".

The frameworks do have benefits; they allow us to shed legacy and rename / deprecate things that have been named wrong for decades. For example, in react, `element.innerHTML` was renamed to `dangerouslySetInnerHTML`. Honestly this is the single best feature of react.

None of this matters if you are just trying to make a single user web tool or a blog. But if you're a corporate manager and you want to throw whatever programmers you can manage to retain at a problem, react is the obvious choice. Chances are you arent gonna get the budget it would take to hire ppl who have the 2-5 years of in-depth web platform experience that it seems to take to be able to really do complex web apps in vanilla js without accidentally creating arbitrary code execution from user-provided content.

I've helped a few folks with their first frontend projects outside of work, and I've found trivial xss every single time.

Yes there are tons of ways to mitigate xss, but none of them really shut the door on it with an ultimate eternal sealing spell like react does.

@zens@merveilles.town I've heard this take a lot too, that usability is inherently exploitative in some way. That ez to use software is necessarily going to be serving a purpose other than offering utility to the user.

IMO its one of those things that is obviously not true, but might as well be true in the world that we live in.

I think its more accurate to say that software development is difficult and expensive, but some people manage to do it as a hobby or for the public good. HOWEVER, software development *including usability testing* is at least 10X MORE expensive, and practically no one has ever managed to come up with the scratch to do it outside of a commercial context. So all the effort tends to go into making it intuitive to buy loot boxes