
Is Rails still relevant in 2018? - bdcravens
https://blog.eq8.eu/article/is-rails-still-relevant-in-2018.html
======
thinkingkong
I mean... Let's pause for a minute and remove the year, and remove the
language / framework. What are we trying to accomplish?

If we know something really well and there are enough developers to support an
ecosystem and the talent pool in your <however you decide your region> is big
enough just use whatever you want.

PHP in 2018? SURE.

C++ in 2018? SURE (You masochist)

Rails in 2018? Youre damn right I would.

GO in 2018? OK. Fine. Whatever.

This is highly opinionated, but our jobs are to make stuff that works in a
predictable, less risky way. Do that.

~~~
fsloth
"C++ in 2018? SURE (You masochist)"

I know this is tongue in cheek, but if one is doing anything related to real
time graphics programming I'm not aware of any good alternatives.

~~~
bsenftner
I write integrated servers with the web server, the database server, a video
server, and a facial recognition application all bundled together in C++. The
application screams: try 1/16th the memory footprint of a traditional multi-
server Internet application, it is 4000% faster, and can run on a $100 Intel
Compute Stick. Try this in any other language...

~~~
mwcampbell
What C++ web server library/framework do you use? Or did you roll your own?
For the database, are you using SQLite or something else?

~~~
bsenftner
Restbed is the C++ framework, and yes, we use SQlite.

------
fergie
Rails really nailed the problems of web development as it was 10 years ago by
(rightly) pointing out that 97.2% of web projects were all about making an
application server talk nicely to a relational database and then generating a
front end that reflected the data model and that had javascript that Just
Worked (everywhere).

Web dev is in a different place now. Developers don't generally install and
maintain application servers from the ground up. Scriptalicious was superceded
by jQuery, which in turn was supplanted by vanilla js actually becoming
useful. Relational databases are not quite as dead as some people would lead
you to believe, but other types of DB are much more common now (key-value
stores, search indexes, etc).

Rails was probably one of the last truly open source projects (Most OS these
days is to some degree 'owned/developed' by Big Tech) to get big traction and
for that it deserves credit. Just the idea that a Danish web consultant could
hack together something that became popular and which then allowed him to
literally retire and become a racing driver before he hit 30 should inspire us
all.

~~~
3pt14159
Rails is good for two things: Fast iterating and fast on-boarding new
employees.

If you want to start a startup, and you know Rails, use Rails with Postgres.

Do the complicated shit (data science, video uploads, etc) in your other
language if you have complicated shit. Use a different subdomain or get nginx
to fork the endpoints for the complex shit if it needs to be public.

I've known plenty of people, myself included, that tried something else
because of "reasons" but the real reason was I wanted to try some new language
or framework but it gets old fast.

> I'm gunna use Riak!

I said. Then I needed to do some random task that would have been trivial in
SQL.

> I'm gunna use Go!

I said. Then I spent hours fiddling with types and boiler plate code and
catching errors.

These are not solving problems startups have. These technologies solve
problems that huge companies have. My only gripe with Rails is that I think it
should be JSON-first, not HTML-first, because almost everyone needs an API
these days and many people use front end frameworks for HTML, but whatever.
It's not that hard to override that stuff.

~~~
mbesto
Agreed with all of these points.

> I think it should be JSON-first, not HTML-first

