I can't help but think that currentgen programmers are misunderstanding Knuth and anachronizing him, with their being a product of the current programming regime where most never lived in a world without structured programming, for example, when we hear "literate programming", we attempt to understand it by building off our conception of current programming practices and try to work out what Knuth could mean given widespread modern affordances as a precondition, when really Knuth is just advocating for something that approximates (with ink and paper) currentgen tooling, and is therefore in fact more primitive than our reference point which we are trying to understand as being capable of being improved upon, but Knuth's LP is an improvement nonetheless of something even more primitive further still.

Good example of a "narrative elsewhere".

The joke being that both jQuery and COBOL were crummy right from the beginning, and now they're crummy and old, right?

What does this even mean?

I also find it laughable/horrifying the comparison between jQuery and greybeardism (or, elsewhere, a bicycle[1]). jQuery is definitely not that. It is the original poster child for bloat.

For all the people feigning offense at the "greybeard" comments at the thread start, it's much more common, unfortunately, to find comments like this one, with people relishing it when it comes to jQuery, because it confers an (undeserved) sense of quasi-moral superiority, wisdom, and parsimony, even though—once again—jQuery represents anything but those qualities.

1. https://news.ycombinator.com/item?id=31440670

jQuery is primarily a DOM manipulation library and incidentally smoothed over differences in browsers' DOM implementations. To the extent that there were any significant differences in browser's JS implementations, jQuery offered little if anything to fix that.

This is 70+% of the reason why I end up ripping out jQuery from old/throwaway projects when I start trying to hack on them. The jQuery object model is really confusing (read: tries too cute/clever), and the documentation sucks, relatively speaking, and the code is an impenetrable blob, which means reading through it to figure out WTF it's supposed to do is a non-option.

This happens to be true of many of the new/up-to-date Web developers I see, too.

Anecdote: I never really did StackOverflow, either as a reader or a contributor. One day several years ago (well after StackOverflow had taken off), I figured that since I see people complain about JS being confusing all the time and since I know JS well, then I'd go answer a bunch of questions. The only problem was that when I went to the site and looked at the JS section, it was just a bunch of jQuery and framework shit—too much to simply ignore and try to find the ones that were actually questions about JS-the-language. "I know," I thought. "I'm in the JS section. I'll just manually rewrite the URL to jump to the ECMAScript section, which surely exists, right? So I did that, and I just got redirected to the JS section...

This remark manages to make this one of the dumbest comments I've ever read on HN.

I'm having real difficulty understanding what is going on here and in what situations such cascading problems occur.

Is it a case of under-abstraction?

Does "what they need" here implicitly mean "a design that no one really benefits from but you can bill a client for $40+/hr for"? Because that's how Glitch comes off to me—more vocational (and even less academic) than a bootcamp without the structure.

What was that part about home-cooked meals?

This is where I think Glitch goes wrong. Why such a focus on apps (and esp. pushing the same practices and overcomplicated architecture as people on GitHub trying to emulate the trendiest devops shovelware)?

"Web" is a red herring here. Make the Web more accessible for app creation, sure, but what about making it more accessible (and therefore simpler) for sharing simple stuff (like documents comprising the written word), too? Glitch doesn't do well at this at all. It feels less like a place for the uninitiated and more like a place for the cool kids who are already slinging/pushing Modern Best Practices hang out—not unlike societal elites who feign to tether themself to the mast of helping the downtrodden but really use the whole charade as machine for converting attention into prestige and personal wealth. Their prices, for example, reflect that. Where's the "give us, like 20 bucks a year and we'll give you better alternative to emailing Microsoft Office documents around (that isn't Google Sheets)" plan?

See also An app can be a home-cooked meal along with this comment containing RMS's remarks with his code-as-recipe metaphor in the HN thread about Sloan's post:

