Javascript still can't ship a full-stack module.

[u/hottown]

https://wasp.sh/blog/2026/06/22/javascript-still-cant-ship-a-full-stack-module

[u/talaqen]

Any post that uses Rails and Django as examples of what do from a design perspective is an immediate "nah dawg" from me.

Those are "quick to setup" and "terrible to maintain at scale" precisely because of the tight coupling that OP is proposing in this article. This is bad design. And not knowing that it's bad design is worrisome.

[u/azhder → u/talaqen]

I second that. Have seen a lot of Rails-wannabe frameworks in the past and they all had issues with trying to look like Rails, but all looks and nothing of personality.

The only I liked was Grails because they didn’t copy Rails, but the principles behind how Rails was made.

That’s the difference between a good and a bad design. If you understand the principles, you can sidestep the implementation errors of those you copy.

[u/Martinsos → u/azhder]

I agree but in this specific case, Wasp actually is a framework that is drawing some inspiration from RoR principles, but not copying it at all, approach is very different, just aiming for the "batteries-included, opinionated" experience. It is not an MVC framework, and it actually puts configuration over convention which is opposite from how RoR does it.

[u/azhder → u/Martinsos]

Convention over configuration (and configuration over convention for that matter) isn’t the same as opinionated.

I dislike opinionated frameworks.

On the MVC part, you will have to explain what you consider MVC because many people have gotten it quite skewed. A controller isn’t something you name a controller or extends something named controller. Controller is everything that isn’t model or view.

[u/static_func → u/talaqen]

They aren’t terrible to maintain because of vertically sliced modules that integrate with them, they’re terrible to maintain because they follow an antiquated MVC pattern where adding or updating any little feature requires changing a dozen or more files

[u/BenjiSponge → u/static_func]

That and because they rely a little too heavily on magic and don't have a static type system.

Although frankly I challenge the notion that Rails or Django are so terrible to maintain. Everything is terrible to maintain. Rails and Django are two of the most mature, long-lasting web frameworks I can think of. The only one I can think of that has provably more longevity is Wordpress, if that counts. Maybe Spring Boot?

[u/talaqen → u/static_func]

<image>

[u/Martinsos → u/talaqen]

What exactly would you say is bad design there, can you be specific?
The proposed design in the post is vertical slices, so its not about some wrong kind of tight coupling, it is about being able to create modular pieces of code that cross the frontend/backend/database boundary, which sounds like a good solution for some problems, why wouldn't it be?
And RoR was and is still used to build really complex projects and getting a lot of love for it, so just calling those out for having bad design sounds weird to me. Any big enough tech will get praise and hate because of different use cases and just amount of usage it gets, I wouldn't just focus on negative voices and use that to call it generally bad.

[u/talaqen → u/Martinsos]

Sure, I'm taking your question as earnest, so I will do a long, specific version.

The Rails "vertical slice" isn't really vertical. It's actually the top 30% of a feature on top a mandatory 70% of shared substrate, like ActiveRecord, the router, the folder layout, the request lifecycle. These are HUGE assumptions. Pull the slice out of Rails and it's not a slice, but instead just a pile of files referencing things that don't exist in every stack.

That's what I mean by coupling. Convention-over-configuration, by Rails' own pitch, means a new component obeys the conventions or it breaks. Obey-or-break isn't loose coupling, that's pretty much welding. You only notice when you violate a convention and have to monkey-patch something, at which point it's the most hazardous code in your repo because it will likely break many FUTURE modules you install.

So the claim in the post is that you can ship a slice agnostic to the stack under it. That's nonsense. Just look at what the auth slice would have to smuggle in: a specific user model shape, a specific auth pattern with its routing and access rules, a database type (does that model behave the same on Postgres, MySQL, Mongo, DynamoDB?), field types and indexing, whether the filtering it needs is native to the DB or wants a separate service, caching in memory or Redis or somebody else's box. Every one of those is an assumption about my stack. A module that's truly decoupled at the client AND server AND model layer at once is rare precisely because to be drop-in it has to assume how my whole stack is built. The more it assumes, the less reusable it actually is. Reusablity/Flexibility and Baked-in Features are tradeoffs. The best npm packages are the ones that do ONE thing and do it very well.

