dfabulich

10,182 karmajoined il y a 16 ans

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.

[email protected] @dfabu

Submissions

You can export/import passkeys now, but only on iOS

danfabulich.medium.com

3 pointsby dfabulichil y a 13 jours0 comments

WebKit Features for Safari 26.4

2 pointsby dfabulichil y a 4 mois0 comments

Chrome will make popular scripts load faster (by picking winners)

danfabulich.medium.com

7 pointsby dfabulichil y a 5 mois0 comments

Beautify Your RSS/Atom Feeds in Browsers Without XSLT

danfabulich.medium.com

2 pointsby dfabulichil y a 8 mois0 comments

Show HN: Style XML Feeds Without XSLT

2 pointsby dfabulichil y a 8 mois0 comments

Platform Evolution: Facebook Social Plugins to Be Discontinued February 2026

developers.facebook.com

17 pointsby dfabulichil y a 8 mois5 comments

Google Play's new "discount offers" charges higher prices in older app versions

danfabulich.medium.com

4 pointsby dfabulichil y a 8 mois0 comments

State of JavaScript 2025 Survey

survey.devographics.com

1 pointsby dfabulichil y a 10 mois0 comments

comments

avant-hierdiscuss

This blog post further undermines my trust in Jarred.

He makes it sound like Claude did a fantastic Rust rewrite, and "the work continues."

But when the Rust port merged to main, the state of the code was very, very bad. There were 13,000 instances of `unsafe`, no Miri tests at all, and, sure enough, it exposed UB in safe Rust. https://github.com/oven-sh/bun/issues/30719

Observers could see this coming from a mile away, objected strongly to using AI to RIIR before the code merged. Rather than incorporate feedback and get the code ready for production, Jarred gaslit us all, right here on HN. https://news.ycombinator.com/item?id=48019226

Just 9 days before he merged the Rust rewrite to the main branch, Jarred wrote:

> This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.

It's plausible that Bun's Rust rewrite is now in much better shape than it was in May. But a blog post like this would have been a place to apologize, to accept that it was a very bumpy rollout, to acknowledge that public messaging was extremely poor, and to earn back our trust.

As it stands, I guess I'll have to run my own tests to try to evaluate whether Bun 1.4 is ready for prime time, because I just can't trust Jarred to give us a straight answer.

il y a 4 joursdiscuss

The inherent property of software is that the only way to be sure your software works on a particular platform is to test on that platform.

