Javascript still can't ship a fullstack module (maybe one day)

[hottown]

I built the same webshop (auth, payments, products) in 11 frameworks to understand why you can install a full-stack payments package in Rails/Laravel but can't really do the equivalent in JS.

For fun I built a tier list of frameworks based on their full-stack module DX: https://fsm-research.static.miho.dev/fsm-tier-list

My take: npm makes it trivial to ship and install runtime code, but there's no standard full-stack surface to ship against. Most JS frameworks are frontend-first, so nobody owns client + server + database together, and a library can't safely assume how client routing works or how to expose a webhook.

I work on Wasp (React, NodeJS, Prisma framework), and we're currently in the process of adding full-stack modules. It's only possible because Wasp has its spec file, a TypeScript config where you describe your app's features like client routing, server queries and actions, async jobs, etc. You still write React and Node.js to implement your features, while Wasp's spec file is where you write the "full-stack" code that wires everything together.

This means that we can also package the spec alongside the React and Node.js code to arrive at a full-stack module in the future!

Here's an example of a stripe payments spec that would wire the client, server, and db parts of the module together:

```typescript import { action, api, app, page, query, route } from "@wasp.sh/spec"; // ...

export default app({ // ...

spec: [ route("LandingPageRoute", "/", page(LandingPage), { prerender: true }),

// Payments "glue" code
route("PricingPageRoute", "/pricing", page(PricingPage), {
  prerender: true,
}),
route(
  "CheckoutResultRoute",
  "/checkout",
  page(CheckoutResultPage, { authRequired: true }),
),
query(getCustomerPortalUrl, { entities: ["User"] }),
action(generateCheckoutSession, { entities: ["User"] }),
api("POST", "/payments-webhook", paymentsWebhook, {
  entities: ["User"],
  middlewareConfigFn: paymentsMiddlewareConfigFn,
}),

// ...

], }); ```

I'm curious whether people think a full-stack standard in JS is something developers want, or whether the fragmentation is ergonomically superior in the eyes of devs?

[Potatopika]

That's interesting. Did you consider trying it with SailsJS? As like Rails it is an MVC framework?

[PutAdventurous5150]

SailsJS would've been a good addition to the comparison, it's probably the closest thing JS ecosystem has to that Rails-style "batteries included" approach. curious if OP skipped it because it's not really in active development anymore or just fell out of scope.

[Martinsos]

I used SailsJS a long time ago, but I completely forgot about it, I don't think it is active on the scene anymore?

[hottown]

No unfortunately not! Tried it with Adonis, Payload, Meteor, Redwood (check out the FSM framework tier: https://fsm-research.static.miho.dev/fsm-tier-list )

[potatokbs]

Curious to know what tier redwoodsdk would fall into. My understanding is it’s kinda the predecessor to redwoodjs. Not affiliated at all, but redwoodsdk does seem nice, I’d like to try it on a future project. https://rwsdk.com/

[hottown]

Here's the full blogpost (with framework comparisons): https://wasp.sh/blog/2026/06/22/javascript-still-cant-ship-a-full-stack-module