This reinforces what I see a lot too - people creating yet another XYZ, but rarely I see someone go and create an integrated solution to streamline development processes or make things easier or clearer.
There are a lot of vocal people who make it seem like you should be doing everything in Go or Angular or what have you, but I want nothing to do with either, and do not have problems that those are meant to solve. I love ruby, and I love rails.
DHH regularly sounds the drum of rationality - in a community at large of idealists and extremists. He is the reason I got into programming, and constantly serves to remind me that what I'm doing is, in fact, perfectly fine; and that everyone else puts up with a lot of nonsense for no great reason.
There are other frameworks out there, but you'd be hard pressed to find one with a leader that has such a sense of direction and reason for why the framework does what it does, and does not.
I am a rails dev. I inherited a legacy application. The biggest problem with Ruby/Rails is that anything Ruby will allow, someone will do. Ruby is the language I learned data structures and algorithms in, built my first significant projects in. It has a generous wealth of helpful builtins. But it makes me long for strictness, static typing, a language where not just anything can completely modify any other.
> There are a lot of vocal people who make it seem like you should be doing everything in Go or Angular or what have you
It might be hard to believe now, but Rails also went through this stage of vocal supporters advocating for it over alternatives. If you go back and watch the introduction video [1], you have DHH creating a blog in 15 minutes using RoR. I remember being impressed by it and vocally pushing for it where I worked then. :)
> There are a lot of vocal people who make it seem like you should be doing everything in Go or Angular or what have you
Can you give examples of the 'lot of vocal people' saying 'you should be doing everything in Go or Angular'? I don't see this. I only hear this kind of black/white sentiment when filtered via junior devs.
Experienced devs I know get there are trade-offs. And I don't see anyone on the React/Angular/Vue teams saying that server-sidey Django/Rails/etc. apps are 'wrong'.
> formalizing conventions, eliminating valueless choices, and offering a full-stack framework that provides great defaults for anyone who wants to create a complete application
Maybe I've drank the kool-aid too much, but I agree with this whole-heartedly.
It reminds me of when I want to paint a room. I can go to Home Depot and spend an hour picking out all the tools I need, or I can buy one of those pre-packed toolkit and get to the actual painting immediately.
Rails + Heroku = My product will be ready to demo by end of the week.
Obviously this mentality only applies to people like me who wants to get things done quickly. People who value craftsmanship and specificity should do what pleases them. (That's not to say you can't do quality work with pre-packed toolkits)
In the last few months I've built a brand new Node + Express application, and I've built a brand new Rails 5.x one.
ES6 has taken the edge off of some of the more obnoxious parts of JavaScript, but it still has a long way to go to catch up to Ruby, and Express is a cheap imitation of Rails.
It takes me over a day to get an Express application up and running. There's dozens of dependencies to wrangle into place. There's hundreds of lines of code to sketch in even the most basic of applications. So many directories to create, so many new files you have to basically build by hand. There's Gulpfiles to configure. There's a lot of work to integrate Passport. It's a lot of work to get as far as "Hello, world".
Meanwhile rails new and some Gemfile dependencies get you almost all the way there within an hour. Then you're making database migrations and laying in CSS and layouts.
I love both Node and Ruby for different reasons, but the out-of-the-box experience for Express is total garbage. You can't even parse a cookie without installing a module for that.
Node is way easier to create real-time services, like a Socket.io server in JavaScript is way less fuss than Ruby+EventMachine. It absolutely kills it when writing thin JSON APIs, and in terms of performance it's ridiculous. There's nothing preventing Node from having a Rails-like easy start for web applications but the attitude of the community where making decisions for people and having sane defaults is apparently against the rules.
Rails showed us all that web development didn't have to be PHP and Apache and constant headaches. Node and Phoenix and the modern paradigm in general wouldn't have come into existence, or achieved the popularity they have, without an act like Rails to follow. That's awesome, and I respect it for that.
But can it truly be said that Rails has a purpose today? Its default performance remains lousy with any kind of load. Its convention-first approach means Rails knowledge doesn't easily generalize, as can be seen in this very comment thread from the experience of those who've approached the Node ecosystem as though it were "Javascript on Rails". The "history? what history?" attitude of its BDFL and his clique makes cause for trepidation out of the prospect of maintaining a Rails app over a significant length of time. And even by comparison with ES5, Ruby is a hot mess.
I get that DHH has to defend it. It's his baby, after all. But it's been a long time indeed since Rails had anything unique to offer beyond an ideology which is, in its own way, every bit as much a straitjacket as RMS' - and Rails' inheritors have innovated in ways that straitjacket makes it very hard at best for Rails to match.
I completely agree on one aspect, anywhere I go, the kitchen sink is missing. You want to compress responses? well, there is an npm / jar / pip library for that. Want to have ORM? just npm / pip / "your package manager here" and you are done.
You can say a lot about Rails but I like the idea that everything I commonly need as a web developer is most likely already in the framework, and there is usually a best practice way to do things. Options are great, but moving out of plumbing and into generating value to customers is still having a value.
If you don't like opinionated, batteries included solutions then Rails is not for you.
However there are other solutions that kind-of cloned some aspects of Rails. Playframework (Scala has a lot more similarities to Ruby IMHO than to Java, at least in philosophy). Also Spring Boot or JHipster (Spring boot + Yeoman - super opinionated)
Maybe Rails has changed from when I last used it five years ago, but I dealt with many of the issues DHH makes against other technology.
> That people spent hours, if not days, just setting up the skeletons. The basic build configurations.
I spent hours everyday getting the asset pipeline to work, or it would break again, meaning I would have to fix it again.
> The vast majority of activity today is for yet another option on the a la carte menu.
Every week the developers want to switch out some module for another module within Rails because it was the hot new thing.
Maybe I worked on a bad project. Maybe I didn't get it. Maybe it was a growing pain that has passed. Rails was a pain in the ass to get to work. The ORM was cool, but did it save me time or mistakes from writing SQL - no.
I would love other people's opinions who have stuck with Rails.
For many years I tried to install Rails in my computer and it just refused to play well with the installation of MySQL on my Mac. I looked on SO and tried some CLI commands and configurations that I could barely understand for a couple of hours and then, when nothing worked, I just stopped and went back to CakePHP (which I used to love). I did this like every six months for maybe 5 years and then I became mostly a front end developer and I stopped caring. Nowadays with most of my projects there's somebody providing me with a REST API and I don't care what they are using to generate it.
>>Every week the developers want to switch out some module for another module within Rails because it was the hot new thing.
You misunderstood DHH's point. He's talking about well-integrated defaults. He isn't talking about preventing people from using other modules if they choose to do so.
I mean, if your developers want to try the hot new thing every week, Rails isn't the problem. That much should be obvious.
> I spent hours everyday getting the asset pipeline to work, or it would break again, meaning I would have to fix it again.
I used to have this problem too -- more so in the early days of asset pipeline. Mostly when trying to use some client side framework. Rails is working on (or maybe already available, I'm not sure) yarn/webpack support.
> Every week the developers want to switch out some module for another module within Rails because it was the hot new thing.
Replacing the batteries which are included can be painful at times. If you want to use the new hotness in Rails, it comes at a price of extra work getting it working... but it only seems painful when comparing to the included batteries -- they just work. Support for different test frameworks, orms, templating languages are pretty good anymore though and are easier to swap out.
You'll definitely have a better experience with Rails if you forego the desire to run the latest and greatest and just use what Rails already has.
I admire the way DHH writes .. confident and persuasive.
However, I'd just like to point out that in the same span of time JavaEE has undergone significant simplification (omakase API standards, anyone ;)) and if you check out the work of Adam Bien, you'll quickly find old myths of bloated memory consumption and fiddly XML configuration debunked.
Java is also lucky to have a parallel full-featured stack in the Spring ecosystem. Projects like JHipster do an opinionated take on how to wire things up and take you to quickly to orbit.
So basically, I disagree with DHH that there is "Very little activity in integrated solutions."
I took his comment about "very little activity in integrated solutions" to mean "[in the JavaScript world]" but maybe that's not what he meant.
I do think that's pretty true of the JS ecosystem though. There are things like Sails, but most of the "new" stuff that comes out is build systems, tools, small libraries, and view libraries.
As to why... it's anyone's guess.
My guess is that making a full-stack opinionated framework like Rails is a big undertaking, and most people are focused on what they see as "quick wins" -- solutions to the obvious surface-level pains like "npm is slow" and "making forms with React is hard" that can gain traction quickly and rise to stardom on Github.
Maybe this is cynical to mention, but fame and recognition (and maybe interesting job offers) seem to be a big driving force behind the constant influx of new and better JS libraries/tools.
I thought that was a strange claim, too (though if it was just about js, that would make more sense), especially given Elixir /Phoenix - which seems like an up-and-coming framework very much in the Rails mold.
So, I have seen rails code and I did not fall in love with the code. Instead what I saw just black magic and all sorts of conventions. Reminded me of perl. You have to invest a lot of time knowing all the magic stuff.
There isn't much black magic. Most of it is pretty sane naming conventions which could be OK in any sw project, plus database schema autodiscovery. The bonus is increased maintainability.
As someone who is just learning Rails [1], I can definitely empathise with the "black magic" comment.
Some of the stuff it does is pretty much voodoo to me at this point. But - it's voodoo that makes me think - even say out loud to myself, sometimes - "wow". I can see how it's amazing that it does what it does with so little code. I can see how this is an enormous benefit to getting a project up and running. I can see how it'll potentially save me hours and hours of configuration.
That's a great benefit, but it comes at the cost of understanding. What exactly is that line of voodoo doing? I dunno. How do I troubleshoot it if it doesn't work? I dunno. Like, I have no idea.
[1]: As the first real "language" I'm trying to actually properly learn, so take my comments in that context. I am not already an experienced coder. I want to be able to knock up little projects, proofs of concept, in a reasonable amount of time. Rails, to me, seems like the framework that will allow me to do that. We'll see.
> So, I have seen rails code and I did not fall in love with the code. Instead what I saw just black magic and all sorts of conventions.
Right, so clearly Rails is not for you. No harm no foul.
This is essentially the point of rails, that I as an engineer don't care enough about those details, because I need to get something working quickly. if it gets to a point where it matters (because it actually does, say, when you're trying to scale) you can invest the time to learn how it all works and either improve it or say ... "you know what, I think we should ditch this entire thing"
Maybe a more relevant question is whether Rails is worth learning if you're looking for a job. Searching Indeed.com's API by title, which removes duplicates, there are currently 133 Rails jobs in the USA compared with 763 PHP (excl. WP, Drupal etc.) and 467 Node.js. In the UK there are 104 Rails jobs compared with 1013 PHP (excl. WP, Drupal etc.) and 230 Node.js. However, if you deleve deeper it turns out that half of the Rails jobs are in London. Outside the capital there are 22 PHP jobs to every Rails job (35 including WP, Drupal etc.) and 3 Node.js jobs to every Rails job so it would appear that unless you have a particular preference for the Ruby language Rails is not a good bet in today's job market.
I don't think indeed.com is representative of the market, many rails jobs aren't even online.
Besides, if for 133 rails jobs and 763 PHP jobs there are 60 and 1500 rails and PHP candidates (respectively,) you're clearly better off choosing rails.
I have been thinking of rails lately. I used both Rails and Merb way back when, but for many years now I have just used Ruby + Sinatra.
I wish that I had a more complex web app to do because it would be fun to get reacquainted with Rails. That probably won't happen since I have been going it the opposite direction, having updated a few Sinatra and PHP sites to be 100% static, and using cloud storage and CDNs.
If you are familiar with Sinatra, have you checked our Padrino [0] ?? Padrino gives you a lot of the Rails goodies without too much bulk added.
I've developed and deployed several 'real world' web apps in Padrino now. I looked at Rails in the early days, but for some reason could never really get to grips with it (probably because it was too opinionated for me). Sinatra/Padrino's DSL methodology seemed to sit better with me, and I ran with it.
Ember.js attempts to do what the front-end what Rails has done for server-side application development. Worth a look, if you're trying to choose between React / Angular / something else.
The only thing I'd really take much issue with is the "provides great defaults" statement made in passing. There are several things that are defaulted more to what I'd call "lowest common denominator" than "great." For example, sessions.
This a great point that gets to the heart of the problem with the premise of a full-stack framework. Defaults end up more "good enough" rather than "great"
This article might be helpful: https://martinfowler.com/bliki/HumaneInterface.html. I use Ruby occasionally only, but agree with DHH's point. At least compared to the languages I knew before I learned Ruby, I found it to be designed to be aesthetically pleasing to humans. This might be even be the cause for the parse ambiguities.
Sorry, but I've really got no idea what you're saying here. What's the connection between users having many devices and the monolithic architecture bit?
We use a distributed architecture in clojure and python where I work, but it has its own downsides, and for a lot of people monoliths are a much better solution.
> You get to use Ruby, which, even in a world that has rediscovered the benefits of functional programming and immutability, remains the most extraordinarily beautiful and luxurious language I’ve yet to encounter.
He's saying there are other beautiful paradigms - especially of the FP variety.
However, Ruby is really, really damn elegant.
What stack do you recommend if not rails for a person that dislikes JavaScript (well rather ecosystem than the language / syntax itself) ?
I love Rails and Ruby do not take me wrong but I am not sure if the sole existence of Rails can make Ruby relevant in 2017.
In terms of jobs prospects and similarity to Rails/Ruby what do you guys recommend ?
Java ?
If I read your comment correctly, I believe you are suggesting that backends will provide APIs, which would leave us with the MC in MVC, the controller is still needed to map data structures to API endpoints.
My question to you is this: why do you believe that? I think we have all witnessed a growth in popularity in front-end MVC frameworks, but are they the correct solution to all problems?
I can imagine more and more web apps as frontends to multiple services of other companies, but there is still space for custom backends. I've got a customer that is developing its company around a custom ERP (under development) because he says there is nothing out there that can interface the systems he has to exchange data with. Of course sooner or later somebody will provide those services, using backend technologies.
meesterdude|9 years ago
There are a lot of vocal people who make it seem like you should be doing everything in Go or Angular or what have you, but I want nothing to do with either, and do not have problems that those are meant to solve. I love ruby, and I love rails.
DHH regularly sounds the drum of rationality - in a community at large of idealists and extremists. He is the reason I got into programming, and constantly serves to remind me that what I'm doing is, in fact, perfectly fine; and that everyone else puts up with a lot of nonsense for no great reason.
There are other frameworks out there, but you'd be hard pressed to find one with a leader that has such a sense of direction and reason for why the framework does what it does, and does not.
ooqr|9 years ago
mavelikara|9 years ago
It might be hard to believe now, but Rails also went through this stage of vocal supporters advocating for it over alternatives. If you go back and watch the introduction video [1], you have DHH creating a blog in 15 minutes using RoR. I remember being impressed by it and vocally pushing for it where I worked then. :)
[1]: https://www.youtube.com/watch?v=Gzj723LkRJY
allover|9 years ago
Can you give examples of the 'lot of vocal people' saying 'you should be doing everything in Go or Angular'? I don't see this. I only hear this kind of black/white sentiment when filtered via junior devs.
Experienced devs I know get there are trade-offs. And I don't see anyone on the React/Angular/Vue teams saying that server-sidey Django/Rails/etc. apps are 'wrong'.
dgfgfdagasdfgfa|9 years ago
vinhboy|9 years ago
Maybe I've drank the kool-aid too much, but I agree with this whole-heartedly.
It reminds me of when I want to paint a room. I can go to Home Depot and spend an hour picking out all the tools I need, or I can buy one of those pre-packed toolkit and get to the actual painting immediately.
Rails + Heroku = My product will be ready to demo by end of the week.
Obviously this mentality only applies to people like me who wants to get things done quickly. People who value craftsmanship and specificity should do what pleases them. (That's not to say you can't do quality work with pre-packed toolkits)
astrodust|9 years ago
ES6 has taken the edge off of some of the more obnoxious parts of JavaScript, but it still has a long way to go to catch up to Ruby, and Express is a cheap imitation of Rails.
It takes me over a day to get an Express application up and running. There's dozens of dependencies to wrangle into place. There's hundreds of lines of code to sketch in even the most basic of applications. So many directories to create, so many new files you have to basically build by hand. There's Gulpfiles to configure. There's a lot of work to integrate Passport. It's a lot of work to get as far as "Hello, world".
Meanwhile rails new and some Gemfile dependencies get you almost all the way there within an hour. Then you're making database migrations and laying in CSS and layouts.
I love both Node and Ruby for different reasons, but the out-of-the-box experience for Express is total garbage. You can't even parse a cookie without installing a module for that.
Node is way easier to create real-time services, like a Socket.io server in JavaScript is way less fuss than Ruby+EventMachine. It absolutely kills it when writing thin JSON APIs, and in terms of performance it's ridiculous. There's nothing preventing Node from having a Rails-like easy start for web applications but the attitude of the community where making decisions for people and having sane defaults is apparently against the rules.
dgfgfdagasdfgfa|9 years ago
Lots of frameworks get you into tech debt quickly. This isn't good. What does it do to get you OUT of tech debt?
throwanem|9 years ago
But can it truly be said that Rails has a purpose today? Its default performance remains lousy with any kind of load. Its convention-first approach means Rails knowledge doesn't easily generalize, as can be seen in this very comment thread from the experience of those who've approached the Node ecosystem as though it were "Javascript on Rails". The "history? what history?" attitude of its BDFL and his clique makes cause for trepidation out of the prospect of maintaining a Rails app over a significant length of time. And even by comparison with ES5, Ruby is a hot mess.
I get that DHH has to defend it. It's his baby, after all. But it's been a long time indeed since Rails had anything unique to offer beyond an ideology which is, in its own way, every bit as much a straitjacket as RMS' - and Rails' inheritors have innovated in ways that straitjacket makes it very hard at best for Rails to match.
patsplat|9 years ago
eranation|9 years ago
You can say a lot about Rails but I like the idea that everything I commonly need as a web developer is most likely already in the framework, and there is usually a best practice way to do things. Options are great, but moving out of plumbing and into generating value to customers is still having a value.
If you don't like opinionated, batteries included solutions then Rails is not for you.
However there are other solutions that kind-of cloned some aspects of Rails. Playframework (Scala has a lot more similarities to Ruby IMHO than to Java, at least in philosophy). Also Spring Boot or JHipster (Spring boot + Yeoman - super opinionated)
bobbytherobot|9 years ago
> That people spent hours, if not days, just setting up the skeletons. The basic build configurations.
I spent hours everyday getting the asset pipeline to work, or it would break again, meaning I would have to fix it again.
> The vast majority of activity today is for yet another option on the a la carte menu.
Every week the developers want to switch out some module for another module within Rails because it was the hot new thing.
Maybe I worked on a bad project. Maybe I didn't get it. Maybe it was a growing pain that has passed. Rails was a pain in the ass to get to work. The ORM was cool, but did it save me time or mistakes from writing SQL - no.
I would love other people's opinions who have stuck with Rails.
armandososa|9 years ago
enraged_camel|9 years ago
You misunderstood DHH's point. He's talking about well-integrated defaults. He isn't talking about preventing people from using other modules if they choose to do so.
I mean, if your developers want to try the hot new thing every week, Rails isn't the problem. That much should be obvious.
deedubaya|9 years ago
I used to have this problem too -- more so in the early days of asset pipeline. Mostly when trying to use some client side framework. Rails is working on (or maybe already available, I'm not sure) yarn/webpack support.
> Every week the developers want to switch out some module for another module within Rails because it was the hot new thing.
Replacing the batteries which are included can be painful at times. If you want to use the new hotness in Rails, it comes at a price of extra work getting it working... but it only seems painful when comparing to the included batteries -- they just work. Support for different test frameworks, orms, templating languages are pretty good anymore though and are easier to swap out.
You'll definitely have a better experience with Rails if you forego the desire to run the latest and greatest and just use what Rails already has.
patsplat|9 years ago
- depending on third party packages can be a pain
- switching environments / languages is annoying
The argument that these things disappear with Rails is weak.
The historical argument that a dynamically typed language can handle these issues more gracefully than J2EE is valid but less relevant today.
currywurst|9 years ago
However, I'd just like to point out that in the same span of time JavaEE has undergone significant simplification (omakase API standards, anyone ;)) and if you check out the work of Adam Bien, you'll quickly find old myths of bloated memory consumption and fiddly XML configuration debunked.
Java is also lucky to have a parallel full-featured stack in the Spring ecosystem. Projects like JHipster do an opinionated take on how to wire things up and take you to quickly to orbit.
So basically, I disagree with DHH that there is "Very little activity in integrated solutions."
dceddia|9 years ago
I do think that's pretty true of the JS ecosystem though. There are things like Sails, but most of the "new" stuff that comes out is build systems, tools, small libraries, and view libraries.
As to why... it's anyone's guess.
My guess is that making a full-stack opinionated framework like Rails is a big undertaking, and most people are focused on what they see as "quick wins" -- solutions to the obvious surface-level pains like "npm is slow" and "making forms with React is hard" that can gain traction quickly and rise to stardom on Github.
Maybe this is cynical to mention, but fame and recognition (and maybe interesting job offers) seem to be a big driving force behind the constant influx of new and better JS libraries/tools.
fusiongyro|9 years ago
blacksmith_tb|9 years ago
Blackthorn|9 years ago
newsat13|9 years ago
pmontra|9 years ago
jen729w|9 years ago
Some of the stuff it does is pretty much voodoo to me at this point. But - it's voodoo that makes me think - even say out loud to myself, sometimes - "wow". I can see how it's amazing that it does what it does with so little code. I can see how this is an enormous benefit to getting a project up and running. I can see how it'll potentially save me hours and hours of configuration.
That's a great benefit, but it comes at the cost of understanding. What exactly is that line of voodoo doing? I dunno. How do I troubleshoot it if it doesn't work? I dunno. Like, I have no idea.
[1]: As the first real "language" I'm trying to actually properly learn, so take my comments in that context. I am not already an experienced coder. I want to be able to knock up little projects, proofs of concept, in a reasonable amount of time. Rails, to me, seems like the framework that will allow me to do that. We'll see.
hekker|9 years ago
trustfundbaby|9 years ago
Right, so clearly Rails is not for you. No harm no foul.
This is essentially the point of rails, that I as an engineer don't care enough about those details, because I need to get something working quickly. if it gets to a point where it matters (because it actually does, say, when you're trying to scale) you can invest the time to learn how it all works and either improve it or say ... "you know what, I think we should ditch this entire thing"
Simple.
dharamgollapudi|9 years ago
gavingmiller|9 years ago
cutler|9 years ago
appleiigs|9 years ago
hashmal|9 years ago
Besides, if for 133 rails jobs and 763 PHP jobs there are 60 and 1500 rails and PHP candidates (respectively,) you're clearly better off choosing rails.
matthewking|9 years ago
elcapitan|9 years ago
mountaineer|9 years ago
https://www.quora.com/session/David-Heinemeier-Hansson/1?sri...
mark_l_watson|9 years ago
I wish that I had a more complex web app to do because it would be fun to get reacquainted with Rails. That probably won't happen since I have been going it the opposite direction, having updated a few Sinatra and PHP sites to be 100% static, and using cloud storage and CDNs.
cyberferret|9 years ago
I've developed and deployed several 'real world' web apps in Padrino now. I looked at Rails in the early days, but for some reason could never really get to grips with it (probably because it was too opinionated for me). Sinatra/Padrino's DSL methodology seemed to sit better with me, and I ran with it.
[0] - http://www.padrinorb.com
horsecaptin|9 years ago
Glyptodon|9 years ago
patsplat|9 years ago
hhandoko|9 years ago
I've used Ruby sporadically as gap-fill in small projects, but I didn't feel the language has any qualities that sets it apart from others.
Perhaps I missed something, any Ruby devs care to comment?
mavelikara|9 years ago
patsplat|9 years ago
GavinMcG|9 years ago
jrs95|9 years ago
headcanon|9 years ago
1. Easy to deploy
2. Integration tests are a breeze
3. Debugging is a breeze
We use a distributed architecture in clojure and python where I work, but it has its own downsides, and for a lot of people monoliths are a much better solution.
spoiledtechie|9 years ago
rco8786|9 years ago
wrsh07|9 years ago
> You get to use Ruby, which, even in a world that has rediscovered the benefits of functional programming and immutability, remains the most extraordinarily beautiful and luxurious language I’ve yet to encounter.
He's saying there are other beautiful paradigms - especially of the FP variety. However, Ruby is really, really damn elegant.
And he's right; it's a joy. [I say as a C++ dev]
cies|9 years ago
blueside|9 years ago
ahallock|9 years ago
cutler|9 years ago
holydude|9 years ago
In terms of jobs prospects and similarity to Rails/Ruby what do you guys recommend ? Java ?
hogrammer|9 years ago
[deleted]
unknown|9 years ago
[deleted]
vcryan|9 years ago
GavinMcG|9 years ago
0xsnowcrash|9 years ago
The web is increasingly moving frontend and the system of 2018 onwards will simply be the M in MVC.
Note, I'm not saying Rails is not worth learning. I'm just saying it's now the Cobol of web technology.
pyrophane|9 years ago
My question to you is this: why do you believe that? I think we have all witnessed a growth in popularity in front-end MVC frameworks, but are they the correct solution to all problems?
pmontra|9 years ago
eternalvision|9 years ago