
Volt: A Ruby web framework where your Ruby runs on both server and client - senorgusto
https://github.com/voltrb/volt
======
willsulzer
I'd have to say this is very exciting, and something that from which the Ruby
web community could benefit greatly. Having the boiler plate cases covered for
data binding and synchronization across the client and server could really
increase productivity for modern web application. For anything else that
doesn't fit that mold, a developer could always degrade to using their front
end framework of choice with Websockets or AJAX back by REST APIs where
appropriate.

------
robertk
Opal is a really neat gem for translating Ruby to JavaScript. For those who
know some math, I used it to convert some Ruby code I had written to perform
finite field arithmetic
([https://github.com/robertzk/FiniteFields](https://github.com/robertzk/FiniteFields))
into an interactive webpage
([http://therobert.org/finite_fields/](http://therobert.org/finite_fields/)).
It would be just as trivial to do with Volt.

~~~
roundpizza
So why not just use JavaScript to begin with?

~~~
PaulRobinson
Because Javascript is a horrible language to code in and debug.

If you're a Ruby programmer, you don't need to learn a new language, and you
can have confidence that the Opal guys have looked after a lot of the issues
you're not experienced enough to understand.

Your question is like asking a C programmer "why not just use assembler?" or
an assembly programmer "why not just toggle 1s and 0s in, because ultimately
your code is going to get turned into binary eventually, right?"

Abstractions and different models of describing a problem solutions are
helpful for a multitude of reasons.

~~~
eyko
It has been my experience that JavaScript is a high level language.

In this particular case, Ruby is not being compiled to JavaScript but being
transpired.

~~~
dragonwriter
> In this particular case, Ruby is not being compiled to JavaScript but being
> transpired.

First, "transpiled" not "transpired".

Second, "transpiled" is a special case of "compiled", so you can never
correctly say that something is _not_ being compiled but _is_ being
transpiled, in the same way you can't say something is _not_ a rectangle but
_is_ a square.

------
sergiotapia
This is the interesting bit for me personally:

Instead of syncing data between the client and server via HTTP, volt uses a
persistent connection between the client and server. When data updated on one
client, it is updated in the database and any other listening clients. (With
almost no setup code needed)

\---

In .NET land, I used SignalR when it first came out and it has since been
baked into ASP.Net.

In Rails, I use Pusher, a paid for service because it's just easy to use and
iterate.

If this works like it says on the tin I am excited! Beyond excited! My one
question though is how many users can it support? How many people can be
'listening' for a broadcast.

~~~
NicoJuicy
SignalR is not really baked into Asp.Net, it's only a gem (=Nuget Package)
away though.

------
thomasfl
The persistent connection makes volt a promising alternative to meteor. I
guess I can't run pry debugging sessions in the browsers javascript console?

Server generated Javascript has come a long way since it was introduced in
Rails, abandoned and then reintroduced again with opal. DHH wrote about opal
one year ago [https://signalvnoise.com/posts/3697-server-generated-
javascr...](https://signalvnoise.com/posts/3697-server-generated-javascript-
responses)

------
juanplusjuan
What's the problem that this framework is trying to solve? I can't imagine
that Ruby code will correctly compile into every possible use case for
JavaScript. Even if it does I won't be able to leverage any gems, which is the
real power of a mature server side language. It seems like this is just a
crutch for Ruby web developers to use a familiar syntax and avoid learning
JavaScript, which seems valuable if you want to do anything beyond a basic web
page.

Please tell me if I'm missing something. I'd genuinely like to know.

~~~
ryanstout
I'm the lead developer on Volt. The goal here isn't to keep people from
learning JS. I've been doing JS development since long before I found ruby.
Just some thoughts on it I had been working on for a blog post:

In web development today, JavaScript gets to be the default language by virtue
of being in the browser. JavaScript is a very good language, but it has a lot
of warts. (See [http://wtfjs.com/](http://wtfjs.com/) for some great examples)
Some of these can introduce bugs, others are just difficult to deal with.
JavaScript was rushed to market quickly and standardized very quickly. Ruby
was used by a small community for years while most of the kinks were worked
out. Ruby also has some great concepts such as uniform access, mixin's, duck
typing, and blocks to name a few. While many of these features can be
implemented in JavaScript in userland, few are standardardized and the
solutions are seldom eloquent.

Uniform access and duck typing provides us with the ability to make reactive
objects that have the exact same interface as a normal object. This is a big
win, nothing new to learn to do reactive programming.

\--

Also, just as a side note, Opal does a great job of compiling ruby to JS. The
code is easy to understand, supports source maps so chrome for example can
bring up your ruby code in the console and show line numbers in the ruby code.
While many gems won't work without some porting, a lot do. Opal currently runs
rspec (a very complex ruby project) with only a few patches. Really though,
typically front-end solutions do different things than backend solutions.

~~~
juanplusjuan
Cool-- thanks for the responses. I agree with the issues in JavaScript, but
I'm not sure I see them as justifying a new web framework. For example, the
Math.max() boolean behavior is simply the result of treating true and false as
1 and 0, which isn't unique to JS. Blocks are a type of closure (which JS
supports) and there are ways to achieve multiple inheritance and even mixins
as well.

That said, the larger point seems to be that data synchronization is the
biggest benefit. If you can write a model once and have JS objects
automatically created that'd be a good start. I'll have a look to see what
other capabilities are there. The HTML rendering when a URL is called directly
could be particularly powerful.

Thanks!

------
mark_l_watson
I like Meteor, which seems to be similar except that Meteor also supplies a
synced datastore (MongoDB on the server and a light weight equivalent in the
browser).

I will definitely try this out, especially since I have already played with
Opal (used in Volt).

~~~
mark_l_watson
One day later: I had time to try Volt, and I really like it.

------
brogrammer90
Very cool! Would it be safe to say Volt is Ruby's Meteor?

~~~
ChristianBundy
Absolutely. I haven't contributed to Volt, but I've lived Meteor for the past
year or so. Volt looks like an interesting option, to say the least.

------
netghost
Just out of curiosity, I noticed that mongo is used in all the demos, and
seems to be the only DB supported.

Any thoughts on how or whether this would be support other backends like redis
or more traditional sql databases like postgres and mysql?

~~~
lkrubner
Handling complex JSON documents is not easy with traditional sql databases
like postgres and mysql. My team just got done building a large site with
AngularJS, and using MongoDB (or any document store) allowed us an easy way of
saving denormalized JSON documents. If you have a JSON object that contains an
array of other objects, and each of those objects has arrays of other data, so
you have a complex document that is 4 dimensions deep, with MongoDB (or any
other document store) you simply put the document in the document store, but
with MySQL or PostGre you would break that document up and store it in normal
form, which means breaking it up into at least 4 database tables, maybe more.
That is a lot more work and, crucially, that is much more likely to be
impossible to automate. The code can not automatically know what deeply nested
array of objects maps to some database table. The requirements for automatic
normalization go beyond the features of your normal ORM.

There has been an explosion of these systems lately that automate the
synchronization of frontend and backend. As far as I know, they all rely on
document stores such as MongoDB.

~~~
karmajunkie
Mongo may be the right call for your team, but just as an aside, the use case
you're describing is perfectly doable with Postgresql using either text
columns or json columns, and moreover, table denormalization is just as much
of an option for relational users as for document store users.

------
nightpool
Wow, as someone who hates JS and loves the server-side, this looks really
really cool. I might have to learn Ruby just to try this.

~~~
laumars
There was discussions last week of compiled C++ being used on the client side
too:

[https://news.ycombinator.com/item?id=8287700](https://news.ycombinator.com/item?id=8287700)

------
segphault
"If the user hits a URL directly, the HTML will first be rendered on the
server for faster load times and easier indexing by search engines."

If I'm understanding this right, it sounds like an incredibly cool feature.
Being able to use the same templates for both server-side rendering and a
client-side SPA-like experience would be a huge win.

------
KaoruAoiShiho
This is the holy grail. Investigation begins...

------
alttab
I would like to reach a point in web programming where JS, or something that
eventually compiles into JS doesn't have to be written or maintained
explicitly. GWT comes to mind, and this does something similar with Ruby it
seems. Interesting take for sure...

~~~
iLoch
There's plenty of flavors of JS that compile into regular JS. Pair that with
Node.js and you've pretty much got what you're asking for. There's plenty of
people using CoffeeScript on server + client, for example.

------
imslavko
Very interesting! I am interested in how data synchronization works. What data
stores does the ORM currently support (my guess is mongodb so far)? How was it
implemented? Would it work with multiple servers? I am not proficient in Ruby
code, reading some code didn't give me a lot of information :)

[https://github.com/voltrb/volt/blob/master/lib/volt/models/p...](https://github.com/voltrb/volt/blob/master/lib/volt/models/persistors/model_store.rb)

(edit: I probably need to note here that I contributed to a similar part of
Meteor, that has data-sync to persistent storage too)

~~~
marknadal
hey, I do all sync stuff too, shoot me an email (you don't have yours listed
in your profile), I have some pretty interesting solutions and I would like to
compare notes.

------
jguimont
Looking at this, it seems something that sits between the view (html) and the
controller (data) would be needed. I understand the reactive html is used for
now, but that would not work for complex UI interactions.

------
abdullin
This reminds me of Lazo.js from Walmart labs
([https://github.com/walmartlabs/lazojs](https://github.com/walmartlabs/lazojs)).
That is also a client-server framework with code shared between client and the
server. Although Ruby is obviously harder to share, than JavaScript.

~~~
clubhi
I'm sure Walmart labs is no joke. I can't think of a worse word association
though.

~~~
chadcf
You realize it is walmart right? There is no bad word association. Any company
the size of walmart, regardless of how you feel about their core business, is
likely doing some cool things with technology.

~~~
abdullin
LazoJS is quite nice. It is definitely more polished than RendrJS from AirBnB
(equivalent framework for building SPAs that have fast first page load and are
SEO-friendly).

------
consultutah
Kind of funny that you selected a name so similar to Microsoft's attempt at
doing the same with .NET:
[http://en.wikipedia.org/wiki/Microsoft_Live_Labs_Volta](http://en.wikipedia.org/wiki/Microsoft_Live_Labs_Volta)

------
Chris911
Why is this "released" now? The projects seems to be semi-dead (only a couple
bug fixes since last April) [1].

[1]
[https://github.com/voltrb/volt/commits/master](https://github.com/voltrb/volt/commits/master)

~~~
ryanstout
Chris, I'm the main developer. So I haven't pushed much because I have been
doing a big refactor on the reactive stuff and did get a little side tracked
with some other stuff. The refactor is almost complete (400+ commits that
should be out next week or the week after). From there there's just a few more
things let and I think it will be ready for people to start building on.
(After that I'll need to do a bunch of tutorials and videos)

~~~
bglusman
Awesome, though why wait to push commits? Just put in a branch people can play
with/watch until it's ready to merge to master or whatnot. Dunno if I'll have
time but I'd love to play and see where it's going, much easier if latest
stuff is online and visible :-)

------
desireco42
Just idea of it, I like it. I am big fan of JS and think it has great future
on both sides, but just on initial description of this, I really like it. I
will try to give it a spin in next few days to have a more realistic
experience. Thanks for making it.

------
beginrescueend
How does something like Phonegap / Apache Cordova fit in to VoltRB?

------
dstarh
Reading over the source on the example apps, the first thing that jumps out at
me is _underscore _prefixed _variables and it just looks odd in ruby,
especially with :_symbols

~~~
obsurveyor
Yeah, it looks like a Python refugee's code or something. I also don't like
the .cur name that you have to use everywhere. It's not descriptive enough by
itself. I wonder why .value wasn't used as the obvious choice.

~~~
ryanstout
obsurveyor, I'm the lead developer. I've been doing ruby forever. The .cur is
going to go away, along with .or and .and I'm in the middle of a big refactor
of the reactive stuff to simplify all of that.

~~~
dstarh
Then why the _'s everywhere, ruby is snake case but I don't think I've ever
seen anyone do :_foo => "bar" or _foo: "bar"

~~~
ryanstout
So the models in volt basically let you read and assign attributes with an _
We could use the model[:key] instead, but the nice thing with using _ is that
you can then define your own getters and setters easily in the model class.
The _ is sort of a quick prototyping tool, allowing you to start using
attributes without defining them in the model. We're going to add it where you
can say something like:

model_attr :field_name, String

then do:

model.field_name = 'something'

(without the _)

The _ keeps people from calling a method that isn't defined, since ._something
will return nil if its not defined yet. But if you called .something, it will
still raise an exception.

Does all of that make since?

~~~
obsurveyor
That sounds ripe for misuse and kind of schizophrenic with the different
behavior based on the name of the attribute. You should pick one
behavior(throw an exception) and apply it everywhere. If you want quick
prototyping features, then make that something you include with a gem or
something, don't let it infect the framework.

------
mattangriffel
This may be an ignorant question, but why not use the <% %> syntax popularized
by ERB instead of { } for view bindings?

~~~
vidarh
Handlebars/Mustache syntax is also widely used. And <% %> might very well
confuse people into thinking the contents is raw code, as opposed to
handlebar-style directives.

(Handlebars/Mustache restrict what actions you can take on view data
substantially - you have to explicitly expose functionality in most
implementations)

------
whistlerbrk
I was just talking about wanting something like this the other day. Wow, this
is great.

------
tazjin
Sounds like rubish to me.

------
snitko
This thing would be million times more useful with Dart, which runs both in
the frontend and the backend and is a stable language with some rich features.
Still, a move in the direction though, I like it, but I think I'd never use
this.

