Comment by bhauer | Hacker News Reader

Comment by bhauer | Hacker News Reader

As someone who is relatively outside of the JavaScript ecosystem, I had the following realization yesterday when I was reviewing this: JavaScript has what I would consider two distinct flavors of "back-end" frameworks.

It has frameworks like Express and Koa, which I would consider traditional back-end frameworks. These are designed around handling HTTP requests and providing dynamic responses in myriad forms: rendered content as HTML, API responses as JSON or other forms, etc.

And then there are what I would call back-ported front-end frameworks, or semi-static site hosts. These are Next.js and Nuxt. As far as I can tell, these can be used to build traditional server-side application logic but they seem intended to host "pages." For example, in looking over Next, I see it does have the ability to expose API routes, but this seems very much a second-class citizen. The Next documentation [1] says "Next.js has support for API Routes, which let you easily create an API endpoint as a Node.js serverless function." This seems to be provided as an escape hatch, but it doesn't appear to be the core focus of the framework.

Is this distinction real or am I sadly misinformed of the, ahem, state of JavaScript?

[1] https://nextjs.org/learn/basics/api-routes

That's about right. I wouldn't call Next a "backend framework", it's an SSR framework.

SSR means that it runs on a server (of course), so it's not too hard to expose basic server functionalities for when you just need a basic endpoint, but you wouldn't want to build a backend on that. It's more akin to dropping a PHP file on a server because you just need a bit of code to run server-side (ie to do some auth with a 3rd party without exposing an API key to the frontend).

Yeah, that's about right. I was also surprised to see Gatsby and Next.js listed in backend, but it makes a weird kind of sense. I think "static site generators" would be a better umbrella, but it's a shady distinction for sure.

And your summary of Next.js API Routes is correct as well. As an example, I have a site built in Next that needs to be able to query data off of a SQLite database. Back in the old days I would have set up a simple PHP server of some kind… today I might have knocked something crappy together in Node… but in Next, you just point at a route, grab the SQLite database out of the filesystem, and look over your query parameters. It's really neat.

Next.js is mostly about server side rendering. If you look at something like nest.js it offers a more familiar backend with more structure. Because you can write your backend these days as serverless functions which just make api calls to other hosted services - the traditional backend framework (orm + routing) becomes less relevant.

I wouldn’t call express a framework though. It’s just a web server with some middleware ecosystem.

I’ve heard some people refer to Next-like frameworks as “middle-end” to highlight their specific intersection of concerns.

Reply on news.ycombinator.com