There is not a baseline target subset of HTML/CSS that reaches 100% coverage that can be statically verified. HTML tables usually work in old browsers, but there were subtle bugs in old versions of Internet Explorer, bugs that you're especially likely to hit if you're using tables for layout (because you can't use modern CSS layout features). The only way to be sure that you didn't trigger one of those subtle bugs is to test your web app on ancient browsers.

The cost of reaching the last 0.N% of users rises with each platform you add to your test matrix. It costs money to test your web app on Internet Explorer. It costs even more money to fix bugs that only affect Internet Explorer.

I think you can't deny that doing that work is expensive. The question then has to be whether that work will repay itself somehow. But the last 0.N% of users will only provide ~0.N% increases to your revenue. Unless your revenue is astronomical, you can't afford even one full-time engineer to test and fix bugs on 0.N% of browsers.

il y a 11 joursdiscuss

Read carefully. There's a big difference between developing a database and developing an app that uses a database.

If you're developing a database, you should use property-based tests to ensure that your database behaves as expected (ACID reliability, etc.). If you can formally verify parts of your database, you won't have to fuzz it, because it will have been proven correct. But if you're developing a CRUD app that uses a database, there may be no properties of your app at all that are worth fuzzing.

Similarly, if you write a library that parses Markdown, you should write property-based tests of it, and fuzz it. If you use a library that parses Markdown, you should pass it your Markdown, and let the library handle it.

E-commerce apps typically don't need to do any non-trivial parsing. Effect-free logic is likely to be ~1% of your code base, or less.

This is why we keep talking past each other: the techniques that make sense for real-time operating systems don't make sense for an e-commerce app, a line-of-business admin dashboard, or a single-player game.

il y a 11 joursdiscuss

Don't forget RFC 5321! But the RFCs are ignored in practice by all popular mail servers. There are email addresses that work in practice that don't comply with the RFCs, and there are email addresses that the RFCs permit that don't work in practice.

(This happens with a lot of standards; sometimes people just ignore them and do their own thing. Something similar has happened with SVGs.)

If you write a formal verification of a syntactical email validator that ensures that all/only RFC-compliant email addresses are valid, you'll have completely wasted your time. Don't do it. Just check for at least one @ sign, and email the address to test it.

(This is a perfect example of the trap of formal verification.)

il y a 11 joursdiscuss

> "No crashes/panics/uncaught exceptions" should be worth it.

Surprisingly, no. Property-based testing and formal validation make it easy to spend tons of time and money "preventing" bugs that would never have occurred in production, especially uncaught exceptions.

There is code where strong guarantees can be worth it, (databases, platforms/operating systems, parsers accepting hostile input) but it's not most application-level code, and certainly not most e-commerce CRUD apps.

Remember, we're here to make users' lives better, not to write correct code for its own sake.

il y a 11 joursdiscuss

The rules of email validation are not remotely well defined! Syntactic email validation is an impossibly hard problem. https://www.netmeister.org/blog/email.html

IMO the industry consensus is never to "validate" email addresses syntactically, but simply to ensure that the email address contains at least one @ and to verify the email address by emailing it an activation code.

Proofs would not have uncovered these failures. The proofs would have proved that they rejected your email address as invalid, and the developers would have patted themselves on the back for a job well done.

il y a 11 joursdiscuss

Formal verification is a siren song. The siren sings, "bug-free code is possible in principle!" But it's a trap. Even with LLMs, bug-free code is impractical.

I argued that property-based testing is mostly unhelpful for e-commerce/CRUD apps, and that formal verification is a performance improvement on property-based tests.

In a property-based test, you identify some rule (an invariant) that you want to apply to your code. Then, you fuzz your app, testing it with autogenerated inputs, failing the test if the rule is broken at any point. In formal verification, you prove that the code always satisfies the rule, so you don't have to try millions of inputs.

Whether you're doing property-based testing or formal verification, it's extremely difficult to think of any non-trivial business logic properties that should apply to CRUD apps, even if they could be written in English, translated perfectly into code, and verified formally, instantly.

An actual rule that should always be followed, inflexibly, such that a mathematical proof would be useful (and that actually matters to your business) is so rare in CRUD apps that I'm not sure I've ever seen one.

Even with general-purpose rules (the app should never crash, the app should not leak memory), the property-based fuzzers tend to find bugs that have never happened in production, and probably never will. It's rarely economical for an e-commerce app developer to spend time fixing those bugs, even if finding them cost nothing at all (which is not remotely true, even with LLMs).

And what about UI? Maybe you'd want a rule like: "The title of the product for sale should never overflow its container rectangle in the UI."

OK, well, what if the title is one very long word? But… none of the products you sell happen to contain any words that are 500 characters with no spaces. I guess you could add code to prevent that product from ever being created? (And ensure that data in the database will never allow product titles that violate your business rules… how, exactly?)

Formal verification shines where property-based testing is already useful. It's already useful for many software platforms. It's useful for databases, where reliability is essential. It's useful for parsers, particularly when you expect the end user to be attempting to send you hostile code.

But e-commerce apps? CRUD apps? Not so much.

il y a 11 joursdiscuss

Formal verification is still too limited to be useful for most app developers. The article gives an example of an e-commerce platform using it to prove the correctness of managing refunds, but then acknowledges:

> As of today, the formally verified core can handle most effect-free logic—invariants, transitions, conflict resolution. But the UI, network calls, and database interactions typically sit outside the verification boundary. Verification makes the core airtight but doesn’t guarantee end-to-end correctness.

So you can formally prove that your e-commerce refund management logic is correct, except for proving that you processed the refund. You can't even prove anything about recording the refund in your database, say nothing of proving anything about your interactions with your payment processor.

If your app is mostly tricky logic with just a bit of I/O, your app is very unusual, and it's almost certainly not an e-commerce app. E-commerce apps are mostly CRUD apps; I/O with the database, the UI, and third-party APIs (e.g. payment processors) is 99% of the code.

Even property-based testing is mostly unhelpful for e-commerce apps like these.

Instead, think of formal verification as a runtime performance improvement of property-based testing. If property-based testing is useful for your app (it probably isn't), then you may be able to convert some of your property-based tests into formal verifications.

But, honestly, you probably can't do it, not even with a high budget of tokens.

I'd love to be proven wrong, but the way to do it would be to formally prove the correctness of non-trivial open-source code with property tests. Perhaps you could formally verify significant chunks of Postgres! (But I doubt it.)

il y a 18 joursdiscuss

The platform webviews are significantly older/worse than typical web browser versions, especially on macOS and Linux.

On macOS, the only way to upgrade your WebView is to upgrade your OS, which requires rebooting. Lots of people just don't bother. You can upgrade to the latest Chrome or Firefox just by downloading it (assuming they support your macOS version), and they auto-upgrade themselves pretty aggressively.

On the web, very old versions of Safari (6+ years old) are a tiny fraction of a percent of your traffic; many web developers just ignore them. In a desktop app based on a WebView, ancient WebViews can be as high as 10-15% of your macOS user base. Ignoring them is not an option.

On Linux, it's common for the major version of WebKitGTK to not upgrade at all except during major OS upgrades. Anyone on Ubuntu LTS 20 is going to have a 2020-vintage WebKitGTK with security patches. (And Ubuntu LTS 20's WebKitGTK was buggier than macOS WebKit, even in 2020, because Apple has more dedicated full-time developers and testers making sure that macOS WebViews work end-to-end.) If you're shipping an app based on WebKitGTK, you can expect to see double-digit percentages of your Linux users running really old WebKitGTK.

Maybe you're such a great developer that your web app works great on ancient browsers, but, if so, it's probably because you didn't need/use much JS in the first place. (Maybe you used HTMX or something.) In that case, is there even any benefit in shipping a "desktop app"? What's your desktop app even for? Offline support? (But your app is all server side…?)

If you have a JS-intensive app that works great on ancient, buggy browsers, then platform WebView might work for you. It's not nobody, but it's hardly anybody.

il y a 24 joursdiscuss

Others in this thread disagree with you! But, if they're good enough for Safari, then you'll find they're exactly as good in Chrome.

https://chromewebstore.google.com/detail/adguard-adblocker/b...

https://chromewebstore.google.com/detail/consent-o-matic/mdj...

il y a 25 joursdiscuss

Safari has never supported MV2 uBlock Origin. Chrome with uBlock Lite is exactly the same as Safari with uBlock Lite.

il y a 30 joursdiscuss

One couldn't, because you'd need to standardize a JS-less DOM, which requires one to persuade Apple, Google, Microsoft, and Mozilla to agree on a new standard for a JS-less DOM API.

The DOM API is currently defined as a JS API, including JS strings, JS objects + properties, JS Exceptions, JS Promises, JS garbage collection, and on and on and on.

The effort to get all the browsers to agree to standardize a new JS-less DOM API would take years; none of the browser vendors even want to begin that conversation today.

le mois dernierdiscuss

It's the last line of the abstract.

> As a consequence of this succinctness, we show that basic verification problems for transformers, such as emptiness and equivalence, are provably intractable: specifically, EXPSPACE-complete.

le mois dernierdiscuss

The last line of the abstract has the most important takeaway.

> As a consequence of this succinctness, we show that basic verification problems for transformers, such as emptiness and equivalence, are provably intractable: specifically, EXPSPACE-complete.

If you were hoping to formally prove the correctness of a large transformer, it turns out that you're going to need an exponentially larger amount of space to do your verification, more than you could possibly afford.

il y a 2 moisdiscuss

Declarative partial updating "sets the stage for client-side includes." https://github.com/WICG/declarative-partial-updates

The linked article suggests a potential syntax:

  <template for="footer" patchsrc="/partials/footer.html">

That would transclude the content of /partials/footer.html in your HTML.

But the road ahead for this is still quite bumpy. Here's a good video from a year ago, talking through the obstacles. https://www.youtube.com/watch?v=t0NBcve0enY

il y a 2 moisdiscuss

  <p>
    <em>Some replaced text
  </p>

Which, by the HTML standard, will automatically close the `</em>` as the `</p>` closes.

il y a 2 moisdiscuss

When you have questions like this, the best places to check are the "standards positions" Github repositories for Mozilla and WebKit.

https://github.com/mozilla/standards-positions/issues/1369

Mozilla hasn't officially weighed in, but one decision maker (hsivonen) did vote in favor of it.

Apple WebKit is officially in favor of it, as of just a few days ago.

https://github.com/WebKit/standards-positions/issues/628

il y a 2 moisdiscuss

The WICG explainers do a somewhat better job than this article.

https://github.com/WICG/declarative-partial-updates

https://github.com/WICG/declarative-partial-updates/blob/mai...

il y a 2 moisdiscuss

The new element syntax is needed to signify DOM ranges that may cross the boundaries of HTML element trees.

  <p>
    <em>Some <?start name="hl"?>text</em>
    to replace<?end name="hl"?>.
  </p>

Jake Archibald at Mozilla has a good video about this. https://www.youtube.com/shorts/yARSOcqOWvY

il y a 2 moisdiscuss

I made a very small and highly defensible claim.

You argued that this article (by David Oks) is an example of "how Westerners idealize Japan." I argued that this article does not idealize Japan, and that, if you interpreted Oks' article that way, then you didn't understand the article.

I didn't say that Japanese business culture is more "horizontal" than Western business culture, or that Japanese business culture is better in any particular way. I didn't even say that the article is right or wrong about anything.

All I did was to restate the thesis statement of the article, to clarify what the article actually says.

I don't harbor any particular affinity for Japan, or Japanese business culture. I know very little about it. I'm not an authority to speak on it, and I didn't.

You assumed what I believe without understanding what I wrote. You did exactly the same thing to me that you did to David Oks.