3 ms·

This is a bit tangential, but I really don't get the value of using the same language on the client and the server. The advantages I see would be: 1) You need

This is a bit tangential, but I really don't get the value of using the same language on the client and the server. The advantages I see would be: 1) You need to know / be comfortable with one language less 2) During development, you can easily move functions back and forth between the client code and the server code, progressively deciding what will be computed on the server and what will be computed on the client 3) You can generate, exchange, and execute code in real time between the client and the server but 1) I don't know any programmer who's both competent and monolinguistic. 3) is of course insane for security reasons 2) I used to think this would be a thing, but once you take the approach of making the client a GUI to an API, this doesn't tend to happen. It's generally very clear what's going to be server side and what's going to be client side.

deleted 11y ago
[deleted]
jmzwar 11y ago
It's an interesting thing nodejs. I think there is also another advantage which is the sheer number of Front End devs who can now do backend work. Showing my ignorance a bit here but why is it insane for security reasons?
enos_feedler 11y ago
What about server-side render on page fetch and client side rendering afterwards? Or running business logic client side so the UI appears snappy and then enforcing that logic server-side? This would benefit from the same code running in both contexts. But I agree with your other points, its not a huge deal. Even the points I mention don't seem like core issues.
frivoal 11y ago
agree on 1 and 3. As for 2, I think it makes sense. You can pre-render your GUI on the server side, so that clients get served proper html rather than an empty pile of js, and then have the same codebase take over on the client side, single-page-app style, just talking to the backend to fetch data.
- murbard2 11y ago
  That sounds good, but it only means that you have to be able to execute the client code on the server. You locally (i.e. on the server) simulate a client connecting and doing some rendering, then send a continuation to the real (remote) client. Also - does Meteor do anything remotely like this? I doubt it.
roneesh 11y ago
I sort of agree, I can see virtues, but I've never seen good examples. From all my full-stack work, it's hard for me to imagine really pure isomorphic examples. Definitely we'll have similar patterns and such, and small snippets that work in both contexts, but large functionality line for line code that works in the context of a server and a client, well I've yet to see good examples (anyone feel free to point me to some!). Perhaps that's not the goal of isomorphic code, but if it's just re-using small lines here and there, I can translate from one language to another pretty well.
afshin 11y ago
I think the biggest benefit of having the same view layer logic on the front-end and back-end is to send pre-rendered views to the client without having to to generate the markup using two different sets of code. Other than that, your data access and APIs could be written in any language, if you separate your view logic out. React on the client and server makes it easy to have the same view logic without making a similar commitment about the rest of your business logic.

deleted 11y ago

[deleted]

jmzwar 11y ago

It's an interesting thing nodejs. I think there is also another advantage which is the sheer number of Front End devs who can now do backend work. Showing my ignorance a bit here but why is it insane for security reasons?

enos_feedler 11y ago

What about server-side render on page fetch and client side rendering afterwards? Or running business logic client side so the UI appears snappy and then enforcing that logic server-side? This would benefit from the same code running in both contexts. But I agree with your other points, its not a huge deal. Even the points I mention don't seem like core issues.

frivoal 11y ago

agree on 1 and 3. As for 2, I think it makes sense. You can pre-render your GUI on the server side, so that clients get served proper html rather than an empty pile of js, and then have the same codebase take over on the client side, single-page-app style, just talking to the backend to fetch data.

murbard2 11y ago
That sounds good, but it only means that you have to be able to execute the client code on the server. You locally (i.e. on the server) simulate a client connecting and doing some rendering, then send a continuation to the real (remote) client. Also - does Meteor do anything remotely like this? I doubt it.

roneesh 11y ago

I sort of agree, I can see virtues, but I've never seen good examples. From all my full-stack work, it's hard for me to imagine really pure isomorphic examples. Definitely we'll have similar patterns and such, and small snippets that work in both contexts, but large functionality line for line code that works in the context of a server and a client, well I've yet to see good examples (anyone feel free to point me to some!). Perhaps that's not the goal of isomorphic code, but if it's just re-using small lines here and there, I can translate from one language to another pretty well.

afshin 11y ago

I think the biggest benefit of having the same view layer logic on the front-end and back-end is to send pre-rendered views to the client without having to to generate the markup using two different sets of code. Other than that, your data access and APIs could be written in any language, if you separate your view logic out. React on the client and server makes it easy to have the same view logic without making a similar commitment about the rest of your business logic.