Any sufficiently complicated network program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of email or Usenet.

If you sync with Thunderbird, it puts all your emails into SQLite dbs that you can peruse.

is this satire.

What are you talking about WRT Koa? Express 4 does not support async/await natively in its middleware. That means if your async method throws an error, you need to catch it and return it yourself or else it will just crash the app. That's one reason why I currently use Koa. Express 5 finally supports async/await and it is only now being officially released.

You can fix async await with express by just installing a package.

Which package?

This one does it via monkey patching express internals to make the fix transparent: https://www.npmjs.com/package/express-async-errors

That still doesn't address the main difference between Express and Koa.

In Express, the route handlers send the response directly so your middleware can only be "beforeware".

In Koa, the route handlers update a response object that bubbles back up the stack before it's sent, so you can write both beforeware and afterware (so, real middleware).

For example:

    app.use(async (ctx, next) => {
        console.log('Request is going down', ctx.request.body)
        await next()
        console.log('Response is coming up', ctx.response.body)
    })

Sure, but that doesn’t seem very relevant to this thread. Also in express there are certainly ways to do what you say, for instance you could make a middleware like the following:

    app.use(async (req, res, next) => {
      console.log("Request is going down", req.body)
      await next()
      console.log("Response is coming up", res.data)
      res.send(res.data)
    })

    app.get("/", function (req, res) {
      res.data = { content: "Hello World" }
    })

I don't think anyone was claiming Express and Koa were carbon copies of one another, only that Koa's benefits over Express are minor and Express is much more relevant.

Your claim that "you have to catch your errors or your app can crash" can be addressed trivially. My Express is rusty and I didn't use exact types, but something like this would do:

    type ExpressMiddlewareNextOptional = (req: Record<any, any>, res: Record<any, any>, next?: (error: any) => void) => any;
    type ExpressMiddleware = (req: Record<any, any>, res: Record<any, any>, next: (error: any) => void) => any;

    const mid = (middleware: ExpressMiddlewareNextOptional): ExpressMiddleware => {
      return (req, res, next) => {
        const result = middleware(req, res, next);
        if (result instanceof Promise) {
          result.catch((err) => next(err));
        }
      }
    }
    
    // example usage:
    app.get('somepath', mid(async (req, res) => {
      throw new Error('Oopsie!')
    }))

I used Koa a long time ago before JS had promises and async/await, and it was a relief then, but since Promises the ergonomics of Express have been better (compared to Koa of 8-9 years ago, it's possible Koa is on par or better now). When I started a new project 4 years ago I saw that express had >100X the active usage of Koa, and many, many more packages and pre-built middleware. That's why I say Koa is largely not relevant.

They're both very lightweight libraries, but the ecosystem for Express is much larger, and as mentioned, I've seen maybe 1 company using Koa in the last 5 years. I'm not saying not to use it, and I'm not saying it's not good, but OP was asking for a comparison to "competitors", and I think the ecosystem around a web framework is one of the most important considerations in choosing one. There are thousands of Node.js frameworks, and I'm sure there are many novel ideas among many excellent frameworks I've never even heard of, but the only ones I'd call "competitors" to Express are the ones operating in or near the same weight class. OP mentioned Fastify which is no more than 1 order magnitude away from express in market share, and Koa, which is at least 2 orders of magnitude below Express in active market share. My response was just pointing out that Koa is largely irrelevant when considering Node.js frameworks as "competition to Express".

If they had asked about "alternatives" instead I probably wouldn't have mentioned it "not being a thing", but just pointed out that Express/Koa are spiritually very similar (as two ultra-minimalist frameworks created by TJ Hollowaychuk), but Express's ecosystem is so much larger that someone who isn't already familiar with Koa would very likely be better off choosing Express for anything serious.

Express definitely has a bigger ecosystem and it's what most people, especially beginners, should use.

But they asked how Express 5 compared to competitors, you brought up Koa, someone suggested that Koa was superseded by async/await + some library in Express, and I pointed out Koa's little native feature that still makes it relevant to the few of us who ever used it.

I don't put a lot of importance on microframework ecosystems because 99% of their library middleware is just trivial wrappers around core libraries like https://github.com/jshttp. I write my own glue code in middleware and Koa's abstraction is just what I expect from server code.

i run a home media server, can't wait to be able to add my own LLM service. it's just a matter of time for it to be something i can install over the weekend with proper hardware

Have you tried https://ollama.com/ ? You may find you already can

  git clone https://github.com/ggerganov/llama.cpp
  cd llama.cpp
  make
  ./server -m models/7B/ggml-model.gguf -c 2048

I don't think it'll take you the whole weekend :)