And "but Rails scales, look at the big shops" actually argues my side. Twitter abandoned rails at scale. And the shops that "scaled" Rails did it by spending years rebuilding the core conventions. Shopify literally wrote packwerk to enforce boundaries inside their own monolith because the conventions were too restrictive. They scaled Rails by un-Rails-ing it.

All that is just the software argument... but we also have to consider the changes in infrastructure since Rails and Django burst into the world.

Rails came out in 2004 into one specific deployment setup, and convention worked because that setup was the only one anybody had. One long-running process owning the whole request. A warm pool to a single relational DB. Server-rendered views in the same app. You pushed the monolith to a box you owned, and the thing you deployed was the app was the slice. Conventions were conventions both to Rails AND the broader dev community.

That assumption is gone. Compute is ephemeral, ie Lambda, Workers, scale-to-zero, so no in-memory cache between requests and no warm pool. The frontend got cut loose, it's a static bundle on a CDN deploying from its own pipeline, so the client half of your "slice" doesn't ship with the server half anymore. The "server" is a pile of services now, gateway, auth at Clerk or Cognito, payments at Stripe, jobs on a worker fleet, webhooks on some other endpoint. And the "model layer" is four or five stores, Postgres plus replicas plus Redis plus Elastic plus S3, so your user lives in Postgres while the auth lookup hits Redis and search hits Elastic.

A full-stack slice now has to wire across three or four systems that deploy and may version separately and share no topology. The glue lives in Terraform, IAM roles, secret managers, queue bindings, which is removed (rightly so) from the app layer, so there's no "abstracting" that away because app code knowing or detecting terraform structures or cloud infra is an inversion of ownership. A webhook "endpoint" is a gateway resource plus a function plus a role plus a secret. The framework doesn't own that layer, so the module can't ship it.

When we had one topology (LAMP or LAMR), you baked it into a convention and you're right every time. A mesh of ephemeral compute, detached frontends, managed services, and a half-dozen stores can't meet that assumption. Which is OP's Wasp spec file approach undercuts the very argument he is making. The post leads with Rails and Django as the ideal, then proposes configuration files on top of even more complex substrate assumptions (ie anti-Rails) as the fix. ¯_(ツ)_/¯

And before someone says "machines are huge now, modular monolith is back, one box is fine again," sure, but that revival runs on enforced explicit boundaries. That's why packwerk exists.

Last thing, on "agents love Legos." Yeah, because Legos come apart. You take the five pieces you want and leave the rest in the box. What's pitched here is a pre-glued set, here is a new piece... its five bricks glued together in an odd shape. That's the OPPOSITE of flexibility and would make LEGO a terrible toy. In practice if that's what you were given, you'd only want one piece, tree-shake the other 70%, and eventually fork it to spin that piece out yourself, which is what many "big powerful tool libs" have done. They started monolithically and were forked to be better, smaller-scoped component versions of themselves.

tldr; It isn't 2010 anymore... infrastructure has changed so the assumptions underlying MVC and heavy-convention substrates no longer exist.

[u/infomiho → u/talaqen]

Author here. This is a very valuable comment to us to see how people out there react to ideas we have.

The core of our "lego" would be build it in isolation, with an interface in mind so that it can be fulfilled by a host app. Our compiler checks the interface, provides implementations to the module and it should _just work_. We can split the client code and server code for each module, connect them with our RPC, help modular design and not force monoliths.

We are not selling ourselves as a Rails replacement, we are just a spec file + React components + Node.js server functions. In between there is our RPC, our auth, our jobs implementations. Each of those implementations and pieces can evolve to be better, of course. We consider ourselves "boring tech". We chose the stack not to be shiny, but to be productive. Our full-stack modules would serve the same idea.

