Ruby on Rails is out: major coding bootcamp ditches it, due to waning interest
thenextweb.com
thenextweb.com
I still love Rails, but when your front end is mostly done using React (or something similar) you lose many of the advantages you previously had when almost your full stack was inside Ruby and Rails.
The latest version moved in the right direction by making Webpack a first-class citizen, but what would really make a big difference would be some kind of native integration of a mature front-end framework. My personal choice would be React, but anything would do as long as the connection between the Ruby API part and the Javascript front-end part followed the DRY and "convention over configuration" principles that made Rails great in the first place.
If I could scaffold CRUD interfaces with basic React components already integrated with the Rails API, and then start developing from there, I would become a much happier programmer :)
Trufflejs and Truffleruby are high performance engines implemented in top of JVM JIT. already trufflejs claims reasonable compatibility with nodejs.
It would be amazing to have a single runtime running a Ruby backend and a react front-end.
ASP.Net MVC has the same issue, but Microsoft headed that off by creating WebAPI, which is a better fit for the single page applications. Not that you couldn't do everything in WebAPI in MVC, but MVC was more of a website framework, while WebAPI has no rendering capabilities.
This. I also suspect that for developers whose first language - or primary language these days - is JavaScript it's a lot more comfortable to reach for a Node backend framework when they need it. Also, Go has become pretty popular for somewhat more custom or complex backend tasks. Plus, there are more and more high-level third-party services offering different pieces of backend functionality.
But when I need more (auth, orm, logging, etc.), I feel like I'm spending more time searching for and curating packages and then trying to get them integrated than I am actually building an application.
Rails (especially its API flag) has caught my attention recently because this becomes a non-issue - you pretty much just use what Rails has included.
Frameworks like Rails and Django cover a ton of functionality and gluing together and maintaining a set of packages to cover even a fraction of that functionality is a ton of work that's often for very little gain.
The goal is still the same - get up and running with an idea as fast as possible while not being cornered - scaling with the product. The FE has simply become where most of the effort and innovation is now. Rails will benefit from helping on that side of the coin.
I haven't kept up-to-date on Rails news, but I thought the Ember.js + Rails pairing was supposed to be their long term answer to that problem. (In that, "we support using Rails with everything, but Ember.js is the philosophically-similar, lowest-friction option"). Is that not happening anymore?
But it really is a one-way relationship. Rails itself now has webpack included as of 5.1+ and its implementation has integrations for React, Vue, Angular, and even Elm - but no Ember. I don't think the Rails core team is opposed to Ember insofar as they're just embracing what appear to be the most common or upcoming SPA frameworks/libs. Ember just never really broke out.
I myself would often spin up a rails api + react frontend.
With rails 5.1 and especially webpacker_react I've seen a possible new direction which combines the best of both worlds.
I think we could see something pretty exciting in this space soon if the integration of rails+react can tighten up a bit.
You lose a lot of that when you go away from Rails and start using a JS based front end. It's not that rails-api doesn't work - it works quite well. It just neutralizes, to some extent, the productivity gains you got from rails.
Here's a quote from the rails doctrine that sums it up nicely: "Rails specifically seeks to equip generalist individuals to make these full systems. Its purpose is not to segregate specialists into small niches and then require whole teams of such in order to build anything of enduring value."
I actually think Rails is still an excellent choice for small to medium business apps implemented as a series of web forms backed by a database. The productivity Rails brings in that case is pretty amazing. And you certainly can bring in a bit of javascript in a progressive development fashion and maintain simplicity and order.
What drives me nuts is when people write an SPA to stand in for a set of web forms, with almost no gain, and a huge increase in complexity (and drop in productivity). Sometimes I get the feeling people on HN are working on more cutting edge stuff. Truth is, an awful lot of business software really is a series of web forms persisted to a database. I do think you can get these apps done with half the staff, twice as fast, with better code clarity, stability, and test coverage, by sticking with Rails. In fact, the slowdown in Rails activity is probably a good indication that you should use it for these apps, not that you shouldn't!
I also really like your comments about an integrated front-end SPA (or other client-side heavy) framework. I don't see javascript having quite the clarity of ruby on the page, but it could be tidy enough to be no problem. I do think something like this will emerge, eventually.
Until then, I'd be tempted to stay with older technology. Remember the churn around spring di, pico, struts, struts 2, spring mvc, hibernate, JPA, ibates, stripes, tiles, etc...? Or, ahem, EJB? All(some?) were good frameworks written by intelligent people trying to provide value (and, in many cases, providing that value). But I wish I'd just stuck with slightly more vanilla jsp/jdbc/servlets + cookbook for a while longer. Why? Because after investing a ton of time and mental exhaustion into those frameworks, I ended up using... Ruby. My guess is that something similar will happen in the current JS chaos. Something will happen that addresses what these frameworks seek to provide, but how it happens will also be somewhat unexpected (though if I had to make a guess, I'd bet on some sort of isomorphic javascript, with a transpiler that allows people to use Python, Ruby, and other languages, breaking there JS monopoly).
Just because you see an expiration date on the milk carton doesn't mean you can't drink it for another week. My guess is that my time with Rails will be up before too terribly long, but that doesn't mean you need to start writing javascript-heavy SPAs now.
Unless, well, you do have to. Unfortunately, my guess is that a lot of people writing this code aren't doing it because they're on one of those projects that actually really needs it (or benefits substantially from it). We have to do this because our orgs require it, a software architect said it should be used, or because we know we won't get hired for our next gig without this experience, so we bring it into our current project even if it isn't helpful.
Ruby itself seems to have settled into a groove. I don't see it ever getting too much faster, which is fine with me. I mean obviously I want moar speed but as a glue language, I think it's fast enough for what it is. GC has been pretty nice since 2.2 or so; we basically don't worry about it in our big monolith app at this point.
Rails is... kind of wacky, still, but again, decently mature... mature-ish. Mature enough. At least compared to the insane Lovecraftian existential dread-inducing abyss that is the Javascript ecosystem.
(I realize the article's about Java, not JS, but let's face it. JS is siphoning people away from RoR, not Java. Java devs have always been in demand; that's just something boot camps have ignored because it's popular but not trendy)
ruby 3 will be 3 times faster http://engineering.appfolio.com/appfolio-engineering/2015/11...
> Rails is... kind of wacky, still,
in what manner? it is one of the most well well crafted and thoughtful pieces of software i've ever used. It has never been "wacky" for me, behaved unexpectedly, or require convoluted effort.
> ruby 3 will be 3 times faster
I'm not entirely sure the 3x speedup is possible; it was just kind of a vague goal from Matz meant to be a rallying cry.
You can get a taste of the future today with bootsnap (not to be confused with Bootstrap) which enables roughly 2x faster app startup thanks to compiled bytecode caching.
The other major speedup on the horizon is probably the effort to make all objects invariant by default. You can get a taste of that today with frozen string literals, though the impact is not huge, which is why the "3x faster" thing seems like a stretch to me. (It's possible that more impactful optimizations are possible if/when this invariance-by-default becomes a core language feature)
I'm no low-level Ruby VM hacker though so my opinions are not especially well-informed. I hope I'm wrong and we soar right past 3x and get a 10x speedup eventually. =)
> in what manner? it is one of the most well well crafted and thoughtful pieces of software i've ever used.
Most non-trivial Rails apps need to veer off the rails at some point due to user/business needs, and that's when dealing with Rails (and the tendrils it has wrapped around so much of Ruby) gets tough.
> The main wacky thing to me is the way in which it modifies so many core Ruby classes.
Ok, fair enough. I actually wish they were part of ruby, more often than not. But I do appreciate them, and use them often. I don't have a puritan objection to their presence, though. I view it as making the world a little nicer.
> Most non-trivial Rails apps need to veer off the rails at some point due to user/business needs, and that's when dealing with Rails (and the tendrils it has wrapped around so much of Ruby) gets tough.
I must disagree with you about jumping off rails. There are numerous, complex large scale applications out there, running on rails. Github, hulu, shopify, basecamp, to name a few. I've worked on complex rails applications and they've performed really well, overall. On top of that, they were approachable and maintainable, even for junior devs.
Most businesses are in fact fine starting on rails, and staying on rails. When i say most, I mean 95%. Short of becoming a twitter or reaching similar huge scale, rails will carry you very, very, very far.
I've never been truly bitten by ruby performance, or ever found it so
Mostly, performance is an issue with large apps and their rspec run times and app startup times. (And of course, those are not purely -- or necessarily even primarily -- Ruby's fault, but still)
There are numerous, complex large scale applications out there, running on rails.
Don't get me wrong, it's not awful, it's pretty good.
Most businesses are in fact fine starting on rails,
and staying on rails. When i say most, I mean 95%.
Our big old Rails monolith (started on Rails 2, currently on 4.2, and hopefully on 5.x in a few months) has carried us to about $500mil projected revenue this year. Could other stacks have done the job better? Quite possibly, but they quite possibly might have been much worse as well. =)
I hear you! I hate long test suit runtimes, and they are easily grown. I made a gem to address this, by running your test suite across a cluster of cloud VM's and reduce test times from 30 minutes to 30 seconds. http://github.com/meesterdude/cloudspeq
> but that's where the "convention over explicit configuration" stuff becomes a hindrance rather than a help
I feel It just gets you going - you have a foundation you can run with - and one that other devs will know "out of the box", which means onboard is easier/faster. But it's never meant it's not configurable. You'll still need to cache, to adjust web servers and background jobs and all of course. But rails makes it possible, easy (and fun!) for one person to do all that.
> Our big old Rails monolith (started on Rails 2, currently on 4.2, and hopefully on 5.x in a few months) has carried us to about $500mil projected revenue this year.
Dayum! Well done! Do you know how many requests a second you serve and the avg. response time?
> Could other stacks have done the job better?
I think so long as you haven't been severely bitten by scaling or performance issues; the product itself is what matters so long as the technology can deliver on it. Clearly you're doing pretty well regardless! Proof is in the pudding.
1) it is a comprehensive and easy to pick up stack, at least for proficiency at a jr. level that a coding school would churn out in 3 months
2) it was hot at the time of the rise of the bootcamps, so from a marketing perspective would attract top students
3) RoR shops would be more amenable than most to taking on bootcamp grads and continue to embrace a mentor/mentee relationship for long-term success
I think largely #3 is the reason for the switch - bootcamps have now been shown to be a valid source for jr. devs and the enterprise is open to it, hence making java curriculum worthwhile - it certainly will scale better. We're still stuck on #1 though...
Of course they ditch Ruby/RoR if their customers want to learn the tech that is in demand.
You seem to be agreeing with the article but disagreeing over phrasing?
Ruby and Rails aren't special anymore, there's lots of other languages which can do the same thing but have huge advantages. Then again, that was the case going back to 2007 (Pylons is but one example - the Rails template on a better VM and with more libraries available and none of the bloat and magic). Rails has always been about hype and that hype doesn't matter when other stacks have 10x the performance and are just as productive.
Brb, gonna go kill some zombie fcgi processes.
Otherwise, there's nothing there other stacks don't have. Scaffolding generation, validation, command line tools, good templating, routing, routing for apis, ORMs, etc, that stuff is built into almost any framework these days and if it isn't it is because you are using a microframework by choice. You have dozens of frameworks across various languages that approach the functionality of Rails.
Django is certainly very comparable, and a good Django dev can pump out apps as quickly as a Rails dev. Stacks in other languages are doing things Rails is incapable of and they have borrowed all of the benefits (because Rails does a lot of things right).
You had the same routing, you had very very fast templating in Mako, the best ORM in the business in SQLAlchemy, all of the tooling around Rails (scaffolding, testing, etc) and the best part of it was it was all designed to be easily swappable. Didn't like the files that were getting generated with your project? Tweak Paste. Different templating system? Few lines of code to be swapped out.
It was a very forward-thinking and well-designed framework at a time when the Python VM was much better than Ruby. Feature for feature it was better than Rails, it just wasn't as popular.
Rails is really stable and has a battle hardened community around it. That's a good combo for teaching, learning and practical usage.
When it comes to teaching / learning / real world usage, the last thing you want to deal with is 18 new versions of 5 different tools every month.
[0]: https://www.kickstarter.com/projects/leotrieu/build-your-own...
I'd love for bootcamps to stop teaching Rails so the rest of us can start raising the bar again.
this is my takeaway as well. It's still lightyears ahead of anything else out there, and the bang for the buck is hard to match.
Many of the core team members of Rails have long moved on to other technologies.
Companies don't see Rails as something that will give them an edge anymore. Yes, it is quick to develop a prototype in, yet the ongoing performance optimizing burden and the mess it becomes at large scale are not worth it anymore.
Competition has been catching up, and many modern frameworks have taken the best out of Rails, while ditching the not-so-good parts.
The job market for Rails devs seems to be pretty dry. Many Rails devs I know, including myself, do not get even 10% of Rails job offers anymore, as it used to be until a couple of years ago.
Ruby, as a language, is completely stuck and stale, and has been for a long time now. There is no real innovation, the single-threadedness and the GIL are just not good enough in 2017. Ruby 3 has been announced for 2020, and if you ask me, what is promised in terms of features is rather too little, too late.
Rails, as a framework, has been steadily releasing improvements and new features, yet those are either not that relevant, or poorly implemented (e.g ActionCable). The framework's creator, DHH, has been very opinionated about the strength of Rails monolithic approach. To me, this is not where the industry is heading (like it or not) and Rails is going to have a tough time keeping up with the latest software architecture trends like microservices (again, like it or not, microservices are here and they solve real problems).
Rails will be there for a long, long time, no doubt about it. But for many of us, it's just not that sharp knife it used to be anymore. Better accept it sooner than later.
Most of it really just goes back to the fallacies of distributed computing. A lot of people don't think about ways that microservices, by way of being decoupled, can be less efficient or fail between components, the network, etc where a monolith can't… until after they're built (or never).
The majority of apps in the world don't reach the point where the benefits of microservices outweigh their tradeoffs. Or they choose microservices to fix a problem that is really that the app is not decomposed well into clean modules and components. Even the creator of microservices says to go monolith first (https://martinfowler.com/bliki/MonolithFirst.html).
Ruby(VM) is unfortunate for not attracting critical mass of users and capital. I mean cmon you can't really compare jvm.clr,v8 and ruby vm. It really is unfair. Ruby supports a lot of magic,different paradigm and the runtimes mentioned earlier received billions in funding over decades. Of course they are "fast".
I mean you need really expensive ingredients to succeed in 21st century in tech. You can be fast and elegant (Crystal,Nim) but what does it matter if you are not mature enough (java,c#,js). Or you are mature enough (ruby and its ecosystem) but you are not fast enough and you did not try enough to cover other markets (adoption by big companies was fairly low, Rubymotion was a poorly executed project so no Android/iOS coverage because of the high costs and lack of interest from community)
The thing is, as you point out, the world has moved in this decade and we have seen most of the Rails key points transposed to other tech stacks, old elephants learning new tricks --see Symfony in PHP, Spring in Java, etc...
Add to that that Rails is mostly feature complete: it's the best tool for developing what DHH calls "elegant monolyths", and I feel the proposition remains true.
But, as the rest of tech stacks has moved on, so has happened in the edge tech stacks, with things like microservices, concurrency, async frameworks, etc, i.e: Node -which seems to be waning due to JS fatigue, Elixir... Rails doesn't seem to be targeting those because Rails doesn't need them.
This is kind of a sad reflection, but Rails is the best frameworks for building things that the industry needs less and less: it is neither "enterprise" in spirit, although it is in capability, and is neither the cool kid in the block.
We will see less developer mindshare because "cool" devs will have moved to sexier things, and "enterprise" teams will go the way of the newer .NET and Java buzzwords.
Microservices are cool but a nightmare to manage,maintain and keep everyone in sync. It's a buzzword in my book but I believe only a handful companies can really benefit from them.
Java/C# are strong in enterprise and while this community dismisses enterprise what I mean is that it is used everywhere and by everyone. You want to communicate to some obscure endpoint that manages this container ship ? SOAP api is there to serve you along with ready to use libs.
Besides..
C#/Java You want to build desktop apps ? Check You want to build mobile apps ? Check You want to talk to hardware (printers,peripherals) ? Check You want to build APIs ? Check You want to build Games ? Check You want to build traditional web apps ? Check
Thanks to Facebook and other companies this is also becoming more and more possible with Javascript as well.
What can Ruby/Rails offer ? Not much.
I'm not sure that's at all what he was saying, though.
Sure, sometimes they do. But more often than not they introduce more problems than they fix, or at best, they fail to fix the original problems.
Most of the benefits that people who choose microservices are looking for come more from good design and are completely orthogonal to microservices vs monolith. For example, separating code out into separate repos and deployments doesn't automatically separate concerns. But microservices inherently introduce a lot of challenges in orchestration, managing state, testing, deployment and all kinds of things that are much easier with a monolith.
Microservices is one of the most cargo-culted ideas in software development these days. I suspect there will be a backlash against it before too much longer. Will there be a resurgance of interest in Rails? Probably not. I suspect something at a much higher abstraction level will take over.
Today, web clients are a thing for many applications (and I build some too). So we're left with RoR to build static pages and APIs, which seems clearly overkilled. I still use rails on many projects, because it's cool how activerecord and actioncontroller allow to build something fast. But actionview, journey, the helpers, the asset pipeline, etc all feel like we're bringing in a lot for no advantage, when writing web clients.
Very rarely does anyone say this. But both Matz and DHH were slow to realise those problems. Cant really blame them since Matz dont even write much Ruby, he write C. And if Rails is all about extracting code from Basecamp. May be Shoptify, GitHub and Cookpad ( All magnitude larger then Basecamp )should step up the game for Rails development.
Outside Rails, Ruby fail to attract any Scientific usage, or even General Programming.
RoR wont die. But it will likely falls into a niche that will gets smaller and smaller. May be yes, it is too little too late.
I would then move on to learn about elixir and Phoenix if I were in your position. Phoenix is similar enough to the good parts of rails but all the really nice stuff is way better than rails. ActionCable in rails is a joke compared to what elixir can deliver.
Or, if you ask me, learn Elixir + Phoenix. I'm betting part of my future career and my company on it, because I believe that it's the future. But Go, Clojure or Scala are great choices for web development as well these days.
I have a fair bit of Java experience but it isn't current (I did Tomcat-based stuff).
The Web 2.0 concept, which was mainly just marketer-speak for using a lot of AJAX, survived and continued. Agile survived but was transformed into its own opposite. Rails continues, but it has lost its ability to draw newcomers, which was its source of vitality. This is not because the technology has changed, but because the world around it has changed.
In a lot of places, learning Ajax was synonym to learning Web 2.0.
I guess a better metric would be the amount of upvotes over time for questions and answers about a topic.
Most experienced developers who know their language just use API docs if needed to get things done. Sure there might be some obscure edge scenario you need to ask a question about once in a while.
Beginners ask lots of questions also new languages/frameworks will generate interest and questions. That doesn't mean those are the things that are most used or most in demand in the industry.
Also SO primarly contains questions on open source based web programming. This discounts entire sectors of the industry using proprietary tech.
SO likes to publish their metrics since it brings more attention to them, its marketing, they are a business.
A good way to track things would be if job postings (not just SO careers) could somehow be marked as filled. Then you could ascertain from the description what tech stack is used.
Yes, that's when you notice a technology is becoming more mature.
But that doesn't mean there will not be any new questions however. When technology evolves people will have new questions. So the number of new questions may be a valid metric for how much the technology is evolving.
I agree that number of new questions does not directly relate to popularity. To do that IMO we first need to find out the relation between popularity and evolution of technology.
> I guess a better metric would be the amount of upvotes over time for questions and answers about a topic
To measure the total number of people who experienced that particular problem, yes. Not to measure the popularity of a piece of technology IMO.
But I'm not anywhere near an expert on this :)
How on earth are those alternatives for Rails?
With ES6/ES7/ES8 becoming reality, I would welcome a move toward a JS/CoffeeScript framework that allows sharing of code between client and server.
But of all the options I have seen, nothing offers the simplicity of elegance of Django's Models and REST Framework's ModelSerializers.
It's really a shame there is no "perfect" isomorphic alternative to Django and Rails, because so much time is wasted doing the research and making the tweaks necessary to get the client and server to talk to each other properly. Not to mention having to learn the intricacies (and idiosyncrasies) of two languages and avoid mistaking one's idioms for the other's.
One of my long-term goals is to learn enough JS/CoffeeScript to be able to port parts of Django and REST Framework to Node.js and the client, along with enhancements that make pub/sub easy, and glue that enables effortless connection to a view library like React.
I realize there are existing solutions that almost achieve what I want, but none is ideal (Backbone doesn't support ES6 classes and doesn't do isomorphic out of the box, Meteor prefers MongoDB over an RDBMS, etc.)
Seems to me that Python is a much more mature language than JS.
Meteor+React [1] is also very interesting, but my understanding is Meteor doesn't support relational databases out of the box.
[0] http://sailsjs.com/ [1] https://www.meteor.com/tutorials/react/creating-an-app
Given that there are no tightly integrated monolithical frameworks in JS land, I doubt there will be for a while.
As soon as I read that, I just stopped. I know the point of this article is to get a big reaction out of the dev community. I'm quite happy with my Rails back-end and React front-end, thank you! Stable, tons of community support, quite fast for my needs.
Only Siths deal in absolutes?
I'm happy to switch to another full stack framework if I can see a clear benefit but as yet nothing comes close.
If all you have is a plain old text editor, you may still have a point, but I feel like the time-saving tooling (static analysis, etc.) in other systems have improved considerably over the years and the Ruby/Rails ecosystem hasn't kept up nearly as well.
Spring makes it easy and fast to develop web applications, AND evolve them in time. A lot of things are ready out of the box, but you can easily customize many, many parts of your application when and if you actually need it, substituting what the framework would do for what YOU actually need. I haven't found anything like that, yet, in other web frameworks (admittedly: there's tons out there, so I probably tried 1% of them).
Go look at those benchmarks again. Over half of the top 10 are JVM servers.
I have no idea what point you're trying to make with regards to complexity or some kind of server vs framework distinction.
If anything, what's popular among coding bootcamps is more indicative of the kind of junior positions which are more readily available.
I'd say many shops have had a similar experience, and full stack development no longer depends on rails for frontend. Which means that the only rails jobs out there, are likely backend/API/distributed systems.
There was a time when I thought rails was out the door and node.js was in, and I converted several large rails codebases over to node.js/express. Looking back, I don't think the node.js community was strong enough, and even today I still miss Ruby's debugging ecosystem.
I once sat down to write a medium post a few years back on why rails is still the best choice for backends. I would cite the number of packages for sidekiq, the diversity of email handling libraries, and the multitude of packages to handle just about everything. I compared it to rust, and go. The only problem was, any time I tried to say "rails has this, X doesn't" Go had X.
Rails will stick around, but I'd recommend smart engineers diversify. Study modern node.js codebases (things have gotten much more manageable with await/async). Study Go. Also, check out actioncable, and start a new rails project with "rails new --webpack=react" and build something. Seems the rails team has embraced the modern world, which may make it one of the best cohesive ecosystems right now.
This says much more about the fact that coding bootcamp grads tend to go into bigger companies more than abything about Rails itself.
JS-heavy frontends and JVM microservices can end up being antipatterns from a user perspective. Increased engineering costs and decreased battety life are not strong selling points. When implemented poorly, SPAs and microservices are scarcely better than make-work for developers.
Most of the time, you should just use Rails and be done with it.
I learned of the framework early-ish and following it introduced me to good concepts that I would not have pursued - my undergrad program was ASP.NET forms based.
However, as much as I enjoyed developing with the framework I only got my foot in the door somewhere I got paid for it once. Honestly, that is my favorite project I've done to date (https://www.wvencyclopedia.org/maps - mapping portion only).
So I wish I would've gotten to do more with it, but screw all those Rails shops that would not hire me - and have probably moved on 3 times framework-wise since then anyways. :)
I ported Ruby 1.8 to the IBM Blue Gene/L. Nothing out of a dislike for Ruby, it is just that Python libraries far surpass what is available in Ruby land.
Maybe I have low standards, but the benchmark for me is how long to write an app that populates a SELECT form field based on a domain table.
By defining both together, you reduce the amount of break points I'm your code dramatically.
So... It seems that Java is resurrecting.
Even in a JS heavy front-end world, Django seems to be a good candidate to create REST services or JSON Web API's.
And for certain kinds of sites, a combination of a static site with parts of it automated with DRF seem to be a very good fit.