Volt: A Ruby web framework where your Ruby runs on both server and client

by senorgusto • 12 years ago

279 60 12 years ago

desireco42• 12 years ago

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.

robertk• 12 years ago

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) into an interactive webpage (http://therobert.org/finite_fields/). It would be just as trivial to do with Volt.

manojlds• 12 years ago

Just to make it explicit - Volt makes use of Opal.

roundpizza• 12 years ago

So why not just use JavaScript to begin with?

PaulRobinson• 12 years ago

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.

nightpool• 12 years ago

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• 12 years ago

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

https://news.ycombinator.com/item?id=8287700

alttab• 12 years ago

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• 12 years ago

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.

bratsche• 12 years ago

Clojure + Clojurescript come to mind as well.

KaoruAoiShiho• 12 years ago

This is the holy grail. Investigation begins...

snitko• 12 years ago

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.

sergiotapia• 12 years ago

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• 12 years ago

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

brogrammer90• 12 years ago

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

ChristianBundy• 12 years ago

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.

Chris9112• 12 years ago

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

ryanstout4• 12 years ago

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)

Chris9112• 12 years ago

Cool. Thanks for answering here. Great project I will surely give it a try at some point.

bglusman• 12 years ago

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 :-)

juanplusjuan2• 12 years ago

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.

glesica• 12 years ago

The interesting thing here is not that Ruby runs on both the client and server. The interesting thing is the client-server data synchronization, at least that was my perception having seen a talk on this a few months ago.

Igglyboo• 12 years ago

Yep I'd have to agree. While I'd rather use meteor for this task since it's native javascript on both ends, the killer feature for meteor is really the data binding across the client/server gap and not the ability to write js in both places.

ryanstout4• 12 years ago

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

juanplusjuan2• 12 years ago

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!

Kequc• 12 years ago

You aren't completely alone a lot of people love Ruby and it's easy to see why. But it isn't the right tool for the job when you're talking about actions on the client, this has caused tension as client side development on the web has exploded.

There are many who wish to continue using Ruby.

I think people should take the opportunity to learn new tools like Meteor. Then come back when for example Ruby really can run client-side. Or with any luck a totally new language, something unlike Dart (which is just another javascript abstraction) comes along.

thinkpad20• 12 years ago

Dart isn't just another javascript abstraction. It has the option to compile into JavaScript, but so do many other independent languages, like Scala, Clojure and Haskell. It is its own language, with a VM, spec, an independent set of libraries, etc. This as opposed to for example CoffeeScript, which is purely (and intentionally) a JavaScript abstraction.

That said, my personal wish would be a language-agnostic virtual machine (or where the only "language" is that of the virtual machine itself) for the DOM, with a well-defined standard that could be implemented by different browsers. This would allow a lot of performance optimizations and remove the need for JavaScript to be a compile target. Instead, JavaScript would simply be one of a number of languages which target this VM.

whistlerbrk• 12 years ago

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

willsulzer• 12 years ago

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.

imslavko• 12 years ago

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

(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• 12 years ago

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.

tazjin• 12 years ago

Sounds like rubish to me.

abdullin2• 12 years ago

This reminds me of Lazo.js from Walmart labs (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• 12 years ago

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

chadcf• 12 years ago

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.

thomasfl• 12 years ago

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

consultutah• 12 years ago

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

mattangriffel• 12 years ago

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

vidarh• 12 years ago

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)

dstarh2• 12 years ago

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

obsurveyor2• 12 years ago

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.

ryanstout4• 12 years ago

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.

jguimont• 12 years ago

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.

mark_l_watson2• 12 years ago

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_watson2• 12 years ago

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

netghost• 12 years ago

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• 12 years ago

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• 12 years ago

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.

segphault• 12 years ago

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

beginrescueend• 12 years ago

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

Volt: A Ruby web framework where your Ruby runs on both server and client

Related Stories