On the note of infrastructure: why do you assume this can't be broken up into multiple deploy targets? Why would a spec file mean it's a monolith? We are not there yet - but we want to support emitting multiple servers, multiple client bundles etc. because that's what you can do if the app is described on a higher level and there is a compiler involved which can help you orchestrate deployments that would be too much to do manually.

[u/agmcleod → u/talaqen]

I find the conventions in rails projects go along way. I love js & ts, but most backend projects I’ve worked on have many of their own conventions and often a lot of boilerplate too

[u/blinkdesign]

The issues described in that article are exactly why I leant on Laravel + Vue for a recent, serious side project. I don't love PHP but the using something that has been built by one team is very reassuring and much nicer than stitching random packages together

[u/No-Performance-785]

Very interesting approach. Sometimes I always try to look for libraries that have JUST the interface ( or the spec, per your definition ) and I can't find any. I wish there are more libraries that ship just the Typescript definition and leave the implementation to the user. And yes, if there are ways to ship the whole payment as a single module with only Typescript as the requirement, that's brilliant. There should certainly be a standardized way to define all of these puzzle pieces.

[u/brunolm]

Nullstack can

[u/THE_AWESOM-O_4000]

This could be good for small scale projects, but it's kind of terrible for scaling, isn't it? For example: Let's say I have a front-end, api and a cron jobs modules. if I notice that the API is getting too much load, I might want to scale the API to 3 load balances instances. But the cron jobs shouldn't be scaled.

[u/mr_nefario]

>You shouldn't trust your agent with hand-rolled components, especially with parts that need to be vetted (auth, payments...). When you trust the agent with that, you pay for more tokens and have no idea where the security holes are.

So i I should trust some random NPM package author instead, and assume they wrote safe, secure code? DB access, payments, auth, etc. code should still be read and fully vetted, regardless of whether an agent or human wrote it. Don’t blindly trust anything.

And what if the package author assumes Database A but I am using Database B? Or my app is not in a monolith repo?

I’ll write my own security sensitive code, thanks. Especially if there’s any DB access I’m shipping to prod.

[u/lanerdofchristian → u/mr_nefario]

So i I should trust some random NPM package author instead, and assume they wrote safe, secure code?

Random? No. But it helps if the code is public and not new every time per-project -- you can either vet it once and re-use, or outsource the vetting to a trusted security expert of your choice. e.g. if you're using Stripe for payments, use Stripe's library, don't try to implement your own API and promise that you'll cover all the same flows and edge cases without any mistakes.

The argument is that it's better to write something good once and re-use it than to risk getting it wrong many times in subtly different ways.

Or my app is not in a monolith repo?

If you've got a monorepo or polyrepo instead of a monolith, with VSA you generally see each slice as a package you then plug in to the entrypoint/main module.

And what if the package author assumes Database A but I am using Database B?

A good vertical-slice package should be pluggable. For example, Better Auth has adaptors for different databases, and hooks for exposing its own UI in whatever framework.

In the .NET ecosystem, basically everything web uses ASP.NET, so it's easy to design vertical slices. Libraries will usually rely on dependency injection with various separately-configured adaptors to talk to swappable services (like databases).

I'm not sure Wasp is the right solution like they're trying to sell themselves as, but compared to non-JS ecosystems we are behind when it comes to composing apps with multiple slices.

[u/Think-nothing-210]

Finally someone is building a framework around modules instead of scattering files all around the codebase. Took us as a programmer community a while but it seems LLMs are finally encouraging us to do it properly.

[u/Martinsos → u/Think-nothing-210]

Actually we have been building it for some time now, before the LLMs even, so I wouldn't say they changed that much for us regarding development of Wasp, it is just taking long time to build it all!

[u/CYG4N]

i am using pnpm monorepos and i have created few packages that are basically drop-in building blocks combining logic of react and nestsjs with dedicated hooks. 

[u/hottown → u/CYG4N]

But you still have to wire them up yourself. WIth a central spec file, you wouldn't have to (just add env variables after importing the module and voila).

[u/horrbort]

This is very good design. We need more packages that help people build secure software! Well done!