5 ms·

I see a lot of people working really hard to use the same language on client and server, but I've never had any difficulty working with multiple languages nor h

by coltonv 10y ago

I see a lot of people working really hard to use the same language on client and server, but I've never had any difficulty working with multiple languages nor have my teammates. The biggest advantage for using different languages for me is that it lets you get to choose the best tool for the job on both sides without compromising. Would anyone who holds the alternate view, that they have reaped significant advantages from using the same language on server and client, care to chime in?

conqrr 10y ago
Its kind of a slight compromise using two languages, although you are offsetting the compromise by the gain from using the right tool. Say there was only one language and it still made the right tool. It would certainly be a plus as it would make things more consistent.
girvo 10y ago
The biggest thing I despise is repeating myself when it comes to validation and data-structures, and often using two different languages between the client and server means that's an unfortunate requirement. This can be mitigated somewhat, see JSON Schema and others, but most of them are leaky abstractions. Being able to truly, completely re-use data structures, validation logic, and pure functions between use-cases has saved a massive amount of time and pain across a number of production projects I've worked on in the last two years; Javascript being the language in question.
artellectual 10y ago
Yeah I agree with you. I never thought switching between languages was that hard, usually when talking about the problem of 'context switching' what I generally find difficult is switching between multiple codebase that solves problems in different domains. I switch between ES6/7 and Ruby on a daily basis, and I don't feel that it holds me back or slow me down. I actuallt enjoy working with ES6/7 now. It was painful to have to learn all the tooling involved but this library seems to be using the same tools. So it's unavoidable to learn the tooling anyway.
Cymen 10y ago
I worked on a robust client-side web application built in React. There was a product decision to make public one of the main pages with less information than a paying logged-in user would see. It was fairly straight forward, if somewhat of a quick hack, to do a server-side rendering of that page, cache it in Redis and expose it to the public web (along with building sitemaps and publishing those). It resulted in the company showing up in search results a lot more thus positively impacting growth. I hesitate to hold this example up as a shining beacon of the great power of using the same language on server and client. There were a fair number of pros and cons. But the end result was very useful and execution was relatively fast.
trungaczne 10y ago
Using the same language is useful for avoiding duplicated code, personally I find these being duplicated often: * Form validation/data sanitisation code * Translation/internationalisation * Data (de)serialisation Also you can do fancy things like server-side rendering, although Google is capable of searching SPAs now. I don't know much about SEO. The argument for less code sharing is that if you are working with a lot of teams and service-based architectures, there are some merits to duplicate your code and keep them redundant, to 1) enable hiring from more diverse backgrounds and 2) reduce communication/maintenance friction needed when you make changes to components would otherwise be shared.
- tibbon 10y ago
  You make a good point- there's really only a handful of things that get duplicated. Maybe instead we should be working on just fixing up those things. Like if there was an easy way to share validation logic from the backend to the frontend... then that would only be needed to be updated once. We don't need to share everything
marcus_holmes 10y ago
the big advantage with having the same language on both ends is being to use server-side rendering (isomorphic). So your first page serve includes the initial rendering of the content, and then the client-side code takes over to handle changes with no refreshes. If the client is written in a different language than the server then you have to maintain two versions of the page code to achieve this, and they have to be in perfect sync. Hard to do. Easier to write the code once and transpile to JS for the browser (or write the back end in JS).
- michaelmior 10y ago
  Not necessarily. You can use something like Prerender[0]. [0] https://github.com/prerender/prerender https://github.com/prerender/prerender
  - marcus_holmes 10y ago
    but... that only renders JS... which is what the client speaks, so the client and server still speak the same language
    - michaelmior 10y ago
      Your backend can run whatever language you want. There are examples right on the page that show integration with Rails, PHP, Go, and others.
