Ruby on Rails is out: major coding bootcamp ditches it, due to waning interest(thenextweb.com)
thenextweb.com
Ruby on Rails is out: major coding bootcamp ditches it, due to waning interest
https://thenextweb.com/dd/2017/07/26/ruby-rails-major-coding-bootcamp-ditches-due-waning-interest/
128 comments
Wholeheartedly agree. And my personal opinion is that this unification is going to come from Java/Truffle.
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.
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.
Laravel pretty much does with Vue what you are suggesting Rails could do with React. It's a pretty nice integration.
This is true for more than RoR.
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.
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.
> 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.
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.
NodeJS as a backend platform is still horribly inefficient and years behind mature Python and Ruby solutions.
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.
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.
Huh I have had a very easy time integrating passport, mongoose, and morgan respectively for the above 3 asks.
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.
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.
Check out hapi. https://hapijs.com
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.
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.
> 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?
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.
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'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 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 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.
https://news.ycombinator.com/item?id=14779881
https://news.ycombinator.com/item?id=14779881
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.
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.
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)
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)
> I don't see it ever getting too much faster
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 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.
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.
> 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. =)
> 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.
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.
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.
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...
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...
RoR is not out it just is not sexy anymore
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.
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.
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.
On the other hand, I'd say RoR optimizes productivity for Day 1 at the expense of Day 60+. I abandoned RoR because I didn't like that deal.
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).
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).
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.
Can you explain the arguments against Pyramid/Pylons?
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.
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.
A few days ago a code school raised $85,000 USD on Kickstarter[0] to build a Rails application.
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...
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...
Additionally, it's still a great choice to back any fancy modern front end tool. API mode and/or Webpacker.
I'd love for bootcamps to stop teaching Rails so the rest of us can start raising the bar again.
I'd love for bootcamps to stop teaching Rails so the rest of us can start raising the bar again.
> 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.
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.
[deleted]
THIS.
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.
I have been working for more than 6 years with Ruby on Rails, and I can definitely tell you, there is waning interest.
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.
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.
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).
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 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)
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.
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.
What can Ruby/Rails offer ? Not much.
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.
> like it or not, microservices are here and they solve real problems
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.
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.
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.
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.
> 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.
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.
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'm halfway through Michael Hartl's RoR tutorial (IMHO, it's very good) and so your comment is a little disheartening. What are the top one or two technologies (aside from just Javascript) that you would learn today?
I would finish that tutorial. RoR shows you what a cohesive approach can do to a framework and it'll get you used to good design patterns that can serve you elsewhere.
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.
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.
Finish that tutorial, understanding Rails will help you undertand better other frameworks that were inspired by Rails.
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.
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.
Elixir is hardly visible in the jobs market. At least if Indeed.com is to be believed. It's too niche. Clojure is at least as good as Elixir, if not better, and has failed to gain widespread adoption after 8 years since 1.0 so I don't see Elixir going anywhere. There's just too much competition.
Can you recommend one or two language + framework combinations that might be a better choice than RoR?
Elixir/Phoenix, Clojure/Luminus, ClojureScript/Macchiato and Scala/Play are arguably better than Rails if you really grok FP but they don't have the community, maturity and adoption that Rails has enjoyed for a long time. If you're ok with OO monoliths Rails is hard to beat.
Golang, Java (and a 3rd would be Rust)
Those are just languages though. They don't really compare to RoR. For the record, I think Ruby is a wonderful language. Python is still my go-to scripting language, but I do admire the expressiveness of Ruby when written by people that know what they are doing.
I have a fair bit of Java experience but it isn't current (I did Tomcat-based stuff).
I have a fair bit of Java experience but it isn't current (I did Tomcat-based stuff).
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 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.
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.
I guess a better metric would be the amount of upvotes over time for questions and answers about a topic.
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.
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.
> 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.
But I'm not anywhere near an expert on this :)
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 :)
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) .
http://www.reallyhyped.com/?keywords=ruby-on-rails%2Cspring
http://www.reallyhyped.com/?keywords=ruby-on-rails%2Cspring
...and this is a pretty good point.
"There’s plenty of really great web development alternatives," Shaw said, mentioning React, Vue.js
How on earth are those alternatives for Rails?
How on earth are those alternatives for Rails?
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.
My only guess is that the journalist truncated the quote or that it was implying a Node / JS backend.
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".
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.
I learned Rails via Code School and Michael Hartl's excellent tutorial, and almost began building real apps with it before settling on Django + REST Framework + Ember. 2 years later, I'm now learning React.
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.)
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.)
TypeScript is probably your best bet. Static typing the same classes on the front and backend is going to make any REST API easier to develop. Another alternative is using something like protobuf [1] to define your data models.
[1] https://github.com/google/protobuf
[1] https://github.com/google/protobuf
I'm interested in TS, but I've been working with CoffeeScript (and Python) for 2 years and am very fond of significant whitespace (and not at all fond of semicolons and curly braces). There was a Typed CoffeeScript project, but nothing is active now. And CoffeeScript 2, with built-in support for JSX, is in beta.
Would you use Django+DRF over NodeJS??
That's what I'm using right now, although I wish I had a viable alternative that would enable me to write elegant CoffeeScript for both client and server.
I am just getting into Django, was just wondering whether NodeJS is a viable alternative to Django+DRF.
Seems to me that Python is a much more mature language than JS.
Seems to me that Python is a much more mature language than JS.
Sails.js [0] is very nice, although I personally haven't been convinced to abandon Django+DRF in its favor yet. For one, its docs suggest ES6 classes aren't supported yet.
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
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
As of yet there is nothing remotely close in feature parity and developer niceties to DRF in Node.
Given that there are no tightly integrated monolithical frameworks in JS land, I doubt there will be for a while.
Given that there are no tightly integrated monolithical frameworks in JS land, I doubt there will be for a while.
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.
It's the Rails job market driving this change, not hotness.
"Is the end of Ruby on Rails nigh? Everything seems to point that way."
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?
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?
There's still nothing to beat RoR in terms of productivity and lines of code.
I'm happy to switch to another full stack framework if I can see a clear benefit but as yet nothing comes close.
I'm happy to switch to another full stack framework if I can see a clear benefit but as yet nothing comes close.
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.
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.
Check out Elixir/Phoenix Framework. It is supposed to be by ex-RoR people.
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.
Elixir hasn't really made its presence felt in the job market yet so it's too early to bet on.
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.
Doesn't look very fast on benchmarks: https://www.techempower.com/benchmarks/#section=data-r14&hw=... .
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).
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).
> I'm sure that pure speed is not Spring best virtue, and it's not Java's either
Go look at those benchmarks again. Over half of the top 10 are JVM servers.
Go look at those benchmarks again. Over half of the top 10 are JVM servers.
Yes... SERVERS... not frameworks. Usually Java-based frameworks are a bit more complex than Python/Ruby/Javascript based ones.
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.
I have no idea what point you're trying to make with regards to complexity or some kind of server vs framework distinction.
It's rather bloated, and constantly throws exceptions for control flow. It can be convenient, but it's not really worth it in my opinion.
Which is in your opinion ?
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?
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.
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.
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.
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'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.
If anything, what's popular among coding bootcamps is more indicative of the kind of junior positions which are more readily available.
Having been a rails engineer for 12+ years, I can say I haven't used rails for front end work in about 5 years. In 2011 I started migrating front ends from erb to ERB heavily enhanced with angular, my frontends relied more and more on an API and slowly, the "@" instance variable assigment started to disappear from my controllers.
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.
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.
> Replacing it is a Java course, which will emphasize the Spring application development framework.
This says much more about the fact that coding bootcamp grads tend to go into bigger companies more than abything about Rails itself.
This says much more about the fact that coding bootcamp grads tend to go into bigger companies more than abything about Rails itself.
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.
What drives the popularity of a framework has very little to do with merit. RoR is still the right choice for lots of apps, and makes millions of dollars for lots of companies, no trendy frontend framework required.
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.
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 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.
I'm pretty sure the Spring framework is not where "developer interest" is going these days.
Sentimentally, too bad. Spitefully, good.
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 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. :)
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.
Django instead of Rails or Yesod on the latest project. Second iteration will be DjangoREST/VueJS. Third iteration breaking the monolith into smaller services.
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.
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.
Sounds like they are changing their target companies to send their students to from startups to existing incumbents. I'm sure all those old 1990's software companies would love to recruit junior programmers but otherwise find it difficult. And it's probably not a bad way for non-programmers to get a decent first programming job.
I think the next step for web development will be a smooth blending of the server and front end which all these node stacks hint at. For instance, defining an endpoint defined both the code for running the endpoint as well as the front end code for consuming it.
By defining both together, you reduce the amount of break points I'm your code dramatically.
By defining both together, you reduce the amount of break points I'm your code dramatically.
«Replacing it is a Java course, which will emphasize the Spring application development framework.»
So... It seems that Java is resurrecting.
So... It seems that Java is resurrecting.
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
Indeed.com (API) by job title/USA shows 611 Rails jobs, 835 Node.js, 353 Django, 243 Laravel, 117 Symfony and 9 Elixir. For the UK (Indeed.co.uk) it's 239 Rails jobs, 758 Node.js, 234 Django, 441 Laravel, 359 Symfony and 11 Elixir. By what measure is demand for Rails declining? Elixir isn't even close.
I am just beginning to learn Django. Would you advise against it??
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.
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.
Both Django and Rails will be around for many years being useful and making businesses a lot of money. Not to mention I've seen quite a few legacy code bases that would be pretty expensive to replace so there will be maintenance work for a long time as well. They'll never be "the new hotness" again, but that's a bad sign anyway IMO.
Surprised they didn't replace it with Node instead.
They already have a MEAN stack course.
Ruby On Rails is the Elizabeth Taylor of software development.
Good, we don't need more wannabes :-)
They are creating future work for specialists though... Even AI won't figure out a legacy RoR project.
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 :)