* 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.
We don't need to share everything
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 , 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)
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.
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.
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).
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.
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.
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.
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.
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.