They are moving to Java+Spring. Is this not just a move from training Rails devs for startups towards training Java devs for big companies? I don't think this is about waning interest in Rails at all, I think it's a move to reposition the bootcamp in a bigger skills market.
Which will also be a factor of big companies being more willing (or able) to hire junior developers whose entire experience in the language is a boot camp
This is a huge bullshit article. RoR is not out it just is not sexy anymore and there are way more Java jobs than Ruby jobs.
Bootcamps are businesses like any others and they only care about making money. Of course they ditch Ruby/RoR if their customers want to learn the tech that is in demand.
If you compare the raw numbers the only stacks worth learning are Java,C# and JavaScript.
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.
RoR is special that it does one thing exceptionally well. And that is monolithic web applications.
I do not know how you measure productivity no other stack comes close to RoR.
It really depends on what exactly you are doing. If you are churning out business-y apps pretty regularly Rails gems are really useful.
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).
It was a compliment. Pylons in 2007 was Ben Bangert and other Python devs who had been working the area since the late 90s with Zope and other projects sitting down and more or less porting the good parts of Rails to Python.
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.
Thanks for the clarification! I interpreted Rails as 'Rails' not 'Rail's' and 'template' as a verb (sorry for the specifics, but I'm at a linguistics conference after all). I've been using Pyramid/Pylons recently and particularly happy with the experience so far. Not sure why it's not more popular, although it's also not particularly a bad thing this is the case.
I think RoR was initially a good thing for bootcamp curriculum because:
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...
Using new SO questions as a metric for popularity is kind of weird. I mean, if people keep asking questions and getting answers, at some point people looking for something already have an answer, right? Even when accounting for duplicates, you can expect the amount of new questions to lower with time.
I guess a better metric would be the amount of upvotes over time for questions and answers about a topic.
> at some point people looking for something already have an answer
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.
I've made this point a few times here on HN. StackOverflow QA& isn't really a good indicator of anything industry wide.
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.
You are right, but using a metric such as SO Careers posts you can get a better picture. And indeed shockingly Spring became more popular than RoR (at least on SO Careers that has a mix of big corps and startups) .
I partially agree...but...
I would say that Ruby/RoR usage is really regional and that is visible in the US,UK,Japan and bunch of other places. Remember that Java/C# were really popular even before Android and mobile platforms. Java was the obvious choice in the Android era, C# slowly caught up with the Xamarin and new initiatives like .NET CORE and CoreRT.
Javascript / NodeJS got really popular because of the low barrier and huge community and fast adoption rate by large corporations.
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)
Rails wasn't about Ruby, Rails was all about dev productivity, and Ruby happened to be the best language at the time.
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.
"..building things that the industry needs less and less.."
What do you mean by that ? Or what does industry need ?
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.
It's not only microservices, either : building frontend apps largely makes RoR less attractive, today. When SPA came around (I prefer to say "web clients", nowadays, since they indeed manage multiple pages and routing), we didn't believe in it. Sure, it had nice use cases, but those hashtags in urls and the fact they can't be indexed by search engines certainly meant they were going nowhere.
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.
Spring Boot is simply exceptional; it makes web application development fast, as it's said to be with Django and Rails, but retains a lot functionality from the Spring environment. I can't recommend it enough - things like Django and Rails just feel "old" after using Spring boot - even tough a good part of Spring power comes from the language and the tooling - some features (like automatic json-to-object conversion with correct typing, or object-to-object mapping) are just very hard to implement in a dynamically typed language.
I guess it's all my opinion, other than exceptions for control flow. Set your debugger to pause on all exceptions and then hit a hello world endpoint...it's terrifying.
I sometimes see people object to exception based control as you do here. I get it; it's essentially goto in diguise. But I've never read anyone discuss the pros and cons, or definitively call it out for what it is. Do you have any references on this topic?
Exceptions for control flow are a performance problem in most environments. The JVM does a good job of optimising exceptions very aggressively but throwing one is a relatively expensive operation if the JIT compiler wasn't able to fuse the throw/catch together. It's a bit weird to use exceptions for control flow for this reason.
I don't, but the when exceptions become the norm it makes debugging much more difficult. I'm not an expert on the subject, but it seems to have a negative impact on performance as well. And in the case of a simple web app, it just shouldn't be necessary. Maybe it makes sense for Spring to do it, but that would indicate that it's more complex than it needs to be.
I don't understand the benchmark completely (there seem to be some web server or "network programming framework" mingled with web frameworks? wut?), by the way I'm sure that pure speed is not Spring best virtue, and it's not Java's either, unless you take care at pre-warming the JIT and you've got enough RAM (and I suppose that, even then, Spring would be slower than other, 'shallower' frameworks).
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).
Plain old java servlets are the #1 result on the json benchmark, at over half a million requests per second. The implementation is less than 40 lines, most of which is imports / comments / curly braces.
I have no idea what point you're trying to make with regards to complexity or some kind of server vs framework distinction.
Isn't Hibernate still the default ORM in the Spring community? If so, what's changed? Hibernate is a monstrosity. Then again, so is Java so I'm still scratching my head trying to understand how anyone is jumping ship from Rails to Spring when Rails was originally an oasis for Java refugees.
They're not really alternatives in that one is frontend and one is backend, but they are alternatives in the sense of "here's new tech that hiring people might be aware of and are the defacto way to make web 2.0 (now 3.0) websites for clients".
The sentence starts with a direct quote, but ends with a sparse summation. The connection between these two may have been vague or even nonexistent except in the writer's mind.
I think the author was suggesting that many web apps are moving towards having a large frontend built in React/Vue. Therefore they don't need such a heavy framework as Rails on the backend and they can use something more lightweight to power their API.
The industry is heading this direction but the problem with microservices is that they're frequently chosen prematurely / misused / cargo-culted, chosen as a panacea without considering their tradeoffs and communication overhead.
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).
I'm no fan of Ruby on Rails BUT measuring it by its popularity within coding bootcamps is not exactly the best metric. While they do provide hype around a technology, RoR is sufficiently established (and has been before coding bootcamps were around) that it doesn't need to be popular within those circles in order to thrive.
If anything, what's popular among coding bootcamps is more indicative of the kind of junior positions which are more readily available.
As a developer who currently works with Rails, there's a deeply cynical part of me that says, "Good for Rails, then! I guess the trendy ones are leaving because Ruby and Rails have finally achieved some level of sanity."
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)
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.
The goal is "three times faster than Ruby 2.0" though, which means we're already part of the way there.
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.
I like Rails! The main wacky thing to me is the way in which it modifies so many core Ruby classes. I understand the the ability to so is a part of the core Ruby and/or Rails magic, but I actually don't necessarily like my framework to blend so seamlessly with my language.
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.
Yeah, we'll have to see about ruby 3. I know they're at least making deliberate effort - and are pondering some static typing. I've never been truly bitten by ruby performance, or ever found it so. But Crystal seems like an interesting language if/when that becomes a larger issue.
> 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
I've never by bitten by Ruby's runtime performance. It's "fast enough" and for common use cases that need more performance, there's usually a C extension (nokogiri, etc) on tap.
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.
Rails is definitely pretty hackable to fit one's own needs, but that's where the "convention over explicit configuration" stuff becomes a hindrance rather than a help.
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%.
I agree! Like I said in my initial post I generally like where Ruby and Rails are at.
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. =)
> Mostly, performance is an issue with large apps and their rspec run times
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.
My master plan is coming to fruition. Become Rails dev, Rails goes out of fashion, market myself as Rails expert, profit. Ah who am I kidding, I dont have the energy to market myself as anything.
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. :)
IMHO, the main reason Rails is declining in relevance isn't microservices or the productivity (!) of Java, but the fact that more and more development effort for web applications is moving into JS front-end coding.
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 :)
> IMHO, the main reason Rails is declining in relevance isn't microservices or the productivity (!) of Java, but the fact that more and more development effort for web applications is moving into JS front-end coding.
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.
I would consider JavaScript my primary language, and you're right - Node is usually my go-to choice for a web backend. Express is pretty easy to grasp and be productive with.
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.
I'd normally also have to select packages for sending emails, running background jobs, internationalization, templates, validation, file uploads and caching at a bare minimum. Then I'd have to make sure they all work well together, setup testing and probably have to write additional functionality that Rails or Django already covers.
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.
> but what would really make a big difference would be some kind of native integration of a mature front-end framework
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?
Rails never had that kind of relationship w/ Ember. Katz was both a Rails and Ember core dev, as well other Ember core devs had links to the Rails world so they are philosophically similar in a way...
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.
Agree and would love Rails to take this further. Rails is still very useful - and is certainly used by countless startups along with React. CRUD plus a smart redux/mobx scaffold of some sort. Or auto graphql-ify.
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.
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.
I hate to be that guy, but this may not be the best idea thanks to the patent stuff. I didn't hear if anything changed for React after the Apache Foundation pushed to change the license for RocksDB.
I agree completely. Rails actually is useful as rails-api, but the real benefit to Rails is the simplicity you get from the integrated development system.
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.
I've been developing rails for over 10 years, and I somewhat have seen this focus shift - but partly it's due to the complexity of frontend interfaces these days.
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.
I've been developing rails for over 10 years, and I somewhat have seen this focus shift - but partly it's due to the complexity of frontend interfaces these days.
I myself would often spin up a rails api + reach frontend. With rails 5.1 and especially webpacker_react I've seen a possible new direction which in my mind combines the best of both worlds. I think we could see something pretty exciting in this space soon.
This article uses questions on stack overflow as its killer data point. Stack overflow definitionally has fewer questions over time for any technology. If anything this is signaling maturity and stability.
I read indeed.com job openings regularly to see what's still in demand and I feel like I've seen a big drop over the years of jobs looking for rails developers but I'm sure github and these job sites have more official stats. Java and JavaScript languages have been jumping in native development a lot more and I think that's a large part of it.
Elixir/Phoenix is not what I would consider a step forward, or something to jump over to. While perhaps technically you can put more load on it - you sacrifice a lot of syntax, approachability and general developer happiness that you get with Rails. Tradeoffs I am not willing to make given the rails stack is more than fast enough.
As someone who first used Rails on the very day it was open sourced, built many Rails applications over the years, worked with other technologies in the meantime, and have recently returned to working on a Rails app I have been somewhat disappointed about the productivity compared to what I became used to.
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.
Rails is a kitchen-sink of tools for building full stack server rendered monolithic web applications. Even the built in support for webpack/React ("webpacker") feels very "rails-ey" compared to just using node. It's still a great framework but it doesn't seem too shocking that bootcamps, trying to teach the new web-dev hotness to students as fast as possible, would drop it. I just wish the article wasn't so dramatic.
They're replacing it with Java/Spring. That's hardly the new web-dev hotness. I suspect this change is less a reflection on Rails and more an indicator that there is a business opportunity to teach new programmers Java, because there are tons of legacy Java apps out in the wild, and the resources for learning Java these days are terrible compared to learning, say, JavaScript.
I wonder if every bootcamp flooding the market with Rails devs and subsequently putting huge downward pressure on wages had anything to do with waning interest. I saw this happening years ago and moved quickly in more niche technologies.
It's the end of an era. From 2005 to 2007, the "Web 2.0" craze, the release of Ruby on Rails, and the rise of Agile methods all happened at once. These ideas all fed into and supported each other, resulting in a cohesive movement with a lot of momentum. The long-term fact turned out to be that this movement didn't benefit large corporations that have always been and usually still are the main source of employment for software developers. So we have returned to our pre-Rails, pre-agile world of high specialization and high bureaucratic control, even if Rails and "Agile" still exist with some popularity.
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.
The part you are missing is that 'agile' has spawned it's own industry that is going to be hard to supplant. From the 'if it doesn't work you're doing it wrong' to the 'we look busy so we must be busy' it's going to be some time before we can put agile behind us and get some work done.
127 comments
[ 3.0 ms ] story [ 190 ms ] threadSo... It seems that Java is resurrecting.
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.
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...
I guess a better metric would be the amount of upvotes over time for questions and answers about a topic.
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 :)
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.
http://www.reallyhyped.com/?keywords=ruby-on-rails%2Cspring
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.
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.
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.
How on earth are those alternatives for Rails?
This says much more about the fact that coding bootcamp grads tend to go into bigger companies more than abything about Rails itself.
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).
If anything, what's popular among coding bootcamps is more indicative of the kind of junior positions which are more readily available.
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.
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. =)
I like Rails! The main wacky thing to me is the way in which it modifies so many core Ruby classes. I understand the the ability to so is a part of the core Ruby and/or Rails magic, but I actually don't necessarily like my framework to blend so seamlessly with my language.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.
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)
Rails is definitely pretty hackable to fit one's own needs, but that's where the "convention over explicit configuration" stuff becomes a hindrance rather than a help.Don't get me wrong, it's not awful, it's pretty good.
I agree! Like I said in my initial post I generally like where Ruby and Rails are at.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.
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 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 :)
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.
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.
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.
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.
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.
https://news.ycombinator.com/item?id=14779881
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.
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.
I myself would often spin up a rails api + reach frontend. With rails 5.1 and especially webpacker_react I've seen a possible new direction which in my mind combines the best of both worlds. I think we could see something pretty exciting in this space soon.
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.
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.