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?
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.
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.
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 , 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)
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.
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.
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).
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.
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.
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.
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.
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.
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.
The code inside the blocks are uncacheable; it's an expensive novelty. Plus these abstractions always break down. Our job is to build products that meet people's needs. Not to contort solutions into our preferred form, at the expense of the product.
I'm pretty sure that the examples with Ruby code embedded in the HTML document are primarily intended as examples rather than as a template for production deployment. They seem to use Reactrb Express (http://ruby-hyperloop.io/gems/reactrb-express/) to perform the Ruby->JavaScript compilation in the browser. For production use this would be done as a build step to produce a compiled JavaScript file that you can include in Rails' asset pipeline (for example - see http://ruby-hyperloop.io/tutorials/showcase/#step-3-webpack-...).
I don't necessarily disagree with your other points, but I think this looks like it's reasonably well put together. If it works well the ability to reuse Rails models on the client might be handy for example.
> Not to contort solutions into our preferred form, at the expense of the product.
A lot of this depends on your starting point (what you already know) and what you have to deliver with the resources you have available. Sometimes building and using abstractions that increase a team's leverage is the right approach for the product, even if it's a limited tactical step rather than a strategic direction.
I'm a happy user of Fortitude which is the real successor to Erector. I find it delightful to use over any of the other common templating languages like Erb or Slim, etc. I consider myself as having seen a large breadth of Rails apps over the years and can count on probably less than a hand how many times I needed caching. As a plus, it is the fastest rendering library available meaning you get a little perf for free everywhere (emphasis on small, and definitely not the reason I choose it). It may be a limitation, but Rails let's you use multiple templating libraries simultaneously so if some page is really that performance sensitive, nothing is stopping you from switching to a cacheable one. As always, right tool for the right job.
I'm honestly not so sure I'd accept it as the "fastest rendering library" for a variety of reasons:
- micro-benchmarks are really good at telling you the story you want to hear.
- profiling erector revealed that it placed a lot of pressure on the garbage collector. This was back when it too was the "fastest templating library." Micro-benchmarks won't really tell that story.
Other issues:
- blocks are a good abstraction until they aren't. No doubt backtraces are better than with erector. This was seriously traumatic to debug, templates were a gigantic ball of mud.
- "_I_ don't need caching" isn't a counter-argument. The reality of using blocks to nest elements is that the boundary between "cacheable, static content" and "dynamic stuff" is indistinguishable.
It's not like caching is turned off in erector (or fortitude). People were constantly making changes to templates, shipping them, and having changes not show up because memcache isn't running in development.
You COULD try to argue that it's the same problem in erb or slim, except it mostly isn't. When ALL your code is ruby code, seeing the "cache below this line" is a lot harder.
I knew I was asking for trouble mentioning the perf thing. Let me roll that whole argument back.
The reason I use Fortitude (and love it) is that writing loops and conditionals and extracting methods or variables is trivially simple, you get great IDE support. It's just Ruby. And it is remarkable easy to write, factor, reuse chunks of code, import modules, etc. You can do all these amazing code-like things because it's code. Not some weird DSL that requires an extra parsing step (both mentally and on the comp) or you have to remember to add the equals sign so that it prints etc etc etc.
I think it is incredibly relevant that I haven't used cacheing much, I lose that with Fortitude but I don't care 98% of my day. Maybe y'all work on ridiculously performance intensive codebases, but there are so many other things slowing you down like the DB, or I/O, etc. I'd happily prefer to tune my db, prune some n-queries, etc than go trying to get silly Rails template-cacheing right. It is so error prone it's ridiculous.
Use Fortitude for the perks, not the missing feature that is incredibly painful to get right.
Is no one going to mention the Hyperloop name? The repo for this project was created Aug 2015, over two years after the SpaceX Hyperloop announcement. Seems like a really poor choice in naming both in creativity and in search keyword collision. I wonder what other poor decisions were made when building this library.
I think you mean the Ruby community excels at memorable and often witty naming for libraries that makes searching for documentation, blog posts, and other references extremely easy because "ruby <very unique name>" doesn't ever return more than a few irrelevant results.
First off, I started moving away from DSLs awhile ago. Syntax and semantics are not something you just bolt on to code. I don't care for JSX, but I like the idea of building HTML with Ruby even less. It can be done but I'd much rather just use a templating system. JSX is an ugly hack but I hate it less the more I work with it. I just use a convention to only put it in render methods and to have render methods only contain JSX. If you do that then JSX isn't so bad.
Second, React is maintained by Facebook. This project is not. If you're greenfielding an app and you base it on this framework rather than real React, then you better hope the app goes EOL before the framework maintainer decides to move on, otherwise you're SOL.
the reactrb ruby-dsl is built on top of React.js. Its not a huge piece of code (no bigger than many many other ruby gems people rely on, on a daily basis.)
I'm a Rubyist currently working with react & redux, I've found the issue for me wasn't the complexity of react but rather the client side data store, aka redux. Can you support redux or how are you handling this otherwise?
It looks like they're handling it with Reactive Record[1] and Synchromesh[2]
> Reactive Record compiles your Active Record models so they are accessible to the front-end and implements an API based on your models and their associations. Lazy loads just the data that is needed to render a component and is fully integrated with Reactrb and paired with Synchromesh to push database changes to all connected clients. ReactiveRecord and Synchromesh give you Relay + GraphQL like functionality with a fraction of the effort and complexity (the original idea for Reactive Record is credited to Volt and not Relay).
They're planning to support Synchromesh pushing updates to clients over ActionCable channels when the whole stack supports Rails 5. [3]
Great question. We have played with a bunch of different names. As soon as we changed to hyperloop our visibility shot way up. We are not convinced that its the perfect name, but so far it has really helped generate interest!
Ha, interesting, I wouldn't have guessed that. Could you elaborate a bit on how you tested and measured it? Would be useful to know for the next time I try to name a thing.