mariusandra 10y ago
I find a lot of value in using a different programming language for backend and frontend code. The context switch between the languages brings with it an awareness of the security implications of everything you write. Plus you are a first class citizen in each world. Thus: * Ruby code = private methods that nobody else can see * Javascript code = public methods that everybody can peek into Once you solve the "how do I pass data from ruby to javascript and vice-versa" question, this mental model holds up quite well. (My own solution to this question is this project: https://github.com/mariusandra/kea-on-rails https://github.com/mariusandra/kea-on-rails , featuring server rendered react views (via react-on-rails) and seamless passing of data back and forth... but it might not be the best approach for your projects)
zem 10y ago
i think this is in part driven by the fact that javascript is not the best tool for the job on the client side, so people fall back on a variety of compile-to-js languages. but then, once you're doing that, why not use a language you already feel is good enough to be your choice of server-side languages? the leap to "okay, now that we're using the same language for both parts of our app, why not make a framework that lets you mix server and client side code in the same codebase" is more a taking that idea to its conclusion than the primary motivation for it.
- catmando2 10y ago
  Amen and well said!
- coltonv 10y ago
  I disagree because I do find JavaScript to be the best tool for client side development. You get full access to the DOM without worrying about your transpilers abstractions. Also I think JavaScript is a pretty wonderful language to code in once you apply a strict linter + Babel.
k__ 10y ago
I had the feeling this doesn't change anything. As companies grow they simply start using the same languages over and over, without any concern if they are the best tool for the job. With one language on client and server you get at least code reuse, if you modularize your stuff nicely.
hiou 10y ago
There is nothing more miserable than working with a team that cannot and/or is unwilling to work with anything but their language of choice. But honestly this typical goes even deeper than language. Its often difficult to get a team to work with something outside of the framework they are used to. Even if it could take 3 times as long or even is just flat out impossible without it. In my experience it has everything to do with developers who like to feel under control and feel really uncomfortable if they are not the smartest person in the room.
catmando2 10y ago
at catprint we are using reactrb (now ruby-hyperloop) to clean up our mess of ruby + JS + HTML + ERB + HAML etc. So far the results have been excellent with a reduction from about 70K SLOC to 35K SLOC. Some of the other advantages: A common tool chain, including testing (we are using rspec), people don't align themselves as front-end vs. back-end developers, easier training for new hires. Point taken about choosing the "right tool for the job", however there is nothing in JS that makes it a better tool than ruby. In fact I would argue (but it is opinion) that ruby is a far better tool than JS. So why not use ruby for full stack? If I felt that somehow JS was better than we would have worked towards using Node for a full stack solution. Of course its not just the language, its language + available libraries and tool chain. In that regard Ruby is far superior.

by coltonv 10y ago

conqrr 10y ago

Its kind of a slight compromise using two languages, although you are offsetting the compromise by the gain from using the right tool. Say there was only one language and it still made the right tool. It would certainly be a plus as it would make things more consistent.

girvo 10y ago

The biggest thing I despise is repeating myself when it comes to validation and data-structures, and often using two different languages between the client and server means that's an unfortunate requirement. This can be mitigated somewhat, see JSON Schema and others, but most of them are leaky abstractions. Being able to truly, completely re-use data structures, validation logic, and pure functions between use-cases has saved a massive amount of time and pain across a number of production projects I've worked on in the last two years; Javascript being the language in question.

artellectual 10y ago

Yeah I agree with you. I never thought switching between languages was that hard, usually when talking about the problem of 'context switching' what I generally find difficult is switching between multiple codebase that solves problems in different domains. I switch between ES6/7 and Ruby on a daily basis, and I don't feel that it holds me back or slow me down. I actuallt enjoy working with ES6/7 now. It was painful to have to learn all the tooling involved but this library seems to be using the same tools. So it's unavoidable to learn the tooling anyway.

Cymen 10y ago

I worked on a robust client-side web application built in React. There was a product decision to make public one of the main pages with less information than a paying logged-in user would see. It was fairly straight forward, if somewhat of a quick hack, to do a server-side rendering of that page, cache it in Redis and expose it to the public web (along with building sitemaps and publishing those). It resulted in the company showing up in search results a lot more thus positively impacting growth. I hesitate to hold this example up as a shining beacon of the great power of using the same language on server and client. There were a fair number of pros and cons. But the end result was very useful and execution was relatively fast.

trungaczne 10y ago

Using the same language is useful for avoiding duplicated code, personally I find these being duplicated often: * Form validation/data sanitisation code * Translation/internationalisation * Data (de)serialisation Also you can do fancy things like server-side rendering, although Google is capable of searching SPAs now. I don't know much about SEO. The argument for less code sharing is that if you are working with a lot of teams and service-based architectures, there are some merits to duplicate your code and keep them redundant, to 1) enable hiring from more diverse backgrounds and 2) reduce communication/maintenance friction needed when you make changes to components would otherwise be shared.

tibbon 10y ago
You make a good point- there's really only a handful of things that get duplicated. Maybe instead we should be working on just fixing up those things. Like if there was an easy way to share validation logic from the backend to the frontend... then that would only be needed to be updated once. We don't need to share everything

marcus_holmes 10y ago

the big advantage with having the same language on both ends is being to use server-side rendering (isomorphic). So your first page serve includes the initial rendering of the content, and then the client-side code takes over to handle changes with no refreshes. If the client is written in a different language than the server then you have to maintain two versions of the page code to achieve this, and they have to be in perfect sync. Hard to do. Easier to write the code once and transpile to JS for the browser (or write the back end in JS).

michaelmior 10y ago
Not necessarily. You can use something like Prerender[0]. [0] https://github.com/prerender/prerender https://github.com/prerender/prerender
- marcus_holmes 10y ago
  but... that only renders JS... which is what the client speaks, so the client and server still speak the same language
  - michaelmior 10y ago
    Your backend can run whatever language you want. There are examples right on the page that show integration with Rails, PHP, Go, and others.

mariusandra 10y ago

I find a lot of value in using a different programming language for backend and frontend code. The context switch between the languages brings with it an awareness of the security implications of everything you write. Plus you are a first class citizen in each world. Thus: * Ruby code = private methods that nobody else can see * Javascript code = public methods that everybody can peek into Once you solve the "how do I pass data from ruby to javascript and vice-versa" question, this mental model holds up quite well. (My own solution to this question is this project: https://github.com/mariusandra/kea-on-rails https://github.com/mariusandra/kea-on-rails , featuring server rendered react views (via react-on-rails) and seamless passing of data back and forth... but it might not be the best approach for your projects)

zem 10y ago

i think this is in part driven by the fact that javascript is not the best tool for the job on the client side, so people fall back on a variety of compile-to-js languages. but then, once you're doing that, why not use a language you already feel is good enough to be your choice of server-side languages? the leap to "okay, now that we're using the same language for both parts of our app, why not make a framework that lets you mix server and client side code in the same codebase" is more a taking that idea to its conclusion than the primary motivation for it.

catmando2 10y ago
Amen and well said!
coltonv 10y ago
I disagree because I do find JavaScript to be the best tool for client side development. You get full access to the DOM without worrying about your transpilers abstractions. Also I think JavaScript is a pretty wonderful language to code in once you apply a strict linter + Babel.

k__ 10y ago

I had the feeling this doesn't change anything. As companies grow they simply start using the same languages over and over, without any concern if they are the best tool for the job. With one language on client and server you get at least code reuse, if you modularize your stuff nicely.

hiou 10y ago

There is nothing more miserable than working with a team that cannot and/or is unwilling to work with anything but their language of choice. But honestly this typical goes even deeper than language. Its often difficult to get a team to work with something outside of the framework they are used to. Even if it could take 3 times as long or even is just flat out impossible without it. In my experience it has everything to do with developers who like to feel under control and feel really uncomfortable if they are not the smartest person in the room.

catmando2 10y ago

at catprint we are using reactrb (now ruby-hyperloop) to clean up our mess of ruby + JS + HTML + ERB + HAML etc. So far the results have been excellent with a reduction from about 70K SLOC to 35K SLOC. Some of the other advantages: A common tool chain, including testing (we are using rspec), people don't align themselves as front-end vs. back-end developers, easier training for new hires. Point taken about choosing the "right tool for the job", however there is nothing in JS that makes it a better tool than ruby. In fact I would argue (but it is opinion) that ruby is a far better tool than JS. So why not use ruby for full stack? If I felt that somehow JS was better than we would have worked towards using Node for a full stack solution. Of course its not just the language, its language + available libraries and tool chain. In that regard Ruby is far superior.