3 ms·

> Too many people only learn JavaScript, become psychologically dependent on it, and they all collectively took it too far outside of a browser. Do you have an

> Too many people only learn JavaScript, become psychologically dependent on it, and they all collectively took it too far outside of a browser. Do you have any evidence for this? Because there's plenty of reasons why you'd share the same code in the browser and the server. Being able to do SSR and sharing validation logic are two huge and obvious reasons. Ever try to exactly duplicate validation rules between the browser and PHP? What about when they use weird regexp rules? I have a site builder codebase that renders previews instantly as you make changes, then uses the same code on the server to render the HTML and CSS for visitors. That would be otherwise be outright impossible to do without writing the same code again in another language.

gls2ro 5y ago
Here is my perspective: There are plenty of reasons to use the same language on FE and BE but for me the main problem is the JS standard library. Let me give you one example: Lets say you want to validate if a string is a valid URL. What is a good way to do this in JS? Just for reference in Ruby for example I can do: URI.parse(input).kind_of?(URI::HTTP) No gems or any other engines needed.
- hoten 5y ago
  The URL constructor.
  - gls2ro 5y ago
    Oh wow, how I missed that. I stand corrected! Seems like JS standard library is better than I thought.
zozbot234 5y ago
> Being able to do SSR and sharing validation logic are two huge and obvious reasons. Ever try to exactly duplicate validation rules between the browser and PHP? What about when they use weird regexp rules? PHP is adding support for FFI to any C ABI-compatible language, and you can run the exact same code in the browser via emscripten or a WASM polyfill. As a bonus, emscripten/WASM compiled code will also be more efficient in the browser than plain JavaScript or Typescript.
- chrisbroadfoot 5y ago
  > As a bonus, emscripten/WASM compiled code will also be more efficient in the browser than plain JavaScript or Typescript. Small gains compared to the cost of implementing. 10-20%. Now you're asking your full-stack developers to know PHP, JS, C, and WASM.
- bastawhiz 5y ago
  It seems silly to add a third language to your stack just so you can share code between the other two languages.

gls2ro 5y ago

Here is my perspective: There are plenty of reasons to use the same language on FE and BE but for me the main problem is the JS standard library. Let me give you one example: Lets say you want to validate if a string is a valid URL. What is a good way to do this in JS? Just for reference in Ruby for example I can do: URI.parse(input).kind_of?(URI::HTTP) No gems or any other engines needed.

hoten 5y ago
The URL constructor.
- gls2ro 5y ago
  Oh wow, how I missed that. I stand corrected! Seems like JS standard library is better than I thought.

zozbot234 5y ago

> Being able to do SSR and sharing validation logic are two huge and obvious reasons. Ever try to exactly duplicate validation rules between the browser and PHP? What about when they use weird regexp rules? PHP is adding support for FFI to any C ABI-compatible language, and you can run the exact same code in the browser via emscripten or a WASM polyfill. As a bonus, emscripten/WASM compiled code will also be more efficient in the browser than plain JavaScript or Typescript.

chrisbroadfoot 5y ago
> As a bonus, emscripten/WASM compiled code will also be more efficient in the browser than plain JavaScript or Typescript. Small gains compared to the cost of implementing. 10-20%. Now you're asking your full-stack developers to know PHP, JS, C, and WASM.
bastawhiz 5y ago
It seems silly to add a third language to your stack just so you can share code between the other two languages.