Isn't that the case in Rails 5?
[https://guides.rubyonrails.org/5_0_release_notes.html#api-
ap...](https://guides.rubyonrails.org/5_0_release_notes.html#api-applications)

~~~
3pt14159
Yes, I'd forgotten that that was option I should have addressed. The issue is
that I want things like cookies to be supported out of the box for things like
Ember, even if I want other API consumers to use locally stored tokens. But
you're right. There is some attention going that way.

------
nurettin
RoR is relevant as long as the community is active, as long as there is job
demand (see crossover, Stackoverflow, etc.).

It is an excellent framework with gems to act as plugins (rack middleware) to
serve websockets, forums, admin interfaces all with a few lines of
configuration. Google, Microsoft, Facebook all maintain Ruby libraries in
GitHub. So as long as you are doing Joe's textile website, it is the right
tool.

Cloud scaling rails can be expensive, as apparent from horror stories [0] but
a few manually managed instances with a load balancer and good web servers can
go a long way.

It lacks development time relative to python which cater to domains such as
data processing and artificial categorization. With extension libraries such
as helix [1] which utilize rust to create native extensions and enough
development time it has the potential to dominate those fields in the future.

One honorable mention is JRuby and while it isn't kotlin in terms of
efficiency, it still lets you use Java libraries when you need any sort of
domain libraries.

In conclusion, I'd say it is still pretty relevant today.

[0]
[https://news.ycombinator.com/item?id=5228200](https://news.ycombinator.com/item?id=5228200)
[1] [https://usehelix.com](https://usehelix.com)

~~~
bdcravens
> So as long as you are doing Joe's textile website, it is the right tool.

I don't think Rails is the best tool for that. A static site or Wordpress are
probably a better fit.

> Cloud scaling rails can be expensive, as apparent from horror stories [0]
> but a few manually managed instances with a load balancer and good web
> servers can go a long way.

It definitely can be, but I think most apps people are working on don't have a
scaling issue (at least of the technology sort). When there is a scaling
issue, it's often something related to the database (bad indexes, poor
instance type, or N+1 queries)

~~~
nurettin
I think there is more to textile than displaying and selling clothes. But,
YMMV.

~~~
bdcravens
Sure, but much of that process isn't customer facing. I tend to draw
inferences when I read "website" as opposed to "web application".

~~~
nurettin
Is this a personal and subjective opinion of yours, or some sort of documented
distinction?

------
sho
Of course it is. The question is kind of silly. For basically any startup, my
advice would be: unless and until you can credibly explain a genuine reason
why you can't use Rails - use Rails.

I'm not some crazy fanboy but until someone can actually name a seriously
competitive, batteries-included, all-in-one framework* which delivers
everything, or even most of, what Rails does - it is very relevant and you
ignore it to your serious disadvantage.

* your list of 30 random npm packages does not satisfy the requirement

~~~
schizoidboy
> your list of 30 random npm packages does not satisfy the requirement

I like Rails, but to be fair, doesn't Rails also require a list of 30 random
gems? Unless things have changed, authorization and authentication aren't even
built-in, so people have to navigate random third party gems, and remember,
you don't want CanCan, but you want the fork, CanCanCan. Again, I like Rails,
and maybe it's still the nearest to an all-in-one framework, but I think
somebody who took the next step and created a truly all-in-one framework would
win big.

My current project:

    
    
      $ grep -c ^gem Gemfile
      75

~~~
amarsahinovic
Django fits that description.

~~~
i_am_nomad
Came here to say the same thing, and add that with Django, you have access to
the amazingly vast landscape of Python libraries. Just being able to spawn
Celery jobs is a huge plus.

~~~
joelbluminator
Couldn't see any advantage over Sidekiq, Resque and friends. Not saying it's
bad but just that the Ruby community has got your back for any web development
need you might have...when working with Django I didn't get the feeling I am
working with superior libraries.

~~~
bpicolo
An advantage of Celery is that it doesn't require payment for an enterprise
version to add things like scheduled tasks.

~~~
joelbluminator
If you're talking about Sidekiq there's free open source solutions for that in
Rails world. [https://github.com/moove-it/sidekiq-
scheduler](https://github.com/moove-it/sidekiq-scheduler)
[https://github.com/ondrejbartas/sidekiq-
cron](https://github.com/ondrejbartas/sidekiq-cron) Besides Sidekiq is just
one out of many.

~~~
bpicolo
Good to know, cheers

------
SnowingXIV
Right tool, right job, etc. I built and run an internal tool for a company
that went from a very dated coldfusion setup, to a cloud crm (expensive), to
now simply using the rails application I built for them with fantastic
sorting, searching, mass updates, login features, and export capabilities, you
name it. It's has over 1M db records and is plenty fast for any mix of
criteria.

Really cheap to run, low-low-low maintenance. I don't even need to touch it
except if there are some security bugs that need to be patched and heroku
handles backups automatically. In the event heroku has problems I run my own
cron-job that does backups of the psql database and the application itself is
put under version control.

I'm not sure there is another framework I could have pieced together such a
smooth application with anything else in the amount of time and resources I
had available plus without having to worry about it ever breaking because of
some weird bug. Stability is very important for many businesses.

Once in a blue moon a new feature is requested and doesn't take long to make
some changes. Now, would I use rails to fire up a basic website like I did in
the past? No. I'd grab a static-gen like Jekyll and maybe some PHP to handle
mail if needed.

------
sidstling
Almost every, and probably every, language that has been used for serious
production is relevant in 2018. COBOL is still one of the most important
languages in the belly of a lot of financial and public software.

You wouldn’t build something new on cobol if you could avoid it of course, but
rails is not cobol. Ruby and rails are still good at getting things out the
door.

I wouldn’t personally touch it, but that’s because I’ve never heard about
anyone using it in my country. If you live in a place where a lot of shops use
ruby and rails, then why not?

Changing tech isn’t easy, so you should only do it if you’re motivated. We’ve
been doing more and more JS/Node where I work because it’s really good at
getting things done quickly, sort of similar to why you’d chose ruby and
rails. However I’ve been a C# developer for years, and I’m nowhere near as
good in the JS environment as I am in .Net. I’ll get there eventually of
course, but I probably wouldn’t without the internal motivation of actually
enjoying the change, partly because JS is so great at getting things done.

The key questions to me when chosing a language would be, _do I really want to
learn it?_ _Why do I want to learn it?_ And also, _is anyone in my area hiring
for it?_.

~~~
fyfy18
> We’ve been doing more and more JS/Node where I work because it’s really good
> at getting things done quickly, sort of similar to why you’d chose ruby and
> rails

I assume people make them comparisons because both ecosystems have a lot of
third party libraries, which means if you want to add some functionality
there’s probably a library out there for it. I don’t really feel that
comparisons like this are really that accurate though (and are often made by
people who don’t have experience with Rails).

If you are using something like Node or Go you need to have knowledge about
which libraries you need to use (bearing in mind that often changes every year
or so, compared to the Ruby ecosystem which is a lot more stable) and write
all the glue logic to make them work together yourself. With Rails you can
literally build a blog by running a handful of commands and editing a couple
of views, and have something up and running in less than 15 minutes.

The beauty of Rails is that it’s opininated enough, that you can build a
pretty decent application just by using what it gives you out of the box. Yes
you may want to add Sidekiq for better performance of background jobs, or
Devise to avoid all the repetitive code you need to handle user accounts, or
add RSpec because TestUnit is the devil, but those aren’t required to get
something done.

~~~
sidstling
I only meant to compare them in the sense that they are both really good at
getting a working prototype up and running fast.

You’re absolutely right that this requires knowledge of packages for node/js.
We haven’t been using a whole lot of modules to achieve this, but we certainly
haven’t used just Node/JS either.

------
tptacek
For whatever it's worth: at Matasano we saw more Rails apps from startups than
any other framework.

At Latacora that has changed dramatically; we see Django a lot, rarely Rails,
but most commonly we see Go, Python, Node, and Java API servers with React
frontends and minimal frameworks.

From my vantage point: Rails is still relevant and still a viable option for
building new stuff, but it is less relevant than it used to be.

~~~
cityzen
How does Laravel rank in there?

~~~
tptacek
To my knowledge I've never been asked to look at a Laravel app.

------
aikah
To me, every framework or web oriented language out there should have a big
tutorial similar to

[https://railstutorial.org/book](https://railstutorial.org/book)

because it covers a lot of things regarding classic everyday web development
which is extremely useful to beginners. So just for the existence of that book
I'd say yeah, Rails is still relevant.

There is also this one for flask which builds an web app from start to finish
for people who like Python.

[https://blog.miguelgrinberg.com/post/the-flask-mega-
tutorial...](https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-
part-i-hello-world)

A lot of ruby books features the design and development of complete medium
sized application from start to finish in various domain.

That's the kind of thing beginners should learn instead of 'Docker' or 'React'
because they've heard everybody constantly talking about the latter.

~~~
faizshah
I second this, Hartl's RoR tutorial is one of the best introductory books to a
framework that I have ever read. I wish every framework would take notes from
that tutorial.

------
RhodesianHunter
> I would keep learning plain Ruby, Elixir, Phoenix and JavaScript as my side
> tools

> I wouldn’t spend too much time learning programming languages outside that
> list as you need more tools in your toolbox but too many tools may get your
> toolbox cluttered

You suggest not cluttering your toolbox, but your recommendation is a list of
completely interchangeable dynamic languages?

~~~
angersock
Javascript, Ruby, and Elixir are emphatically _not_ interchangeable.

Elixir is compiled, the other two are interpreted.

JS is supported natively by all browsers and is at its core an event-driven
functional language, the other two are not.

Ruby is probably the comfiest OOP language out there, and certainly the one
with the best standard library.

 _These are not the same languages._

~~~
M_Bakhtiari
> Elixir is compiled, the other two are interpreted.

How can a language be intrinsically compiled or interpreted?

Sure, Befunge is one example of a language that's notoriously hard to build a
compiler for but easy to build an interpreter for, but surely that can't be
said for Ruby and JavaScript. V8 is a good counter-example to the claim that
JavaScript has to be interpreted.

~~~
angersock
> _How can a language be intrinsically compiled or interpreted?_

This is a great example of an academic nondistinction that is completely
worthless in practical matters.

~~~
M_Bakhtiari
It is highly relevant because we in industry are the ones who actually have to
work with and scale all these needlessly slow piece of shit language
implementations. Implementations that get a pass because nobody can be
bothered to have this conversation. Languages that are dynamic or good for
scripting, rapid prototyping or whatever the hook is do not need to be
implemented using slow and inefficient techniques and shouldn't get a pass for
it. Similarly terrible languages shouldn't get a pass for being terrible just
because they happen to have fast implementations.

It's precisely in academia where it is a worthless nondistinction, there a
language doesn't even need to be implemented to be studied. For instance
lambda calculus predates the programmable computer.

------
whalesalad
I commented a few months ago that if I was starting a new company today I’d
use Rails without hesitation.
[https://news.ycombinator.com/item?id=17355776](https://news.ycombinator.com/item?id=17355776)

Well, I’m starting a company and our current prototype is Rails. I don’t
regret my decision at all, although after spending the last four years writing
exclusively Python it’s been a little jarring. The muscle memory is still
there though and after two weeks I’m almost back to 100%.

I really missed Active Record and all of the conveniences there around
migrations. When you’re prototyping and constantly evolving your data model -
but still intend to throw real traffic at it - flexibility here with the
hardened foundation of PostgreSQL is vital.

The framework and language aren’t red hot anymore but they are far from dead
or even stagnant. There’s a tremendous amount of active development happening
in Rails.

Meanwhile I’ve been learning Elixir via a course called “Elixir for
Programmers” and love it a lot. I didn’t want to risk building things on
Phoenix at this stage. It’s full featured and likely more than capable but the
smaller ecosystem and it being a first production app for me wasn’t worth the
risk. I’m dying to put the actor model and OTP to work in an environment where
it would really shine.

Anyway... still loving Rails and Ruby! A lot! With SASS, Haml, rake tasks,
lots of data fixture tools etc... and no BS with React and webpack, slow
pipelines and maintaining two codebases for an API and a Frontend... you’re
left with lots of functionality being built daily. It’s great.

Don’t get me wrong, React is awesome and it’s certainly the new foundation of
UI development. But... the ecosystem is still learning to walk imho. Redux
isn’t the answer. GraphQL is great on paper but the way people use it is not
ideal (coupling data to ui). Long way to go before I’d go 100% JS.

This reminds me to book a ticket to rubyconf.

~~~
paulie_a
To be fair the technology stack is almost irrelevant when you are starting a
company. write it in perl, python, rails, hell write it in old school cgi and
use c++. It all comes down to how many sales did you make today. The clients
will rarely care what language was used behind the scenes.

~~~
PopeDotNinja
I refuse to write Perl. If enough people feel the same way, Perl is not a good
choice.

~~~
wolco
Long term perhaps but short term it means increased salaries.

~~~
PopeDotNinja
You're not wrong.

------
collyw
Its kind of ridiculous that in this industry we are expected to jump on new
trends every couple of years to stay current, rather than learn how to use the
tools that we do have well. Sure we get some benefits, but 90 % of the time it
seems we are just chasing fads.

(Yes is my answer to the question).

~~~
joelbluminator
That happens mostly in front end, backend world moves slower. It's why I just
don't like front end coding anymore, I feel like I have better use of my time
than learning a new framework every 3 years.

~~~
collyw
Front end is way worse, but a few years ago we were all told to jump on the
Mongo bandwagon. Now we have serverless. Sue these things do have use cases
but they are oversold a lot of the time.

------
hspak
Rails is still probably the most productive* web framework out there. It's got
a mature ecosystem that covers it's weaknesses.

* productive as in easy to get started, easy to iterate, easy to get things done.

~~~
batiste
Granted you know Ruby well and like coding in it. The amount you need to learn
if you don't know RoR or Ruby is huge... You might get some stuff running fast
copy pasting some example but claiming that it is all super easy to do
anything meaningful is misleading.

~~~
maximp
This was exactly my experience. I struggled building with Rails, and every day
was an uphill battle trying to learn the machinery. I switched to Node, and
feel my better. My structure isn't nearly as pretty, optimal, or efficient
now, but I'm actually learning the base concepts and understanding what I'm
doing.

------
misterbowfinger
The example of why Elixir is less productive makes 0 sense:

 _Doh Phoenix and Elixir are trying to do all the best to help developers be
productive, when you are a technology that promises such a huge scale you need
to introduce practices that need to be decoupled = > bit slower for
developers._

 _Good example of this how a “model” writes to database. Module (with schema)
need to call a changeset, changeset call repository, repository writes to
database (example). That’s 3 manual steps where in Rails you have in in one._

Phoenix & Ecto work that way because 1) Elixir is functional, and 2)
ActiveRecord mixes a lot of concerns that suck in the longterm.

IMO the real thing holding back Phoenix/Elixir is deployment & operational
issues. It's being worked on a lot with Distillery, but from what I understand
there's still a lot of kinks to be worked out.

~~~
andy_ppp
I personally think the deployment story heavily conflicts with container
management. I’m going to give edeliver on real hardware a go at some point and
things should work very well and be very simple.

~~~
gamache
Only if you want Erlang clustering or hot upgrades. In the usual army-of-one
deployment scenario, Elixir and Erlang work inside a container just fine.

~~~
andy_ppp
Sorry I wasn't clear; what I'm saying is using the default deployment story
with Erlang/Elixir is actually simpler than Kubernetes in most cases.

------
ankurdhama
The article mentions: Root of all evil is state. No its not, but again we love
to make generalised sweeping statements (i.e small statement that can be
quoted and people think of them some kind of wisdom) The problem is that
"mutable shared state" is hard to manage and can lead to various kinds of
problems. There are many tested patterns/libraries around that you can use to
manage it rather than trying to implement your own solution.

~~~
pythonaut_16
> Root of all evil is state.

That's such a funny thing to say. You'd be hard pressed to have a program
without state. Every program is made up of a combination of 3? components:
logic, data(state), and time.

The thing that differentiates different programming languages and tools is
what abstractions they build around those three things and how they are
exposed to the programmer.

------
danmaz74
I think that there is no better alternative to Rails to write the back-end for
web/mobile applications in a very efficient and maintainable way, unless you
have very demanding (and uncommon) requirements for performance and "web
scale".

I also think that the most important part which is missing to make it even
more relevant is a much easier (opinionated, convention-over-configuration and
DRY) way to connect rails with React and similar frameworks. Something like
generators to synchronise your data with a state manager in the front end (eg
Redux). I even have some ideas about this, I just wished I had time to work on
it.

------
atdt
Optimizing for happiness is very good advice for beginners. The failure mode
for beginners is to get overwhelmed, discouraged, and then give up. So it
makes sense to pay more attention to how happy a particular programming
environment makes you, and worry less about how marketable it is.

------
sshine
The short version:

> Yes. But I have a crush on Elixir.

The article doesn't say much else.

~~~
seanhandley
Yes, I gave up 1/4 of the way in because the author was waffling.

------
sjellis
It will be relevant until somebody does a monolithic Web application framework
that is better in a way that it so compelling that it's obvious. A
microservices architecture is not always the right choice.

Django, Laravel and other established frameworks can be a bit better or a bit
worse, depending on your criteria.

Buffalo (Go) and Phoenix (Elixir) are the only competitors that I know of that
could match Rails at it's own game, and also have compelling advantages over
it. Both have smaller ecosystems right now.

(Source: I've been working at a Rails shop for 6 years).

------
throw2016
The need for a build environment itself limits Ruby deployment to developers.
This becomes a real problem for end user apps and expecting end users to
compile is perhaps expecting too much. And now you need a build environment in
deployment.

And with this comes potential dependency hell, an app like Discourse pulls in
over 140 dependencies. This means either you are a Ruby developer who can
debug compile or version conflict issues quickly or have a lot of time to go
down various rabbit holes.

Many casually suggest Docker but this simply doubles complexity as now not
only does the end user need to know Ruby but also Docker. This means
understanding networking, port forwarding, volumes, state separation and
single process environments just for starters before we even get to the app.

For in house apps none of these are deal breakers but one wishes language
developers thought more seriously about the deployment story.

~~~
hrcxxx
Docker is the answer. Hire a separate production engineer to handle docker if
your devs are not interested in ops.

------
sergioisidoro
I've recently made the switch from Django/Flask to Rails. And I have a feeling
that those frameworks surpassed rails in terms of maturity. Rails feels a bit
hacky in comparison (ORM, migration management, validation and data
management, etc)

This might be a personal opinion, and just a disagreement on philosophical
cornerstones. However, if asked, I would point to Django as a starting point
to whoever asks me "What should I use to start project X"

------
ksec
_This is pretty amazing. Both GitHub and Shopify are huge, billion dollar
companies running on the original apps made over a decade ago. And they now
both on the latest Rails, helping to push the framework forward_ [1]

 _I can 't wait for y'all to see what we upstream now that we're in a position
to give back and improve Rails. My keynote; Rails 6.0: Scalable by Default [2]
at RailsConf was just a small portion of our plans for Rails._ [3]

There are also work from Discourse on Rails performance, Ruby is getting a
Method JIT. [4] and working on more pref work. TruffleRuby is close to 1.0 and
it is available on all ruby manager [5]. The Open Source build is now also
available on macOS as well.

There are lots more, and all of them were years in making, It took a year for
Github to get to latest Rails release.

For the past few years, many have been writing off Ruby Rails, Ruby is
comparatively expensive to scale ( and it still is ) , we expect other
frameworks to catch up in terms of productivity, and will spell doom to Ruby
Rails. Not only has such framework yet to appear, Ruby Rails continues to
improve on all front.

I say the best days of Ruby Rails has yet to come.

[1]
[https://twitter.com/dhh/status/1030528476250562569](https://twitter.com/dhh/status/1030528476250562569)

[2] [https://speakerdeck.com/eileencodes/railsconf-2018-the-
futur...](https://speakerdeck.com/eileencodes/railsconf-2018-the-future-of-
rails-6-scalable-by-default)

[3]
[https://twitter.com/eileencodes/status/1030461847256875008](https://twitter.com/eileencodes/status/1030461847256875008)

[4]
[https://twitter.com/k0kubun/status/960112559343878144](https://twitter.com/k0kubun/status/960112559343878144)

[5]
[https://github.com/oracle/truffleruby/blob/master/doc/user/r...](https://github.com/oracle/truffleruby/blob/master/doc/user/ruby-
managers.md)

------
flosim
I work in a small full-stack JS/TS shop, and we've inherited a RoR application
lately.

I see a lot of criticism against the Javascript ecosystem. Let me tell you why
I prefer working in Javascript rather than with RoR.

It all boils down to the magic Rails advocates rave about, which is precisely
what made my life a nightmare while working on that Rails project. Conventions
over configuration is fine when you know those conventions. When all you have
to do is work on the frontend part and rebuild an app, then you don't really
care all that much about what an asset pipeline might be, or how you're
supposed to use it. All those abstractions slow me down. At the end of the
day, your run-of-the-mill CRUD apps are all structured kind of the same, and
calling a cat a cat instead of inventing non-obvious abstractions is
detrimental to speed of dev.

I prefer having `package.json` explicitly listing all the commands I might
possibly need than having to memorize what does what with Rails. We've had
absolute noobs work on both JS and Rails project and they seem to move much
faster and be stuck less on the JS project than with the magic Rails provides.
The fact that JS is more imperative helps linking parts of the source code
intuitively, compared to Rails having standard classes and hooks and whatnot.

I'm very grateful for what Rails brought to Webdev in general, but I do think
that monolithic framework are on their way out. I kind of appreciate being
able to follow non-smart code when things go south, and being able to
understand what is wrong by just reading the code. I've spent waaay too much
time skimming through outdated documentation pages about things that were so
clever that they were changed in ulterior versions.

I had the same problems when dealing with Symfony (which still angers me to
this day), or Angular.js, or just anything that pretends to know better than
me how I should write code. It's kind of a recurring pattern with frameworks
that makes me increasingly wary of all of them.

Working with much smaller libraries that you can hope to grasp fully has
proven to be much less frustrating personally.

Another advantage is that I can write code once for both the frontend and the
backend, which helps me move a lot faster than writing the code + tests in 2
languages.

I know this is not a proof by any means, but I felt that having the point of
view of a non-believer would be interesting to you guys.

~~~
bdcravens
I think a lot of devs are over the asset pipeline. Recently I built a small
app where front-end performance really wasn't a concern. I stuck all of the
assets in /public and called it a day. I also think you'll see more Rails apps
using package.json and webpack for assets management.

As for the scripts section of package.json, that's typically managed via rake
tasks, that can be listed via rake -T.

------
Shinobi881
How is Ruby utilized outside of web development?

For example:

Python \- Server \- Cloud infrastructure SDK' \- AI/Data \- General scripting
\- Configuration management \- Blockchain \- ...

JavaScript: \- Browser \- Server \- Cloud infrastructure SDK' \- AI/Data
(however, not the most efficient choice) \- General scripting \- IoT \-
Blockchain \- Mobile development \- ...

Basically, while Javascript may not be the most efficient choice for data
science, you can get an understanding of the concept and make the switch to
Python or Rust...

Does the Ruby ecosystem have gateways into other areas of engineering?

~~~
wukerplank
Not sure if that makes it a gateway, but some tools for iOS/macOS development
use it: fastlane and cocoapods are the most prominent ones. It's a great
scripting language and good to develop DSLs.

~~~
Shinobi881
Ah yes! Homebrew, for example.

~~~
hrcxxx
Maybe it is just me. I always had a feeling that Cli tools written in ruby
were slow ...

------
martco
The long and rambling, confusing and grammatically indirect answer that this
piece puts forth is that yes, Rails is still relevant in 2018. I could agree
more.

------
da_murvel
In my opinion, now when Rails is starting to become stable, and a bit
'boring', is when it's starting to become relevant as well.

------
sam0x17
Almost every startup I've worked with still uses Rails, and this includes 3
startups founded in the last few years. Yes many are using React/etc on top of
that via the webpacker gem, but on the server side Rails is still super
popular among startups. Crystal is also gaining traction especially for
microservices among my network.

------
ccnafr
Yes it is. Real software engineers don't care about trends or hypes. RoR gets
the job done and that's all they care.

------
lbriner
Lots of these discussions are about how "nice" a framework is but there are
other genuine pressures, including the availability of developers - either
outsourced or in-house. As newer frameworks and languages become the weapon of
choice, developers in other frameworks dry-up and it becomes easier to, say,
port a system from .Net to Node/Angular/etc.

Of course, not everyone has the luxury of being able to rewrite or create a
new site from scratch, which is why lots of companies really struggle to
succeed.

There is also the issue of trade-offs, not just in the more obvious
"performance" but as the OP mentioned, in velocity, in security defaults, in
documentation, in community support. Something that might seem attractive to a
newb who just needs to do something quickly might not appeal to a more
experienced developer who would rather have something that works more
correctly/securely/performant.

------
zerogvt
I'm not a web or compiler/interpreter dev so this is probably a noob question
but here it goes anyway. If the main complain about ruby is that it is slow
then why not trying to make it faster? I don't know how easy or feasible that
is but is there an effort towards that?

~~~
fouc
Absolutely. Ruby has had major performance improvements. Plus there's also
JRuby for those that want access to the Java ecosystem. Alternatively we can
detect bottlenecks and re-write those in a different language, such as Rust.

~~~
vasilakisfil
..or Crystal.

------
dhnsmakala
Man these language debates are so irrelevant when you're talking about web
apps. I honestly couldn't give a shit what I use, it takes like 2 weeks max to
adjust to a new framework/language.

Most people I know and work with feel similarly...and it's not some amateur
speaking here.

~~~
TheRealDunkirk
If you say you can pick up Java/Spring/Angular in 2 weeks... Sorry; I just
don't believe you.

~~~
sheeshkebab
For a recent developer - no, it’s impossible. For anyone who wrote code for
10+ years, picking up a new language and framework is typically piece of cake
(I’d say 80 hours is more than enough).

Complexity comes from learning a new domain - a web developer can’t learn
mobile, game engine, or HFT development in two weeks, but that doesn’t have to
to do with languages or frameworks.

~~~
TheRealDunkirk
I'm 49 years old, and I've been programming since I was 10, on a Vic 20. I've
been doing web development for 20 years, from Frontpage to PHP to Rails to
.NET to Java. Picking up .NET wasn't terrible, but I've been at the
Java/Grails/Spring/Angular stuff for MONTHS, and I'm just barely getting off
the ground. I guess I'm just old and/or stupid.

~~~
joelbluminator
I get you can't escape Angular (and friends) if you are doing front end, but
why not just stick to 2 things on the backend? php and java, ruby and .net or
whatever. I just don't see the point in doing Grails, Rails, Spring, Laravel,
Node etc etc instead of mastering 1-3 technologies really well.

~~~
TheRealDunkirk
I was told, essentially, that Rails is still too new and scary to be
considered secure and mature and ready for enterprise use, and that I had to
use either .NET or Java. There's another half of this project that's already
written in pure client/server Java, so that's what I chose. If I had it to do
over again, I would have chosen .NET.

------
pankajdoharey
Here is an Interesting trend on Githut
[https://madnight.github.io/githut/#/pull_requests/2018/2](https://madnight.github.io/githut/#/pull_requests/2018/2)

Seems Ruby is on a downward trend, while other languages are picking up,
Kotlin, Elixir , Lua , Clojure. Surprisingly Perl is also on an uptick. There
is a high traction for Functional languages and this trend will increase as we
transition to a more multicore world Ruby cant cut it in those environments,
JVM would stay but it isnt sure which JVM lang will be preferred in that
environment. Rails on the other hand is too convention driven and may not
survive what is coming.

------
patagonia
I’m looking forward to Crystal 1) getting a critical mass of developers behind
it and 2) (I consider this a deal breaker) supporting parallel programming.
Then, yes, Rails, in the incarnation of its proper successor, is more relevant
than ever.

------
tboyd47
The article is good but it completely ignores the rise of Python, which is the
main thing challenging Ruby in 2018.

Elixir doesn't really compete with Ruby. It may be technically superior, but
will never supplant Ruby because it's just not very accessible, and the timing
was bad. So it attracts different sorts of people. Same with Clojure, although
they really, really tried.

Javascript is the opposite; it gained and held the popularity advantage early
on, but is inferior to Ruby technically in painfully obvious ways.

Python is very close to Ruby technically, syntactically, and philosophically.

~~~
sam0x17
Python is definitely becoming the language of ML stuff, largely thanks to
Python being popular as a replacement for Java in academia. If you look at the
general trend, python is on the rise:
[https://trends.google.com/trends/explore?date=all&geo=US&q=%...](https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fm%2F05z1_).
If you look at web frameworks though, you can see that Python web development
has been stagnant since 2012:
[https://trends.google.com/trends/explore?date=all&geo=US&q=%...](https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fm%2F06y_qx,%2Fm%2F0dgs72v,%2Fm%2F04gsvp7).

~~~
sam0x17
That said, it looks like Rails interest is as stagnant as Python web framework
interest, tracking almost exactly with interest in them, just more popular:
[https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F06y...](https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F06y_qx,%2Fm%2F0505cl,%2Fm%2F0dgs72v)

------
viburnum
Rails is soooo boring now but you can't beat it for productivity.

~~~
sbov
Code with excitement. Code in assembly.

------
vinceguidry
Apologies for the length here, but it seems like programming language and
stack philosophy discussions simply require obscene amounts of length to
produce fully-rational arguments. Trying to cut back invariably forces you to
end the journey to philosophical truth with subjectively-felt emotion. Would
appreciate feedback on what could be removed without compromising legibility.

Programmers generally overvalue the utility of a programming language to solve
a particular _problem_ , undervalue the utility of fine-grained knowledge of
tools, and overvalue the utility of learning different paradigms.

We're moving from Rails to NodeJS, while it's not as drastic a change as, say,
Rails to Python would have been, it's a big enough change to where I can
slowly, over time, come to understand the absolutely stark differences between
the two ideals.

The first thing that hit me is there just isn't the availability of third-
party libraries in Javascript. We've had to re-implement functionality that we
had gems for, first for pgsearch, second for CarrierWave, and I'm sure there's
others. We undertook a fairly significant search for JS libraries that could
replicate the functionality, but failed, leaving us to spend 1-2 weeks to
write a bare-bones JS implementation.

I wrote the PGSearch implementation, and it involved studying the Rails gem
output and the Postgres docs and concatenating SQL fragments together in a
composable way. Luckily it didn't have to actually interoperate with
Sequelize, that would have involved another week or two of work, the
documentation on Sequelize is pretty far from Rails-caliber and I'd have
needed to source dive from day one.

The second thing that hit me is the immaturity of the semantics of the
language itself. When ES6 breaks, I simply don't have bandwidth to figure out
why, the project is just that new. Ruby never breaks, I didn't even know that
syntax and semantics of a production-quality general purpose programming
language _even had failure modes_ , that's how solid Ruby semantics are. But
I'm finding myself having to wrap my head around the concept of semantic
breakage in ES6, with frightening frequency. One day I'll isolate the root
cause of what makes things like destructuring assignment fail to generate
expected output, but right now workarounds are the order of the day.

I'm finding nothing really useful in those semantics that the team lead who
made the nearly-unilateral decision to re-platform that are in any way
interesting or even useful to spend time learning rather than just leveling up
my standard library and framework understanding of Ruby and Rails. They just
seem like hacky ways to do things that Rails already figured out clean
approaches to solve.

NodeJS and React in particular seems to encourage weird separations from an
OOP standpoint. Today I had the realization that routing is happening in both
a centralized place, a dedicated, declarative routes file ala routes.rb, and
more specialized routes in the controllers. This particular separation means
that if I want to understand how a particular controller action is being
routed, I must look in two locations rather than one, and if I'm starting
outward trying to get in, I need to remember that the centralized declarations
exist. When brought up, this was defended as "it works."

Of course it _works_ , what I want is flat, easy-to-traverse declarative trees
of definition. Is there a way to get to that? Not without breaking the
conventions of Restify. This is something I didn't realize I'd come to lean on
in Rails until it was gone. The semantics of modules in ES6 favor composition
and discourage inheritance. A composed class in which the components live in a
separate file than the parents needs special tooling so that you can
understand the parent if all you have a reference to is the child. Otherwise
you have to remember. JS fans seem to love to rely on memory.

Lack of clarity in the codebase forces me to use a debugging REPL to ascertain
program behavior. This is another area in which no available JS-ecosystem tool
even comes close to the power and utility of just dropping in a one line
invocation into the codebase, cmd-tabbing over to the terminal or browser,
then up-arrow and enter in case of the terminal, and cmd-r in the case of the
browser to re-execute the code path, then immediately running commands in the
context of the running application.

This fluidity appears to be impossible to find in Node, though browser
debugging is mostly on par. I need it because I need to move the debugger
around to ratchet closer to the source of the defect. Every extra keystroke
matters. The three or so extra actions required in Node to get the debugger
working is unconscionable, the sheer pain of it discourages a debugger
workflow and relegates me to using logging statements, which, again, has a
strictly worse standard framework implementation to Rails'. I could get into
why, but this is way too long as it is.

It's not that I want to work with Node the same way I work with Rails. I'd
love to be able to appreciate the Node Way. It's just that the Node way is
cruftier and hackier.

This hell has me yearning to get back to the motherland. And I haven't even
touched the differences in the metaprogramming workflow, which could easily
double the size of this comment.

~~~
tinco
Straight up porting an app from Rails to Node.JS seems like a bad idea to me.
Not that I'd ever consider using node.js, but the whole appeal is that you can
quickly build small services, with either an integrating endpoint or a
straight up api in front. If you're just replicating your Rails monolith you
forfeit all the benefits.

To be clear instead of node I would consider either Ruby because it is more
comfortable, or golang for it's simplicity and performance.

~~~
vinceguidry
Preach it, brotha.

------
adamnemecek
I find the “just tools” attitude to be such an Anglo meme. On the other hand
the French say “Good tools make good workers.” I agree with the latter.

~~~
collyw
"A bad workman blames his tools" is a counter to that.

~~~
adamnemecek
That’s not a counter.

------
casper345
"A chainsaw is an amazing tool, but you would not use it for all your home
projects"

Alot of divides and conflicting ideas in coding languages, framework, and even
development processes agile vs test driven. But to build a castle in the sky,
you cannot rely on one tool in order to build the whole thing. Use whats best
for that case and use another tool for another case.

------
zerogvt
" Long story short some decent friendly developers were highly criticized over
minor jokes they say on social media.

    
    
        I’m not going to name that language as it would just spawn a fire of outrage comments from that community. It would just prove my point but at the same time I’m not suicidal.

" who would that be?

------
abhchand
I'm not sure why this question keeps coming up in the developer community. Is
Rails seen as a fad? Thousands of successful sites are built on it. It's
incredibly easy to build even a basic app. It's the intersection of
development speed and robustness that caters to the startup industry.

------
acangiano
Do you want/need to build an SPA? Take something like React and pair it with
an API built in Node/Go/Elixir or something that offers great performance out
of the box.

Don't need an SPA? Rails is one of the most productive options out there.

------
jbernardo95
I guess this question pops up here once a year. And the answer is always the
same.

------
TheRealDunkirk
While I've done a lot of work in .NET and PHP, I've used Rails as my go-to
tool for over 10 years, since early 2.x days. I got moved into a new role at
the beginning of the year. I was in the middle of rewriting yet another legacy
Java web app in Rails. Some jerks got involved, and I was told that I could no
longer use Rails because I was the "only one" in my 38K-employee company that
used it. I said that Rails was the most productive thing I've seen in
programming in 15 years, and asked why in the world "we" wouldn't hire for
that skillset. We "moved on" in the meeting.

Predictably, I was forced into using "Java" for my current project. After some
experiments with Grails, I settled on Spring Boot, and Angular. However, I'm
stuck trying to build a CRUD page with a dropdown list of options for a
nested, associated model. There's no example of nested models in the official
docs, and every tutorial on the internet 1) wants to spam me about emails,
books, and classes, and 2) stops short of showing an actual, working example
an editing component with a nested model. Combine this with the fact that
searching for anything on the stack leads to examples from AngularJS 1.x, 2,
4, 5, and 6, and now they've just released 7. And even if you stick to the 2+
series, you have NgForm, Reactive, and Dynamic templates to sort thought.

If you'd have asked me if I thought finding good examples of this would be
easy before I started, I would have called you crazy for suggesting that it
would not have been. Yet, here I am, months into this project, and it's a
daily struggle to find good examples of some of the most basic things I took
for granted in Rails. Just yesterday, I found a SO Q/A that spoke exactly to
the situation I'm trying to code at the moment, and the very-highly-upvoted
solution simply does. not. work. At this point, I still don't know why.

I sat down the other night while I watched a movie, and got more done in Rails
-- just for the fun of it -- in a couple hours than I've gotten done with
Spring/Angular in a couple weeks. You want a dropdown list of associated
models in an edit page in Rails? That's, like, 1 line of code in 3 source
files, and you can find examples of it in the official docs, and hundreds of
good web pages about it. In Spring/Angular, I need a dozen more source files
to describe the interfaces and objects to the compiler, setup repositories and
controllers, models and components, and THEN write the template.

There's absolutely no comparison in development velocity between Rails and
Java, and I will fight anyone who says otherwise. I could have had a working
site up and running in Rails in the time it has taken me to bootstrap a
development environment and get some models created in Java. (Manifestly not
true, but that's how it FEELS at the moment.) I'm wondering what I'm missing.
How is this the stack that seems to have absolutely captivated online
discussion of programming for the past couple years? Maybe Angular WITHOUT
Spring is really great?

My personal belief is that, just like some people gravitate to Windows, and
some to Mac(Linux/Unix), there are people who just _like_ how Java works, and
some who like Rails. Some people like to specify absolutely everything in
code, and some people like letting the framework do the boring parts for them.

The bottom line is that I still don't know what stack can even hold a candle
to the productivity of Rails.

------
JamesAdir
The number of the language occurrences in August 2018 Who is hiring thread:
React 377 Python 306 Node 153 Ruby 118 Rails 113 Django 69

Just numbers to think about. It's not scientific in any way.

~~~
douglaswlance
Occurrence is an interesting metric. It'd be great to see the pay ranges
associated with the number of occurrences. It may be easier to get a React job
because there are so many, but if the pay is much lower, then it isn't a good
idea to focus on that avenue of attack.

------
diegoholiveira
I do believe that Rails will be sexy again when Ruby 3 cames out.

------
sunstone
If you're a railway, rails are definitely still relevant.

~~~
yellowapple
If all you have is a tramcar, everything looks like a rail.

------
bishala
Rails is still very relevant in 2018. The meme templates used are from 2011
though.

------
symlinkk
I think the fact that this question is even being asked says a lot.

------
ravenstine
It's still relevant if someone is paying you to use it.

------
omarforgotpwd
100% yes

------
mseidl
"There is no “bad” programming language, only badly chosen project where you
would use that programming language."

 _cough_ php _cough_

------
stevebmark
I struggle with how to say "both Ruby and Rails are poor technology choices"
without sounding ranty. I have seen nothing good come from the flexibility and
non-portable conventions of these tools. I have seen so much nicer web stack
designs than Rails, with none of the problems. Maybe if you're building a
Basecamp type site - slow / speed doesn't matter, limited views / minimal
front end functionality, small surface area, trickle of users - maybe you
won't notice the downsides.

~~~
whalesalad
This viewpoint is so far off from reality that I don’t even know how to
respond.

GitHub, Airbnb, Shopify, Indiegogo, Kickstarter, Urban Dictionary... the list
goes on and on and on. Having the hardline opinion that Ruby or rails is slow
is plain ol’ ignorance. You can build highly performant apps in Ruby and
Rails, you just need to know what to optimize. The same applies to any other
language or platform. Facebook is still humming along on PHP.

~~~
wonnage
Pretty much no Rails app at these large companies can even do something as
basic as concurrent network requests. This is an area Ruby the language is
weak in, and it's extremely difficult to graft on something like concurrent-
ruby to a large existing codebase that assumes all requests are sequential...
Also, in the past the multithreading/concurrency story around ActiveRecord has
been "it probably works, might leak connections", and you will probably
deadlock your dev mode server as a side effect.

Ruby is slow for humans too. Code intelligence/IDEs are hamstrung, thanks to
the constant possibility of run-time monkeypatching. You basically are stuck
with grep. It's fine if you have 30 engineers all familiar with Ruby and the
codebase, not so great with 100s of engineers trying to figure where things
are. Things get worse if your engineers embrace writing DSLs in Ruby and you
now have to debug a mini language-within-a-language.

The dirty secret at large companies is that the majority of the codebase sucks
and is maintained by a legion of new grads who are doing their best to ship
code before deadlines. Ruby is not the answer.

~~~
joelbluminator
Ruby has threads, when networking the GIL doesn't matter since the threads
will context switch. For a company like Shopify paying for an extra 50 servers
is like hiring one developer, I don't think it has much significance to them.

~~~
anotheramala
JRuby can solve that problem. Threading in Ruby. Some companies do use it:
[https://github.com/jruby/jruby/wiki/SuccessStories](https://github.com/jruby/jruby/wiki/SuccessStories)

------
pankajdoharey
Rails is over there is too much traction for Functional Programming these
days, and Javascript seems to be the easiest language to explore functional
programming and Composability. JS and Nodejs in my opinion are the best and
most used langauges in 2018. Also Rails is not beginner friendly, if you are
using Rails for a few yrs only then you can understand tons of quirks and pre
written code in your controllers. If you are unaware the evolution of quirks
then it may seem alien to you. An interesting framework to me seems to be
Hanami, compared to Rails. Also if you are feeling Brave then Try Go or
Clojure. These are excellent languages and are targetted to solve particular
niches they serve. Both of these Niche areas they serve have grown
significantly in the past few yrs.

~~~
keymone
> JS and Nodejs in my opinion are the best and most used langauges in 2018

most used? probably. best? not even close. the main reason transpilers from
other languages into JS became so popular this last decade is because JS is a
horror shit show of a language.

~~~
pankajdoharey
I said for 2018. The App ecosystem has changed a lot since 2005 when rails was
Released, more apps these days use a combination of JS + Firebase. For most
CRUD styled SPI's this is the "best" way to write apps. Rails is no where in
this ecosystem, it still depends on age old Nginx+SQL+Rails style, but the
truth is most new apps want to start small. So for 2018 JS is the "Best"
unlike Rails. The number of transpilers that exist for JS is an indication of
JS invasiveness, its ubiquity and simplicity to transpile to. Since JS is a
much smaller languaage than Ruby it is easier to transpile to. Some languages
do give better tools of abstraction but at the end all those higher thoughts
are implemented in the same JS which is a good indication of its usability,
There are good and bad parts both in JS, but i dont think it is a complete
shit show, just better educate yourself as a programmer to use the good parts.
I think you are not aware of the interesting ways you can write composable
code in JS. Rails depends on the Magic of Ruby, one can write great DSL's is
Ruby and thus Rails, But Rails with its MVC toolchain alone does serve the
needs of large apps, it is OK to do CRUD apps, but for large apps MVC breaks
inside Rails. This is a big reason why a number of people have switched back
to simpler ways to do things like Routing+Templates+Glue Code makes a webapp
such as in Express.js , Rails is simply too big when it starts, with too much
magic that people dont want to bother with. Which is why more Apps these days
are activated in Nodejs frameworks. There is a reason for its popularity it
isnt a coincidence, there are things people like in JS/Nodejs/Express.js that
it is so popular.

~~~
keymone
The reason for its popularity is like with Java and C++ and C# - a combination
of unfortunate feedback loops: companies are looking for cheap developers
familiar with technology they already use.

Has nothing to do with JS’s or ecosystem’s sanity or (nonexistent) advantages
over other languages.

------
iamleppert
One thing you'll run into with rails in 2018 for web development is it's going
to be hard to find developers and only getting harder by the day. Rails
developers are aging. They are no longer your 20 year old hipsters, that
stereotype has long since gone, they have families now and boy are they
EXPENSIVE. React is what people new to web development are LEARNING and that's
all you need to care about. You can get react developers, who can
fundamentally produce the same thing (your run of the mill CRUD apps), for a
lot cheaper and they are (more) readily available. Anyone who claims that
rails does something magic the others don't do by now is showing their
allegiance rather than making a factual technical statement.

In a few years I expect the problem to worsen as react chips away at rails,
and with no standardized reactive SPA (maybe save for ember), more and more
developers who aren't die hard rails/ruby guys are going to be rebranding
themselves, who will then be in the pool with the rest of the react
developers, which, also seems to have crossed an inflection point recently.

I also encountered a few guys who had rails experience but wouldn't take the
job because they didn't want to risk falling behind on react. Sad but true.

This post isn't supposed to come off as agist, its just an observation when
working in a tech field that is largely driven off fashionableness, trends and
approval, rather than strict technical merit.

~~~
bdcravens
Why would you compare a backend with a frontend framework? Are you implying
Node on the backend? React developers are dependent on a backend, be it Node,
a managed solution like Firebase, or Rails.

I don't think it's a matter of React instead of Rails, but rather, Rails
developers are learning they must add frontend skills, and React seems the
safe bet. Many are probably shifting to Node, given the idea (true or not)
that Javascript in the entire stack makes the most sense.

~~~
iamleppert
I’m talking about your traditional rails app with classic templates views and
controllers (no SPA) vs. react + node (express) stack.

~~~
bdcravens
Guess I was correct about the unspoken assumption :-)

Keep in mind there's no real React default. You can pair React with a Rails
backend pretty easily (or Elixir or .NET or ColdFusion or PHP or ....) It's
really just a matter of what you have in place or what your developers are
already competent in.

