2
points
dfabulich
Joined 9,825 karma
I'm Dan. I co-founded https://www.choiceofgames.com/
Choice of Games is the world’s largest publishing house for interactive novels. Our award-winning games are entirely text-based—hundreds of thousands of words and hundreds of choices, without graphics or sound effects—and fueled by the vast, unstoppable power of your imagination. Choose your path: your choices control the story.
dan@fabulich.com @dfabu
- > Many seem to think there is a path to Wasm replacing JavaScript within the browser—that they might not need to include a .js file at all. This is very unlikely.
This article didn't even seriously entertain replacing JavaScript as an idea, saying nothing about why it's "very unlikely." But it's the #1 thing most devs are excited about in WASM: maybe they could ditch JS and use another language instead for browser UI, at least Rust, but maybe Go or even Python.
The reason that's unlikely is that browser UI is defined in standards as a JavaScript API; restandardizing an ABI for low-level languages would take years (perhaps decades). https://danfabulich.medium.com/webassembly-wont-get-direct-d...
- Not really. At a buffet restaurant, if you could take the food out with you, you'd takeaway more food than you can eat at one sitting. OpenCode users and Claud Code™ CLI users use tokens at approximately the same rate.
This is more like an all-you-can-eat restaurant requiring you to eat with their flimsy plastic forks, forbidding you to bring your own utensils.
- For folks not following the drama: Anthropic's $200/month subscription for Claude Code is much cheaper than Anthropic's pay-as-you-go API. In a month of Claude Code, it's easy to use so many LLM tokens that it would have cost you more than $1,000 if you'd paid via the API.
Why is Anthropic offering such favorable pricing to subscribers? I dunno. But they really want you to use the Claude Code™ CLI with that subscription, not the open-source OpenCode CLI. They want OpenCode users to pay API prices, which could be 5x or more.
So, of course, OpenCode has implemented a workaround, so that folks paying "only" $200/month can use their preferred OpenCode CLI at Anthropic's all-you-can-eat token buffet.
https://github.com/anomalyco/opencode/issues/7410#issuecomme...
Everything about this is ridiculous, and it's all Anthropic's fault. Anthropic shouldn't have an all-you-can-eat plan for $200 when their pay-as-you-go plan would cost more than $1,000+ for comparable usage. Their subscription plans should just sell you API credits at, like, 20% off.
More importantly, Anthropic should have open sourced their Claude Code CLI a year ago. (They can and should just open source it now.)
- This looks really cool, but I'm not going to use it today, because it only supports SQLite, with Postgres and SQL Server "coming soon." This seems like a very odd starting point, especially for a paid tool. I don't have any SQLite databases I'd want to explore, and certainly none with "massive tables." I'd want to use it for Postgres and MySQL/MariaDB first.
Also, if autocomplete is what we care about, PRQL support seems like it will offer the best experience. https://prql-lang.org/ PRQL queries transpile to SQL. Just having the `FROM` clause first does wonders for autocomplete.
- Mozilla's problem is unsolvable.
Firefox gets 90% of its funding from Google, putting Google effectively in control of Mozilla.
Ideally, Firefox would be financially supported by its users, like Wikipedia. But that requires ads nagging users to donate, preferably on a subscription plan.
Most of Firefox's users block ads, and they refuse to pay Mozilla a dime under any circumstances. Their users are freeloaders, providing no value to Firefox's other users or to Mozilla.
It would be nice if Mozilla could ignore the freeloaders and simply nag for donations anyway, but if the freeloaders leave and Mozilla tries to serve its donor users, they'll lose all of their Google funding and die.
- No, passkeys haven't added a new general lockout issue, because Apple, Google, etc. don't allow you to create an account where you can only login via passkey with no external authentication factor. They require you have something outside the Google account, whether that's a password, a hardware key, etc.
People keep falsely imagining that Google is setting people up with passkey-only accounts, with no way to backup their login credentials. Gosh, wouldn't that be terrible?
That would be like 1Password letting you create a passkey-only account with no password, storing the only passkey in 1Password. The whole idea makes no sense. 1Password doesn't do that, and neither does Apple, Google, Microsoft, etc. (We can all imagine them doing something that stupid, but, it turns out, they don't.)
Pre-passkeys, the most common lost-credential scenario was creating a fresh Gmail address on a new device (an Android phone) with a password and forgetting both your Google password and your password for your cellular-phone carrier (AT&T, T-Mobile, etc). Your Google password would be stored locally on your phone and in Google's cloud, but when you lose your phone and forget your passwords, no backups remain.
At that point, you're pretty much screwed. Google can't email you a reset-password link, because Gmail is your email. Google can't send you a 2FA SMS until you get a new phone with the same number, but you can't convince AT&T to do that, because they want to send a reset-password link to your email, which you don't have, or SMS to your phone, which you don't have.
(The cellular carriers don't even allow you to show government ID at a physical store. They don't allow you to take over a phone number that way, because people could then threaten/bribe a T-Mobile store representative to falsely claim that you presented valid government ID, taking over other people's accounts. If you walk into a store, they'll just put you on the phone with customer service, where they'll insist that you provide your AT&T password, or reset your password via email or SMS. If you've lost your email and your phone and all your passwords, you're completely out of luck.)
If Google allowed you to create a passkey-only account, with no SMS 2FA and no way to backup your passkey, that would be even worse.
But, luckily for all of us, they don't even allow that, and they're certainly not pushing it unilaterally on billions of people.
- The author still has one last misconception about passkeys, namely that if you lose a passkey, you have "no recourse."
People wrongly think passkeys are like Bitcoin wallets, where losing them means there's absolutely nothing you can do, your account is simply lost forever.
Losing a passkey is exactly like losing your password, which is to say, that for 99% of services, you can reset your password/passkey really easily. There's a prominent "Reset Password" button right on the login form. It sends you an email or an SMS, you click it, and it lets you reset right then and there. You can reset your passkey in exactly the same way.
It is not that easy to reset if you lose your password to your Apple, Google, Facebook, etc. They all have a bunch of factors that they use to authenticate you if you reset your password, and they don't even document which ones they use.
So, if you care about those accounts, you've got to make sure you have backup access. They all let you generate and print "backup codes" (emergency passwords) and store them in a fireproof safe or a literal bank vault. Do that!
As everybody knows, you can't store all of your passwords in a password manager. You need something outside of the password manager to login to the manager itself. That's why 1Password/LastPass is called that; you still need one last password that you keep and manage yourself.
That's true of passkeys, too. You can login to Google with passkey, but if Google is your password manager that stores your passkey, you need something else outside of Google's password manager to login to Google. Whether it's a password, a backup code, a YubiKey, whatever, you need one more thing to login to Google, ideally more than one, so you can back it up and keep it safe.
- Apple's native SwiftUI framework and Google's Jetpack Compose framework stumbled upon basically the same layout system, "Constraints down, sizes up":
1. Proposal: The parent component proposes a size/constraints to the child
2. Measurement: The child component picks its own size based on those constraints
3. Placement: The parent component then positions the child in its coordinate space
It's all done in a single pass. It scales great. It fits great with React-like reactive UI frameworks. (SwiftUI and Jetpack Compose are based on React.)
This is what CSS needs.
- > With JSON, you often send ambiguous or non-guaranteed data. You may encounter a missing field, an incorrect type, a typo in a key, or simply an undocumented structure. With Protobuf, that’s impossible. Everything starts with a .proto file that defines the structure of messages precisely.
This deeply misunderstands the philosophy of Protobuf. proto3 doesn't even support required fields. https://protobuf.dev/best-practices/dos-donts/
> Never add a required field, instead add `// required` to document the API contract. Required fields are considered harmful by so many they were removed from proto3 completely.
Protobuf clients need to be written defensively, just like JSON API clients.
- > Lack of support for .appx and .msix bundles on Windows
https://github.com/tauri-apps/tauri/issues/4818
Whoa, I had no idea about that. Tauri is way less fully baked than I realized.
The bug goes on to explain that Tauri apps can't have Windows "package identity", which means that there's a bunch of Windows APIs you simply can't use in Tauri, including the notifications API.
Without package identity, IMO, Tauri isn't ready for primetime on Windows.
- "Yet you don’t need SEEDS analysis to know that the British economy itself is at an advanced stage of disintegration."
"Put another way, very little of the world’s supposedly enormous wealth actually exists in any meaningful sense."
Citation overwhelmingly needed. His claim that the economy is disintegrating is supported by the argument that: "you know, just look around." But what we're looking around and seeing is wealth accumulating at the very top.
The mistake he's making is thinking that if most people aren't doing well, then nobody is doing well, that the 1% aren't even really rich because their wealth is all a fiction.
In fact, wealthy people are really, actually wealthy. They are unimaginably wealthy. It is literally beyond the author's imagination how wealthy they are, leading him to the truly absurd conclusion that they're not really even wealthy at all.
"Nobody could be that wealthy, could they?!" Yes, my dude. Yes, they actually can be that wealthy. Indeed, they actually are.
- That's entirely right. Products have to transition from fast-moving exploratory products to boring infrastructure. We have different goals and expectations for an ecommerce web app vs. a database, or a database vs. the software controlling an insulin pump.
Having said that, at this point, Cloudflare's core DDOS-protection proxy should now be built more like an insulin pump than like a web app. This thing needs to never go down worldwide, much more than it needs to ship a new feature fast.
- It works great in Chrome, Safari, and Firefox.
https://github.com/dfabulich/style-xml-feeds-without-xslt
Google has recommended a polyfill for XSLT ever since they announced their plan to remove it. https://developer.chrome.com/docs/web-platform/deprecating-x...
- It would have been murderous with just CSS, but it would have been trivial to do with JS, much easier than the hundreds of lines of XSL you wrote. https://wyrm.org/inventory/skylanders.xsl
- 2 points
- For RSS/Atom, you put this in the XML, right inside the document element (the <feed> element or the <rss> element):
You can also put CSS in there, like this:<script src="https://example.org/script.js" xmlns="http://www.w3.org/1999/xhtml"></script>
Or like this:<style xmlns="http://www.w3.org/1999/xhtml"> * { color: red; } </style><link href="https://example.org/style.css" rel="stylesheet" xmlns="http://www.w3.org/1999/xhtml"/> - XSL is a Turing-complete functional programming language, not a declarative language. When you xsl:apply-template, you're calling a function.
Functional programming languages can often feel declarative. When XSL is doing trivial, functional transformations, when you keep your hands off of xsl:for-each, XSL feels declarative, and doesn't feel that bad.
The problem is: no clean API is perfectly shaped for UI, so you always wind up having to do arbitrary, non-trivial transformations with tricky uses of for-each to make the output HTML satisfy user requirements.
XSL's "escape hatch" is to allow arbitrary Turing-complete transformations, with <xsl:variable>, <xsl:for-each>, and <xsl:if>. This makes easy transformations easy and hard transformations possible.
XSL's escape hatch is always needed, but it's absolutely terrible, especially compared to JS, especially compared to modern frameworks. This is why JS remained popular, but XSL dwindled.
> It gives a low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements.
JavaScript is a much better low-effort high-power on-ramp to templated web pages with no build steps or server software. JavaScript is the natural fit for adding custom HTML elements (web components).
Seriously, XSLT is worse than JavaScript in every way, even at the stuff that XSLT is best at. Performance/bloat? Worse. Security? MUCH worse. Learnability / language design? Unimaginably worse.
EDIT: You edited your post, but the Custom Element API is for interactive client-side components. If you just want to transform some HTML on the page into other HTML as the page loads, you can use querySelectorAll, the jQuery way.
- In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser"
Actually, you can make an RSS feed user-browsable by using JavaScript instead. You can even run XSLT in JavaScript, which is what Google's polyfill does.
I've written thousands of lines of XSLT. JavaScript is better than XSLT in every way, which is why JavaScript has thrived and XSLT has dwindled.
This is why XSLT has got to go: https://www.offensivecon.org/speakers/2025/ivan-fratric.html
- I think we might be on the same page at last.
The last refuge of the Cartesian is always, "My argument is correct in an ineffable way that I couldn't possibly write down."
"Cogito ergo sum" presents itself as a self-evident deduction, the one guaranteed universally agreeable truth, but, when you investigate it a little… oh, well, it's really more of a vibe than an argument, and isn't "logical argument" really a monkey-mind distraction from the indescribable lightness of existence?
Mu, indeed.
- I note that you keep saying "cogito" without the "ergo."
"I think therefore I am" is invalid, and what's wrong with it is the "therefore," the idea that you knew one thing, and you drew a "logical" conclusion from it, in a "prior to language" environment where words have no meaning, where "true" and "false" are indistinguishable, and logic is impossible.
Logic requires words. "Logical" means "verbal," from the Greek logos (λόγος). You can't have a logical argument (you can't draw a conclusion) from the instantaneous standpoint of someone "experiencing" cogito, where words mean whatever you want, or nothing at all.
The experience you're having is not a logical argument. As a sentence, "cogito ergo sum" is invalidated as soon as you write it down in a shared language.
I'm sure it feels right to you! But you can't actually say anything true about it in English, or Latin, or any other shared language.
Thereof, you simply must remain silent.
- That's not what I'm arguing. The argument is that "cogito ergo sum" is invalid, which is part of an argument against the existence of a "mind" above and beyond what the brain does in a living body. The atoms are all there is.
I don't think I have a "mind" above and beyond my body, and I don't think you do, either. Animals can remember stuff, solve puzzles, and express pain, just like you or I do. We do all that with our brains, not with our "minds."
- The canonical 20th-century response to "cogito ergo sum" is Wittgenstein's "private-language argument." https://plato.stanford.edu/entries/private-language/
When you thought to yourself, "I think therefore I am," in what language did you think it? In English? The English language is an artifact of a community of English speakers. You can't have a language with grammatical rules without a community of speakers to make that language.
Almost nobody in the English-speaking community has direct access to the internals of your mind. The community learns things through consensus, e.g. via the scientific method. We know things in English via a community of English-speaking scientists, journalists, historians, etc. etc. Wittgenstein calls these the "structures of life," the ordinary day-to-day work we do to figure out what's true and false, likely and unlikely.
As you're probably aware, the scientific method has long struggled to find a "mind" in the brain doing the thinking; all we can find are just atoms, molecules, neurons, doing things, having behaviors. We can't find "thoughts" in the atoms. As far as our ordinary day-to-day scientific method is concerned, we can't find a "mind."
But "cogito ergo sum" isn't part of the scientific method. We don't believe "cogito ergo sum" because reproducible experiments have shown it to be true. "Cogito ergo sum" proposes a way of knowing disconnected from the messy structures of life we use in English.
So, perhaps you'd say, "oh, good point, I suppose I didn't think 'cogito ergo sum' in English or Latin or whatever, I thought it in a private language known only to me. From this vantage point, I only have direct knowledge of my own existence and my own perceptions in the present moment (since the past is uncertain), but at least I can have 100% certainty of my own existence in that language."
The problem is, you really can't have a private language, not a language with words (terms) and grammatical rules and logical inferences.
Suppose you assigned a term S to a particular sensation you're having right now. What are the rules of S? What is S and what is not S? Are there any rules for how to use S? How would you know? How would you enforce those rules over time? In a private language, there's no difference between using the term S "correctly" or "incorrectly." There are no rules in a private language; there can't be. Even mathematical proofs are impossible when every term in the proof means anything you want.
Descartes didn't originally write "cogito ergo sum" in Latin. He originally published it in French, "je pense, donc je suis." But in Europe, where Descartes was writing, Latin was the universal language, the one known to all sorts of people across the continent. For Descartes, Latin was the language of empire, the language every civilized person knew because their ancestors were forced to learn it at the point of a sword, the language of absolutes.
Wittgenstein has a famous line, "Whereof one cannot speak, thereof one must be silent." So must we be silent about "cogito ergo sum." "cogito ergo sum" isn't valid in Latin; "je pense, donc je suis" isn't valid in French. It could only be valid in an unspeakable private language, a language with no grammatical rules, no logic, where true and false are indistinguishable. "Cogito ergo sum" could only be valid in an unusable language where everything is meaningless.
Thereof, we must remain silent.
- They're discontinuing the Facebook Like button on third-party sites. That's pretty wild! The Like button used to be Facebook's major initiative back in 2010. https://en.wikipedia.org/wiki/Facebook_like_button
Media sites in particular used to try to drive people to click the Like button, causing their articles to appear prominently on Facebook. And since it was an <iframe> running on every site, Facebook would automatically know what articles you viewed, data that they could use to target ads to you.
How/why did that die out, I wonder?
- 17 points
- 4 points
Orion will never reach "self-sufficiency" as long as you don't actually charge for Orion. Orion is completely free to use. I can donate to Orion+, but Orion+ offers no paid features; it's basically a Patreon. https://help.kagi.com/orion/orion-plus/orion-plus.html
(No major browser has ever sustained its own development independent of a search engine's funding, not even Netscape, which charged $40/seat in the 1990s, with a free "shareware" tier so generous that hardly anyone paid. Netscape was funded by advertising, especially from Yahoo search. Funding browser development entirely on donations to a commercial business would be completely unprecedented.)
What if, instead, you made Orion "source available" to paying customers, but not open source? You could merge PRs only from users who sign a CLA. (Users would file PRs out of charity, for the same reason they sign up for Orion+ today.)