DHH answers: What makes Rails a framework worth learning in 2017?
quora.comThis 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.
This. Often, you can't find where this variable or function comes from. You read the sources only to discover that there is no trace of this variable and it is probably defined dynamically in some callback. You can only find this kind of stuff with the help of debugger. The dynamism, which allows one to create beautiful interfaces, and is often advertised as a programmer's friend, is actually the enemy of the programmer who is going to read the code afterwards.
I've actually run into methods defined from names concatenated from multiple strings, i.e. methods you can't even use grep over the whole codebase to find. This has left me with a lingering vague fear ever since.
I've seen worse.
A system that would load chunks of code out of MySQL and eval them in place.
Magic variables with magic meanings... shudder
Sounds like the coder was might have been imitating the idea of SQL stored procedures.
Actually he was imitating Lotus Notes...
that sounds like shitty code - i wouldn't blame ruby or rails for that.
Lots of things are possible - but not everything is a good idea - or is, but could be done in a clearer way.
This.
I used to work at places where we cared deeply about our code. You should see some of the code reviews from one of the places, sometimes they got kinda ridiculous and people got into arguments about coding style and the discussion never ended... But the code was great. I kept it for some time after leaving the job and I looked at it to see how good a Rails project can be. Ah, we had over 90% code coverage from the beginning too.
Without Rails, I don't think that codebase would have been as maintainable as it was.
Then at my next job after that, I was hired as a Rails developer. Rails was a dependency and they used controllers and views and wrote the most insane code I have ever seen. Not that many tests, and the tests we had required a significant amount of setup and no one really knew how to run them (and make them pass).
I'm used to Rails being nice and friendly to work with, so joining a project where they fucked up everything really sucked, because I know what it's like to work in a good rails app.
I feel that ways as well... and I'm loving F# for being easy to write and read and yet giving me algebraic data types which allow me to better to model the domain I'm working in and for forcing me to explicitly demarcate what's mutable and what's not.
You should check out Scott Wlaschin's talk, Domain Modeling with F# if you get the chance. https://vimeo.com/97507575
> 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. :)
Crikey that takes me back. Almost 12 years ago! I was 23 then and big-time into .NET but caught wind of this and watched it (hooray for student housing with decent net speeds -- sometimes, off-peak!) with an amused smirk as so much other tech stuff that comes and goes. Funny, this kind of stuff wouldn't raise an eyebrow today, other than "15 minutes to create a blog" in a fresh framework install being perceived as suspiciously cumbersome at best! ;) do realize that it was a much needed breath of fresh air back in the day for what was the widespread "LAMP stack" (linux/apache/mysql/php for ye young'uns) ..
> 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'.
At least once a week I read comments or a submission about how X should be written in Rust. That's a pretty common occurrence here; if you stay long enough it'll be another language.
Before Rust it was Haskell, before Haskell it was Erlang, and before Erlang it was Lisp.
I've seen a lot of Rust posts on HN lately, but none saying you must ditch mature frameworks like Rails for Rust equivalents (there aren't any yet, and they know that, for one).
Where's the evidence for this claim DHH/Rails is the only rational force in a sea of extremists?
(Of course the dull reality with real apps is "it's complicated" and most devs are busy grappling with that).
> Rails for Rust equivalents (there aren't any yet, and they know that, for one)
... Can we please call it Rusty Rails?
Do you have any examples?
I mean it sounds rational until you realize that modern rails apps are a perfect example of the complexity you want to avoid.
> modern rails apps are a perfect example of the complexity you want to avoid
Nope. This is a misnomer that get's passed around a lot, and it's not based on anything factual. It's also dangerous, because people will read that and think "oh, i guess rails is bad". but it's not.
When you leverage the framework and best practices, it's great. There are different styles that can make things more complex, sure - but that's by no means the fault of rails.
People can go overboard at any level of the stack - rails won't stop you from this. Things can get sloppy and not perform efficiently - or become convoluted. again - not the fault of rails.
Sometimes, you need a little magic. Ruby (and rails) makes this possible. But if you rely heavily on magic, it'll bite you in the end.
This. Legacy codebases convinced me that good languages / frameworks are the ones you can do many things in.
But the great ones restrict how you can do those things down to a few patterns (in a way that doesn't actually seem like a restriction).
> 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.
> It takes me over a day to get an Express application up and running.
I feel so much better after seeing this sentiment here. I've tried to dip my toe into the node.js world repeatedly only to feel like I'm trudging through setup for hours.
Of course I may have incorrect memories of how difficult/easy it was to set up my first rails app however long ago.
I should also add it "only" takes me a day because I can crib from a half dozen other Express projects I've created in the past and cherry-pick cut-and-paste parts that I like.
As one example my web app Gulpfile has evolved significantly from the first iteration and it would take multiple days to recreate all of that from scratch.
The Rails Asset Pipeline might be obnoxiously rigid, but at least it works without having to tear your hair out.
Forgive me, but what apps do you work on that have such a complex and lengthy gulpfile?
Nothing exotic but even a routine web application can have 150-250 lines of Gulp directives. Zero of this is provided for you.
Each chunk is fairly small, but they add up. You want linting, auto-restart on changes, tests, your various asset chains to compile things correctly, etc.
Ok, I see your point. I, too, hate writing boilerplate code. But I did three things to resolve this: I built a `config.js` file, which contains the paths to resource files in a more compact format, and is sourced into the gulpfile. I then replaced long path strings with easier to read code.
I also threw my standard gulpfile into a git repo, so if I need it, it's there.
Lastly, I built a yeoman generator. Now, not only is my gulpfile standardized, but I have the rest of my skeleton application built in a matter of minutes. All my favorite libraries/npm modules, custom scss files, basic routing to the standard pages of a simple site, are all built out for me to my preferences while I make a cup of coffee. You can even provide yourself command line flags to determine whether or not to include tests, which preprocessors for html or css you prefer, etc. Really a worthwhile investment.
Write once, utilize many times.
Tools like Yeoman can help here, but they're also relatively obscure and there's a lot of yak shaving involved in getting them working correctly.
In a sense complaining about this the Node world is like asking fish how they can stand being wet all the time. It's just part of the terrain.
I'm not saying what Node is doing is fundamentally wrong, but that this almost absurd aversion to making decisions for users is sometimes a bad thing.
For example, I'd love to be able to declare dependencies for an NPM module that are open-eneded, like "any one of A, B, or C will do", but like it is with Ruby, Python, etc. you must declare all or none.
I'm not trying to restrict choice, just cover the base condition of when you don't care of providing a sane default.
To a degree Rails has this: The first thing I do in a new project is jettison all the garbage I don't want (see you later turbolinks) and drop in all the things I do want. It's actually just a few lines to manipulate, so I can hardly complain.
In the Node world there's a lot of hand-holding required to get even the most basic application up and running. I can see this getting cut down dramatically if you had things like "npm install express +extras" where there was some way of saying "plus whatever other stuff you think is a good idea", or even an "express-fully-loaded" version of the package that comes with a bunch of stuff out of the box.
I really like Gulp and when configured it gives you an amazing amount of control over your build process. Although the Rails Asset Pipeline system works as a pretty good default out-of-the-box they really should steal some ideas from Gulp on configurability for those occasions where you want to change the default behaviour.
Vinyl.fs (https://github.com/gulpjs/vinyl-fs) is an amazing thing that the Ruby world desperately needs.
Yup. I think, as you say, it's a part of the terrain of the ecosystem. Could the makers of Express have created a more comprehensive boilerplate that includes things like Helmet, Async, Moment, gulp, etc., etc.? Yeah, and I definitely think it would be a good addition to the community if they had. On the other hand, I do agree with the general sentiment that by forcing you to include the dependencies you desire, the programmer exerts more control over what is in the app, and it forces them to actually understand what they're doing with each package.
In the end it boils down to: Start with a monolith and chisel away the stuff you don't want - RoR, or start with a skeleton and add what you need as you need it.
Rails is omakase. Node is a grocery and a kitchen supply store. Approaching either as if it's the other is a sure recipe for regret.
Node is like walking into a Home Depot when you want a house. Technically you can build one out of the bits they can provide, but it's a ton of work.
The thing is Node could offer the Rails out-of-the-box experience through a package that provided sane defaults. There's nothing preventing people from doing this but cultural resistance.
People do this, Node isn't a framework.
Walmart labs has contributed some great out-of-the-box, with hapi.js and now http://www.electrode.io/
I'm not saying Node is or should be a framework, but that Node itself lacks frameworks that do what Rails does.
Those are good examples of steering in the right direction, but it's still a long way off.
If you want to build a house, go to Home Depot. If you want to buy one and move in, go to a real estate agent. Standing in the middle of Home Depot complaining about how no one there seems to want to talk about about plats or points doesn't seem like a very worthwhile use of time.
There are a large number of projects offering a Rails-style OOTB experience in Node. None of them is blessed as the Node framework. This is because there is no one to do the blessing. Node's developer culture being one you find unsatisfactory is not an example of "resistance". It is an example of difference. And if you do not find the Node style to provide you comfort, there is absolutely no requirement anywhere that you partake of it.
> There are a great number of projects offering a Rails-style OOTB experience in Node.
Which would these be? Even the best tend to fall far short of the full Rails experience.
> And if you do not find the Node style to provide you comfort, there is absolutely no requirement anywhere that you partake of it.
Translation: "If you don't like it, fuck off."
That's not how the Node community has treated me as long as I've been a part of it. The people I've interacted with are often very welcoming, encouraging and responsible. I'm talking about cultural conventions, not individual attitudes.
The difference is that the Node world is used to things taking time to put together. The Rails world finds this to be unbelievably fussy. Python people from the Django realm are in the middle.
To promote a new way of doing things, like Rails did, is an effort way beyond my singular capability. It will require a lot of like-minded individuals to go "You know, maybe we could make something that wraps around Express and gives you a Rails-like experience for those that want it." and then work towards making that happen.
> Translation: "If you don't like it, fuck off."
If you like, but that's not what I'm saying. What I'm saying is instead that you're not going to find value in Node the same way you do in Rails, and complaining that Node is not Rails will not change that in the slightest. Neither will approaching Node as though the first thing to do is make sure your project tree contains every piece of functionality your app might ever conceivably need. Gulp, for example, is extremely powerful, but also has an enormous complexity cost. NPM is a task runner, too, and shell scripts can be fine for a surprisingly long while. I'm not sure what led you to think you need Gulp to get to "Hello, World". But part of using Node effectively is understanding that you are, in the end, responsible for the choices of tooling you make. If Gulp seems like more work than necessary to solve a simple problem, it probably is! Think about using something simpler instead. No one will force a choice on you, either in favor of Gulp or against it. The other side of that is that no one will make a choice for you, either. That's on you. If you'd rather it not be, this may not be the toolset for you.
Although, again, there are a lot of seeds and starters. I don't use them myself much, because I already have a battle-hardened stack that's simpler than most of them anyway, but I hear very good things of Sails. I wouldn't expect it to replicate Rails in full, but what I've heard suggests it will get you closer than most. Even here, though, you have to choose; there are no BDFLs and no One Right Way.
I'm not here to suggest a One Right Way, either. I do think the Node style is better in a few ways, not least of which is that, in exchange for paying a higher setup cost up front, you become less likely to run into teething troubles later on, especially in the realms of scaling and keeping the codebase up to date where I've observed Rails very frequently to have major problems. On the other hand, it can be considerably easier to start with Rails, especially if you're unfamiliar with it, and not strongly or at all supported by people who are - precisely because it relieves its user of the responsibility of making choices that user may not yet be prepared or equipped to make.
But all of that is an opinion that I'm having, and opinions certainly do differ. That doesn't gravel me. What does gravel me is seeing someone complain at considerable length about one style because it isn't exactly the same as another. That seems unlikely to produce any especially worthwhile result, either for the one who does it or for his interlocutors.
I'm not complaining that Node isn't Ruby, or that Express isn't Rails. What I'm saying is that there's an opportunity in the Node space to create something as fast, friendly, and forgiving as Rails is.
The "translation" there is how comments like that are perceived. "Put up or shut up" is not a good way to build community. Yes, obviously we have options, but the amount of commitment it takes to go with some of them is a lot higher, and in many cases needlessly so.
> I'm not sure what led you to think you need Gulp to get to "Hello, World".
If you have a non-trivial plan for what your application is going to do and you're intending to iteratively deploy it then you really do need an asset handling plan. Gulp does a great job of this if you spend the time to configure it correctly. With ~200 lines of configuration I get minification, compression, asset hashing, linting, auto-starting, and more. In some important areas that's ahead of Rails, especially in terms of control.
I'm talking about cultural concerns here, about the experience of someone new trying to build a Node application and needing to cobble this all together themselves. It took me about six months of iterative work to come up with a reasonable environment to build Node + Express apps. It took me two weeks to get settled into Rails back in 2005, and I've walked people through the same process with every version since Rails 1 and it's rarely more than a few days of coaching. This friction is something that's a serious problem and no amount of hand-waving dismissal of "that's just how Node is" will change that.
If you want to bring new people into your platform, into your culture, into your community you should make a better effort to lay out how things can or could be done. It shouldn't involve foraging through blog posts, Stack Overflow answers, and pestering co-workers for snippets of code, assembling a veritable quilt out of them that you pass on to others like some sacred heirloom.
For example, I'm consistently impressed with the quality of the documentation Node projects have, even humble ones with obviously limited appeal. The Ruby world is filled with crusty, opaque code with half-assed documentation that's often wildly out of sync with the shipping version, even for foundational components like Rake, Rack, or Rubygems.
If Node had a softer start for those that wanted it, respecting the culture of being able to pick and choose on a very granular level, I'm sure people would be more productive, use it on more projects, and contribute more back into the community. This is a lost opportunity.
It's interesting to me that your experience with Rails sounds a whole lot like my experience with Node, and vice versa. Granted, I was able more quickly to become productive in Rails for trivial tasks, but the additional time cost it imposed on nontrivial tasks more than swamped the early gain; while I have also found a knee in the efficiency curve for Node, it goes the other way.
But, in general, "friendly, fast, and forgiving" is exactly how I've always found the Node/Express tooling and ecosystem to be, while Rails has been among the least welcoming stacks I've ever had the displeasure to use - and, to your point about having to commit, in deciding "Rails: never again" I essentially threw away most of a year's worth of professional experience, which was so Rails-specific as to offer nothing useful in any alternate context. That's a choice I'm glad I made, rather than chasing the sunk cost, but if we're going to talk about things that require a lot of commitment, I think we have to talk about that kind of thing, too.
Based on the apparently almost mirror-opposite nature of our experiences with these platforms, I'm inclined to wonder whether the characteristics of either are strongly to blame, or whether instead it's a question of preference, or congruence between personal style and that of the platform, or just good vs. bad first impressions.
Not least to that last point, I do agree that a more reliably findable onboarding experience might be warranted. But it does sort of come down to "put up or shut up", harsh as that may sound; again, without a BDFL or a One Right Way, there is no one to mandate such a thing must be done, and thus, until someone comes along with the knowledge and the passion to do it, that thing does not get done. There's some degree of cost in that, to be sure. But the difference in engagement makes it reasonable to ask whether it's as much of a problem as it might seem.
I've known several of the main devs behind gulp for some time... and tbh, I switched away from gulp to direct scripts some time ago. If I can run it straight in npm, I'll do that... if I need more, I'll favor running a script in a directory for that purpose. glob, shelljs and mz give you a lot of what you might need. And it's often less code than gulp scripts might be.
An example[1] work in progress boilerplate I've been heading towards as time permits, will probably have it flushed out by the end of next month, including migrating to the latest webpack.
Of course a lot of the reason for options, is there are so many... server rendering, react v angular, angular 1 or 2+, bootstrap or foundation or ??? In the end, it's great in some was and not so much in others. I, like you prefer to have the choice/control.
Frameworks like rails are great at getting you 85-90% of the way to done... but that other 10-15% is so painful, you're often better off with DIY in the long run.
https://github.com/tracker1/react-redux-materialui-boilerpla...
There are a lot of configurators that give you a house... yoeman, create-react-app etc. The difference comes down to what kind of house you want.
Your best bet is to search for Foo boilerplate, where foo is what you want to work with, and start from one of many thousands of starting points.
I think the resistance is generators take time and persistent upkeep, while a boilerplate can exist as it is and upgraded intermittently.
In the end, I'd rather work with a lego bulk pack, than the prescriptive kits.
Adonis might be Rails-enough for you. https://adonisjs.com/
node has sails (http://sailsjs.com/) which i believe is rails-inspired. haven't used it though.
Sure, it's just the people who have to work with the demo that will want to murder you.
Lots of frameworks get you into tech debt quickly. This isn't good. What does it do to get you OUT of tech debt?
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.
Agreed. Would love to see DHH build an opinionated framework for node rather than waxing poetic about Ruby.
This is the first time I've seen someone complain that Ruby is a worse language than JS(ES5). Care to elaborate for those curious?
JS is simply the language that runs in the browser... even with newer options for compiled code coming close to being a reality, it'll be a while before tooling catches up.
JS is actually a decent language, and imho with more recent advancements better still. Combined with npm there is simply anything you might need available (for the most part). Not that there aren't a lot of gems out there.
In the end, having one language to think about, rather than how to shoehorn communications and logic between two languages is simply more difficult. I went, similarly from C# to node, not because I didn't like C#, but because the friction in writing JS on the server and the client was so reduced from two differing languages throughout the day.
Similarly a lot of devs went to simpler data stores so they don't have to deal with layers of ORMs that only half work, and can simply store and query basic data forms. Mongo fits this development model well, early hiccups in the technology aside.
In the end, it allows you to build web apps in one language, and not have to write translations to get from one to the other on the client.
Absolutely agree.
I've helped maintain REST APIs in both Java and NodeJS at different points in time.
Doing so in Java was always a painful iterative process; ask the ORM for data, painstakingly map the data to Java DTOs created mostly for defining JSON structure, pass it off to RESTEasy or some similar framework, see how the JSON turned out. Adjust and repeat until satisfied. Yuck.
In NodeJS, by contrast, fire off the SQL to get the data, map into the JS object that you need and return it.
Kind of funny how, years back, a selling point of GWT was that you could use the same language across the stack. It wasn't a bad idea, just a poor choice of language.
JS(ES5) runs across a wider range of devices than Ruby. If the core premise is to build a single framework to consolidate all development JS(ES5) is a better run-time to target.
One can argue that Ruby is prettier, but JS can be very good with thoughtful api design.
I'll bite :-) Keep in mind that I don't mind using Ruby at all, and consider it historically a good incremental improvement over what we used to have. I'll happily code in Ruby any day.
ES5, for me, was a complete surprise because I wasn't really expecting to enjoy using it. Perhaps I let myself be unduly influenced by the crowds ;-).
Prototypical inheritance is surprisingly nice. It is a simple concept and it is obvious exactly what's going on under the hood (if you care to look ;-) ). It allows a lot of functionality without requiring a large amount of language syntax. Ruby, on the other hand, has a more complicated (perhaps one can say more sophisticated) system, but requires a lot of language features to implement. Things like method_missing and all of the meta programming features feel bolted on.
ES5 has this really nice core design where language features just pop out. So private accessibility is done simply by using closures, etc. You have higher order functions without the absolute craziness of procs and blocs. Even things like mixins and traits are incredibly easy to implement with a couple of lines of code. Ruby, on the other hand, is a kind of byzantine structure where everything is bolted on with C code and the language itself is rather inflexible.
I really like the idea in ES5 that classes are simply functions that return an object. Hooking up inheritance structure is a complete PITA, but conceptually the design is really clean. Even the idea that objects are simply hashes and that methods are simply functions in a hash is really nice. Even the weird this pointer is at least consistent (despite being practically useless).
Where ES5 gets its bad reputation is in type/data coercion (which it shouldn't do at all IMHO, and it certainly shouldn't do it the way it does it). It also has a truly awful standard library -- to the point where most experienced developers simply avoid it! My main other problem with ES5 is that it is overly verbose, but this is something I feel that is shared with Ruby in many ways.
IMHO, use of a transpiler is just a good idea with ES5 because while the core of the language is excellent, the stuff surrounding it is full of pitfalls. I personally like CoffeeScript quite a lot and honestly prefer writing CS to Ruby. Typescript seems like it is also quite nice, though I haven't used it. Lately I've been playing with Purescript and while it is legitimately a different language compiled into JS, I really enjoy reading the compiled JS output, because it often compiles into something very elegant.
Conclusion: Ruby is fine, but ES5 is just a lot more elegant internally and it is much easier for me to use it intelligently to produce nice code. Ruby has a much better standard library, but language features are bolted on without them being driven by an internal design. Basically, I think they think "Hey, this would be a convenient syntax. Let's write the C code to make that work." without really evaluating whether there is any internal consistency. Some people may actually consider that a plus, but I prefer simpler languages. Note that I feel that in many ways ES6 is wandering over in this direction and I am somewhat disappointed with it. I was happy you specified ES5 in your question, because a similar question about ES6 would have been harder for me to answer.
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.
Until a new point release comes out and everyone forgets about the one you're running. Then you get to find out how much of your code you'll need to rewrite so it'll run with the Rails chefs' wild new menu. And there's no point even trying with an app written for an earlier major version. Just give up now, because the whole ocean's been boiled and recondensed since then, and now occupies but few of the basins it once did.
Granted, it's been a couple years since I dealt with any Rails apps. That's in large part by design, because every Rails app has a relatively high curation cost just to keep it up to date with the latest and greatest, and you have to do that if you want to be able to add features or usefully maintain anything without undue agony, because the Rails community has the collective memory of a goldfish and even less interest in maintaining continuity with the past.
I get that that's the big selling point, the drum DHH and his fans never stop beating: "Rails is omakase." This is a fundamentally broken metaphor, because sushi is dead by the time it gets to you, and all you have to do with it is eat it; the history of the ingredients is of little consequence. Would that software were so simple.
> Until a new point release comes out and everyone forgets about the one you're running
This is definitely a pain you'll feel with rails, and any other combination of software pieces which you bring together.
For what it's worth, within the last month, I've touched rails 3.2, 4.0, 4.1, 5.0, and 5.0.1 apps which are running in production. It's possible to maintain these apps on old releases, but the idea of never upgrading will be painful in the end.
It's worse in Rails because of the rate of change and the near-total lack of interest in backwards compatibility. Granted that the change in question often improves Rails' performance or stability, but that so much scope seems to go on existing for such improvements is in itself concerning, and the larger question, of whether it would be wiser to instead invest in a less volatile and more stable platform, remains valid.
Many of DHH's complaints are normal parts of every software project:
- 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.
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.
> As to why... it's anyone's guess.
I think its because recreating rails in javascript just doesn't make sense in the current ecosystem. Either you are rewriting stuff like express from scratch (and why are you doing that?), or you're building on top of those modules and adding configuration conventions and scripts, in which case, congratulations, you've just written Sails.
When Rails first got started, ruby didn't have anything close to the ecosystem that JS enjoys today, so DHH et al. had to write most of the individual components themselves, with the intention of making them all work together.
So in my view, its similar to how Humans and Gorillas evolved from a common ancestor, but you won't see Gorillas becoming Human anytime soon.
I think you're right that Rails basically built up the Ruby ecosystem around itself, whereas most of the JS libraries are just riding the wave started by... Node and NPM, I guess? It's much more fragmented.
> ...or you're building on top of those modules and adding configuration conventions and scripts, in which case, congratulations, you've just written Sails.
This doesn't jive with a lot of what's been done in the JS community, at least frontend anyway. There are a TON of libraries that already had perfectly good implementations, where people just decided to reinvent the wheel because they "couldn't find any X library that did what they needed." (see: anything to do with forms)
Backend too, though. There's Express, Koa, Hapi, and more. They all basically do the same thing.
Maybe it's just a difference in mindsets -- maybe JS devs prefer light libraries they can cobble together vs. kitchen-sink frameworks? But then there's the counter-example of the popular frontend frameworks (Angular 1/2, Ember), so I'm not so sure that applies universally either.
Personally I think Sails is pretty cool in it's own right. As far as websockets go I feel like that is one area where Sails makes things dead simple and I've not been amazed by the overcomplicated Rails 5 implementation of websockets.
That said, I don't see Sails gaining a ton of traction even though it's been around for quite some time yet, and with it's security settings and beta status I don't feel great about building production apps with it yet.
I certainly like sails, and can't levy too much criticism against it (except its ORM left quite a bit to be desired, although I haven't looked at it recently). I'm only asserting that it will never be Rails, partially because of how and when each respective framework came to be.
The complexity level of JavaEE and Spring is still enormous, even if you don't need fiddly XML configuration.
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.
Can you point to some specifics by Adam Bien? I'm very curious but don't know where to begin.
start with his youtube series on JavaEE dockerized microservices, and go from there
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.
> The bonus is increased maintainability.
It will never have strong-typed discipline though... (sad)
They are talking about adding some optional type inference in Ruby 3.0. See the rejection comments of https://bugs.ruby-lang.org/issues/9999 This is the most stong typing I'll accept for Ruby. There are plenty of other languages if strong typing is important for a project. They usually look bad (not because of strong typing) but if one really needs them...
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.
What's wrong with conventions? It seems to me that code conventions would make code more maintainable.
newsat13 wasn't complaining about using conventions. newsat13 was complaining about how Rails uses black magic with conventions.
I can't speak to Rails, but I've worked in other codebases that used reflection to dynamically attach different pieces of code together. It was hard to trace code because I couldn't do a search for the value being generated nor could I use the static analysis to find the value. I had to manually trace through the whole stack to find the bit of reflection that was generating a value.
I've never worked in a codebase like that, but in all my years of helping people with Ruby and Rails I've concluded that reflection is a code smell. It's one of those things that is taught in CS and winds up appearing where conventions might not have been immediately apparent, a fallback to training.
> 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"
Simple.
Its DHH, not DDH. Mods, please update the title.
corrected - thanks
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.
So you are saying that PHP is worth learning in 2017? I think it goes beyond job posting counts.
Have you looked at Laravel recently? With Vue.js integrated into the framework and adopting the best bits of Rails I'd say it's looking in better shape than Rails right now.
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.
That's not very scientific until you can establish that Rails jobs are more likely to be posted offline than PHP jobs. I don't see any evidence for this.
I find for the jobs market usually Java and C# dominate.
Rails has become so much more enjoyable since all the hipsters left for node.js. [What makes Rails a framwork worth learning in 2017]
DHH also answers a few other questions about Ruby and Rails in the same Q&A
https://www.quora.com/session/David-Heinemeier-Hansson/1?sri...
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.
[0] - http://www.padrinorb.com
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"
But a collection of consistently good enough components is better than tying together two dozen different things of wildly different quality and conventions.
I hear this a lot about Django. The ORM is really good but "not as good as SQLAlchemy". The templates are great but "Jinja is better".
The thing is that as an engineer I value that the components are incremental improvements with sane defaults where change is deliberate and the benefits of what I'm missing out on are truly, honestly irrelevant. There's really very few times where I said to myself, "Oh of only my templating language had better support for these idioms". I just write a decent workaround because I've been using the same tool for years and it's maintainable and the total number of workarounds is so small that there are no good reasons to switch to an alternative even in the long term.
This is much better than the alternative of looking for 5 alternatives for the same component, discarding the first 3, using one for a month until I find it has fatal flaws, and finally settling for the last one.
Once one critical component in the framework is no longer good enough it can be very difficult to upgrade.
Frameworks aggregate many dependencies. Managing the dependencies that deliver value while ignoring those that are irrelevant can net out as more productive.
> You get to use Ruby, which [...] remains the most extraordinarily beautiful and luxurious language I’ve yet to encounter.
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?
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.
Thanks! I agree Ruby looks to be far user-friendly in this context.
Just to add, my work revolves around the JVM ecosystem, but mostly in Scala and some Kotlin... Both already provide a nicer interface for Java :) e.g. in the context of collections both have `list.head` or `list.first` and `list.last`.
Each user today commands a personal fleet of many devices. "You get to use Ruby" is a weak justification for a monolithic architecture.
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?
There was a moment in web development where a single "full-stack framework" was possible, that moment has passed, and that moment was more rare and unique than it seemed at the time. The future seems to be more about lambda functions[1], api gateways, and many native clients.
Quoting DHH, the Rails pitch was use Ruby for everything:
> The core premise of Rails remains in many ways as controversial today as it was when it premiered. That by formalizing conventions, eliminating valueless choices, and offering a full-stack framework that provides great defaults for anyone who wants to create a complete application, we can make dramatic strides of productivity.
That premise is irrelevant today. A complete application today isn't just a website. It's a website, a phone app, a car app, a TV, a kiosk, a conversational bot, etc. Choosing even the highest common denominator across all those platforms means eliminating unique opportunities to delight the user.
If now the premise of Rails is that it's a great way to generate JSON on the server, sure but that's a fraction of the stack. The selling point for Rails is now simply an aesthetic choice between Javascript and Ruby. DHH admits as much with his closing argument:
> Just look at some code. I dare you not to fall in love.
Since the core premise of Rails remains full-stack, plugins at best are a cycle behind innovation. Conventions have to be explored elsewhere before they can be formalized, and before choices can be exposed as valueless. At worse, plugins are multiple cycles behind innovation due to pointless infighting.
This just seems way too slow, I'd rather get my hands dirty today.
[1] or process containers, let's not get bogged down in vendor details.
Your first quotation is something you're seriously misreading, I think. It's not about using Ruby for everything. It's about not spending time on minor decisions that don't affect the outcomes you're pursuing. And that's what that quote says – nothing about Ruby; everything about pruning down the pointless decisions you need to make as a developer.
> A complete application today isn't just a website. It's a website, a phone app, a car app, a TV, a kiosk, a conversational bot, etc.
I disagree pretty strongly with that. A complete application can be any one of those things. Sure, if you have a need for all of those at once, then Rails isn't going to be your one and only tool. But it could still well be the tool for your complete web application, and at the same time your API server for (some/all) of the other tools.
> DHH admits as much with his closing argument
No, he says that Ruby's beauty is an additional reason to use it. It's hardly an admission that it's all that differentiates Rails from other options.
Ok but then we are talking about Java, .NET and JavaScript. They all more or less work on many more devices than Ruby but at some points are so huge and complex and do not perform the same on all of these devices that you still kinda want to pick a specific technology.
Hell Ruby has RubyMotion that allows you to write native apps.
Put another way, it would be absurd to generate Arduino, Hololens, and Android runtimes from any single language framework.
He considers the monolithic architecture to be an advantage: https://m.signalvnoise.com/the-majestic-monolith-29166d02222...
If he really believed that, then the thing todo would be to re-write rails to run on top of node. Then he'd have a runtime that spanned nearly every possible use case and device.
Sticking with Ruby betrays that aesthetics are really the core premise of Rails, rather than aspirations of being the one framework to link all run times and in the darkness bind them.
Frankly, node needs such a framework.
Why on earth is Node considered the default for concurrency with its shitty single-threaded callback execution model? Anyone switching from Rails for improved concurrency would surely be better advised to choose Elixir?
Was referencing the run-time's viability on devices as small as a Beagle Bone micro controller, a mobile app, up to a backend service, etc.
There's an attractive opportunity for code reuse.
Have a preference for process pools over thread pools so don't mind the execution model. Would not be surprised that some applications are better served by other backends like akka etc. Elixir is on my list to learn.
That does of course play into the position that a great "full stack" framework is a thing of the past.
Agree with your comment, but am not sure there is a more potent monolith than AWS or GCP.
Perhaps, but what about this:
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.
There's a separate argument to be had about single process vs multi process backends, but that gets away from the core premise of Rails. Part of that premise included opinions and defaults about client-side development.
Rails was unique in its time in that it shipped with solid client-side DOM manipulation (prototype.js). It supplied a "full-stack" framework that made it easy to build a dynamic, AJAX Ux.
But lately the "best practices" in the node ecosystem move so fast that any default may soon be outdated. What would today's javascript Ux best practice be? Vue.js? React? Angular? Which state management solution is "best" ? Which CSS framework is "best" ?
Any choice you make will be out of date by the time you ship. There's a ton of activity. It's a decision that belongs on the project, not the framework.
This answer sounds a lot like what Microsoft's answer to Java was. C#. Everything in this answer reminded me of c#.
What does Ruby have to do with immutability
Let's consider the quote:
> 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]
".freeze" :) it's all runtime baby, love it (at least accept it), or move on
I think Rails is always worth learning, but is it worth learning right now if you want to find a job?
Here's a reason: money. Rails is still very popular, so there's plenty of work out there.
See my top-level comment about this. Rails' presence in the job market is definitely declining and dwarfed by both PHP and Node.js.
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 ?
It's always important to study history :)
Snarky, low-content comments really aren't valued highly here.
Rails, as any backend system such as Drupal or Symfony, is inevitably a dead end technology.
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.
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?
> the controller is still needed to map data structures to API endpoints.
I mean, kind of. You don't really need much controller logic most of the time anymore. Last Rails backend I wrote probably involved personally writing a few lines of code here and there. Generally, I'm just pushing a JSON object back and forth. Auth and emails can just be 3rd party. The vast majority of controller type behavior ends up client side at this point. Partly, because its way simpler to scale with you push as much processing to the client as you can. Also, look at something like Firebase or Hoodie as examples of simple stores that require no backend logic.
Its not that Rails and Symfony are useless, I use them all the time, its just that they are kind of dated concepts. Heck even Wordpress solves a specific problem on the backend enough to be useful sometimes. That said Drupal at this point is such a dated concept(superseded by things like Rails and Symfony many years ago) that is should no longer be used.
Well, I don't think anyone's taking much notice of that advice if you go by job stats. Drupal is enjoying tremendous adoption and if you look at Drupal 8 code you'll discover it is built on Symfony components.
Not to mention Rails has an API only generator for new apps now... so this problem is framework destroying 'use case' is solved with a single flag.
Front-end MVC frameworks are deployed and run client-side. Their emergence is a supporting point to the argument that the view is migrating away from the web server and onto the client device(s).
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.
Can you provide examples of the move you describe?