If we define its success by quality of discussion, I think it has also failed. My interactions on Mastodon have almost universally resulted in experiences that were worse than a typical HN interaction (already not great!), for example. About on par with what you've always been able to find in places like /r/programming or Keybase chat or IRC—ostensible nerds memetically regurgitating low-effort cynical takes and being hostile to outsiders who haven't yet sufficiently ingratiated themselves to the community. Very little diversity of thought or norms of interaction.

So how about a voluntary breakup? Something that the unfederated networks would never do unless trying to avoid being the target of litigation for anti-competitive practices, but where is the pressure to refrain from doing this for mastodon.social or anywhere else in the fediverse?

Backend for Backblaze's B2 suspiciously absent.

That's the problem—thinking about this in terms of "wanting software". It's wanting to publish. Tech workers have an especially hard time understanding this.

You're probably not under the impression that when the last person you heard of who got their book published finally pulled it off, they did it as a matter of wanting, say, an InDesign workflow versus something else. Because they weren't, and it didn't factor into their motivations at all—not even a little bit.

The problem almost certainly starts with the conception of what we're doing as "building websites".

When we do so, we mindset of working on systems

If your systems work compromises the artifacts then it's not good work

This is part of a broader phenomenon, which is that when computers are involved with absolutely anything people seem to lose their minds good sensibilities just go out the window

low expectations from everyone everyone is so used to excusing bad work

sui generis medium

violates the principle of least power

what we should be doing when grappling with the online publishing problem—which is what this is; that's all it is—is, instead of thinking in terms of working on systems, thinking about this stuff in such a way that we never lose sight of the basics; the thing that we aspire to do when we want to put together a website is to deal in

documents and their issuing authority

That is, a piece of content and its name (the name is a qualified name that we recognize as valid only when the publisher has the relevant authority for that name, determined by its prefix; URLs)

that's it that's all a Web site is

anything else is auxiliary

really not a lot different from what goes on when you publish a book take a manuscript through final revisions for publication and then get an ISBN issued for it

so the problem comes from the industry

people "building websites" like politicians doing bad work and then their constituents not holding them accountable because that's not how politics works you don't get held accountable for doing bad work

so the thing to do is to recognize that if we're thinking about "websites" from any other position things that technical people try to steer us in the direction of like selecting a particular system and then propping it up and how to interact with a given system to convince it to do the thing we want it to do— then we're doing it wrong

we're creating content and then giving it a name

This page is useful, but it needs footnotes citing the relevant standards.

Consider a "man2blog" — combining several things:

• a publication pipeline/authoring tools combo that is effected by copying the tool's manual somewhere, where the manual includes, like here in ANPD, an exact (machine executable) specification of its behavior
• the plain.txt.htm format https://www.colbyrussell.com/LP/debut/plain.txt.htm

So the steps look like:

1. Clone the repo, which is empty except for a lone "README.txt"
2. Write your blog post(s) as markdown and commit to the repo
3. Upload a copy of README.txt to your web host, except name it man2blog.txt.htm instead
4. Visit the URL for your copy of man2blog.txt.htm in your web browser
5. Press Ctrl+Enter
6. Feed in the sources to your blog

You could also include in the text of README.txt aka man2blog.txt.htm instructions for how to author an "adapter" for your web host, so that when man2blog.txt.htm finishes processing your input, it transfers control to the adapter, which handles automatically uploading the build artifacts. (The adapter should, of course, also live as a first-class piece—i.e., content—on your site, too, the way that ANPD explains it.)

Name chosen as a nod to the use of Template:Should be SVG on Wikipedia

See also: Web page that parses and explains the label on a bike tire

HN comments: https://news.ycombinator.com/item?id=30137984

wrong

There is no 7 anymore.

Isn't that a sign of (good) health, not an illness? in fact, i think by more critically observing the downsides of current practices, we can increase the number of drive-bys by 10x, and that we should aim to.

Whether "dealing with [the] community" takes more work than writing code is another matter, but one that can also probably be solved by being more critical of contemporary practices and expectations.

