Aston J

Ruby is about to get red hot. Again.

Posted on: October 30th, 2014 by AstonJ 60 Comments

Widely regarded as the language of the web, Ruby’s always been pretty damn hawt. But now it’s about to get even hotter. AltRubies have been pushing Ruby into realms we never thought possible. Is Ruby set to become the preferred language of the browser? Of mobile apps? Of hardware, even? Let’s take a look at some of these alternative Rubies and the exciting things they bring with them…

Ruby in the browser, thanks to Opal.

One of the biggest shifts I’ve seen in the last year or so is towards dynamic front ends – spearheaded by JS frameworks such as Angular and Ember. As nice as these might be, there’s one thing you just can’t escape when using them – Javascript! As a Rubyist, I am sure you’ll agree that JS (or even CS) doesn’t quite cut the mustard. It simply doesn’t possess the panache – that special something – that many of us feel Ruby does.

Opal lets you write Ruby that compiles to Javascript. Yep – this means you can now write Ruby that runs in the browser! Opal also has a number of gems that extend it, such as Opal-jQuery and Opal-Vienna (the latter being a front end, Backbone-style library). But this is just the beginning.

Opal is now paving the way for new Ruby frameworks that run on the front end, or even the front and back end, and I’m hearing a lot of buzz around how Opal is one of the hottest things in Ruby right now and is set to play a big part in its future. I agree, and we’re only just starting to see why…

Ruby on the back AND front end! Thanks to Volt!

Volt is an exciting new Ruby framework that runs on the front and back end, and even has plans to integrate with RubyMotion further down the line.

Volt is a reactive framework, meaning it creates a persistent connection between the client (the user’s browser) and the server, and when data is updated in one client, it propagates – if you want it to – to all other listening clients (with the option to update your database in the process). Welcome to the world of real time apps (RTAs).

volt

When Volt did the rounds in the Ruby media recently, unsurprisingly it generated a heap of interest – before it was remotely ready for prime time! This, however, has turned into a blessing by allowing early feedback on many of its features – something the Volt team have been listening and reacting to. One such feature is adding a user and auth system into the core framework – a stellar move in my view.

I really like how Volt embraces cutting edge web technologies and methodologies: declarative HTML, web components, websockets and of course Ruby on the client side. They’re also adding RethinkDB support – a new database that is also rumoured to become big in Ruby.

Of course Volt isn’t just for RTAs, but I’m sure we’ll all be thinking of creative ways to add a little real-time sparkle to our sites! I’m excited to see what everyone is going to do with it. Oh, and if you’re worried about the initial lag often associated with sites running front end JS frameworks, don’t – Volt is concurrent, meaning it’ll render the first page a user hits on the server, making it lightning fast.

Ruby on your iOS, OS X and Android devices – thanks to RubyMotion.

If you are a Rubyist then you are probably already familiar with RubyMotion, so I won’t go into the details here – but if you’re facing the same RubyMotion vs Swift dilemma that I was, here’s why I’ll be learning RubyMotion:

  • RubyMotion lets you create native iOS apps – so the code you end up with is just as optimal as the code had you used Objective C.
  • RubyMotion lets you create OS X programs as well.
  • RubyMotion now allows you to do the same with Android apps. This, I think, is killer, because it’s something you can’t do with RubyMotion’s most compelling alternative, Swift.

There are lots of other reasons too, but the main reason for me is our old friend Ruby. While you still need to learn the associated frameworks, Ruby is there for the rest of it… allowing you to write mobile apps in the language you know and love. And if you do ever decide to move to Swift, none of the time spent learning the Apple frameworks is wasted, because you take that knowledge with you.

Ruby in embedded systems, thanks to mruby.

This it Matz’s own little baby. Little being the operative word! It’s tiny, and that’s the whole point – to make it lightweight enough to use in embedded systems (hardware). Thanks to its C99 compliance it is extremely portable, yet manages full compatibility with Ruby 1.9.

Matz thinks it will create the same sort of buzz in embedded systems, as Ruby (and Rails) did for the web. I reckon he might be right.

Rails is ten years old!

I can’t not mention Rails in a post about Ruby being cool. Rails is the killer app that got Ruby off to such a great start, arguably, making it so cool to begin with. In fact it’s probably true to say that Rails was the original ‘Cool kid’ on the programming block.

