Also not to be confused with the notion from the area of information theory of Kolmogorov complexity. (At least not directly—but that isn't to say there is no relation there.)

Pretty nuts that Safari isn't open source. I thought for sure that Edge was going to be fully open source, both before and after the Blink conversion. Why even build closed source browsers in 2023?

I agree that this approach is bad. I hate that this exists. The differences between doctype-triggered standards and quirks mode was bad enough. This is so much worse—and impacts you even when you're in ostensible standards mode.

Huh? Why? Why even waste the time? Just go fix your code.

"... you keep using that word"

I don't think that has been shown here? The zip.js stuff breaking is one thing, but the poor error detection regarding off-screen canvas doesn't ipso facto look like part of a larger pattern.

Answer: because they care about Web compatibility. If they delay X because Y is not ready, then that's ΔT where their browser remains incompatible with the rest of the world, even though it doesn't have to be.

This is a huge reach.

Although it's debatable whether having mismatched support is a good idea for a vendor, arguing that it breaks the commitment to compatibility is off. Construct broke not because something was removed, but because something was added and your code did not handle that well.

Two things: * Why would it have mentioned anything? It wouldn't have. It hadn't shipped yet. * MDN is not prescriptive; it's written by volunteers

The second = sign is completely superfluous here. Only one is necessary.

Well, the biggest problem is that anything can ever lead to a blank screen because Construct isn't doing simple error detection.

If you are allowed by someone to owe them money, then what are you getting revenge for...?

the export blind spot effect, when tutorial creators do not anticipate steps where novice tutorial takers may have difficulty

I call this "developer tunnel vision".

In other words: spam

The purpose of SublimeText is not to be "relevant" or "compete" against VSCode in the social media influencer sense of relevance and competition. It is to be a text editor that makes the author money both directly and indirectly (i.e. by selling licenses and being the kind of text editor that the author themselves uses to make software).

This is such bizarre article and headline. It's almost clickbait.

This is folly.

Identifiers are public information.

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-806

Whether it was from a drugstore or not, that $40 in 1962 was like $400 today...

Premature generalization is the root of all evil?

Calling out the X/Y Problem.

Most people who think they need a database really just need a cache? See jwz on the Netscape mail client:

So, we have these ``summary files,'' one summary file for each folder, which provide the necessary info to generate that message list quickly.

Each summary file is a true cache, in that if it is deleted (accidentally or on purpose) it will be regenerated when it is needed again

https://www.jwz.org/doc/mailsum.html

Why would you pick Python for this?

That's not a position supported by the opinion itself. It claims (explicitly) that there are.

from https://web.archive.org/web/20061108162904/http://www.stifflog.com/2006/10/16/stiff-asks-great-programmers-answer/

... but instead replacing all the cognitive load that would have gone to that task instead to reasoning about AWS infrastructure...

... which, as it turns out, is exactly what Yegge said he thought was going to happen in his response to the question that Linus was answering.

from https://learn.microsoft.com/en-us/archive/msdn-magazine/2012/june/don-t-get-me-started-the-silent-majority-why-visual-basic-6-still-thrives

from https://news.ycombinator.com/item?id=22616667

from https://news.ycombinator.com/item?id=8439611

Consider also a change to the conventions of UGC, where service operators give control of the objects (URLs) "owned" by a given user over to them, the owner. You should be able to connect your account with a request servicer like Cloudflare. You upload a document specifying how a worker should handle the request to your servicer of choice, inform the website operator that you'd like to route your requests through the servicer, and you're good.

No they don't.

This conflates the runs-in-a-browser? property with the depends-on-mobile-code? property.

mm... not really

This is such a good title.

Just be honest about your scumminess, instead of trying to be cute.

What if someone exploited this for a conversion strategy—and it was planned that way all along?

Startup A receives VC investment. They spend it wooing creators to their platform, and those creators are able in turn to make a profit. The startup doesn't take a cut. The signs that they are going to crash and burn appear. Suddenly, 6 months before even the most pessimistic critics would have guessed, the startup announces that it is the end of their incredible journey. They warn everyone that in two weeks it will flip to read-only, and then 4 weeks after that it will go dark. Everything goes nuts. The creators were relying on the platform themselves to make money. No platform means no money. Suddenly a solution appears: Startup B. They offer more or less a drop-in replacement for Startup A's highest revenue-generating users. The only catch is that Startup B's plans cost money. Startup C also appears, along with Startup D, each catering to a different segment of stalwarts who haven't signed a deal with B. In fact, B then announces that they're investing in C and D, in order to promote a healthy ecosystem. Somehow A appears and says that they're investing in C and D, too. Meanwhile, A's sunset never happened—a month after the site went read-only, it's still in read-only mode. Then A announces low-cost paid plans, flips back to read-write, and opens for new signups, having successfully converted the most lucrative clients to the more expensive plans with B since they knew it was in their best interests to maintain continuity of revenue no matte the costs.

Yes.

Does that dislike extend to the reformatting of old publications e.g. when you pick a new template for your site? I'd guess not, but I'd argue that you should at least consider not doing that, either.

... unless...?

Better analogy: in real life you can't actually unpublish something. At best you can go around trying to snatch up copies and then burn them. More realistically, you can published a new edition with corrections to errata incorporated, but—notably—the "bad" version will always be *Blah Blah Blah, first ed." The existence of the second edition doesn't erase the first one from people's bookshelves.

It's on the Web and how poorly orgs' information architecture is carried out that foo.example.com/bar can be one thing one day and then another thing entirely the next day. If we used URLs like <https://mitpress.mit.edu/Zachary, G. Pascal. Endless Frontier: Vannevar Bush, Engineer of the American Century. 1st ed. MIT Press, 1999.> would this be as big of a problem? Would doing so nudge born-digital documents in the same direction?

Edit it, sure. But don't clutter the ability to unambiguously refer to the previous version (by the same name it was given initially) as a way to distinguish it from later versions.

In my experience the file-and-folder model is the reason behind so much URL breakage. People don't seem to realize that even if you have foo/bar/ and foo/baz/, then that doesn't mean that you need to have a view that involves bar/ and baz/ among other things contributing to the "clutter" perceived when gazing upon something called foo/ (and that foo/, in turn, cluttering up whatever it's "inside").

It's this perceived clutter and the compulsion to declutter that leads to people moving stuff around in the pursuit of a more legible model.

There's a lot wrong with Google Docs, but the fact that documents stick around is not one of them. Documents should stick around.

No.

Nah. The latest URI should be a (temporary) redirect to the canonical URI of whatever the latest version is.

"Don't change your URIs" and "don't stop maintaining your documents" is contradictory.

If Kartik has a published document at /about in 2022 and then when I visit /about in 2023 what it said before is no longer there and it says something else instead (because he has been "maintaining" "it"), then that's a URI change. These are two separate documents, and the older one used to be called /about but now the newer one is.

It's actually the expectation that /stormforce/closings.shtml should mutate, reflecting recency that is anathema to the project here...

The tone immediately makes me question the credibility/reliability of the information in this piece. (Perhaps, though, I made a mistake in not realizing not to expect too much from a site calling itself "allaboutlean.com"...)

Not unlike shopping carts and the modern grocery store (Piggly Wiggly), footnotes, and page numbers, this is something that had to be invented.

Notably, though, it is not a market product.

Bart asked me about what it is that I think causes NPM to be so bad, generally (or something like that), and I responded with the one-word answer "insecurity".

I think "striving for acceptance" is a better, more diplomatic way to put it.

Imagine if they answered "Google Docs, and then pick 'HTML' when you save it".

It's the sort of thing that seems obviously wrong on its face, but in practice is more expedient and not egregiously worse than the accepted alternative.

See https://web.archive.org/web/20050305223533/http://www.nesc.ac.uk/esi/events/Grand_Challenges/proposals/Memories.pdf.

(From https://web.archive.org/web/20050305223533/http://www.nesc.ac.uk/esi/events/Grand_Challenges/proposals/.)

Based on https://empslocal.ex.ac.uk/people/staff/pjbrown/public_html/annotation/jodi_dec.html, this paper is from 2003.

This is an unfinished form of the paper that's available (without broken inline images) here:

http://diglib.stanford.edu:8091/diglib/pub/reports/commentor.html

Try http://infolab.stanford.edu/pub/papers/extract.ps

Available at http://diglib.stanford.edu:8091/diglib/pub/reports/brio-chi95.html

Now at http://hci.stanford.edu/~winograd/papers/acm97.html

A draft(?) version with inline comments by Winograd: http://hci.stanford.edu/~winograd/papers/annotations.html

It's here: http://www.dlib.org/dlib/august95/stanford/08roscheisen.html

Available at http://diglib.stanford.edu:8091/diglib/pub/reports/commentor.html

Traveller:

Try https://dougengelbart.org/content/view/114/ instead.

Alternatively, try cajoling yourself to invert the "[kind of like] the present, but cruder" thinking and frame the present in terms of the past—with present systems being "Engelbart, implemented poorly".

wat

'k, but we should also be able to see (a) that it has been edited, (b) what was edited, (c) how to unambiguously refer to a particular revision. To not offer the ability to do so is to take advantage of something that is technically achievable given the architecture of the Web but violates the original intent (i.e. to give someone a copy that looks like this at one point and then when they or someone else asks for that thing at a later date to then lie and say that it really looks like that).

WTF? This has fuck-all to do with RSS.

Mmm... how? It's just linear, unless I'm missing something.

You don't need to do that.

Also: this problem is not specific to podcasting. It affects everything to do with RSS, generally.

read: links to

This makes it sound like a hack/workaround, but to want to do otherwise is to want to do something that is already on its face wrong. So there's no issue.

This shouldn't even be an argument. package-lock.json isn't free. It's like cutting all foods with Vitamin C out of your diet and then saying, "but you can just take vitamin supplements." The recommended solution utterly fails to account for the problem in the first place, and therefore fails to justify itself as a solution.

Uh... what? This is a total shifting of the goalposts.

Excellent summation.

Give this one another go and think it through more carefully.

Emphasis: last sentence

The common perception of the Web as a sui generis medium is also harmful. Conceptually, the most applicable relevant standard for Web content are just the classic standards of written works, generally. But because it's embodied in a computer people end up applying the standards of have in mind for e.g. apps.

You check out a book from the library. You read it and have a conversation about it. Your conversation partner later asks you to tell them the name of the book, so you do. Then they go to the library and try to check it out, but the book they find under that name has completely different content from what you read.

I abhor tardiness and agree that being early is good advice, but this is a fucking stupid saying.

Being on time is on time.

(I mean this generally—not specific to the setting of this article.)

"30 minutes", immediately followed by "45 minutes"... What?

If you don't want version control, then that's your choice, but admit it (ideally out loud for others to hear, but failing that then at least to yourself) that that's what you're about.

Funny (and ironic) that you should ask...

I myself have been asking lately, what problem does the now-standard "Run npm install after you clone the repo" approach solve? Can you state the NPM hypothesis?

See also: builds and burdens

I'm not going to make the same defenses that folks on HN prefer.

But the problem with Casey's worldview is that it provides no accommodations for the notion of zero-cost abstractions.

I didn't realize recursive descent was part of the standard grugbrain catechism, too, but it makes sense. Grugbrain gets it right again.

Not unrelated—I always liked Bob's justification for using Java:

I won't do anything revolutionary[...] I'll be coding in Java, the vulgar Latin of programming languages. I figure if you can write it in Java, you can write it in anything.

https://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-expression-parsing-made-easy/

This goes on to provide a bunch more info with the express purpose of making it possible to 1. Print out this page, and then 2. Recreate the whole thing by hand if you wanted to, using only the printed page as reference.

Could easily add a section that describes a bookmarklet that you could use to transform the "live" (in-browser) document into something formatted like the one at "This page is a truly naked, brutalist html quine" https://secretgeek.github.io/html_wysiwyg/html.html.

Note that if you add any highlights using Hypothes.is to any of the CSS code blocks here, it will break them.

If you're looking for Stavros's "no-bullshit image host", that's https://imgz.org/

NB: there may be a race condition here? In which case, running into errors should be (one) expected outcome.

ETOR probably stands for Estimated Time of Restoration

https://news.ycombinator.com/item?id=21244868

This is stated like unanimous agreement is a foregone conclusion.

The Web is for content. Just because people do build in-browser facsimiles of mobile-style app UIs doesn't mean that the flattening of content and controls into a single stream is something that everyone agrees is a good thing and what should be happening. They should be doing the opposite—curbing/reigning it in.

You mean your promise—the position of the Web Hypertext Application Technology Working Group.

Have you considered that the problem might have been you and what you were trying to do? You're already conceding failure at what you tried. Would it be so much worse to say that it was the wrong thing to have even been trying for?

You mean developers will gain.

Fuck developers.

Jesus fucking Christ. Fuck this shit.

This isn't new. Also: good—application developers shouldn't be the only ones holding the keys to the kingdom when it comes to making stuff available on the Web. Authors* and content editors should have those keys.

* in the classic sense; not the post-millennium dilution/corruption where "authors" is synonymous with the tautologically defined "developers" that are spoken of when this topic is at the fore

On HN, the user bitwize (without knowing he or she is doing so) summarizes (the first half, at least) of the situation described here:

The appeal of JavaScript when it was invented was its immediacy. No longer did you have to go through an edit-compile-debug loop, as with Java, or even an edit-upload-debug loop as with a Perl script, to see the changes you made to your web-based application. You could just mash reload on your browser and Bob's your uncle!

The JavaScript community, in all its wisdom, reinvented edit-compile-debug loops for its immediate, dynamic language and I'm still assmad about it. So assmad that I, too, forgo all that shit when working on personal projects.

https://news.ycombinator.com/item?id=34827569

Basically, ignore almost everything that Modern JS practitioners tell you that you need to be doing. You're halfway there with this experiment.

One of the most interesting and high-quality JS codebases that has ever existed is all the JS that powers/-ed Firefox, beginning from its conception through to the first release that was ever called "Firefox", the Firefox 3 milestone release, and beyond. To the extent that there was any build system involved (for all intents and purposes, there basically wasn't), the work it performed was very light. Basically a bunch of script elements, and later Components.utils.import calls for JSMs (NB: not to be confused with NodeJS's embarrassing .mjs debacle). No idea what things are like today, but in the event that there's a lot of heavy, NodeJS-style build work at play, it would be wrong to conclude that it has anything to do with necessity e.g. after finally reaching the limits of what no-build/low-build can give you (rather than just the general degradation of standards across Mozilla as a whole).

The best possible outcome for everyone likely includes a world where MS open sourced (at least as much as they could have of) Trident/EdgeHTML—even if the plan still involved abandoning it.

Ooh... this might benefit from improvement. I mentioned to Rochus the benefits of direct (no build step) runnability in the vein of Python or JS, and he responded that he has already done this for Oberon+ on the CLI/CLR.

For the same reasons that direct runnability is attractive, so too might be the ability to copy and paste to mix both syntaxes. (Note that this entirely a different matter from whether or not it is a good idea to commit files that mix upper and lower case; I'm talking about friction.) Then again, maybe not—how much legacy Oberon is being copied and pasted?

I agree, of course, with the criticism of the price point. As I often say, $9.99/month (or even $4.99/month) is more expensive than premium email—and no matter how cool you think your thing is, it's way less important than email. You should always return something for ~$20, especially if you already have a free tier. (When I say "for $20" here, I'm talking about a one time payment, or on a subscription basis that maxes out at $20/yr.)

The following musings are highly specific to the market for what's being sold here.

Paying $20 should get you something that you aren't bothered about again for the next year. Maybe to make it even easier, enable anyone to request a refund of their $20 for any reason within the first 7 days. This gives a similar feel to a free trial, but it curbs abuse and helps target serious buyers in the first place. In the event that 7 days is not enough time even for people to convince themselves that they need it, maybe keep open the ability to use a severely limited version of the service for the remainder of the year. E.g. you can continue to log in and simulate what you'd get with the full version, but it's only accessible to you because you can't publish them and/or share links with anyone who doesn't have access to your account.

Despite being a Rust apologist and the fact that this paper makes Rust look better than its competitors, Steve Klabnik says this paper is quite bad and that he wishes people would stop referencing it.

For Oberon+, try https://oberon-lang.github.io/

The W3C actually chartered a CSV working group for CSV on the Web. Their recommendation resolves ambiguities of the various CSV variants, and they even went on to supercharge the format in various well-defined, nice-to-have ways.

Huh? This sounds like it's saying the opposite of what was said two paragraphs earlier.

In order to make it way easier to keep track of things in bookmarklet workspaces, there needs to be an option that adds an incrementing counter (timestamp?) to the bookmarklet title, so when dragging and dropping into your bookmarks library, you don't lose track of what's going on with a sea of bookmarklets all named the same thing.

This has been giving me problems in the latest Firefox releases. It ends up throwing an error.

@34:00

In theory? RDF, it's awesome. I like it a lot. This is why I'm working on this. But in practice [...] the developer experience it's not great, and when people when they see Turtle and RDF and all these things, they don't like it, you know? My opinion is that it's because of lack of learning materials and the developer experience to get started.

Miguel de Icaza Jun 17, 2022 @migueldeicaza Replying to @migueldeicaza @markrendle and 2 others The foundation should fund, promote and advance a fully open source stack. And the foundation should remove every proprietary bit from the code in http://dotnet.org.

Microsoft can and should compete on the open marketplace on their own. [...] And we should start with the debugger: we should integrate the Samsung one, it should be the default for OmniSharp and this is now we get contributions and improvements- not by ceding terrain to someone that can change the rules to their advantage at will.

I tried (although perhaps not valiantly, but as an outsider) to convince Miguel and the then-Director of the .NET Foundation in 2015 that this state of affairs was probably coming and that he/they should reach out to the FSF/GNU to get RMS to lift the .NET fatwa, become a stakeholder/tastemaker in the .NET ecosystem, and encourage free software groupies to take charge so that FSF/GNU would be around as a failsafe for the community and would inevitably benefit greatly esp. from any of MS's future failure on this front. I tried the same in reverse, too. They seemed to expect me to be a liaison, and I couldn't get them to talk to each other directly, even though that's what needed to happen.

I find it odd that this is framed here as an example of an "unusual thinker". The solution seems natural, if underappreciated, for a domain where any tool's output target is one that was specifically crafted to intersect with what is ordinarily a (or in this case, the) "preferred form for modification".

You can (and we probably all more often should) do the same thing with e.g. HTML+CSS build pipelines that sit untouched for years and in that course become unfashionable and undesirable...

This is a good thing. https://bracha.org/pluggableTypesPosition.pdf

Refer to §6 #3.

If this were using professionally installed videoconferencing hardware, there would be no need for "eye contact correcting software" if done right. The use of such software would be an indicator of failure elsewhere.

"... assuming you rebase your site on top of Indiekit beforehand" (which is a big leap).

Now just get rid of the server part.

The real missing link between (conventional) static sites and the W3C's social protocols is still static. This post itself already acknowledges the reasons why1.

See also https://news.ycombinator.com/item?id=30862612

See also: What happened to simple, basic web hosting?

"... with current recommended practices", that is.

There really is no substantial increase in trust. You were already trusting their player to do the right thing.

Some thoughts:

• This is indeed good UX.

• What's not good UX—and which I discovered/realized this week—is that there seems to be no easy/straightforward way to map a podcasts.apple.com podcast page to either its feed URL or to the original publisher/podcast's Web site. In reality, this would be as trivial as embedding a <link>.

Additionally, there's a missed opportunity in the podcasting space to make judicious use of the Link header—every piece of media served as part of a podcast should include in the HTTP response a link back to the canonical feed URL and/or the original site! (And they should also have CORS enabled, while they're at it.) Why isn't this already a thing? Answer: because it's a trivial detail; podcasters could do this, but what's the point?, they'd say—almost no one is going to attach a network inspector to the requests and check to see whether they're sending these headers for only the sake of steadfast and adherence to hypermedia ideals. Worth noting that this is the exact opposite of Jobs's principle of carrying out good craftsmanship throughout e.g. a chest of drawers or when building a cabinet, even for the parts that no one will see, in order to "sleep well at night". Maybe this could be used to shame Apple?

Traveller:

You're looking for https://www.ribbonfarm.com/2008/11/18/the-organization-man-by-william-whyte-introduction/

And cyclists need to make sure they have wheels attached before riding a bicycle.

This is one of those things that superficially seems like a relevant retort, but as a reply it's actually total nonsense.

Or, if you wanted to put it more abrasively: Instagram photos are not podcasts, dumbass.

Good example of the "always return something (for $20)" principle.

Another casualty of the Copenhagen interpretation of ethics (or close enough, at least)?

https://hn.algolia.com/?query=copenhagen%20interpretation%20of%20ethics%20strikes%20again&type=comment

The author here makes it sound like they have to reach out and grab content stream chunks, stitch them together with their own hands, and then plonk them down on the assembly line for 14 hours a day or something.

It's a program. You write a program that does the building.

This is not a good approach. It's the opposite of what you want. Module resolution remains easy for computers (because of their speed), but tedious for humans.

As a writer, maybe there's some benefit for no correlation. As a reader trying to understand a foreign codebase, esp. one who is in the moment trying to figure out, "Where is this thing defined? Where can I read the source code?" when jumping through procedure definitions, not being able to trivially ascertain which file a given thing is in is unnecessary friction. Better to offload a tiny bit of work onto the author who knows the codebase (or at least their own immediate intention) well rather than to stymie the progress of dozens/hundreds of readers trying to work things out.

Worth noting that for many of Rochus's own projects (esp. ones related to Oberon/Oberon+), it's just a bunch of .cpp and .h files in one directory...

Imagine an arxiv-like depository that dealt with native hypertext, rather than TeX/PDF.

Food for thought: PWP as a prereq? What about RASH+SingleFileZ

The opposite of current Web app norms (contra desktop).

This is the one thing so far where the procedural syntactic mechanism isn't doing obvious heavy lifting.

... at some expense to ergonomics.

It's odd that they didn't introduce special syntax for this. They could have even used import to denote these things...

The class semantics for new in ES6 really bungled this in an awful way.

Is that mechanism or culture?

Not all names, I think. Local identifiers, for example...?

Larry makes a similar analogy (pass by value vs pass by reference) to my argument about why patches are actually better at the collaboration phase—pull requests are fragile links. Transmission of patch contents is robust; they're not references to external systems—a soft promise that you will service a request for the content when it comes. A patch is just the proposed change itself.

Is that really the ultimate, most worthy goal? It seems that "minimizing the level of skill required[...]" is used as a proxy here for what we're really after—minimizing the total cost of producing the thing we want. Neither the minimization of skilled use nor reuse should be held as a priori goals.

The irony* of this comment is that Google and Google engineers are famously some of the most well-known users/proponents of monorepos.

* not actual irony; just the faux irony—irony pyrite, or "fool's irony", if you like

He doesn't exactly say it here, but many others making the same observations will pair it with the suggestion that this is because of some intrinsic property of the digital medium. If you think about it, that isn't true. If you consider paper, people tend to be/feel more empowered to tweak it for their own use (so long as they own the copy); digital artifacts seem more hands-off, despite their potential, because the powers involved are reserved for wizards, largely thanks to the milieu that those who are the wizards have cultivated to benefit themselves and their livelihood first, rather than empowering the ordinary computer user.

It's clear that gklitt is referring to the ability of extensions to augment the browser, but: * it's not clear that he has applied the same thought process to the extension itself (which is also software, after all) * the conception of in-browser content as software tooling is likely a large reason why the perspective he endorses here is not more widespread—that content is fundamentally a copy of a particular work, in the parlance of US copyright law (which isn't terribly domain-appropriate here so much as its terminology is useful)

This has almost always been the case—at least as far back as 10+ years ago with addons.mozilla.org, too.

NB: there's no such thing as a "CSS class". They're just classes—which you may use to address things using CSS's selector language, since it was conveniently (and wisely) designed from the beginning to incorporate first-class* support for them.

* no pun intended

This is an unfortunate reality about the conventions followed by programmers building applications with Web-based interfaces: no one honors the tradition of the paper-based forms that their digital counterparts are supposed to mimic; they're all building TOSS-style APIs (and calling that REST) instead of actual, TURN-style REST interfaces.

• MementoWeb
• WebDAV

That was what pre-WebExtensions Firefox was. Mozilla Corp killed it.

See Yegge's remarks on The Pinocchio Problem:

The very best plug-in systems are powerful enough to build the entire application in its own plug-in system. This has been the core philosophy behind both Emacs and Eclipse. There's a minimal bootstrap layer, which as we will see functions as the system's hardware, and the rest of the system, to the greatest extent possible (as dictated by performance, usually), is written in the extension language.

Firefox has a plugin system. It's a real piece of crap, but it has one, and one thing you'll quickly discover if you build a plug-in system is that there will always be a few crazed programmers who learn to use it and push it to its limits. This may fool you into thinking you have a good plug-in system, but in reality it has to be both easy to use and possible to use without rebooting the system; Firefox breaks both of these cardinal rules, so it's in an unstable state: either it'll get fixed, or something better will come along and everyone will switch to that.

Something better didn't come along, but people switched anyway—because they more or less had to, since Mozilla abandoned what they were switching from.

Worth noting that c-smile, the creator of Sciter, put out an offer during COVID lockdowns to make Sciter open source if someone would fund it for $100k. That funding never came through.

You're looking for https://mek.fyi/math

You're looking for https://mek.fyi/essays/software/what-the-browser-is-missing

https://michaelkarpeles.com/math.html

https://michaelkarpeles.com/essays/philosophy/what-the-browser-is-missing.html

My central goal is a universal knowledge repository freed of discrete "document" boundaries