Having front-end and backend in the same language and mono repo is such an outrageous productivity booster for me. Obviously the opposite may still be true if you've got big, separate frontend and backend teams but if you just want to ship.. I wouldn't have it any other way.

▲

webdevladder 5 days ago | parent | next [-]

Full-stack rich schemas, not the poor lossy JSON Schema or other language-agnostic ones, are so nice for long-term quality and development velocity. You get to categorically avoid bugs that drag teams down. Zod 4, ArkType, and Valibot are all great.

▲

smaudet 5 days ago | parent [-]

This is the problem inherent in web dev I suspect. JS developers thought they reached the zenith of programming because they had a type system and could realize some gains via strong typing checks applied to what would otherwise be network calls.

However, at a certain point, you're better off not writing a web app anymore, just an app with a somewhat wonky, imprecise runtime, one that lacks any sort of speed and has many drawbacks.

And you lose one of the most fundamentally important parts of the web, interop. I'm sure other langs can be made to speak your particular object dialect, however the same problems that plague those other type systems will still plague yours.

Which circles back to my issue, no, sticking your head in the sand and proclaiming nothing else exists, does not, in fact, make things better.

	▲	webdevladder 5 days ago \| parent [-]
		You've missed the point, it's inherent in any serialized communication, and the gains are far greater than a type system. Protobuf and friends, and every type system in existence, pale in comparison to runtime capabilities and guarantees.

▲

happimess 5 days ago | parent | prev [-]

You can have a monorepo with any tech stack you'd like.

You can write your front-end and back-end in the same language.

No shade to you for finding a productive setup, but Next.js tightly couples your front-end and back-end, no question.

	▲	evilduck 5 days ago \| parent \| next [-]
		> Next.js tightly couples your front-end and back-end, no question. I'd question that statement, since it's wrong. There's no requirement to connect your NextJS server to your backend databases, you can have it only interact with your internal APIs which are the "real backends". You can have your NextJS server in a monorepo alongside your APIs which are standalone projects, and Next could exist solely to perform optimized payloads or to perform render caching (being the head of a headless CMS). It seems like a weird choice to make but you could also build almost a pure SPA have have Next only serve client components. The tightness of the coupling is entirely up to the implementor.
	▲	matt-p 5 days ago \| parent \| prev [-]
		I don't use next.js really any more. That's exactly what I do.