With Rails 5 on the horizon, it will be interesting to see where DHH and the core team take it. I personally hope they ditch Coffeescript in favour of Opal, otherwise they might find Volt steals some of their thunder. But what do I know – perhaps they have something else up their sleeve. (As we saw with Turbolinks, they often do!)

Maybe, just maybe, they will set Rails on Fire…

Let’s turn up the heat.

So as we’ve seen from the above, Ruby’s about to get piping hot. But there’s one more thing to share with you. Ruby Fire.

Fire

Although Fire is currently in conceptual stage, it’s definitely something worth getting excited about – a front end framework allowing you to create your frontends in Ruby easily. It’s being brought to you by the same team behind Opal (and Vienna – the Backbone style front end library) so they know a thing or two about Ruby on the client-side. It’s being designed for use with your favourite framework on the back end, making it perfect for bringing our current apps slap bang up-to-date without having to abandon so much of our existing code.

The team behind Fire say they plan to include quite a bit of ActiveSupport, making it a perfect fit for Rails. I’d actually love to see Rails officially adopt Fire – a match, quite possibly, made in heaven. I reckon this move would single-handedly catapult Rails back to where it belongs – at the cutting edge.

Fire will be focused on the very latest best practices in front end development, selecting the best methodologies currently out there, and Rubyfying them. The current client-side frameworks better watch this space!

In short, Fire is Ruby’s answer to Angular and Ember – so if you’ve been yearning for a front end Ruby framework, then Fire might well be just what the doctor ordered. I genuinely believe that it, along with Volt, really will help Ruby set the wwworld alight again.

This is only the beginning.

This is an exciting time for Ruby. Thanks to the power of AltRubies, you can now do in Ruby what you would otherwise have had to do in languages that you may not have been very fond of (that’s me putting it politely :p).

While RubyMotion and mruby are courageously (and actually, quite effectively) taking on big new adversaries, I think both Fire and Volt are going to be pivotal in Ruby’s continued success as the language of the web. And guess what? You can be a part of it.

Join the discussion in the respective Gitter channels or use the hashtags #RubyFire and #Voltrb on Twitter …you really can help shape, and secure, the future of Ruby on the modern web – this time, from the very beginning.

Want to see more posts on Volt and Fire? Let me know in the comments below or tweet me!

