On Mon, Oct 6, 2025, at 1:50 PM, Edmond Dantes wrote: > Of course, you might say that there are simple websites for which FPM > is sufficient. But over the last two years, even for simple sites, > there’s TypeScript — and although its ecosystem may be weaker, the > language may be more complex for some people, and its performance > slightly worse — it comes with async, WebSockets, and a single > language for both frontend and backend out of the box (a killer > feature). And this trend is only going to grow stronger. > > Commercial development of mid-sized projects is the only niche that > cannot be lost. These guys need Event-Driven architecture, telemetry, > services. And they ask the question: why choose a language that > doesn’t support modern technologies. Async is needed specifically for > those technologies, not for FPM.
We must have a different definition of mid-sized, because FPM has been used for numerous mission critical large sites, like government and university sites, and has been fine. And such sites still benefit from faster telemetry, logging, etc. Regardless, we can quibble about the percentages and what people "should" do; those are all subjective debates. The core point is this: Any async approach in core needs to treat the FPM use case as a first-class citizen, which works the same way, just as reliably, as it would in a persistent CLI command. That is not negotiable. If for no other reason than avoiding splitting the ecosystem into async/CLI and sync/FPM libraries, which would be an absolute disaster. --Larry Garfield