Should be optional.

Nah. If you're using "npm, webpack, babel, create-react-app, redux", you probably don't "love JavaScript". Those things exist and are used because the people who created and use them hate JS and have slowly worked together to try to make JS something else other than what it was (and still is).

I riffed on this here: https://hypothes.is/a/jXcnuhpDEeywaAuYKkKwbQ

Why are these back "links" not actually HTML links? Annoying. Conjecture: Since this is what you get with creator-controlled presentation, that's one of the reasons why people opt for Twitter et al.

I don't see how this ranks as "ideal". Ideal would be experiments created in a publishing pipeline that is as freeform as MS Paint but escapes the historical quagmire that Web publishing has been entangled in. (11ty and others earlier mentioned ain't it.) Something like Flash, but primarily aiming to aid the creation of content based on the written (or spoken) word, and less about applet-based application experiences or video/animation. (Although appropriately wielded, those would be fine, too. If everyone achieved their own tiny Encarta, that wouldn't be a bad place to be.)

This sounds like there's a conception of "blog" at play that's just a corruption of what a blog actually is. (Twitter can and mostly is just as "performative", by the way, if not moreso...)

Maybe PG's advice on exotic languages is really just another form of indirect gatekeeping to select for the well-off who can afford to have arbitrarily spent so much time on high-cost, zero-return endeavors—like spending school studying philosophy or learning to distinguish wine and appreciate art.

Or just save time and use recursive descent there, too.

... and Java for Everything.

I actually don't want this, for the same reasons listed under "Focus". See lkesteloot on IDEs "bleed[ing] red" https://www.teamten.com/lawrence/programming/write-code-top-down.html

Highlighting this, but really the whole section is almost perfectly written. Hardest is achieving your desired inner discipline and then having to fight with people who don't understand this shit (because their performance never matters, or they don't give a damn).

Indeed; untrusted drive-by apps are best handled by the sandboxed runtime that the world has already settled on—and that everyone already has—the WHATWG/W3C hypertext system, aka, the Web browser.

Remember: "the program is a locally saved copy" and "runs offline" are not mutually exclusive with "runs in the browser".

It's hard even it's more ideal forms (for different reasons). I outlined the antidote a year (or maybe two? geez) ago—the fanclub economy. Posted originally to socii, but it's dead now, so all I have is the local JSON dump, which I haven't fixed up and put online myself.

"will resemble"? What year was this written?

Is it? Who calls it that? Sounds like Pournelle's iron law of bureaucracy.

You're looking for https://nadia.xyz/creator-economy

We should be able to track down the source here just as easily as we can see verbatim quotes' original place.

citation needed

This is a popular way to describe it, but I don't believe it is actually helpful to people who don't already understand.

Obscurantism isn't a virtue.

Accessibility is more important, after all, than Kartik says it is (elsewhere; cf recent Mastodon posts).

Looks like it's dead. The link goes nowhere.

Apple is going to ditch TSMC for Intel—or rather, what will be the Apple-owned fabs formerly operated by Intel. After the acquisition, Apple will become a major champion for USG "investment" in US-based fabs, and they'll get what they want. They'll achieve parity with or surpass TSMC.

Two important things to be aware of:

1. Projections of semiconductor advancements hitting a wall, if they turn out to be valid and true, describe a set of circumstances that are actually beneficial to anyone trying to catch up to the tech leader.

2. There's a lot of low-hanging fruit to be had in fab operations. A lot. Given sufficiently mature/advanced (i.e. adequate) tech to start with, Apple can make leaps and bounds over, say, Samsung by business process improvements alone.

