
Hyperloop – The Missing Ruby Front-end Library - geordee
http://ruby-hyperloop.io
======
coltonv
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?

~~~
zem
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.

~~~
coltonv
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.

------
gonyea
Oh sweet jesus. This is erector all over again.

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.

~~~
gleenn
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.

Edit: spelling and minor changes

~~~
gonyea
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.

~~~
gleenn
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.

------
colordrops
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.

~~~
gaius
The Ruby community excels at cute but meaningless naming.

~~~
olivierlacan
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.

That must be what you mean.

------
vinceguidry
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.

~~~
catmando2
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.)

------
ericb
What an unbelievably negative group of drive-by comments for something I think
is pretty impressive.

~~~
prxi
It's much easier to tear down what others have built instead of building
something yourself.

------
evolve2k
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?

~~~
mhw
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]

[1] [http://ruby-hyperloop.io/tutorials/showcase/#using-
reactrb-r...](http://ruby-hyperloop.io/tutorials/showcase/#using-reactrb-
reactive-record)

[2] [http://ruby-hyperloop.io/tutorials/showcase/#synchromesh](http://ruby-
hyperloop.io/tutorials/showcase/#synchromesh)

[3]
[https://github.com/reactrb/synchromesh#transports](https://github.com/reactrb/synchromesh#transports)

------
michaelmior
Can mods fix the typo in the title?

------
raitom
As a Ruby AND react developer I'll definitely try it.

------
daenney
Though it's great to see these kind of efforts why did you pick a name that
seems bound to cause discoverability and visibility issues?

~~~
catmando2
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!

~~~
daenney
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.

------
yefim
You were so busy wondering if you could do it you never stopped to ask if you
should.

