Justine vs Bellard, that's a nice setup.

Note that it's really dom centric and doesn't include ajax.

Isn’t AJAX fairly well supported via fetch now?

In the same way selectors and map replace jquery. It depends how much sugar you want.

Yeah at this point I’ve totally forgotten $.ajax API but fetch is pretty easy, just a single function call

Now we only need something that makes websockets more resilient against network errors and corporate firewalls.

... unless you want to send a body with your HTTP GET. There is tons of utility value in this! For example, let's say you want to GET some data but also provide some client request statistics along with the request -- happens all the time in the real world.

Fetch will reject your GET if it contains a body (a deliberate maintainer decision), even though it's entirely permissible by HTTP and done by many real-world AJAX APIs. Real AJAX will do what it's supposed to. (The HTTP 1.1 2014 Spec says that including a request body in a GET "might cause some implementations to reject the request." Guess which one!)

Also, advanced features like progress are completely absent from Fetch as well.

However, there are some fantastic libraries like Axios[1], SuperAgent (requires npm), and, yes, jQuery[2], that have really excellent API's (far superior to Fetch), or you could just write your own (or use an LLM) short wrapper around modern AJAX and call it a day. h/t to Claude:

    const xhr = ['GET','POST','PUT','PATCH','DELETE'].reduce((x,m) => (x[m.toLowerCase()] = 
      (u,d,opt={}) => new Promise((r,j) => {
        const q = new XMLHttpRequest();
        q.open(m,u);
        q.responseType = opt.responseType || '';
        if(opt.headers) Object.entries(opt.headers).forEach(([k,v]) => q.setRequestHeader(k,v));
        if(opt.signal) opt.signal.addEventListener('abort', () => q.abort());
        q.withCredentials = opt.credentials === 'include';
        q.onload = () => r({
          ok: q.status >= 200 && q.status < 300,
          status: q.status,
          headers: new Headers(q.getAllResponseHeaders()),
          text: () => Promise.resolve(q.responseText),
          json: () => Promise.resolve(JSON.parse(q.responseText)),
          blob: () => Promise.resolve(new Blob([q.response])),
          response: q
        });
        q.onerror = () => j(new TypeError('Network request failed'));
        q.send(d instanceof FormData ? d : JSON.stringify(d));
      }), x), {});

This gives you xhr methods with a fetch-style API and you can still do all the things that fetch can't (but this won't do real streaming or cache control like Fetch, but it'll do 95% of all common use cases in a tiny bit of code.)

Each method listed above returns a Promise that resolves with the XMLHttpRequest object or rejects with the error. So you get both the Promise functionality and full access to the XHR object in the resolution.

Usage:

    xhr.post('/api', { data: 123 }, {
      headers: { 'Content-Type': 'application/json' },
      credentials: 'include',
      signal: abortController.signal
    })
    .then(res => res.json())
    .then(data => console.log(data));

For more advanced AJAX stuff, check out the very powerful and flexible Axios library[1].

And, if you don't need AJAX but do want some of the features from jQuery (like some of the more unusual selectors) that aren't in Cash (to save bytes!), AJAX (and special effects) is excluded from jQuery Slim which brings the code down to only 69KB[3].

1. Axios https://github.com/axios/axios (41kb)

2. jQuery AJAX https://api.jquery.com/jQuery.ajax/ (87kb but includes ALL of jquery!)

3. https://code.jquery.com/jquery-3.7.1.slim.min.js

Caching is the most important reason to consider GET for a non-hypertext API. Vary headers tell the server which header diffs should cause cache misses, but there's no way to do that for an encoded body.

I believe providing a body with GET is non-standard, which could lead to problems with proxies. IETF is introducing the QUERY method to fill this gap.

It's not non-standard; it's actually in the standard: https://www.rfc-editor.org/rfc/rfc7231#page-24

In standard HTTP/1.1, any method can have a request body. In Representational State Transfer (REST) as defined by Dr. Fielding, HTTP doesn't even come up, let alone "methods" per se, so there is no distinction between DELETE, POST, or GET from a REST standpoint, only within HTTP as an engine for hypertext. Further, in HTTP, any of these requests can contain a request body.

But, because of this behavior by the WhatWG for Fetch, the IETF has added this paragraph to the specification for HTTP/1.1:

  "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request."

"Some existing implementations" really just means fetch. The p*ing contest between two groups resulted in a neutered and prescriptive fetch.

In other words, it's fetch that is non-standard, and the actual HTTP standard had to be updated to let you know that.

You've got the chronology and causality wrong. The Fetch API came after the RFC 7230 advice. Due to arguably dubious interpretation of arguably poor wording in RFC 2616 (from 1999) that suggested you SHOULD ignore GET bodies, various caching and proxy servers would ignore or reject GET request bodies, so that it became dangerous to use them.

Since then, each iteration of the HTTP specs has strengthened the advice. The most recent 9110 family says you SHOULD NOT use GET request bodies unless you have confirmed in some way that they'll work, because otherwise you can't trust they'll work.

Fetch was going along with this consensus, not causing the problem.

The pool was muddied; nay, poisoned. And so the solution is the QUERY method. That's how things tend to work in such a space. See also 307 because of 302 being misimplemented.

You are thinking you can pay them to not use your data? Think again. They will sneakily use your data anyway. If not yours, then the data of people who do not change setting xyz. Oops, the last update must have reset that option for some users.

You either die a hero or mumble mumble

So the issue is if you let people opt out by paying you’re left with a low intent, likely lower net worth group of people to advertise to. As a result those eyeballs are worth less. The advertisers will turn to other platforms if you only let the worst people see their ads.

