4 ms·

> Otherwise, just tread the well-trod path and stick to either a react-vite SPA or something like Rails doing ordinary SSR. Just write your SPA the grown up wa

by mvdtnz 1y ago

> Otherwise, just tread the well-trod path and stick to either a react-vite SPA or something like Rails doing ordinary SSR. Just write your SPA the grown up way. Write your APIs in a language and framework well suited to such work (pick your poison, Rails, Spring, whatever Microsoft is calling this year's .NET web technology). And write your front-end in Typescript. There's absolutely no reason to tightly couple your front-end and backend, despite how many Javascript developers learned the word "isomorphic" in 2015.

b_e_n_t_o_n 1y ago
Agreed. It's a bit insane that updating a button padding redeploys your entire backend.
- matt-p 1y ago
  Not the same problem though is it? You can have a express backend and react-vite frontend both in typescript and in a mono repo.
- fragmede 1y ago
  Are you paying for computer time by the CPU cycle?
zarzavat 1y ago
I don't agree. Having front-end and backend in the same language is so convenient I would never go back to doing it the old way. I'd rather compile the frontend to WASM than introduce a mismatch. I used to use Django and there were so many issues that arose from having to duplicate everything in JS and Python.
- turtlebits 1y ago
  What about HTML? Are you writing HTML via JS - if not you're already writing multiple languages.
  - zarzavat 1y ago
    HTML is not a programming language. But yes, I don't write much HTML anymore. The issue with mixing languages is that they have different data models, even simple things like strings and integers are different in Python and JS, and the differences only increase the more complex the objects get. Sometimes I write some code and I realise that this code actually needs to execute on the client instead of the server (e.g. for performance) or the server instead of the client (e.g. for security). Or both. Using one language means that this is can be a relatively simple change, whereas using two different languages guarantees a painful rewrite, which can be infectious and lead to code duplication.
matt-p 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
  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.
nchmy 1y ago
or dont even write a SPA. Send hypermedia from your backend language/framework, use HTMX + Alpine or Datastar, and call it a day.
- icedchai 1y ago
  I’ve been experimenting with HTMX and it feels so much simpler.
jakubmazanec 1y ago
> There's absolutely no reason to tightly couple your front-end and backend I'll give you one reason: Gel [1] and their awesome TypeScript query builder [2]. [1] https://www.geldata.com/ https://www.geldata.com/ [2] https://www.geldata.com/blog/designing-the-ultimate-typescript-query-builder https://www.geldata.com/blog/designing-the-ultimate-typescri...

by mvdtnz 1y ago

b_e_n_t_o_n 1y ago

Agreed. It's a bit insane that updating a button padding redeploys your entire backend.

matt-p 1y ago
Not the same problem though is it? You can have a express backend and react-vite frontend both in typescript and in a mono repo.
fragmede 1y ago
Are you paying for computer time by the CPU cycle?

zarzavat 1y ago

I don't agree. Having front-end and backend in the same language is so convenient I would never go back to doing it the old way. I'd rather compile the frontend to WASM than introduce a mismatch. I used to use Django and there were so many issues that arose from having to duplicate everything in JS and Python.

turtlebits 1y ago
What about HTML? Are you writing HTML via JS - if not you're already writing multiple languages.
- zarzavat 1y ago
  HTML is not a programming language. But yes, I don't write much HTML anymore. The issue with mixing languages is that they have different data models, even simple things like strings and integers are different in Python and JS, and the differences only increase the more complex the objects get. Sometimes I write some code and I realise that this code actually needs to execute on the client instead of the server (e.g. for performance) or the server instead of the client (e.g. for security). Or both. Using one language means that this is can be a relatively simple change, whereas using two different languages guarantees a painful rewrite, which can be infectious and lead to code duplication.

matt-p 1y ago

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 1y ago
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 1y ago
  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 1y ago
    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 1y ago
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.

nchmy 1y ago

or dont even write a SPA. Send hypermedia from your backend language/framework, use HTMX + Alpine or Datastar, and call it a day.

icedchai 1y ago
I’ve been experimenting with HTMX and it feels so much simpler.

jakubmazanec 1y ago

> There's absolutely no reason to tightly couple your front-end and backend I'll give you one reason: Gel [1] and their awesome TypeScript query builder [2]. [1] https://www.geldata.com/ https://www.geldata.com/ [2] https://www.geldata.com/blog/designing-the-ultimate-typescript-query-builder https://www.geldata.com/blog/designing-the-ultimate-typescri...