Tags: , , , , ,
  • googya

    ruby rocks!

    • Enda Rochford

      Gems my friend

      • Joe Seeley

        Indeed. rocks are for Lua.

      • Cyle Hunter

        Minerals!

  • DFYX

    I guess most of the things you linked (apart from Rails of course) still need a little time to become production ready but I’m always excited about new ruby-based stuff.

  • http://estebanrules.github.io estebanrules

    I’ve been interested in trying out Volt, never heard of Fire. I wish there was a bit more concrete information about what “Fire” is exactly.

    • http://astonj.com AstonJ

      In short, Fire is Ruby’s answer to Angular and Ember :)

      • http://estebanrules.github.io estebanrules

        Yes, that’s what I was thinking ;). I’ve been getting into Angular a lot lately. I haven’t tried using it in Rails yet (though I plan to). I suppose I would use Fire over Angular if it can compete…Angular is a pretty solid framework with a huge community.

      • ylluminate

        Yeah, that’s good to hear b/c over nearly the last year now we’ve been just using Opal straight and it’s been quite a joy. Seems like a lot of potential here! Volt certainly had me excited, but when I took a peak a few months ago it just wasn’t ready for digging in yet with our current needs.

        • http://estebanrules.github.io estebanrules

          You’ve been using straight Opal in production for the last year?

          • ylluminate

            We have been using Opal quite a bit yes. It is / has been in production apps and we are building a rather large app at the moment with Opal replacing effectively all JS in this Rails app. We’re also dabbling in it with game creation at the moment.

          • http://estebanrules.github.io estebanrules

            Wow, that is very cool ;)

          • ylluminate

            Yeah, we’ve used it from time to time, but honestly it never really felt “right.” The thing that really captivates us is being able to use a singular language across the board. It lends a lot of power and synergy when you can look through the lens of a singular language in my opinion. Sure, it’s great to learn other languages and change up your paradigm, but as a project manager you want to get things done and for everyone to be able to communicate. That’s why Opal really shines IMO.

        • Matthew Blott

          I tried about three or four weeks ago and that was still the case. The plan is to have it ready mid November but I’m not sure how likely that is.

  • donlpowers

    “Widely regarded as the language of the web”

    Uhhh….no

    • the_truth
      • http://estebanrules.github.io estebanrules

        This made me “lol”:

        “PHP was originally designed explicitly for non-programmers (and, reading between the lines, non-programs)…”

      • Tomasz Kowalczyk

        People should be punched in the face for even mentioning Fractal as a representative criticism. Yeah, PHP sucks as a language, but you need to work harder to rant on it so that PHP programmers won’t simply laugh it off.

    • http://estebanrules.github.io estebanrules

      Yeah I was just going to say…I love Ruby, but we all know JavaScript is “widely regarded as the language of the web”.

      • Matthew Blott

        Reckon so :-)

    • genericid

      it must have been a real pain to go throughout all this article for you, isn’t it?

  • bmo

    don’t forget JRuby too!

    • genericid

      And Ruboto!

  • ylluminate

    Well DHH did raise his head when I mentioned the work that was done on Opal-ActiveSupport. That seemed to really change his tone and I think there’s some real opportunity there.

    • http://astonj.com AstonJ

      Have you got a link to that conversation? Would be interested to see what he said :) @ylluminate:disqus

  • Ruby r gud

    Aw yeah, now I can litter everything with that nasty “end” keyword. I love Ruby!

    • Ben Coullie

      Ever heard of HAML? It’s the end of ‘end’.

  • Turd Burglar

    Guys, Tim Cook finally come out of the closet today, we can now stop pretending we love ruby so much and get back to real frameworks like C#.

    • Matthew Blott

      C# isn’t a framework, it’s a language. Mono and .NET which C# targets are frameworks.

  • Jon Forrest

    “JS frameworks such as Angualr” ->
    “JS frameworks such as Angular”

    • http://astonj.com AstonJ

      Ooops. Thanks, fixed.

  • luke bickle

    Hi AstonJ,

    Great blog! I have followed from a distance for awhile as a Junior dev.

    Your story was flagged and “killed” on HN. I have posted it again to make sure that it gets a second chance and thought you may want to respond to a future thread (or would be happy to delete it –if you have a preference).

    I will check your blog back for a response.

    Keep it coming!

    Luke

    • http://estebanrules.github.io estebanrules

      Why exactly would it be flagged?

      • luke bickle

        Not sure exactly. There were about ten comments. I copied/pasted the link to an Evernote file. 15 minutes later it was “flagkill” ed.

    • ylluminate

      What’s the link? Can’t find any hits with an opal search there…

      • luke bickle

        I added “opal” — “Volt” to the title, so you can check again if you care.

        • ylluminate

          Got it. Thanks.

    • http://astonj.com AstonJ

      Why would they kill it? I’m quite happy for you to post it – thanks! :)

      • ylluminate

        I’m sure it’s the JS purists. : I’ve had OpalRB ridiculed time and again by such folks over the last several months. It’s going to take some time for people to accept it unfortunately it really seems.

        • http://astonj.com AstonJ

          Ah right. I guess they’ll have to get used to it – Opal/Volt/Fire is to the browser what RubyMotion is to iOS devices..

          • ylluminate

            Agreed.

      • luke bickle

        There were maybe 5 negative comments specifically about your comment that maybe Ruby might be ” the preferred language of the browser” and a couple comments for PHP.

        Crazy to “flag” a comment because you have a different opinion!

        • http://astonj.com AstonJ

          Oh k. Negative comments are fine – they can be challenged. It’s the childish one’s that can’t ;)

  • ferdinandrosario

    Great to know some new projects in Ruby. Thanks for sharing the info.

  • jbrodriguez2

    it’s not going to get red hot again … dependency hell liability HAS to shift to the developer rather than the end user.

  • pmccann

    Ruby is beautiful, and using Rails can be a lot of fun, but overselling it is just annoying (as is the brain-dead addition of “awesome” to any topic remotely related to Ruby, but that’s a different rant…)

    Exhibit A: the first sentence of this piece. Does *anybody* really think that “Ruby is the language of the web”? Certainly no one I’ve ever talked to, and I’ve been around since the year dot (internet time). Javascript, maybe. Or even Perl in the days of CGI. But Ruby? Nope. Please turn down the hype level, Ruby doesn’t need it.

  • Thomas Fuchs

    …or just use some CoffeeScript, sparingly, and don’t write huge monster front-end MVC stuff. It’s almost never necessary, and often it’s detrimental to performance and developer productivity. Ruby or not, that won’t change. See also http://www.shopify.com/technology/15646068-rebuilding-the-shopify-admin-improving-developer-productivity-by-deleting-28-000-lines-of-javascript.

    Don’t get me wrong, I prefer Ruby over JavaScript. However, I think this is trying to solve the wrong problem with heaps of complex technology that will ultimately only support code bloat, make things slower to develop, harder to debug and impossible to maintain.

    • http://astonj.com AstonJ

      I think it’s too early to say with any certainty that that will happen… it hasn’t been tried yet, and Volt is already beginning to prove that it’s not just possible, but better.

  • http://www.spry-soft.com David White

    Another cool implementation of Ruby that’s always worth sharing / keeping an eye on is Rubinius X: http://x.rubini.us/

    Which is aiming to provide a modern (experimental) version Ruby. Including a non-blocking IO, promises, mirrors and more…

  • ferdinandrosario

    a new programming language implemented with Ruby.

    * HP:
    * CODE:

    Message from the creator of Q :
    ### Why Ruby?

    Let me present why I implemented Q with Ruby.

    1. Ruby is the language I’m used to and it’s very productive,
    so I can make prototype quickly and modificate easily.

    2. I’d like to prove that Ruby is enough functional to conduct numerical analysis
    (Actually
    I’m univ. student and my professor says “Python is more preferable for
    numerical analysis than Ruby. So you should use Python” I’m angry with
    that.)

    3. I love Ruby! (we don’t need any other reason.)

    And I like developing OSS with awesome engineer.
    Welcome any your PR or issue. You can become commiter, if you commit even once.Since you report a bug, I will response within 24 hours.

  • 都是牛奶装什么特仑苏丶

    Good!

  • Rafael Jesus

    Ruby should be multi-core per default, this is one of reasons why we see lots of posts like “Migrating from a monolithic Rails app to Go/Scala/ANY”

    Yes, We do Have JRuby, Rubinius, Vertx for multi-core, but guys does not detaches from MRI and Rails way as well,

    In Node we build fantastic apps with Express.js wich is based on Sinatra, we can’t see the same in most Ruby apps out there with Sinatra,

    Rails is not the best fit for Microservices Architecture and Distributed Systems(Node.js as well), yes we have actors models with Celluloid but the recommended way to use is with JRuby/Rubinius and not MRI

    Hey I love Rails, but its not solving problems with scalability nowdays

    • Alex

      I used to think like this too but at my most recent role we are working with an extremely horizontally scalable rails architecture. Yes Rails may not scale super well with vertical scalability but should you be really making your apps like that anyway?

  • Kelsoh

    One challenge with Opal is that it’s performance is not even close to native javascript, so there are performance implications to picking it over vanilla javascript/coffeescript.

  • Dave Routen

    Great article Aston, definitely going to check out Opal, Fire, and Volt!

  • JimmyLu

    Did Ruby get red hot again?

    • Matthew Blott

      No :-)

  • Matthew Blott

    It’s often fun seeing what happened to someone’s predictions. Fire never started and Volt is now abandonware. A lesson all software developers should heed: always beware the Hot New Thing – the dull but tried and tested is often a better option :-)

    • http://astonj.com AstonJ

      For me, this post was more of a call to arms than a prediction. Ruby was at a crossroads. It could have gone either way – there was so much promise after all – just see above. So my post was intended to reinvigorate the community and help push things down the opposite path of which I (and many others) felt things were going. I think it had some success in that regard – the hype this post created was pretty insane.

      I personally believe Fire never started because of Opalgate. And Opal was also intrinsically linked to Volt which while itself was being seen as the ‘Rails’ of the next generation, was unfortunately later drowned by the hype of Elixir and Phoenix when they came on the scene (Phoenix now being seen as the Rails of the next generation).

      Opalgate aside, if Opal had the same sort of blessing that coffeescript had from DHH/Rails we could be witnessing a very different story today.

      I suppose there is a lesson in there for everyone. Perhaps more for some than others.