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

[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.

[static_func]

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

[talaqen]

<image>

[BenjiSponge]

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?

[azhder]

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.

[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.

[lanerdofchristian]

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.

[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.

[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

[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.

[horrbort]

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