... but still harder than it should be. (Isn't this team supposed to be sensitive to stumbling blocks? I thought that was pretty much the entire gestalt of this platform...)

Foolish constraint.

Case study in equivocation.

... which is of course the whole point! We'd probably be better off promulgating "RFC" as a relevant term for more than just tech standards.

That's hardly tight. What it is, like much of Go, though, is "gcod enough". And a lot of JS is the same way, if you—once again—reject the desire to follow-by-example without taking care to make sure you don't pick bad examples—which is what the NodeJS world offers, by and large (which itself makes esbuild's entire raison d'etre part of a somewhat existential paradox).

Of course this fares poorly if the input ("your bundler's code") is low-quality.

It's important to make an apples-to-apples comparison, so you don't end up with the wrong takeaway, like, "Stuff written in JS is always going to be inherently as bad as e.g. Webpack," which is more or less the idea that this paragraph wants you to get behind.

It shouldn't be surprising that if you reject the way of a bad example, then you avoid the problems that would have naturally followed if you'd have gone ahead and done things the bad way.

Write JS that has the look of Java and broad shape of Objective-C, and feels as boring as Go (i.e. JS as it was intended; I'm never not surprised by NPM programmers' preference to write their programs as if willingly engaging in a continual wrestling match against a language they clearly hate...)

Should have led with this.

Zotero desktop needs an "inbox"—a Dropbox-like directory where you dump stuff into it, and then Zotero adds it to your library.

The same is true for login systems that use cookies, but no one cites that as a downside. There's an asymmetric standard being applied to HTTP native authentication.

How to get remote control over the Hypothesis sidebar (one way, at least):

1. Use the bookmarklet to open the sidebar
2. Click the sidebar's "Help" icon in the top right
3. Right click the "Help topics" link and select "Inspect" in the context menu to open the element in the browser devtools
4. Remove "noopener" from the link (easiest way is to just delete the element's "rel" attribute)
5. Change the link target to something other than "_blank" (e.g. "foobar")
6. In the sidebar, click the now-modified "Help topics" link
7. For good measure, in the new tab that opens, navigate to the same URL loaded in the sidebar (should be something like https://hypothes.is/app.html with a site-specific URL fragment; you can get the actual URL from the devtools JS console with document.documentURI, or right-clicking the sidebar and selecting "View Frame Info")

From the secondary tab ("foobar" opened by click in step #6) you should now have unrestricted, scriptable access to the DOM of the original sidebar iframe, using e.g. the JS console in devtools instance or a bookmarklet applied to the secondary tab—access it as window.opener.

Nope. That was way scummy.

"The greatest performance improvement of all is when a system goes from not-working to working" https://web.stanford.edu/~ouster/cgi-bin/sayings.php

wat

This is stupid.

See Java For Everything. https://www.teamten.com/lawrence/writings/java-for-everything.html

On the other hand, explicit is better than implicit. If you're attaining "no code" via implicit magic, that's not a win.

let id = response.headers.get("X-Request-ID");
if (id) {
  let info = this._pendingRequests.get(id);
  if (info) {

This is unused.

This is not a look-how-great-Webpack-is observation. This is a look-how-bad-the-source-code-is observation.

I keep seeing people say this, and it's one of the dumbest things I've ever heard. It's a WebExtension. There's even less reason to use obfuscators for extensions than there is to use them on the open Web...

... so?

The costs here tend to be overstated (and stated by people without a strong background in either browsers or languages, I've found).

I remember someone mentioning to Boris Zbarsky (and expecting him to agree) that IE compatibility was a source of bloat in Gecko. Of course, he corrected them.

Actual URL: https://www.xml.com/pub/a/w3j/s3.nelson.html

See also http://www.xmlvm.org/

Shame that setting up the Java project itself isn't as simple.

I like this one better than the traditional form, which is clumsy.

A good case study in ho-hoism.

Refer to the previous two notes:

• https://hypothes.is/a/RQgF4md_EeyzTmv5uuVjrg
• https://hypothes.is/a/9zTb-md_Eey_YRtWX7Mtxg

Desired workflow:

1. I navigate to the APL login page https://austin.bibliocommons.com/user/login
2. I invoke a bookmarklet on the login page that opens a new browser window/tab
3. In the second tab, I navigate here—to a locally saved copy of (a facsimile of) my library card
4. I invoke a bookmarklet on my library card to send the relevant details to the APL login page using window.postMessage
5. The bookmarklet set up in step 2 receives the details, fills in the login form, and automatically "garbage collects" the second tab

Some other thoughts: We can maintain a personal watchlist/readlist similarly. This document (patron ID "page") itself is probably not a good place for this. It is, however, a good place to reproduce a convenient copy of the necessary bookmarklets. (With this design, only one browser-managed bookmarklet would be necessary; with both bookmarklets being part of the document contents, the second bookmarklet used for step 4 can just be invoked directly from the page itself—no need to follow through on actually bookmarking it.)

Need to figure out the barcode format used on the actual cards and reproduce it here, too.

In fact, Ideally, this digital facsimile should hew close enough in fidelity to the actual thing that I should be able to print my own (using only the data encoded in this document as input).

Best way to view these in order:

Open the socii JSON export in the browser, defuse the unhelpful JSON viewer by using "View Source" if necessary, and then open a JS console to run the following snippet:

let o = JSON.parse(document.body.textContent)
o.sort((a, b) => (
  String(a["created"]["epoch_time"]) - String(b["created"]["epoch_time"])
))

Other useful snippets:

Easily spot thread chains (look or empty string for thread roots):

o.map((x) => (x["replyTo"]))

Get replies to other accounts:

o.filter((x) => (o.map((y) => (x["replyTo"] && y["id"])).indexOf(x["replyTo"]) < 0))

(It also wouldn't be a bad idea to take Fritter and wire it up to be able to read the export.)

You are looking for https://htmx.org/essays/rest-explained

Should system configuration files be full-fledged documents? I.e., explain to the user—with rich text, even—both the conventions of the configuration format as well as what the given system's actual configuration is?

It's almost as if the WebExtensions design was not very good...

Not so much "On the Web" as it is "In JavaScript". mjs is an invention of runtimes like NodeJS (and the unending toolchain hell that sprang up around it) to paper over NodeJS's non-standard idiosyncrasies that are entirely the closed loop result of their own doing.

The fact that this has infected discussion of JS itself is even more reason to despise Node and its ecosystem.

should be "loving"

missing an "until" here

Yikes.

Disingenuous, or just dumb?

Incomprehensible.

In a world where programmers behave reasonably (i.e., not the one we're living in), this is what the list of GitHub forks would be useful for. You have some need to extend a project, you look at the list of people advertising their forks of the upstream, you see one that could also benefit from the change you're looking to make, and you file a pull request to ask them to accept your changes. After reviewing your changes and accepting them (in the best case), then they can optionally pitch these changes to the original maintainer if they want (e.g. in the case of non-hostile forks).

In the world where we actually live, the list of forks is more or less useless; if you were to suggest that someone take your changes into their "fork", then they'll call you a weirdo and say that's not how any of this works—if they say anything at all.

Should be "compatible"

The distinction between Chesterton's fences and Rhesus ladders defined.

Ra ∋ Rhesus ladders https://hypothes.is/users/mrcolbyrussell?q=rhesus

typo for "exists"

Damn. HN's feedback has been dogshit when responding to Dan's posts. (Or at least I can say that this has been the case for 2 out of 2 of the most recent pieces that I've seen posted and witnessed the reaction in near real-time. They're so bad that I'm not really interested in checking the sentiment on other, older pieces of his that I've read.)

Work on solving it with the fanclub "economy".

From Understanding how killall works using strace https://jvns.ca/blog/2013/12/22/fun-with-strace/

From Ten Great Books https://sites.google.com/site/steveyegge2/ten-great-books

From Great Hackers http://www.paulgraham.com/gh.html?viewfullsite=1

From Architecture astronauts take over https://www.joelonsoftware.com/2008/05/01/architecture-astronauts-take-over/

I used to wince at these posts, but now I encourage them. See A New Publishing Discipline.

Counterargument: nobody's measuring anything.

Counterexample: GitHub.

None of this is really relevant. Of all the apps listed, none are especially relevant to the Web. They'd best be classified as internet apps. Granted, they might be dealing in HTTP(S) at some point as a bodge, but then again, almost everything else does, too, whether it's part of the Web or not.

(re @eric_young_1 https://twitter.com/eric_young_1/status/1470524708730851328—not sure how well the twitter.com client and Hypothesis interact)

The dream is still alive among semweb people (incl. Tim Berners-Lee himself).

The sad state of current norms re webapps created by professional devs leads to what probably seems like a paradox but isn't, which is that the alternate future outlined in this tweet is closer to the ideal of the Web than the "Modern Web".

404

The subtext here is, "that's why i created BeachfrontDigital". But this shows how "apps" (and systems) have poisoned how we conceptualize problems and their solutions.

The simplest solution to the problem described is a document, not a never-finished/never-production-ready app. Bespoke apps have lots of cost overhead. Documents, on the other hand—even documents with rich structure—are cheap.

See also: standardjs.com. The arrogance that it takes to try to pull stuff like this is... hard to describe.

Geez.

"Interoperable", you mean.

... why? Maybe it was only clear in hindsight, but Gruber's lack of response to the request is functionally equivalent to a pocket veto.

No.

The thing about syntax errors is that even if the build takes a long time (project is huge), syntax errors can be detected quickly.

Good way to describe ANPD.

Social barriers important, too, but underappreciated.

It is different. However, they're similar enough to draw lessons from.

I use similar, non-specced canaries all the time. E.g. small fixes for things in projects that are nonetheless obvious errors, or determining whether someone is going to try to frame my attempt to contribute by "upperhanding" me, whether they're hostile to messages attached to a name that they don't recognize, etc.

For example, if it takes too much back and forth to get a typo or link fixed in the docs (or any sort of review process for content on what is purported to be a "wiki"), then odds are, things are messed up at a greater level that are going to be a source of frustration later. At that point, I'm out.

A surprisingly large number of projects fail these, in what we are otherwise expected to consider the present Renaissance of FOSS...

Stanford runs their own archive instance (https://swap.stanford.edu/). Why shouldn't the LOC, too?

Does it? It's pretty much just as easy or easier than doing it the way that everyone else insists is correct. I'm more than half convinced, in fact, that the npm install way being unnatural is the reason why it's sacrosanct. You can't just let things be easy—people dislike any state of affairs where their experience/participation isn't some combination of necessary and valuable.

I've tried making this case. People flip their shit and then for lack of a good argument they start doing that thing where they try to shut you down because of how weird it is—and you don't want anyone thinking you're weird, do you?

It is unusual. It's not a bad thing to do, but it is still, in the literal sense of the word, unusual. That doesn't say anything about the practice itself so much as it says something about how bad the "usual" way of doing things is.

I've noted elsewhere that despite the reputation of WYSIWYG editors' tendencies for handling HTML, modern mainstream Web development practices are so bad today that just typing a bunch of junk into LibreOffice and saving as HTML results in one of the most economical ways to do painless authoring of Web content...

This gets it right. The similar essay "The JavaScript Trap" is anathema. As Richard was later cajoled into clarifying:

to be philosophically clear, the language JavaScript, as such, is not morally better or worse than any other language. What's bad is running code immediately as it arrives from someone else's server

The clarification is needed. With the existence of "The JavaScript Trap", people are under the (silly) impression that JS or programs written for the browser and executed by its JS engine are inherently bad.

Broken link. (And it's an antipattern, anyway.)

In "FactForge: A fast track to the Web of data", Bishop et al give this criterion as, "Use URIs as identifiers for things".

There may need to be a zeroeth step here, which is "don't make the mistake of designing systems in such a way that things can't be identified by name".

Weird statement. WebKit is an element in the set defined as "the 2 major browser engines".

Two things that still need to be addressed in section 7:

• the top module is special
• an uncluttered root directory is good practice

That's not right... should be "./src/LineChecker.src". (The fact that the compiler isn't throwing an error on this is a bug in and of itself...)

Spurious close paren here.

s/.*/Let's discuss an implementation strategy/

Someone should launch a "No regressive GitHub bullshit club".

This loop showcases a UI pattern that I think could be improved. There is an "edit" button visible, which opens the sidebar. The principles should more closely resemble the Hypothesis sidebar. Instead of requiring an explicit edit button which the user clicks, the editor should operate on object selections. Merely clicking any of the displayed values should select it, which should provide a handle to the underlying object, which should reveal the editor sidebar (with, ideally, the relevant field focused).

The current incarnation of the tutorial (https://raw.githubusercontent.com/akkartik/mu/7195a5e88e7657b380c0b410c8701792a5ebad72/tutorial/index.md) starts by describing "Prerequisites[:] You will need[...]", and then goes on to list several things, including various software packages—assuming a Linux system, etc.

This is the idea I'm trying to get across with the self-containedness I've been pursuing (if not with triple scripts then at least with LP docs).

That prerequisites list should be able to replace with two requirements, i.e.:

"You will need: (1) this document, and (2) the ability to read it (assuming you have an appropriate viewer [which in 2021 is nowhere close to the kind of ask of the old world])"

Another way of saying that the use of V8 means that JS isn't actually an "interpreted language" (not that that's even a real thing).

Fielding's MOMspider, one of the very first web tools, does this, albeit not at build time in a static site generator.

Just say no to backslash for path separators, even on Windows.

(I can't believe the Powershell people got this right originally and then chose to fuck it up.)

"burden"

Good example of why leveraging the browser's runtime is better. i wouldn't have guessed that the md2blog creator was using Windows. (And I didn't. I just assume that everyone is using a Mac, even though I'm on neither.)

See also Translating Type Hierarchies: Framework Analysis and a Proposal (Malone 1988) http://hdl.handle.net/1721.1/49308

First(?) published in JEP Vol. 1 Issue 1: https://doi.org/10.3998/3336451.0001.137

Any known previous occurrences to this phrase? It's used today in the Solid Project.

From the WebNet 96 Conference Proceedings (San Francisco, California, October 15-19, 1996). https://eric.ed.gov/?id=ED427649

This paper covers various shades of Semantic Web problems (not yet coined at the time) and several problems being dealt with by the Solid Project folks today.

See Market-like task scheduling in distributed computing environments (Malone, 1987).

Fuck this shit. Would you think it was a good idea to show your appreciation to someone by tipping them -$1?

It's stupidly easy to achieve the intended effect without fucking it up. If you want to send your thanks but there is no obvious way to do that, then congratualations you have found a bug. File a bug report about that instead of subjecting the recipient and everyone else in the project orbit to your public wankery.

Every item filed in a bugtracker should correspond to a defect.

Stop encouraging people to misuse project infrastructure.

The single best piece of advice in a column filled with bad advice.

This should go without saying. The fact that it doesn't is an indicator of a bigger issue that probably calls for a drastically different approach.

"... then consider not".

The problem with lots of these examples is that they read like a robot emulating what they think genuine sentiment sounds like. This example is no different.

Again: maybe modelling your approach off something that is broken is not the best thing to do.

If these techniques are supposed to work and this is the result, maybe consider the possibility that all the advice here is not the way to go about doing things.

Bad execution of mostly acceptable advice, in contrast to much of the earlier stuff, which constitutes bad advice.

Things that you say should be true.

Please, no (unless you're actually writing an email and introducing yourself).

Bugtrackers are not message boards.

On the contrary, this kind of PR speak is a good example of how to piss people off by sounding like you think they're too stupid to recognize this "trick".

"Open source" doesn't make this hard. How you're advocating that open source has to be done is what makes that hard. So stop doing that.

Gross.

You can.

Gross.

If the costs are high, then start charging people for it.

Please, no. This is a big reason why the relevant problems here exist in the first place.

It's almost like the way that GitHub is typically used is an example of how things shouldn't be done!