some of you may not ever write computer programs, but perhaps you cook. And if you cook, unless you're really great, you probably use recipes. And, if you use recipes, you've probably had the experience of getting a copy of a recipe from a friend who's sharing it. And you've probably also had the experience — unless you're a total neophyte — of changing a recipe. You know, it says certain things, but you don't have to do exactly that. You can leave out some ingredients. Add some mushrooms, 'cause you like mushrooms. Put in less salt because your doctor said you should cut down on salt — whatever. You can even make bigger changes according to your skill. And if you've made changes in a recipe, and you cook it for your friends, and they like it, one of your friends might say, “Hey, could I have the recipe?” And then, what do you do? You could write down your modified version of the recipe and make a copy for your friend. These are the natural things to do with functionally useful recipes of any kind.

Now a recipe is a lot like a computer program. A computer program's a lot like a recipe: a series of steps to be carried out to get some result that you want. So it's just as natural to do those same things with computer programs — hand a copy to your friend. Make changes in it because the job it was written to do isn't exactly what you want. It did a great job for somebody else, but your job is a different job. And after you've changed it, that's likely to be useful for other people. Maybe they have a job to do that's like the job you do. So they ask, “Hey, can I have a copy?” Of course, if you're a nice person, you're going to give a copy. That's the way to be a decent person.

And how future-proof was the result or how easy was it to make sure you could share it with others in a form that they could make use of (and not be dependent on you or some third-party or their internet connection)?

There's a related phenomenon/paradox: the superinferiority of "native" applications.

superfluous and ostentatious

this page should link to the flyctl CLI docs

When I created a blank app with flyctl launch, it gave me a fly.toml with 8080. The fly.toml cloned from the repo, however, already has it set to 8043.

It's possible that the quoted section is still correct, but it's ambiguous.

Also available here, from the Computer History Museum's channel on YouTube (parts 1 and 2): * https://www.youtube.com/watch?v=_oGq1RcM8B0 * https://www.youtube.com/watch?v=4ffAkshf2n8

Also available here: https://www.ayeconference.com/Articles/Whatssospecialaboutsw.html

This is supposed to be the justification for increasing code size. So what's the excuse for projects today? Software of today is not exactly known for adding more "error checking and correction". It feels more like growth for growth's sake, or stimulating some developer's sense of "wouldn't it be cool if [...]?".

No need to constraint yourself to comments, though. Why comments? We can do full-fledged, out-of-line doclets.

This is part of the reason why I advocate for language skins for comparatively esoteric languages like Ada.

Well, there could still be a weave step—same as there is like with triple scripts (to go from compilation form back to the original modules) or with Markdown, which should be readable both as plain text and in rendered form.

(NB: the compilation "object" format here would, much like triple scripts, be another form of human readable source.)

Do we have to wait for people to die before these kinds of digital fanclubs can materialize for people who aren't in entertainment?

Having trouble sourcing this quote? That's because some shithead who happens to run a popular programming blog changed the words but still decided to present it as a quote.

Raskin's actual words:

the fundamental reason code cannot ever be self-documenting and automatic documentation generators can’t create what is needed is that they can’t explain why the program is being written, and the rationale for choosing this or that method. They cannot discuss the reasons certain alternative approaches were taken. For example:

:Comment: A binary search turned out to be slower than the Boyer-Moore algorithm for the data sets of interest, thus we have used the more complex, but faster method even though this problem does not at first seem amenable to a string search technique. :End Comment:

From "Comments Are More Important Than Code" https://dl.acm.org/ft_gateway.cfm?id=1053354&ftid=300937&dwn=1

This is a good case study for what I talk about when I mean the fancub economy.

Wouldn't it be better if gklitt were a willing participant to this aggregation and republishing of his thoughts, even if that only meant that there were a place set up in the same namespace as his homepage that would allow volunteers ("fans") to attach notes that you wouldn't otherwise be aware of if you made the mistake of thinking that his homepage were his digital home, instead of the place he's actually chosen to live—on Twitter?

I loved the Moto G (the original—from during the brief time when Google owned Motorola). I used it for 6 years. It's not even an especially small phone. Checking the dimensions, it's actually slightly smaller (or, arguably, about the same size) when compared to either the iPhone 12 Mini and the iPhone 13 Mini—which I'd say makes those deceivingly named. They're nothing like that one that Palm made, which is called, uh... "Palm", I guess. (Described by Palm as about the size of a credit card.)

