When?

Use of JS, including the NPM-backed bloat you see in libraries used on the modern web, is orthogonal to whether a site is on a static host or not—which is what "static website" actually refers to.

For examples, see: a bunch (most?) of the stuff hosted on GitHub Pages.

> Nowadays every page you see is always using fancy technologies and "modern" UI that looks like unicorn barf.

... says the person responsible for authoring/publishing a post exhibiting some of the worst decisions I've seen for styling a Web page all week.

> hopefully that [1MB] will be served from a cache

Barcodes have been generated for decades on low-resource embedded devices. Even what would have been a modest-to-low-end machine 25 years ago would have no problem handling the compute needed for this job.

On this end, it just looks like the user has to deal with the penalty of dealing with 1 MB of resources when hitting the main page.

Have you considered offering, as penitence, a public feed to share the information that this process produces?

So much for those oft-touted benefits of Apple's policy on gatekeeping third-party apps so it allows them to enforce quality standards.

Not "just". You left out its role as a bot network exit node.

On that note please excuse my use of a shared account, as I finish wrapping up my affairs on this benighted website; Mr. Gackle has proven after all very inclined to behave in a precipitous and spiteful manner, and not nearly so evenhanded as I had previously seen cause to confide.

Assuming this comment survives to be read, I would counsel those continuing to use this website to conduct themselves accordingly and with all due care. Not my kind of problem any more, thank God: I work in a grocery store these days. Imagine that! It's like a gym membership that pays me.

You mean your browser's. There is no "the browser".

> Where are the interface boundaries? Why are there methods that are 200 lines long?

LLM-backed code assistants have brought to languages that have been historically less "toolable" the same downsides that IDEs brought to e.g. Java.

Expectation: nominally, an IDE would do one thing, which is to make it faster and easier to do what you would have done without the IDE.

The reality: IDEs make their programmer slightly more productive and other programmers not using IDEs much less productive; instead of "producing programs, faster", what IDEs do is produce programmers who produce programs that aren't especially work-withable (e.g. navigable) without tooling.

It's not merely "like" that. That's what it is.

"Wiki" comes from the Hawaiian work for "quick". You spot an error, you click the button to change it, and the change is made. That's wiki.

"Open a pull request and get it approved" is not wiki. It's what the default collaboration model was before wikis and exactly why the wiki was invented (to replace it).

1. forking the repo

2. committing the changes

3. submitting a pull request

... then you don't have a wiki.

Or MIME, even.

In a literal sense, it very well may have been trivial, even if neither you nor the professor would have been able to easily show it.