PJ Hagerty Rails…Still?!?! [email protected] | @aspleenic DevRelate.io

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate Prompt - Mental Health in Tech

http://mhprompt.org [email protected]

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

I also do some side work coordinating Prompt - a mental health in tech organization. If ever you want to help start the conversation on Mental Health in Tech, let us know. We are also always accepting donations. FULL DISCLOSURE

❖ I don’t hate Rails - let’s just be clear. This talk isn’t meant to disparage Rails or folks who love Rails - there will be no Rails bashing (probably).

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Before we get started, let’s address the elephant in the room. Rails is great. It really is what you need for large scale production applications most of the time. It has history. And if you got started in Ruby working on the web, chances are Rails is what you are most familiar with. Why is Rails so great?

PJ Hagerty | @aspleenic image credit: Jason Hoffman / thrillist http://devrelate.io | @devrelate

Many developer came to Rails by default. Maybe we were Ruby hobbyists looking to move to the web, maybe we were web developers looking for the next great language. Maybe we learned to code in a bootcamp, where Ruby on Rails is preferred teaching method because of its ease of use and ability to be installed nearly universally (yes, even on windows!). Rails, when it arrived on the scene, shook up the open source world of web development. There was finally an alternative to Java, PHP, and Perl - and it was actually fun to use. There was magic in the air! The Magic

image credit: http://www.dailymail.co.uk PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Part of the allure of Rails was the magic. I remember it being said you could build a web application in Ruby on Rails, get 90% of the work done in 10% of the time. While the last 10% was a real pain in the crack, this was very attractive - especially to Dev shops looking to do fast turn over or convert from legacy systems to a more modern language. Rails did things “automagically” - you had ways to handle database connections, you didn’t need to worry about straight SQL queries..I mean, heck, Rails came with a built in index page just to let you know you we’re “Riding the Rails!” But, doing things automagically can come with problems… The Rails Monolith

