3 ms·

I'm not sure I agree with this, you can always achieve parallelism with multiple processes and IPC, and can do so fairly efficiently if communication is light.

by bodas 8y ago

I'm not sure I agree with this, you can always achieve parallelism with multiple processes and IPC, and can do so fairly efficiently if communication is light. Rails' biggest problem is that it isn't JavaScript, and thus code is not portable between client and server.

haggy 8y ago
I have rarely seen the mystical pattern of "sharing Javascript code between client and server" actually work in a scalable and maintainable way outside of having a shared "enums" file.
- lghh 8y ago
  Things like lodash, moment, validation logic, and http libraries are the big benefit of this. It is generally less of business focused code and more of utility type code that is easy to share. I do this on a daily basis, and have been for years.
pankajdoharey 8y ago
If that were so true why would people rewrite apps in Go or use a JVM Language? Process based parellelism is memory intensive and you a=have no control, the best one can do is hope that the scheduler of the OS will take care of everything. Also code portability is not the issue, it is about what gets you started quickly scale well for a long time and dont ask for rewrites. Rails doesnt fit the bill, you cannot get started fast, It doesnt scale well unless you throw more hardware, MVC breaks with slightly complicated apps.
- jashmatthews 8y ago
  Ruby IS a JVM language today via JRuby. You get JIT, thread parallelism, and all the usual compacting GC goodness etc. The GIL in CRuby means you need one process per core but that's also true of NodeJS. Processes and threads aren't as different as you think. Linux pthreads are "just" processes which are allowed to write into the same memory. PostgreSQL remains process based to the day, although it does give them a little pain.
strken 8y ago
Out of curiousity, where have you found it useful for code to be portable between client and server? I've been using Node.js/React together for a while, and I haven't found code reuse across client and server to be as important as I initially thought. The only code that I've tended to share is validation and a handful of utilities, which are a tiny proportion of the total, and even for those the business rules aren't always the same.
- simonbw 8y ago
  I've made a few multiplayer games where players need to keep a game state synchronized with the server. I used redux for state and game logic, and it's been really nice to be able to share the reducers between server and client. This made it so all I had to do to keep all clients in sync was share actions across clients as they happened. I've also found it useful to have TypeScript on client and server to be able to share types between them. Also, when using React, Node on your server makes server-side rendering a lot easier.
- NewsAware 8y ago
  Personally not so much in model code, but in typescript interfaces/DTO which are used by both routing-controllers on the server side (additionally generating swagger api docs along the way) and by mobx on the frontend.

by bodas 8y ago

haggy 8y ago

I have rarely seen the mystical pattern of "sharing Javascript code between client and server" actually work in a scalable and maintainable way outside of having a shared "enums" file.

lghh 8y ago
Things like lodash, moment, validation logic, and http libraries are the big benefit of this. It is generally less of business focused code and more of utility type code that is easy to share. I do this on a daily basis, and have been for years.

pankajdoharey 8y ago

If that were so true why would people rewrite apps in Go or use a JVM Language? Process based parellelism is memory intensive and you a=have no control, the best one can do is hope that the scheduler of the OS will take care of everything. Also code portability is not the issue, it is about what gets you started quickly scale well for a long time and dont ask for rewrites. Rails doesnt fit the bill, you cannot get started fast, It doesnt scale well unless you throw more hardware, MVC breaks with slightly complicated apps.

jashmatthews 8y ago
Ruby IS a JVM language today via JRuby. You get JIT, thread parallelism, and all the usual compacting GC goodness etc. The GIL in CRuby means you need one process per core but that's also true of NodeJS. Processes and threads aren't as different as you think. Linux pthreads are "just" processes which are allowed to write into the same memory. PostgreSQL remains process based to the day, although it does give them a little pain.

strken 8y ago

Out of curiousity, where have you found it useful for code to be portable between client and server? I've been using Node.js/React together for a while, and I haven't found code reuse across client and server to be as important as I initially thought. The only code that I've tended to share is validation and a handful of utilities, which are a tiny proportion of the total, and even for those the business rules aren't always the same.

simonbw 8y ago
I've made a few multiplayer games where players need to keep a game state synchronized with the server. I used redux for state and game logic, and it's been really nice to be able to share the reducers between server and client. This made it so all I had to do to keep all clients in sync was share actions across clients as they happened. I've also found it useful to have TypeScript on client and server to be able to share types between them. Also, when using React, Node on your server makes server-side rendering a lot easier.
NewsAware 8y ago
Personally not so much in model code, but in typescript interfaces/DTO which are used by both routing-controllers on the server side (additionally generating swagger api docs along the way) and by mobx on the frontend.