Unless enough people all pay, the whole thing stops working. But there aren’t enough people who will pay because most people don’t care.

Tldr: the ad supported business model fundamentally doesn’t work if you let all your best products (you) opt out by paying. It requires them to pay an amount far in excess of what they would be willing to pay for the system to work.

There's some truth to that, but Netflix, YouTube, etc seem to be OK with both ad-supported and paid ad-free versions, so I think the logic you described does not always dominate the considerations.

I think you’re right that it’s not universal - maybe something to do with medium and attention?

You can pay to get fewer ads

> Honestly, if I can disable ads by paying them, then I'm ok with it.

The modern maxim is: any content platform large enough to host an ad sales department will sell ads

Vanishingly few (valuable) consumers have zero tolerance for ads, so not selling ads means leaving huge sums of money on the table once you get to a certain scale. Large organizations have demonstrated that they can't resist that opportunity.

The road out is to either convince everyone to have zero tolerance for ads (good luck), to just personally opt for disperse, smaller vendors that distinguish themselves in a niche by not indulging, or to just support and use adversarial ad blockers in order to take personal control. Hoping that the next behemoth that everybody wants to use will protect you from ads is a non-starter. Sooner or later, they're going to take your money and serve you ads, just like the others.

They're definitely still using your data though

New Pipe X if you need a full client does that as well.

I know of NewPipe (Android) but can't find anything about New Pipe X

Because ORM attribute access usually trigger requests, and you must design the API so that those requests, which trigger called to the network, don't block.

I see, the ORM backed objects are lazy and trigger I/O when the data is accessed. On first blush I'm surprised that Rust culture would go for this as it spread network i/o (incl network errors), async waiting and memory allocation widely in your code. This would seemto hamper eg the common "functional core, imperative shell" architecture which gets you many of the classic FP virtues. I wonder if I'm missing something that makes these less of a problem?

this has been a solved problem for... a long time, can't remember how long even.

https://docs.sqlalchemy.org/en/20/orm/queryguide/relationshi...

the older I get the more I'm convinced this should be the default behavior.

I think you are talking past each others. Preventing N+1 by doing lazy fetching and having synchronous / asynchronous API are orthogonal issues. Async API must not block the thread/event loop when the data loading is being done.

Diesel hasn't been providing an async API for reason told in this thread: https://github.com/diesel-rs/diesel/issues/399

The situation might change some day though, once async support in the core language and surrounding ecosystem gets stronger.

diesel_async exists and is also maintained by the same creator.

Yes, but it started as a experiment, and isn't official part of Diesel yet.

The creator said it is production ready, and that it will never be "officially" part of diesel as diesel only supports a sync interface. Nevertheless, diesel_async is fully fine to use, he mentions.

Why is it not just blocked in India? How come an American product, some of it is hosted on European servers cannot be reached in France?

The new generic syntax is great as well, the debugging improvements are handy and I do appreciate the new @deprecated. But 3.13 really shines, once again, with the improvement of error messages.

Now when you are a professional dev, you see them less and less, because you make less mistakes, but also because you heavily use tooling to prevent errors or diagnose them.

But if you observe beginners with modern versions of Python, it's quite magical really. The autonomy and confidence they get from those are huge.

The energy that Pablo Galindo Salgado injected into the culture of good error message has been a boon to the language.

Yes, because all the other people on HN use unlock origin.

Their own home page says their Hot reload on RSBuild is slower than Vite's.

Since I don't care if my build takes 1 second more (per their benchmark again), but I do care very much that the page refreshes faster when I do an edit, it's a hard sell.

I love Vite and I use Vite, but come on man, the values you are comparing are 50 ms vs 80 ms. They're the same from a practical standpoint.

This just benchmarks a small "hello world"-type demo app[1]. With larger apps it can become 500ms vs 800ms, or 1 second vs. 1.6 seconds. It's not really a very useful benchmark.

[1]: https://github.com/rspack-contrib/performance-compare

I just wrote a script that uses 2 ultrasonic sensors + 1 raspy to detect if somebody is moving in one direction, so that I can put that in a giant green tunnel at the entrance of a video-game-themed party next week:

https://0bin.net/paste/GrfAHJRt#oqVtar1pUzqtdCWWzvEEK71mNlcd...

When the person walks in the tunnel, it makes the sound of Mario when entering a pipe.

It does nothing else. It's for one night only, and nobody will ever use it again.

Meanwhile, it's setup in my bathroom, because it makes me giggle when I go.

It's the little things.

I do have a timing problem, as for now the sound is triggered no matter the direction I walk.

For the same party, I made a "loot generator". You scan a QR code, and go to a page that asks you to enter some info. Then it generates what your own cadaver would loot to heroes if they killed you. Used that as an excuse to try Cloudflare workers:

https://loot-generator.drax2industries.workers.dev/

(It's in French and can get pretty politically incorrect)

Again, it's one-time use software, mostly for drunk people to have a giggle. Then it will disappear like tears in the rain.

Last year, it was a light-speed effect on a fake spaceship cockpit:

https://www.bitecode.dev/p/light-speed-with-python-and-js?ut...

Ephemeral software for the fun of it.

>> the sound is triggered no matter the direction I walk

if you use it in a bathroom, the easy fix would be to only trigger sound on odd detections. Unless you are in the habit of going in a bathroom with company or if there is another way out of the bathroom.

Your projects look like they bring delight into this world!

In the party, it will be used at the main entrance, but there will be multiple secondary ones so it won't work.

What I need to do is to move my ass and fix the timing.