image credit: Rene Aigner - Monolith (from the https://m.signalvnoise.com blog) PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Rails is huge. Huge comes with a cost. One of those costs is not being able to easily find things under the hood. I know there was a reference to this in DHH’s keynote a couple years ago. He was of course defiant and defensive. He wanted to talk about new features, but focused on why monoliths can be better than microservices or other methods of division of application labor. And of course that’s not a surprise - David is part of the problem. Granted, he created the solution initially - but having a Benevolent Dictator for Life can be a hinderance and part of a monolithic structure.

But beyond the politics of Rails there is an underlying issue. What else is there?

image credit: http://iruntheinternet.com/01548 PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

This is where we get into the nitty gritty - looking at alternatives. Once upon a time, there were only a few alternatives to Rails if you wanted to put Ruby on the web. Today, that landscape has changed. While we’ve never achieved the full framework wars of other languages (and that’s really a blessing not a burden), we have seen growth in frameworks that can do specific jobs better and in a more streamlined way in comparison to Rails. Let’s take a look at a few. Sinatra

http://sinatrarb.com

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

We’ll start with Sinatra. How many folks here have used Sinatra or at least checked it out? Created by a gent named Blake Mizerany back in 2007, Sinatra was really one of the first steps towards using ruby on the web without Rails. Since it’s inception, Konstantin Hasse has been the main maintainer and deserves much credit when it comes to making Sinatra a more recognizable name as time went on. Based on using routes for code to be activated, Sinatra is a lightweight solution for applications that don’t need the overhead Rails provides. Sinatra’s Strengths

image credit: Getty Images PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Even with the use of some of the API tools in Rails, Sinatra still has the upper hand when it comes to building an application that is ingesting something from an external API. Because of it’s inherent simplicity Sinatra focuses on the task at hand with none of the over-arching strain the various parts of Rails can put on an application. Say there is no need to retain DB records, just read and organize API pulled information - why would you build a Rails application with all the extra classes just hanging out doing nothing? Sinatra would be the best thing for what you need to do.

And if there’s something you need from Rails that Sinatra doesn’t do, YOU CAN ADD IT IN! Sinatra is written in Ruby just as Rails - so you can add components like ActiveRecord as you need them! Sinatra’s Weaknesses

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

To be fair, everything has its drawback and nothing is perfect. Sinatra, and the other alternatives on this list will need to show they’re ugly bits as well.

With Sinatra, it’s already been said - lightweight. For a larger scale web application, Sinatra will not be what you want. It’s really for applications dealing with fewer endpoints and few or not frequent or concurrent users. Sinatra will crash if put under too heavy a load.

That, and as it is compatible with Rails components like ActiveRecord, as your application grows, you may end up with half of Rails revisited - send spawning the need for converting it to a Rails application. While not difficult, a little foresight may have been helpful in avoiding just that.

So, Sinatra is small, but good for some things, just not everything. Almost Sinatra

https://github.com/rubylibs/almost-sinatra

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

When looking for Sinatra and it’s documentation, do not get fooled by something called “Almost Sinatra”. Be it known, maintainer Konstantin Hasse is a bit of a joker and his sense of humor lead him to attempt a rewrite of Sinatra in just six lines. To say it is unsafe but functional would probably be the best quote. For a laugh though….feel free to checkout the repo Padrino

http://padrinorb.com/

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Based in Sinatra at it’s core, Padrino is a lightweight full-stack ruby framework. Unlike Sinatra, it has some features that are very Rails like, such as a method for generating applications with padrino g project myapp.

Think of Padrino as Sinatra part two, or maybe Sinatra’s younger but more robust sibling. that happens sometimes, right? Padrino’s Strengths

image credit: Paramount Pictures PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Part of the beauty of Padrino is the tooling. With support for many database libraries along with testing and mocking tools, it goes a step further with a drop-in admin interface that is ORM agnostic and comes with scaffolding and authentication features.

Essentially, Padrino is a step between Sinatra and Rails that goes beyond the simplicity of Sinatra and allows more complex applications to grow. Padrino’s Weaknesses

image credit: Funko Pop Inc. PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Here we run into some of the same issues we ran into with Sinatra. Sure, more of what we need for a more robust application are available, but, if we need to implement more and more things, aren’t we really just implementing Rails?

I like Padrino a lot for projects that are bigger then Sinatra, but not quite Rails ready. Think a proof of concept application that may see production someday. Of course, when someday comes, that may be the day you rewrite in Rails. Cuba

http://cuba.is

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Since we are on the topic of Micro frameworks - let’s take a look at Cuba! Cuba is one of the most easy to start with micro-frameworks currently available to Rubyists. Written by Michel Martens, the key to Cuba, like Sinatra, is simplicity. With the avoidance of large scale overhead, this micro-framework is designed to build and deploy simple apps while avoiding bloat and unnecessary functionality. Like many micro-frameworks, Cuba is Rack based. Rack minimizes the interaction between the webserver supporting Ruby and the framework itself. This helps improve app response times and makes using the framework, in this case Cuba, fairly simple. Cuba’s Strengths

image credit: Shutterstock PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

One of the best parts of Cuba is the documentation. A walkthrough guide is available online and allows anyone to look into and take advantage of Cuba’s functionality. After working for a short time with the walkthrough guide you will have a simple Twitter clone called Frogger. At this point, you should be familiar enough with Cuba to start using it in your own projects, if it’s the right fit. TO THE REVOLUTION NOW, right? Cuba’s Weaknesses

image credit: http://www.gripmagazine.com PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Cuba has never been able to capture the Ruby community’s attention quite like other options. Certainly not like Rails or Sinatra. As such, Cuba may have some seriously outdated parts these days, making it less compatible with modern applications.

Cuba also suffers from limited focus. Similar to Sinatra, the main job is to build a minimal rack application. If you are looking for something with a bit more infrastructure, a micro-framework is probably not for you. Hanami

http://hanamirb.org

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Bring out the fully fleshed out frameworks! Let’s take a look at something more robust - HANAMI!

If you think what we talk about here sounds a lot like another framework called Lotus, you should not be surprised. Lotus became Hanami a few years ago after a certain large corporation decided they didn’t want to share the name. Hence, Hanami - created by Luca Guidi, this is a complete era framework that has shed some of the wait of Rails for better performance. Hanami’s Strengths

image credit: https://japanbook.net PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Speed. Hanami has the features of a fully fleshed out framework without the hard overhead that sometimes causes performance issues in Rails. This speed comes at the cost of having a few features not readily available. But as some of these things are CoffeeScript features, ActionCable type things, and other things the Rails ecosystem always added as “nice to have, but don’t usually need”, it’s not as big of a drawback as it might seem.

Hanami seems to have been built with the purpose of directly competing with Rails for framework dominance. That said, there are some drawbacks. Hanami’s Weaknesses

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

The pace of Hanami builds are its biggest drawback. While it may someday be a major player in the world of Ruby frameworks, it moves along at a snails pace as far as new features and additions to the standard build.

Part of this could be easily resolved - by folks like you. Get involved, submit PRs, write some code - this is what open source is all about. If you try hanami and you like it “but it’s missing…” whatever - build that whatever to help make it better. Volt

http://voltframework.com

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Volt is another framework that has been fresh in the mind of many Rubyists recently. With a focus on building a fast application and eschewing the yak shaving, Volt offers the opportunity to get things moving quickly. Instead of focusing on syncing data via HTTP, Volt works using a persistent connection. Part of the reason for Volt’s quickness is that it lives on top of Opal, a really amazing gem that translates Ruby to JavaScript conveniently. Volt’s Strengths

image credit: http://survival-mastery.com/diy/construct/how-to-build-a-faraday-cage.html PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

I can say “speed” here again. Volt focuses on the persistent connection to bypass anytime is would take for a http to sin data. Which is awesome. The entire focus being speed.

And the use of Opal to translate things to JavaScript means less focus on dealing with JS while writing code, which agains translates to speed, but this time it’s speed of writing code instead of an application performance metric. Volt’s Weaknesses

image credit: Insane Clown Posse

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

One inconvenience for Volt at the moment is that it only supports MongoDB. While MongoDB is a great database solution, it’s not always what you want to use. As, in recent polls, most rubyists are using PostGres or MySQL, this may not be the solution for you.

The other weakness of Volt is it’s a schema shift. Most ruby applications for the web are written with HTTP as the intended method of transfer. While it’s not hard to consider when writing code, writing in Volt means taken into consideration the persistent connection. Trailblazer

http://trailblazer.to

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Trailblazer is the latest gift from long time Ruby punk rocker, Nick Sutterer. The idea behind it is to help Rails to work more efficiently as a framework by enforcing encapsulation and adopting a more intuitive code structure.

In the beginning, Trailblazer was an abstraction layer on top of rails, meaning it was not truly a framework, but more like a framework for the Rails framework…it that makes sense. From that time, Trailblazer has come a long way. Trailblazer’s Strengths

image credit:LeanPress

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

One of the biggest strengths of Trailblazer is it’s focus on moving business logic out of controllers and into other pieces of code - this logic is moved to service objects known as “operations”. This makes controllers and models more lean and therefore more streamlined for use.

Additionally, Trailblazer keeps the code more DRY, something many rubyists have trouble with when dealing with Rails - or sometimes Ruby in general. Trailblazer’s Weaknesses

image credit:Nick Sutterer

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Like many things from early rubyists, Trailblazer is very opinionated. The ideas behind it stem from other projects in Nick’s repertoire, like Cells.

That said, Trailblazer has a large community and there more and more sources on learning to apply Trailblazer to projects coming out. Elixir/Phoenix

http://phoenixframework.org

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Like so many rubyists, maybe we should take a looks outside of our day to day. Let’s look at Phoenix, the elixir web framework created by Chris McCord, a former rubyist who started working in Elixir and spotted the need for a web framework.

Chris was influenced by Rails and continued to look for an MVC solution that would work in his new ecosystem. Not finding one, he build Phoenix. Elixir/Phoenix’s Strengths

image credit:http://mythology.net

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Phoenix is fast, scalable, and makes it easy to build web interfaces and connect to backend applications.

If you’ve used Rails, and I’m guessing most of you have, you will feel right at home with Phoenix. The MVC aspect is the same, so coding things up generally works the same. The key being: as long as you are familiar with Elixir - a portmanteau of Ruby and Erlang. Elixir/Phoenix’s Weaknesses

image credit: Warner Bros.

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Well…not a weakness, and possibly even a fun exploration - you’ll have to learn Elixir. That means learning Functional Programming, removing yourself from the Object Oriented world of Ruby. Additionally, you’ll need to learn OTP - Open Telecom Platform.

See, Elixir is based on Erlang, a functional language developed by phone companies for packet transmission. Pretty neat stuff to delve into, but if you are working on a project that has a timeline that doesn’t allow for a language switch, perhaps this is not for you. What’s the right framework?

PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

This is the sad point. There is no right answer. Your choice of framework depends entirely on the project you are working on and the needs of your end user. Take everything into consideration when deciding what framework to use.

Also, explore other places, find the things you like and the frameworks you are comfortable with. Defaulting to Rails is always an option - but remember, it’s an option - meaning there are choices out there. Conclusion

image credit: AFP PJ Hagerty | @aspleenic http://devrelate.io | @devrelate

Rails is here to stay. And there’s really nothing wrong with that! It does a great job. But, at the very least, we have seen there are alternatives to doing Rails just because it’s the 800 kilo gorilla in the corner. So go out, explore other framworks (except Almost Sinatra) - maybe build the next best thing to Rails on your own!

As with all open source, these things are your to take, make, build, better, and use - don’t simply do for the sake of doing, build things that make things better for everyone in the community. Thanks!

PJ Hagerty |[email protected] @aspleenic

PJ Hagerty | @aspleenic http://devrelate.io http://devrelate.io | @devrelate

Thank you.