Memory usage is a concern? wat

It's a problem, sure, if you're programming the way NPMers do. So don't do that.

This is a huge problem I've noticed when it comes to people programming in JS—even, bizarrely, people coming from other languages like Java or C# and where you'd expect them to at least try to continue to do things in JS just like they're comfortable doing in their own language. Just because it's there (i.e. possible in the language, e.g. dynamic language features) doesn't mean you have to use it...

(Relevant: How (and why) developers use the dynamic features of programming languages https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf)

The really annoying thing is that the NPM style isn't even idiomatic for the language! So much of what the NodeJS camp does is so clearly done in frustration and the byproduct of a desire to work against the language. Case in point: the absolutely nonsensical attitude about always using triple equals (as if to ward off some evil spirits) and the undeniable contempt that so many have for this.

on baggage: "package.json", for example, is not an ECMA standard

My argument: JavaScript is a future-proof programming language

Also (related moreso to Future-proof), Haxe? Dart?

Absent from consideration: * Gecko/XULRunner (check out the way that Zotero is built) * GtkJS

Both deserve a look

My reaction to the author's take on future-proof programming languages even before I got to this post (and this part in it) was that he should look at porting (or getting ported) the C# standard libraries (to JS—as part of my argument that JS the future-proof programming language Krinke is looking for).

Dear wanderer:

A copy of the content you're looking for can be found here: https://s3-eu-west-1.amazonaws.com/kosmos-social/media_attachments/files/105/949/240/042/806/220/original/0572af7c5d7f0191.png

My argument for the use of the Web as a medium for publishing the procedures by which the documents from a given authority are themselves published shares something in common with the argument for exploiting Lisp's homoiconicity to represent a program as a data structure that is expressed like any other list.

There are traces here as well from the influence of the von Neumann computational model, where programs and data are not "typed" such that they belong to different "classes" of storage—they are one and the same.

Consider ways to build on the static node architecture that wouldn't require you to give this up:

• PGP blobs instead of plain text
• messages relayed through WebRTC when both participants are online
• you could choose to delegate to a message service for your DMs, to guarantee availability, just like in the olden days with telephones

Yes.

Interesting that this is written by a BSD guy.

This is really only a problem in languages that make the unfortunate mistake of allowing references to unqualified names that get fixed up as if the programmer had written this.mPoint or Foo.point. Even if you're writing in a language where that's possible, just don't write code like that! Just because you can doesn't mean you have to.

The only real exception is distinguishing locals from parameters. Keep your procedures short and it's less of a problem.

similar to my strawman for language skins

This old hat description captures something not usually brought up by CLI supremacists: GUIs as ways validate and impose constraints on structured data.