we actually used an .ai domain and one night, round 11pm it stopped pointing to us. To add a record, the registrar at AI literally had a spreadsheet which upserts all the records when they upload it, and someone fat-fingered the row with our domain. It took the whole night to get a hold of the one person on that island who could fix it. This was about 5 years ago, maybe they've gotten better.

it was always mac for laptops, pc for desktop for me. I guess there's something to be said when the vendor owns all the parts, including the OS.

actually I'm pretty sure that all our social security numbers leaked in full since the Experian/TransUnion hacks. I have kept my scores frozen ever since then. It's a minor annoyance but I don't know why this isn't required now

They've been leaked ever since they were shared with anyone other than yourself and the Social Security Administration. Any system using an SSN as a password is fundamentally broken - just the fact that a company can verify your SSN is proof that it's an authentication mechanism known to more than only yourself... (Ok, they could be hashing it, or at least the first five digits of it... but they're not.)

As a full-time Node.js dev, I agree with your decision! Too much time is wasted on compatibility problems. I'd almost say it was easier when we just had browsers to deal with. At least you could just drop in jQuery and call it a day.

Yes, jQuery is often derided as outdated, but it worked quite well for a very long time, with minimal hassle for developers. In fact, I was working full-time on static Elixir/Phoenix pages with jQuery sprinkled on top as late as 2022… it felt a bit clunky but it worked as advertised and wasn’t frustrating in any significant way.

I still use JQuery because of all the syntactic sugar and shortcuts.

Me too, I prefer the API.

At the end of the day I’m delivering reliable and productive solutions for my clients, and they don’t care what the tech is.

However the Django API, GraphQL with React front end stack I’ve inherited is an frustratingly flakey to use and a nightmare to develop :-/

It’s so bad I’m regretting all my life choices that led me to this point LOL

I’m curious to hear what are some of the most frustrating points developing with Django, React, and GraphQL.

same here, maybe we can improve things!

I mean, a whole sea of WordPress developers still use JQuery. It's still out there and thriving.

you mean the title cut off? it happens on desktop too. i wonder if it's intentional

Yes, it is intentionally their design.

In that case, awesome.

It's not "unbundling" they literally just added new costs for features that were originally free because they can get away with it. So far, I have also found you are now REQUIRED to pay for your seats if you want to sit together. Frontier splits me and my wife even when there's seats available

I fly Southwest too. I like the flexibility that they provide.

If you don't feel like flying today, that's fine with them. No change fees. However, sometimes they don't feel like flying either, and you also need to extend them the same courtesy.

Hear hear. It would've been one thing if, when they invented Basic Economy, it was "you can get cheaper flights now but you lose all these things you're used to." Instead, as I recall, it was "welcome to Basic Economy, where you still pay the same amount you used to, but we've taken away a bunch of stuff you now have to pay extra fees for."

It's interesting you used Frontier as an example. Frontier's whole business model is "unbundle everything the law allows." This means dirt-cheap fares that alone can't cover their costs of running the flights. They need the fees to make the whole thing work.

The last Frontier flight I took had the following cost breakdown:

Airfare: $0.01

Taxes and fees: $18.97

Total: $18.98

I fly on Frontier all the time, and while I do hate all of their upselling during the checkout process, my flight does end up being significantly cheaper than any other option.

In this case, I searched for a flight to Atlanta - Frontier was $49, Delta was $250. After going through the checkout process, I paid exactly $49 for my Frontier flight. I need to add a checked bag, which it looks like they charge $50 for, but $99 is still << $250.

When I lived out of state, I'd go up to visit family for the weekend with just a laptop and 2 changes of clothing. The dirt cheap budget flight options were amazing.

4 fare types, Early Bird, A-List? Not displaying prices with aggregators? Surprisingly-expensive fares quite often?

I appreciate Southwest's philosophy but it isn't immune from trying to squeeze more revenue out of each trip - they just do it differently.

I understand people been angry for a fee for choosing the seats.

But a fee for lugage is very natural. Handling lugage has a clear cost. It looks natural to unbound it.

Who the hell flies without luggage? Do you literally carry only your wallet when you take a flight?

At least here, all include a small backpack/bag that you can put under your seat. A notebook and enough cloth for a few days.

The Next team's core use case is a serverless framework for Vercel. Anyone looking to use it as a long-running server is just a second-class citizen.

If you aren’t deploying to vercel for the duration of the project, use something other than next.js. It has become a vercel only product at this point.