4 ms·

The JavaScript fanatics will downvote me for saying this, but I'll say this, "using a single JavaScript codebase on your client-side and server-side is like coo

by ashishb 10mo ago

The JavaScript fanatics will downvote me for saying this, but I'll say this, "using a single JavaScript codebase on your client-side and server-side is like cooking food in your toilet, sooner or later, contamination is guaranteed" [1] 1 - https://ashishb.net/tech/javascript/ https://ashishb.net/tech/javascript/

leptons 10mo ago
This isn't a Javascript problem, this is a React problem. You could theoretically rewrite React and RSC in any language and the outcome would be the same. Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript.
- ashishb 10mo ago
  > This isn't a Javascript problem, this is a React problem. It happened with Next.js as well https://github.com/vercel/next.js/discussions/11106 https://github.com/vercel/next.js/discussions/11106 > Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript. Yes. And since Python does not natively run in the browser, that mistake never happens. With JavaScript, the desire to have "backend and frontend in a single codebase" requires active resistance.
  - rounce 10mo ago
    > It happened with Next.js as well It's the same vulnerabilities because Next uses the vulnerable parts of React. Your rational is quite poor as I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then? Look, many of us also strongly dislike JavaScript but generally that distaste is based on its actual shortcomings and failures, you don't have to invent new ones plenty already exist.
    - ashishb 10mo ago
      > I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then? If you have a single codebase for Go-based code running in an untrusted browser (the "toilet") and a trusted backend (the "kitchen"), then the same contamination is highly likely.
  - leptons 10mo ago
    >And since Python does not natively run in the browser, that mistake never happens. Did you even bother to read my comment? Try again, please. Next time don't skip over parts.
pier25 10mo ago
You can still have separate codebases for server and client in JS/TS...
- ashishb 10mo ago
  > You can still have separate codebases for server and client in JS/TS... Indeed, but unlike Go/Python (backend) and TS/JS (frontend), the separation is surmountable, and the push to "reuse" is high.
  - pier25 10mo ago
    > and the push to "reuse" is high Other than types and stuff like zod validators there's not a lot of overlap between server and client code. I agree with your point that iso code can be confusing. But beyond that I think you're just pushing an irrational anti JS narrative.
0xblinq 10mo ago
You're mixing programming languages with software architecture.
- ashishb 10mo ago
  > You're mixing programming languages with software architecture. Programming languages do lead to certain software architectures. These are independent but not orthogonal issues.

by ashishb 10mo ago

leptons 10mo ago

This isn't a Javascript problem, this is a React problem. You could theoretically rewrite React and RSC in any language and the outcome would be the same. Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript.

ashishb 10mo ago
> This isn't a Javascript problem, this is a React problem. It happened with Next.js as well https://github.com/vercel/next.js/discussions/11106 https://github.com/vercel/next.js/discussions/11106 > Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript. Yes. And since Python does not natively run in the browser, that mistake never happens. With JavaScript, the desire to have "backend and frontend in a single codebase" requires active resistance.
- rounce 10mo ago
  > It happened with Next.js as well It's the same vulnerabilities because Next uses the vulnerable parts of React. Your rational is quite poor as I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then? Look, many of us also strongly dislike JavaScript but generally that distaste is based on its actual shortcomings and failures, you don't have to invent new ones plenty already exist.
  - ashishb 10mo ago
    > I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then? If you have a single codebase for Go-based code running in an untrusted browser (the "toilet") and a trusted backend (the "kitchen"), then the same contamination is highly likely.
- leptons 10mo ago
  >And since Python does not natively run in the browser, that mistake never happens. Did you even bother to read my comment? Try again, please. Next time don't skip over parts.

pier25 10mo ago

You can still have separate codebases for server and client in JS/TS...

ashishb 10mo ago
> You can still have separate codebases for server and client in JS/TS... Indeed, but unlike Go/Python (backend) and TS/JS (frontend), the separation is surmountable, and the push to "reuse" is high.
- pier25 10mo ago
  > and the push to "reuse" is high Other than types and stuff like zod validators there's not a lot of overlap between server and client code. I agree with your point that iso code can be confusing. But beyond that I think you're just pushing an irrational anti JS narrative.

0xblinq 10mo ago

You're mixing programming languages with software architecture.

ashishb 10mo ago
> You're mixing programming languages with software architecture. Programming languages do lead to certain software architectures. These are independent but not orthogonal issues.