(NB: this is in response to the question Why not just use wordpress + wysiwyg editor similar to *docs, and you're done?.)

This is a good of an explanation as any for local-first software.

A natural response (to potatolicious's comment) is, "Well, somebody has to maintain these no-code Web apps, too, right? If there's someone in the loop maintaining something, the question still stands; wouldn't it make more sense for that something to be e.g. a WordPress instance?"

Answer: yeah, the no-code Web app model isn't so great, either. If service maintenance is a problem, it should be identified as such and work done to eliminate it. What that would look like is that the sort of useful work that those Web apps are capable of doing should be captured in a document that you can copy to your local machine and make full use of the processes and procedures that it describes in perpetuity, regardless of whether someone is able to continue propping up a third-party service.

There's plenty of irrationality to be found in opposing camps, too. I won't say that it's actually worse (because it's not), but it's definitely a lot more annoying, because it usually also carries overtones that there's a sort of well-informed moral and technological high ground—when it turns out it's usually just a bunch of second panel thinkers who themselves don't even understand computers (incl. compilers, system software, etc.) very well.

This is what makes it hard to have discussions about reforming the practices in mainstream Web development. The Web devs are doing awful things, but at least ~half of the criticism that these devs are actually exposed to ends up being junk because lots of the critics unfortunately just have no fucking idea what they're talking about and are nowhere near the high ground they think they're standing on—often taking things for granted that just don't make sense when actually considered in terms of the technological uppercrust that they hope to invoke. Just a kneejerk "browser = bad" association from people who can't meaningfully distinguish between JS (the language), browser APIs, and the NPM corpus (though most NPM programmers are usually guilty of exactly the same...).

It's a very "the enemy of my enemy is not my friend" sort of thing.

Flems does something like this:

To allow you to use Flems with only a single file to be required the javascript and the html for the iframe runtime has been merged into a single file disguised as flems.html. It works by having the javascript code contained in html comments and the html code contained in javascript comments. In that way if loaded like javascript the html is ignored and when loaded as html the javascript part is ignored.

https://github.com/porsager/flems#html-script-tag

I've referred to a similar (but-unrelated) architecture diagram for writing platform-independent programs as being a Klein bowtie. There is a narrow "waist" (the bowtie know), with either end of the bowtie being system-specific routines (addressed by a common interface in the right half of the diagram).

From https://news.ycombinator.com/item?id=31378614:

There's this tendency of languages to want to be the be-all end-all, i.e. to pretend that they are at the center of the universe. Instead, they should focus on interoperating with other languages[...] This is one reason I'm working on https://www.oilshell.org -- with a focus on INTEROPERABILITY

wrt the sentiment in the McHale tweet:

See Tom Duff's "Design Principles" section in the rc manual http://doc.cat-v.org/plan_9/4th_edition/papers/rc, esp.:

It is remarkable that in the four most recent editions of the UNIX system programmer’s manual the Bourne shell grammar described in the manual page does not admit the command who|wc. This is surely an oversight, but it suggests something darker: nobody really knows what the Bourne shell’s grammar is.

See also https://www.oilshell.org/blog/2022/02/diagrams.html

Chesterton's fence/Rhesus ladder

Reference to a Kiczales talking point, e.g. Why are Black Boxes so Hard to Reuse?.

This is a very odd place to apply the word "compression", since pretty much the opposite is happening: there's enough redundancy that a single signal error doesn't bungle the entire attempt to communicate.

I think the only thing I liked that got close to this was Keybase.

Consider a Sufficiently Smart Compiler/Runtime where a multiply-instanced class has the exact same runtime characteristics as code that has been hand-"tuned" to use a singleton.

This is a fine perspective as long as you're not penalizing people who arrive at 12:59:59 — "If you are on time, you are late" is a stupid mantra that, while my sample size is low, I've only heard from people who were themselves egregious time wasters and made the remarks as a way of honoring Ra.

(I'd argue further that anyone who arrives at any time between [13:00:00, 13:01:00) are doing okay, so long as they're wiling to accept that no one is obligated to wait for them. I.e. what "the meeting is at 1:00 PM" means is that everyone has permission to start the meeting at 13:00:00, whether you're there or not.)

See also: GitHub contribution graphs

How do hyperlinks neutralize the ability for people to take things out of context? I see it all the time. The backchannels of Wikipedia are rife with it.

Academic citations are an amazing piece of technology, though.

I dunno. I think all the things about dynamism and liveness that follow this claim are true in the minds of most people. The rarity is for people to conceive of content on the Web (or elsewhere rendered to a computer screen) as capable of being imbued with the fixity of print. Everything feels transient and rests on a shaky, fleeting foundation..

Cool plurals don't apostrophize

This is an easy one: those people are wrong.

It actually can be easier than that if the only reason PHP is involved is for templating and you don't want CGI. (NB: This is admittedly contra "the mildly dynamic website" described in the article).

If you're Alice of alice.example.com, then you open up your local copy of e.g. https://alice.example.com/sop/pub.app.htm, proceed to start "hacking on it until it works", then rsync the output.

See also: The Computer Lib Pledge

Counterpoint: Phone is still the best way to order pizza

@45:18

In fact, after I did this, Nigel sent me a CL to do exactly that and[...] it's probably better, and it probably fixed what performance problems there may be, if any, but it just wasn't as pretty so I pushed back. I like this better.

Psst: Philip gave me a copy of this piece (just like he did many others before he decided to unpublish it). I will totally let you peek at my copy (if you want, and if you happen to be in Austin—I'll respect Philip's commandment not to distribute unauthorized copies, but to reiterate: you're free to look at the copy I already have). It's a great article, even if lots of the feedback at the time unnecessarily focused on quibbling with his decision to characterize the issue as being inherent to "command-line bullshittery", rather than charitably* interpreting it as general discontent with the familiar pain** of setting up/configuring/working with any given toolchain and the problems that crop up (esp. when it comes at the price of discouraging smart or even brilliant people who have interesting ideas they wish to pursue.)

* See also https://pchiusano.github.io/2014-10-11/defensive-writing.html

** See also http://lighttable.com/2014/05/16/pain-we-forgot/

If what we're discussing here is the decision to no longer opt in to playing along with the "Western" regime for IP, then why would they limit themselves to Linux and Wine—two products of attempts to play by the rules of the now-deprioritized regime? Why wouldn't they react by shamelessly embracing "pirated" forms of the (Windows) systems that they clearly have a revealed preference for? If hackability is the issue*, then that's ameliorated by the fact that NT/2000 source code and XP source code was leaked awhile ago—again: the only thing stopping anyone from embracing those before was a willingness to play along and recognize that some game states are unreachable when (artificially) restricting one's own options to things that are considered legal moves. But that's not important anymore, right?

* i.e. malleability, and it's not obvious that it should be—it wasn't already, so what does this change?

"You keep using that word..."

No, but further: the question (about being "limited") presupposes something that isn't true.

If you're doing PHP here, you're doing it wrong—unless the PHP application is written with great care (i.e. unidiomatically) and has some way to reveal its own program text (as first-class content). Otherwise, that's a complete failure to avoid the "elsewhere"-ness that we're trying to eradicate.

The difference being that you don't read shell scripts, except in the course of editing them. Shell isn't a very good language for writing checkllsts/SOPs, anyway.

"one day" is really only considered mlniscule by the likes of programmers, etc. Taking an entire day to work on something that would be seen as incidental is likely not to get approval in many organizations. (Places like Samsung exist.) And would they be wrong? Why should it require any porting effort at all?

"everything looks like a nail"

Answer: it's hosted under the same auspices as the main content. The "editor" is first-class content (in the vein of ANPD); it's really just another document describing detailed procedures for how the site gets updated.

In other words, do a lot of work to route around the problems introduced by the way that using npm routes around your existing version control system.

These packages don't/can't do the amount of exception handling suggested by this comment.

Using triple equals to check the results of typeof is totally unnecessary, and a sure sign that someone, somewhere has unthinkingly adopted some dubious advice; it's a code smell/red flag.

A standard equality comparison (using ==) does exactly the right thing while also avoiding association with questions/doubts about the quality of the surrounding code.

Food for thought.

How do companies that produce goods (light notebooks and graph paper) turn a profit? (For either of the two aforementioned examples, anyone can make their own from possibly cheaper primitives. Making graph paper, for example, is just putting lines on paper.)

Those goods being disposable and tangibly/temporally "rivalrous" in the physical world is one part of it, but it's not everything. People pay for convenience. (Look to e.g. paid Netflix subscriptions versus just pirating the stuff.) "Buy this ready-to-consume ebook" is one example of potentially profitable convenience that has made at least some inroads with the general public. Why shouldn't "buy this ready-to-use template" belong to the same set? Yeah, you could make your own, but this is graph paper.

See also https://hypothes.is/search?q=tag%3A%27%22algorithm%22+vs+%22heuristic%22%27

Isn't what we have now, i.e. the situation for most artists, pretty close to that?

When "ordinary" artists (i.e. not career creatives) make money from their work, how much do IP laws have to do with that? It seems like the overriding factor is a culture of patronage and/or paying for convenience. (And are those two even distinct? Does one explain the other?)

wat

This site has a total of two pages! Just reify them as proper documents instead of compilation artifacts emitted from an SSG.

Shouldn't the spirit of this project demand that, instead of this link pointing to a GitHub pretty-printed render of the style sheet source code, this link point instead to a hosted copy—which can itself by styled by XSL, rather than merely being presented in its raw XML form?

PS: Can an XSL style sheet point to itself to specify how it should be styled?

Needs to be resurrected. "Autonomous Data" is a way better name (being both cooler and less subject to ambiguity) than either "Solid" or "zero data [application]".

This term is well-suited for the sort of thing I was going for with S4/BYFOB.

@tomcritchlow's comment about being hobbled by CORS in his attempt to set up an app[1] that is capable of working with his Library JSON is relevant. With a BYFOB "relay" pretty much anyone can get around CORS restrictions (without the intervention of their server administrator). The mechanism of the relay is pretty deserving of the "autonomous" label—perhaps even moreso that Noel's original conception of what Autonomous Data really means...

1. https://library-json-node-2.tomcritchlow.repl.co/library?url=https://tomcritchlow.com/library.json

I'm confused by the continual references to the Replit. Once you have Replit-style power, you can do Mastodon interop—but it keeps you dependent on third-party SaaS. Continuing to violate the principle of least power isn't really any improvement. If you're going to shoot for displacing the status quo, it should be to enable public participation from people who have nothing more than a Neocities account or a static site published with GitHub Pages or one of the many other providers. Once you bring "live" backends into this (in contrast to "dead" media like RSS/Atom), you've pretty much compromised the whole thing.

There's nothing about this that requires Replit (or NodeJS, for that matter). The whole thing can be achieved by writing a program to run on the script engine that everyone already has access to—the one in the browser. No servers required.

A sort of "backend on the frontend".

A similar "BYFOB" design principle was the basis for a proposal to bring "Solid[-like] services for static sites" into existence. I submitted this proposal to NLnet in their call for applications for their user-operated Internet fund. It was not accepted.

Get rid of the networking, and make it more like the RSS/Atom model.

ActivityPub, for example, shouldn't really require active server support if you just want publish to the clear Web (i.e. have no use for DMs). Anyone, anywhere can add RSS/Atom "support" to their blog—it's just dumping another asset on their (possibly static!) site. Not so with something like Mastodon, which is unfortunate. It violates the Principle of Least Power at a fundamental level.

See also this thread with Noel De Martin, discussing a (Solid-based) organizer for your media library/watchlist: https://noeldemartin.social/@noeldemartin/105646436548899306

It shouldn't require Solid-level powers to run this. A design based upon "inert" data like RSS/Atom/JSON feeds (that don't require a smart backend to take on the role of an active participant in the protocol) would beat every attempt at Solid, ActivityPub, etc. that has been tried so far. "Inert"/"dead" media that works by just dumping some content on a Web-reachable endpoint somewhere, including a static site, is always going to be more accessible/approachable than something that requires either a server plug-in or a whole new backend to handle.

The litmus test for any new proposal for a social protocol should be, "If I can't join the conversation by thumping on my SSG to get it to produce the right kind of output—the way that it's possible with RSS/Atom—then the design is fundamentally flawed and needs to be fixed."

Before Keybase died, I had hopes that they would do something kind of like this. It'd work by installing worker services in the Keybase client and/or also allow you to connect to network-attached compute like AWS or DigitalOcean (or some Keybase-operated service) to seamlessly process worker requests when your laptop was offline. The main draw would be a friendly UI in the Keybase client for managing your workers. Too bad!

There was something like that, in HTML5's pre-history: Google Gears.

I've thought for a long time that someone should resurrect it (in spirit, that is) for the world's modern needs. Instead of running around getting everyone to install NodeJS and exhorting them to npm install && npm run, people can install the "Gears 2" browser extension which drastically expands the scope of the browser capabilities, and you can distribute app bundles that get installed "into" Gears.

Beaker (mentioned later in this post) was an interesting attempt. I followed them for awhile. But its maintainers didn't seem to appreciate the value of frictionless onboarding experience, which could have been made possible by e.g. working to allow people to continue using legacy Web browsers and distributing an optional plug-in, in the vein of what I just described about Gears.

A graphical JS interpreter? That's the browser! And it just so happens that it's already installed, too (everywhere; not just on Macs).

Nah. Just stop programming directly against NodeJS to start with!

The Web platform is a multi-vendor standardized effort involving broad agreement to implement a set of common interfaces. NodeJS is a single implementation of a set of APIs that seemed good (to the NodeJS developers) at the time, and that could change whenever the NodeJS project decides it makes sense to.

(Projects like WebRun which try to provide a shim to let people continue to program against NodeJS's APIs but run the result in the browser is a fool's errand. Incredibly tempting, but definitely the wrong way to go about tackling the problem.)

Agreed. NodeJS is developer tooling. It's well past the time where we should have started packaging up apps/utilities that are written in JS so that they can run directly in* the browser—instead of shamelessly targeting NodeJS's non-standard APIs (on the off-chance everyone in your audience is a technical user and/or already has it installed).

This is exactly the crusade I've been on (intermittently) when I've had the resources (time/opportunity) to work on it.

Eliminate implicit step zero from software development. Make your projects' meta-tooling accessible to all potential contributors.

* And I do mean "in the browser"—not "on a server somewhere that you are able to use your browser to access, à la modern SaaS/PaaS"

Why require Node?

Everything that this script does could be better accomplished (read: be made more accessible to a wider audience) if it weren't implemented by programming against NodeJS's non-standard APIs and it were meant to run in the browser instead.

All in all, despite its own flaws, I think this piece hints at a useful ontology for understanding the nuanced, difficult-to-name, POLP-violating design flaws in stuff like Mastodon/ActivityPub—and why BYFOB/S4 is a better fit, esp. for non-technical people.

https://hypothes.is/search?q=%22black+and+dead+is+all+you+need%22+user:mrcolbyrussell

But you're not! When you wield PHP like this, there is no URL for the piece of code per se—only its (potentially fleeting) output—unless you take special care to make that piece of code available as content otherwise. PHP snippets are just as deserving of a minted identifier issued for them as, say, JS and CSS resources are—perhaps even just as deserving as the content being served up on the site, but PHP actually discourages this.

Agreed, but a it's a very ironic remark, given the author's own position...

I argue that PHP is not reasonable here. The only appropriate thing for this use case is (unminified) JS—or some other program text encoded as a document resource permitting introspection and that the user agent just happens to be able to execute/simulate.*

• Just like the advocates of "a little jQuery", author here doesn't seem to realize that the use of PHP was the first step towards what is widely acknowledged to be messed up about the "modern" Web. People can pine for the days of simple server-side rendering, but there's no use denying that today's Web is the natural result of an outgrowth that began with abuses of the fundamental mechanisms underpinning the Web—abuses that first took root with PHP.

* Refer to the fourth and sixth laws of "Sane Personal Computing, esp. re "reveals purpose"

Controversial opinion: this is actually closer to doing the Web the way that it should be done, taking the intent of its design into account. NB: this is not exculpatory of minified JS bundles (where "megabyte" is the appropriate unit order of magnitude for measuring their weight) or anything about "modern" SPAs that thumb their nose at graceful degradation.

"an URL"? C'mon.

I dunno how sound this conclusion is. Even for static sites, there are lower friction ways to do them, but people usually opt for the higher friction paths...

Hey, look, it's an actually good example of the "steep learning curve".

(I never understood why people insist that referring to it as a steep curve is wrong; clearly the decisions about your axes are going to have an impact on the thing. It seems that everyone who brings this up is insisting on laying out their graph the wrong way and implicitly arguing that other people need to take responsibility for it.)

That makes them constitute separate editions. It makes things messy.

Unnecessary violation of the Principle of Least Power.

No active server component is necessary for this. It can be handled by the user agent's content negotiation.

Should we lean into that? Maybe some sort of "server BASIC" is what we need.

NB: need not (read: "should not") actually be a BASIC; moreso a shared spirit (see also: Hypercard)

It's not nearly as timeless as a person might have themselves believe, though. (That's the "predilection" for certain technologies and doing things in a certain way creeping in and exerting its influence over what should otherwise be clear and sober unbiased thought.)

There's basically one timeless API, and that means written procedures capable of being carried out by a human if/when everything else inevitably fails. The best format that we have for conveying the content comprising those procedures are the formats native to the Web browser—esp. HTML. Really. Nothing else even comes close. (NB: pixel-perfect reproduction à la PDF is out of scope, and PDF makes a bunch of tradeoffs to try to achieve that kind of fidelity which turns out to make it unsuitable/unacceptable in a way that HTML is not, if you're being honest with your criteria, which is something that most people who advocate for PDF's benefits are not—usually having deceived even themselves.)

Given that Web browsers also expose a programming environment, the next logical step involves making sure these procedures are written to exploit that environment as a means of automation—for doing the drudge work in the here and now (i.e., in the meantime, when things haven't yet fallen apart).

This would be a much better name than "blank nodes"...

Uh, it's the last element, though, not the first—right?

Bad idea to introduce this notation here at the same time as the (unexplained) use of square brackets to group a list of objects.

Lame.

Were parens taken?

Terrible choice for a name.

What was wrong with some variation of "anonymous"?

But this one did. Or rather, it used to be resolvable as http://infomesh.net/2001/08/swtips/ (note the trailing slash), but now that returns 404 and is only available as http://infomesh.net/2001/08/swtips (no trailing slash).

But Semantic Web Tips http://infomesh.net/2001/08/swtips/ is returning 404...

There's an unnecessary dichotomy here between uses JS and page is served as HTML. There's a middle ground, where the JS can do the same thing that it does now, but it only does so at edit time—in the post author's own browser, but not in others'. Once the post author is ready to publish an update, the client-side generated content is captured as plain HTML, and then they upload that. It still "uses JS", but crucially it doesn't require the visitor to have their browser do it (and for it to be repeated N times, once per page visit)...

A great case study in how the chest-puffing associated with the certain folks in certain segments of the compiled languages crowd can be cover for some truly embarrassing blunders.

(Also a great antidote against a frequent argument by self-taught "full stack" devs; understanding the runtime complexity of your program is important.)

I dunno. Was the wiki software in question MediaWiki?

I always thought it was weird when people would set up a wiki and'd go for something that wasn't MediaWiki (even though I have my own quibbles with it). MediaWiki was always the clear winner to me, even in 2012 without the benefit of another 10 years of hindsight.

This could/should be part of Zonelets itself.

This is less than ideal. Besides non-technical people needing to wade into the middle of (what very well might appear to them to be a blob of) JS to update their site, here are some things that Zonelets depends on JS for:

1. The entire contents of the post archives page
2. The footer
3. The page title

This has real consequences for e.g. the archivability for a Zonelets site.

The JS-editing problem itself could be partially ameliorated by with something like the polyglot trick used on flems.io and/or the way triple scripts do runtime feature detection using shunting. When the script is sourced via script element from another page, it behaves as JS, but when visited directly as the browser destination it is treated like HTML and has its own DOM tree for the script itself to make the necessary modifications easier. Instead of requiring the user to edit it as freeform text, provide a structured editing interface, so e.g. adding a new post is as simple as clicking the synthesized "+" button in the list of posts, copying the URL of the post in question, and then pasting it in—to a form field. The Zonelets script itself should take care of munging it into the appropriate format upon form "submission". It can also, right there, take care of the escaping issue described in the FAQ—allow the user to preview the generated post title and fix it up if need be.

Additionally, the archives page need not by dynamically generated by the client—or rather, it can be dynamically filled in exactly once per update—on the author's machine, and then be reified into static HTML, with the user being instructed to save it and overwrite the served version. This gets too unwieldy for next/prev links in the footer, but (a) those are non-essential, and don't even get displayed for no-JS users right now, anyway; and (b) can be seen to violate the entire "UNPROFESSIONAL" etthos.

Alternatively, the entire editing experience can be complimented with bookmarklets.