> Is it? It performs slower than e.g. Fastify. Don't see how that's doing well.
It's such a marginal difference when you consider real-life applications built with either express or Fastify though. Seldom is the actual bottleneck which HTTP library you use (unless you're at a really, really, really big scale), and more about how you structure your code, database and general architecture. I can count on one hand the number of times I've had to care deeply about the HTTP stack in order to optimize something, while I've probably had to optimize 100s of web products over the years, all done without touching the HTTP parts at all.
> It doesn't. That's the whole point. Software is always evolving and I doubt it's even close to complete. There hasn't been meaningful updates to Express in a long time. Why do people use it and/or promote it as a standard?
How to handle HTTP requests kind of doesn't. HTTP 1.1 continues to work, and will continue to be sufficient for at least 90% of all the use cases on the web for a long time.
I know that the JS community generally suffers from "If it hasn't been updated in the last year, it's probably broken and not modern enough" syndrome, but some software actually end up being "finished" and good enough for the task at hand. What improvements could you actually add to express without breaking the API interface that millions of applications depend on? Sometimes stability is wanted and needed, and that's how you get mature software. Who wants to rewrite their application and architecture every time some library you happen to use decides to "improve" it?
> How to handle HTTP requests kind of doesn't. HTTP 1.1 continues to work, and will continue to be sufficient for at least 90% of all the use cases on the web for a long time.
If you take out your 386 and boot up Dos 3.1 it'll; continue to work too. Let's just not improve, right?
> but some software actually end up being "finished" and good enough for the task at hand
Like dead? Do you ever stop learning and growing? Are you "finished" too? There are new vulnerabilities, new compatibilities, existing bugs, different use cases, etc - you think it's finished = turning a blind eye.
> It's such a marginal difference when you consider real-life applications built with either express or Fastify though.
That's how we get Electron and everything become a resource hog. Oh it doesn't matter. Oh marginal difference. No don't recycle, don't do good for the environment and anything in life because it's all marginal. Why even reply? It's a marginal difference.
It's such a marginal difference when you consider real-life applications built with either express or Fastify though. Seldom is the actual bottleneck which HTTP library you use (unless you're at a really, really, really big scale), and more about how you structure your code, database and general architecture. I can count on one hand the number of times I've had to care deeply about the HTTP stack in order to optimize something, while I've probably had to optimize 100s of web products over the years, all done without touching the HTTP parts at all.
> It doesn't. That's the whole point. Software is always evolving and I doubt it's even close to complete. There hasn't been meaningful updates to Express in a long time. Why do people use it and/or promote it as a standard?
How to handle HTTP requests kind of doesn't. HTTP 1.1 continues to work, and will continue to be sufficient for at least 90% of all the use cases on the web for a long time.
I know that the JS community generally suffers from "If it hasn't been updated in the last year, it's probably broken and not modern enough" syndrome, but some software actually end up being "finished" and good enough for the task at hand. What improvements could you actually add to express without breaking the API interface that millions of applications depend on? Sometimes stability is wanted and needed, and that's how you get mature software. Who wants to rewrite their application and architecture every time some library you happen to use decides to "improve" it?