17 ms·

Rails has won: The Elephant in the Room

316 points by mjbellantoni 10y ago

tariqali34 10y ago
> Experienced people often forget the learning curve when they were themselves beginners, and at that time Rails was so attractive, so sexy. Remember that feeling? Of accomplishment in the face of the knowledge that some nice witch left super useful black magic behind? As one of those beginner programmers who had graduated from a development bootcamp, I fell in love with Sinatra much more than I did with Rails. Part of that love may be due to our curriculum...we have to master Sinatra first before you can start learning Rails. But I also liked the finer control that Sinatra provided to me. I suppose you can translate this to the current buzzword jargon of "hating Rails' magic", but writing out simple authentication using Bcrypt is just as much an accomplishment as using the Devise library. But your bigger point still remains intact. Passion should take a backseat towards choosing the right tool for the job. If you need Wordpress, use Wordpress. If you need Rails, use Rails. And so on and so forth. I may not like a certain tool...in fact, I may hate it, but I should still go ahead and use it anyway. You're here to complete a job. And you should make sure you do it well.
- ascendantlogic 10y ago
  I too like Sinatra but in my time writing Rails for both my day job(s) as well as various consulting gigs, I inevitably see Sinatra apps that start out with the best of intentions but always end up being just a shitty, hand-rolled version of Rails.
  - wyaeld 10y ago
    The amount of time I hear - Rails, you ain't gonna need it, followed 6 months later by some version of "can we use this library to add a feature which OOTB Rails would have given us if we used it". What is bloat, and what is a useful feature you haven't quite grown into yet, is all a matter of perspective. I haven't yet found a project where you know 100% of what you're going to need upfront, so having a bit of depth in the toolbox is serving me well.
- rubiquity 10y ago
  Want to hear about an interesting project I heard of recently? Converting a Sinatra crap bomb into a Rails app.
- busterarm 10y ago
  As someone who didn't love Rails until I learned it "the right way", I'd argue that you have to thoroughly understand SQL joins and ActiveRecord before you can even attempt to architect a rails project. Very few bootcamps get this right, I feel, but a few do.
deleted 10y ago
[deleted]
kinkdr 10y ago
Nice read. I understand the sentiment but I find the "win declaration" a bit too weird. How can one say "Rails won"? It's not like people will stop making web frameworks. Like any other software it will eventually be made obsolete by something newer and better. Maybe I am just nitpicking.
- vonklaus 10y ago
  Yeah, I found that weird. However, if I think deeply about it, given the move to micro-services and soa type architectures I can see elixir winning longer term which is really railsy. regardless, rails has a ton of influence and some great usecases, but I would say nodejs is about as vogue as rails was and will dominate for another several years. as a nodejs dev, it is super annoying managing the asynchornicity of node and the horrifying dependencies. I suppose rails had stability issues as well. If you read rails is a ghetto by zed shaw, it is interesting (albeit super biased) look at how and why rails developed. edit: As noted, elixir isn't comparable to rails the framework in that arena is phoenix which is similar (at least in function). Thanks!.
  - jghn 10y ago
    Elixir isn't comparable to rails, it's comparable to ruby. Phoenix is the thing comparable to rails Edit: I don't mean comparable as similar per se, but that one set are languages and the other are web frameworks
  - deleted 10y ago
    [deleted]
  - kinkdr 10y ago
    > rails is a ghetto by zed shaw Hilarious! :D
- untog 10y ago
  I think the "Rails won" sentiment is that 90% of the time, when you talk about a "Ruby job", it's a "Ruby on Rails" job. Not always, but the vast majority of the time. Now, that doesn't apply to any language other than Ruby. But this post might well be aimed at Rubyists exclusively.
vonklaus 10y ago
I haven't used rails in about 3 years (when I first started programming) and I only built 1 application which was a super shitty weekend instagram clone that didn't really work well. I didn't want to use rails anymore because it didn't feel like programming and nodeJS was getting hot. The thing is, I knew fuck all about programming then and now, I have the luxury of knowing very slightly less than fuck all. Which gives me the perspective that this article has, rails is pretty fucking awesome for building a crud application that uses a relational datastore. The author indicated ~80%. Wordpress is also something I swore off when I was learning because it straight up wasn't programming. I installed wordpress on a server for the first time last week to setup a blog. I browsed a few thousand themes, it took me a while to find a theme for a blog. The just a blogging platform is actually more ironic now, than it ever was. So, I agree with the author the design patterns shape the community and then the community shapes the design patterns. You can pretty much build any type of app with any language if you are motivated and talented, however, from my observation, the following languages seem to give you the highest leverage in the domains the community has evolved them for: PHP/Wordpress: Blogging sites & CMS building. Node/JS: Applications and APIs typically with a noSQL database. Ruby/Rails: Building CRUD apps with relational datastores. Python: Data intensive applications & programming. erlang/elixir: Never used this, but seems ideal for highly scalable concurrent architecture and highly scalable process choreography. So in essence, I agree with the author. I would love to switch from node to Rails as I like the framework aspect where you can just get productive super quick. I also see rails as going away, so I wouldn't make the time investment. I think learning node was the right thing to do ~3 years ago, but I wish I spent another 6 months using rails and got really comfortable with it first. > This is not serious programming/you aren't a serious programmer fairplay. I am a jr. web developer, explaining my conception of some frameworks/communities/languages, so I agree with you that I am not a particularly talented programmer (it isn't my core skillset) and I am not solving hard problems in this arena(as I don't conetend that I am). I disagree that I claimed any of the above was my definition of serious programming. Of the hard problems I will work on/what I think needs to be solved, I have spoken of at length elsewhere.
- rubiquity 10y ago
  > I didn't want to use rails anymore because it didn't feel like programming and nodeJS was getting hot. > Wordpress is also something I swore off when I was learning because it straight up wasn't programming > Python: Data intensive applications & programming. I would love to hear your definition of programming.
jaequery 10y ago
If we are talking about frameworks, I believe Padrino is a much better designed framework than Rails. It doesn't have any magic of Rails and architected in a very elegant way. I just can't tolerate ActiveRecord, so Padrino having Sequel support out of the box was definitely an important step in going away from Rails. Also being built on top of Sinatra, it is also much lighter and faster than Rails, another huge reason to switch. Yes Rails wins the popularity contest, but it doesn't mean it's the best thing for Ruby.
fieryeagle 10y ago
I suppose this is how you gain fame these days, writing sensational counter-arguments instead of coding? Oh right, the author is a 'Ruby Activist', he couldn't help it. PHP has won, Node has won and now yet another language up to debate? Having something with its own niche and cult doesn't mean anything if it's not suitable for work. It does help populate shortcut-seeking approaches such as Heroku and more CRUD apps than ever before so Rails has its places. Here's a piece to deflate any ego issues http://www.paulgraham.com/identity.html http://www.paulgraham.com/identity.html.
- Ace17 10y ago
  The article you linked is pure gold ;thanks for sharing!
  - fieryeagle 10y ago
    Yeah, such a poignant read that cuts to the heart of the problem - our needs to associate and express.
- deleted 10y ago
  [deleted]
programmer1234 10y ago
Time saver: Just look at his company's website. Time waster: Rails has won in the same way that PHP and .NET "won" in the 2000s. There are a lot of problems with Ruby, it's sort of this isolated language that's useful for Rails only, and I wonder if python and django don't offer a suitable replacement for 80% of cases where you can choose between hiring Rails and Django engineers. Graphing "PHP", "Rails", and "Nodejs" on Google Trends makes Rails look like a fad and all the future money is going to be in maintenance work. The article's weakness lies in the fact that it argues against the assertion that "Rails has these big problems, it's no longer the best approach", by instead arguing that "Rails is good enough most of the time" in a way that doesn't quite live up to the title.
Bahamut 10y ago
"But I would never, ever, begin a new business that depends solely on Angular to survive. Why? Because Google doesn't need it. It didn't blink to give up GWT, it didn't have to think twice to decide to rewrite Angular 2 in an incompatible way to Angular 1, and so on." This is just wrong - almost 3/4 of Google's web apps depend on Angular from what I have heard from multiple Googlers. If a rare instance where an Angular release failure occurs, it shuts down Google's development process dramatically & costs millions in productivity. That rewrite is aimed at making Angular vastly improved - that doesn't equate to giving up on Angular, that is a poor analogy. In fact, Google decided to start investing vastly more resources into the Angular team, rapidly hiring and growing the team into a proper one, as opposed to it being a pet project of the Adwords team. In the next year or two, that ambition will bear much more fruit as mindshare grows with the realization of the technical problems solved & improved upon by ng2 - if React doesn't gear up to evolve, we'll probably see either a lot of defection to Angular, or a competitor that disagrees with the complexity that Angular introduces appearing to swallow React, just as React has done the same to grab disenchanted Backbone/Angular/etc. users. Otherwise, the article does a good job explaining a lot of things, but it is very defeatist, as if it is futile to try to improve upon things. I can't say I agree with that sentiment, it goes against the heart of research/trailblazing/experimentation/etc. It also makes some weak assertions, such as "One rarely benefits from big bang rewrites from scratch.", which is a generality being applied to every single situation, a fallacy. Confusing commonly accepted wisdom in development with an overextension of their meaning can lead to bad conclusions, as well as bad decision making.
- educar 10y ago
  > This is just wrong - almost 3/4 of Google's web apps depend on Angular from what I have heard from multiple Googlers. If a rare instance where an Angular release failure occurs, it shuts down Google's development process dramatically & costs millions in productivity. So you were quick to call somebody wrong based on complete heresay? Do you have any conclusive proof that they use it? Gmail? Analytics?
  - ben_jones 10y ago
    Literally 5 seconds of Googling [1]. Turns out the app that allows Google's Ad customers (i.e. their main source of revenue) to use the Google platform is written in angular. It's also one of the oldest and largest Angular apps in existence. [1]: https://www.youtube.com/watch?v=62RvRQuMVyg https://www.youtube.com/watch?v=62RvRQuMVyg
EpicEng 10y ago
I'm sure I'm going to get piled on here, but whatever. I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it. "This framework's the best!" "No, this one is obviously better!" "My design pattern is better than your design pattern!" I don't know, maybe I'm a 32 year old curmudgeon, but I just don't see this in my area. I work at a lower level; robotics, image processing/analysis, and general systems level stuff. We worry about what technologies we use for a given task as far as it impacts our design goals, i.e., "which technology is best suited for the job" (and there are more options nowadays than there used to be). Our customers couldn't care less about how we got there as long as the final product kicks ass. Once we arrive at a conclusion we move on and spend the remaining 99% of development solving actual problems. Hard problems. Often times unsolved problems. Our number one priority is reliability and accuracy (ok, that's two priorities). Whether or not we used e.g. C++ or Python to do it is irrelevant. What matters is that we built a system which works as it is supposed to and was engineered correctly. I don't understand this 'programming for programming's sake' mentality. At the end of the day these are just tools, not an end goal. Help me to understand.
- hliyan 10y ago
  As a 36 year old curmudgeon, I agree. I think the overabundance of framework/tool choices is resulting in decision paralysis. The C++ world doesn't (or at least it didn't) have this problem -- there's usually few standard ways to do something and it takes a only a few minutes to pick one. The rest of developer energies are spent on actual implementation.
- kinkdr 10y ago
  > Help me to understand. Human nature, maybe? People seem to like to form groups based on some random similarity (supporting the same football team, driving the same car model, believing in the same religion, being of the same race, etc..) and start fighting the opposite groups. My favorite example is the following trivia from the "Planet of the Apes" movie: "During breaks in filming, actors made up as different ape species tended to hang out together, gorillas with gorillas, orangutans with orangutans, chimps with chimps. It wasn't required, it just naturally happened."
bascule 10y ago
I've been using Rails for a decade now, across many jobs, and one thing I've experienced fairly consistently is the worst Ruby web apps I have ever dealt with are the ones that weren't written in Rails. I've both seen and spent a lot of time rewriting overgrown Sinatra monstrosities with assorted non-AR ORMs. These apps were generally riddled with XSS since they didn't handle escaping correctly, often had unmaintainable code that sometimes was thousands of lines long crammed into a single file, and lacking any sort of basic structuring principles mixed parameter handling with business logic all over the place. I've seen several attempts to "build a better Rails" that's "more OO", but even frameworks that solve the problems I've just described in the previous paragraph have one huge drawback: Rails is a lingua franca for web development in Ruby, and whatever incremental gains you get from having a better framework are heavily outweighed by the costs of making people learn a new framework-per-project, the lack of features and documentation, and the lack of the library ecosystem that surrounds Rails. At points I've tried to keep three ORMs/DB libraries in my head at a time: AR, DataMapper, and Sequel, which just left me wishing I was dealing with AR (the devil you know...) ORMs need massive feature sets to jam the proverbial square peg of relational databases through the round hole of objects, and AR is the only one I've used that's both expressive enough to cover all the cases I'm interested in and mature enough to even have a story around database concurrency, even if most Rails developers are getting database concurrency wrong with AR (e.g. http://www.bailis.org/papers/feral-sigmod2015.pdf http://www.bailis.org/papers/feral-sigmod2015.pdf ) At least AR has any story around things like optimistic and pessimistic locking and lets you build apps where you can read an object and persist your changes without silently clobbering another requests's database writes with your locally cached copy of stale data. tl;dr: if you want to do web development but dislike Rails, your best bet is probably to switch to a different programming language than Ruby.
- eropple 10y ago
  > AR is the only one I've used that's both expressive enough to cover all the cases I'm interested in Have you never worked on a system big enough to need a service layer?
  - bascule 10y ago
bdcravens 10y ago
These days, I'm finding a lot of joy in taking parts of a Rails app that feel clunky (meaning they usually aren't Basecamp-like, and I find myself using a lot of magic and config to make it fit a Rails-shaped hole), extracting it out as a stand-alone Sinatra app that uses Sequel instead of ActiveRecord, gemifying it, and then pulling it back into the parent monolith as an engine.
- girishso 10y ago
  Wow! I didn't know Rails engines can be written in Sinatra/Sequel. Wondering how that works exactly.
  - bdcravens 10y ago
    Wrap your app in a class (extending Sinatra::Application or Sinatra::Base), require (I gemified it for componentization) then mount in routes: mount MySinatraApp => '/some_path' (you can also mount it as rack app in config.ru, but not sure if you'd get access to things like authenticated session, etc)
    - girishso 10y ago
      Cool. A quick search landed me on https://robots.thoughtbot.com/how-to-share-a-session-between-sinatra-and-rails https://robots.thoughtbot.com/how-to-share-a-session-between... it discusses sharing session using config.ru. Even after using rails for so many years, learning something new every day!
glasz 10y ago
> Rails can now be considered a "problem" for the very same reasons that made it popular in the first place. And this is bound to happen to any technology. so, we won't be jobless anytime soon.
holografix 10y ago
Ruby was the number 1 reason why about 6 years ago, fresh out of uni with a Java/C background, I chose to learn Python and Django. Ruby seemed rather useless outside of Rails and I really, really liked what I saw in the Zen of Python. Ie. less magic, explicit > implicit. Etc.
- gamesbrainiac 10y ago
  I have to agree here. Its a good thing that Django doesn't have the kind of overwhelming power that Rails has in the community, which is pretty awesome! There's a lot of diversity, like flask, pyramid and others; although Django does have a large part of the pie.
  - dec0dedab0de 10y ago
    I think he was saying thay Django has a relatively small part in the overall Python pie.
    - elbear 10y ago
      As in web development plays a small part in everything Python. Python's scientific use comes to mind as a strong alternative.
- saiprashanth93 10y ago
  It's great that you learned Python and Django instead of Rails, but it seems pretty uncalled for to call Ruby useless outside of Rails. Programming languages take off because they show off their power by implementing a great library or by doing a better way of doing things which is what Ruby did using Rails. The impact of Rails on frameworks/libraries in other languages is also significant since a lot of Ruby developers moved to JS/Elixir/Go and started contributing and implementing the best patterns found in Rails/Sinatra etc.
  - pluma 10y ago
    I think "useless" in this case is meant in the sense of "isn't used much". The Ruby community and ecosystem is dominated by Rails to a much greater degree than Python is dominated by Django. Django is merely one of the more popular solutions to a larger niche of what Python is used for. The closest equivalent to Rails in Python in terms of dominance is probably SciPy and even that comparison is a stretch. The Python ecosystem is much more diverse than Ruby. Not because Ruby can't be used for anything other than what Rails is used for, but because there are simply more people doing the different things Python can be used for. And ultimately the practical usefulness of a language depends not just on the suitability of the language itself for the given task but also on the availability of libraries for the common problems you encounter when solving that task. So the usefulness of a language (for a given task) is at least partially defined by how much it is actually used (to solve that task).
jeffehobbs 10y ago
There’s a lot of personification and anthropomorphism of technology in this piece that distracts. Use the best tool for the job.
- deleted 10y ago
  [deleted]
- Jeff_Dickey 10y ago
  Agreed, but I'll just point out that works both ways. Devs "identify" with their default tool of choice, and too many coulda-been-GREAT tools try to be the Swiss Army Nuclear Ginsu Chainsaw of Code rather than the sweet hammer they started out as. Sometimes this happens to dominant tools in a category (such as Rails within Ruby); other times, it's happened to entire languages (PHP, VB, and many others; I once had to maintain a terminal emulator written in COBOL.) As Larry Wall and countless others have noted, great programmers are creatively lazy. Mediocre-to-average devs are lazy in less creative ways, like sticking to one language/toolchain for years and not diversifying. Anything that lives, including your career, either grows or it dies. Anything that grows within an impenetrable walled garden will eventually crush itself to death within those walls. It's sad when I see people do that to their careers, and over nearly 40 years in this craft, I've had ringside seats to multiple such bouts.
izietto 10y ago
Periodically raise up such articles à la "Rails is dead, long live the Rails". Rails has won in the past because it was so more pragmatic than its alternatives, and in the end better designed, and still wins now because it is more mature than its recent better designed competitors (Phoenix, Hanami, ..), and its community is so a big speed up now. > People think that because something is "technically superior" everybody else should blindly adopt. But this is not how the market works. This is really the citation describing the web development of the last 10-15 years. No surprise it comes from DHH.
singularity2001 10y ago
Why can't ruby? http://poignant.guide/book/chapter-7.html http://poignant.guide/book/chapter-7.html
aswanson 10y ago
I never thought I'd hear myself say this, but the ASP.NET MVC/IDE is a better ecosystem than Rails now. No more missing bundle x, install devkit x,....just install visual studio 15 and get to work.
- brianwawok 10y ago
  As long as you agree with the choices Microsoft makes. If you have a different opinion? Too bad.
  - Touche 10y ago
    Same with RoR, no?
    - gnuvince 10y ago
      Relevant username.
  - deleted 10y ago
    [deleted]
  - atonse 10y ago
    Eh... this stopped being true quite a while back. .NET has quite a vibrant open source ecosystem now, and it's only growing.
- brightball 10y ago
  The problem is that it basically locks you out of the ecosystem of Linux/Unix and that is significantly larger and more important than the ecosystem of Rails.
  - aswanson 10y ago
    Ok. Imagine me a developer just trying to put up an MVP to see if the idea gets traction. Pitch me on why I should rely on a toolchain that has multiple versions, bundles, and a plethora of (possibly) compatible packages vs one ide with autocompletion and a built in package manager that automatically picks the jquery, json, whateverelse-supporting-javascript library I need etc with a single install?
rosalinekarr 10y ago
Rails isn't the fastest or the smartest framework. It has weird choices, confusing aspects and some downright terrible defaults, but for me at least, it is the best framework and it has been for years for one simple reason: DOCUMENTATION! Every few years or so, a bunch of these articles come out shouting from the roof tops, "Rails is dead!" and "Long live Rails!" They often like to praise some new framework, like Hanami, as the answer to all our woes, but they never seem to address documentation. In my opinion, documentation is where Rails blows every other framework away. I have never been forced to read Rails' source code to understand how something works (I have read some of the source, but for fun, not out of need), and I can't say that about any of the other framework I've worked with. There's always some obscure method or class somewhere in them that does something unintuitive that I always have to look up. In Rails, finding the documentation on that method is as simple as a Google search, but in django, expressjs, or any of the others I've encountered, that documentation usually doesn't even exist at all. Efficiency, scalability and reliability are all great, but when I'm starting a web app from scratch, they're really not that important. I can worry about those things once I have funding. In the meantime, I only need them to be good enough, and Rails defaults are usually good enough. What I really need when I'm starting a new project and I'm working on a shoestring budget, is speed. I need to build something fast so I can get funded. Once I'm funded, then I can think about implementing JRuby or splitting code out into microservices or rewriting with another framework, but by then, I'll have the money to take my time. Until then, Rails is the perfect framework for me and I'll keep using it until it's not.
- brightball 10y ago
  Elixir and Phoenix is what you're looking for. Most of the goodness of Rails for productivity, without the long term bad decisions that come with it to force eventual rewrites when the funding comes. There's a reason Rails core guys have put so much time into it. It gets every...single...dang...decision...right. I may never use another language unless forced because it's what I've spent years trying to find.
  - jonstokes 10y ago
    If you discover a hot new language/framework that solves all of your problems, then here is what you've actually learned: you didn't have any hard problems. No tool is perfect for every situation, and if you find one that is perfect for every situation that you encounter, then that says a lot more about you than about the tool.
pcarolan 10y ago
Watching the Google IO keynote, I couldn't help noticing that their new instant apps could be accomplished in open webtools if they would have focused on browser integrations rather than native apps. I hope this doesn't mean native apps are shutting the door on the original idea of pure webapps ( remember that iPhone 1 keynote? ). I think it would take a major new platform doing exclusive html5/css3/js first and only to shift the paradigm. Then, follow that up with mobile browser improvements to make payments, contacts, hardware integrations better and we'd be on our way. Anyone know of a good app that is web only? Unfortunately, I think as native apps continue to dominate, there will be less incentive to build out mobile browser integration with open web platforms.
putzdown 10y ago
This article is a superb example of bad writing, of bad thinking. I have no skin in the Ruby/Rails game. I'm not a web developer. But I'm interested in the fates of languages and the merits of major approaches that define many jobs and decide the employability of millions, so I read it. The problem is: what in the world is he saying? What is his thesis, and what reason does he give us for believing his thesis? His opening section summarizes as: "I started to read a rant. It made me mad so I wrote a rant. Then I read the whole thing and felt better, so I wrote this." Okay, now try to summarize the second section. Something about Rails and Basecamp. Wordpress. Apple crushed Adobe. Finally: "Then there is the issue that Ruby's future is now tightly coupled with Rails." What issue? What is the point of all this? Sorry, OP, this is bad writing. It's bad thinking. It's saying "stuff" without knowing why. My advice: if you have skin in this game and need to make real decisions about what platform/language you use, find an article that reasons soundly about what the questions are and convinces you of its answers. Don't listen to this one. And if this quality of thinking is diagnostic of how Ruby/Rails developers think generally... well I'm glad that's a game my skin is safe from.
- tboyd47 10y ago
  I found it pretty coherent, actually. The author is trying to reset our focus from the technical details of how Rails works to the bigger picture of how the market for web technology has evolved over time. All the more important for those of us with "skin in the game," which I'm guessing means coders, because we tend to be myopic about our little world of symbols and tools, and often get caught clueless when the rug gets pulled out from under us by market forces that are indifferent to which design patterns are objectively better than others.
  - justinwr 10y ago
    I concur. Coming from São Paulo, Brazil, I thought Akita's post was well written and derived out of positive, lightly spoken, opinion. Breath of fresh air against the backdrop of hostile tech machoism.
- edbloom 10y ago
  Ah now that's a bit harsh. I thought it was pretty clear. Perhaps not getting to the point as quick as possible - but clear nevertheless.
tboyd47 10y ago
> The most important change of all: 2010 saw the advent of the Walled Garden App Store, commercially available native applications for smartphone and tablets. Forget web development: mobile was getting it all. This is the real elephant in the room. Everyone is looking for the "next Rails." There will be no "next Rails" because the web is not what it was when Rails came out. It's not "dead" or "dying," but it is just not the same. > Experienced people often forget the learning curve when they were themselves beginners, and at that time Rails was so attractive, so sexy. I always like to say Rails is for those kids who used to read the players' guides and instruction manuals for video games first, so they know all the secret moves and bonus areas before they even start playing. Some people prefer the challenge and power of discovering and designing things on their own, and they are never going to enjoy Rails because they'll be too caught up negotiating with themselves about how they would have done it.
ninjakeyboard 10y ago
Where there is a need for dynamic languages, Ruby can be a good fit. For example, Ruby is used in devops world where there is a bit of a split between Ruby and Python. It's very short sighted to think that Ruby has no future.
braythwayt 10y ago
I recall a lot of articles like this about J2EE. And then a lot like this about MSFT technologies. There was an essay pg wrote where he said that Microsoft was Dead (http://www.paulgraham.com/microsoft.html http://www.paulgraham.com/microsoft.html). He didn’t mean dead as in “Dead," he meant dead as in “Nobody is afraid of them any more,” and the generalization of that is that it was no longer relevant. I think Rails is there. I think Rails is dead. Obviously, not dead as in dead, but dead as in, it is no longer revolutionizing anything. It is no longer making new things possible. People no longer adopt it and discover a productivity dividend they didn’t expect. It no longer swings business decisions (“How can we get this done in three months? What about using Rails? Let’s try it.”) I think that’s fine. I can quote “A new perspective is worth 80 points of IQ.” I don’t think that’s true of Rails today, but then again, I don’t think that’s what people want from Rails. If people want 80 points of IQ, they’re off looking at Elixir and Phoenix. Likewise, I can say that “A language that doesn’t change the way you think about programming isn’t worth learning,” but who is learning Ruby and Rails in order to change the way they think about programming? They’re trying to bang out CRUD apps, and they don’t want to think about programming, that’s why they value a stable community with widely adopted “best practices.” When you have a stable, mature language and framework, you spend more time thinking about your business and less time thinking about programming. And thus, Rails (and sorry, but Ruby too) is not for people who want 80 points of IQ or to change the way they think about programming. And thus, in the sense of being influential, in the sense of disrupting anything or changing anything Rails is dead. It has matured. It is mainstream. It is plumbing, it is concrete, it is rebar, it is infrastructure. Necessary and useful. But not something you want to spend a lot of time thinking about, just something you use if it suits your purposes.
- pjc50 10y ago
  “A new perspective is worth 80 points of IQ.” That's not how IQ works. It's not additive.
  - braythwayt 10y ago
    The quote is from Dr. Alan Kay. I think he knew that when he said, it, and personally I think IQ is a racist, bullshit metric. But the general idea of the quote is still meaningful, and the thing I am saying when quoting it is that having gone mainstream, adopting Rails is no longer about adopting a new perspective. It’s tautological: You don’t get a new perspective, or an advantage, by adopting the mainstream thing and using it the mainstream way with the mainstream best practices, carefully writing your code to be familiar to the mainstream programmers. That’s not a bad thing, but it is a different thing from when Rails was first popping up in Reddit’s old days and HN’s early days.
websitescenes 10y ago
I'd agree that the initial approach of Rails is becoming dated but Rails is quickly moving away from this. Consider Rails 5. Native web sockets and an API mode make Rails an excellent backend for JS apps. You fail to recognize the evolution of the framework and where it continues to fit in today. If you're done with Rails it's probably because you failed to evolve with the framework.
deleted 10y ago
[deleted]
grandalf 10y ago
Rails was most influential in Rails v1 and v2, and after that it pretty much stagnated. In spite of that, millions of dollars have been spent upgrading Rails apps through subsequent versions, millions spent on developer training, etc. Sinatra picked up the REST torch from Rails (and from Camping) and sparked a significant change in how web apps are built and a cultural shift from monolithic frameworks to micro-frameworks. Node and Flask picked up from there, and gathered steam because both the Python and Node dependency management systems are less broken than Rubygems, allowing more practical use of smaller, orthogonal modules. Now Elm and React are focused on improving the reliability and reducing the incidental complexity of web applications. Aside from the occasional PR stunt rant from 37 Signals, Rails does not really have a thought leadership role in the development community anymore, aside from a loyal following of career rails programmers, who likely adopted Rails after v3 and would have been just as happy with nearly any monolithic framework and authoritative pundit. None of this is good or bad. Who knows what the future has in store. Rails pre v3 inspired a lot of the thinking that came after, but has not really embraced any of the ideas that emerged subsequently. I think the best analogy is Windows. It's a cash cow, it's not going to change quickly, and many people consider it the only sensible tool for the job.
mcguire 10y ago
"Basecamp-like apps are not too difficult to make, at least in terms of architecture. You don't need fancy super performant languages with super duper highly concurrent and parallel primitives. Also a reality is that 80% of the web applications are Basecamp-like (disclosure: my feelings for years of experience in consulting)." Someone once wrote something like, "An engineer is a person who can do for $1.50 what any damn fool can do for $5.00." I admit I don't actually have much experience with Rails itself; we had a couple of Rails apps that, after a couple of months of painful deployment and uptime teething, we moved to JRuby running on the same architecture as the rest of our apps. Then, after a couple of years of deferred maintenance and no updates (and a long list of security vulnerabilities) we rewrote them as plain, no framework, no ORM, Java and Javascript. But this quote rubs me the wrong way. Building small to medium web apps is what we do. A lot. We ought to be able to build them cheaply and quickly. But we also ought to be able to build them to be efficient and to not waste resources unnecessarily. In my experience, Rails succeeded because it's easy to go from nothing to a demoable proof of concept. And the Rails environment succeeded because it's possible to teach someone up from nothing to building a pretty application in six weeks. So why are we still fascinated with a tool that makes something easy that wasn't hard to begin with? That makes the first 10% trivial while leaving the other 90% alone, if not making it harder? That is optimized for the wrong thing? And it soaks up resources like crazy?
jrbapna 10y ago
As a rails / startup guy, I can run circles around developers who are using Node/Angular/React/etc. The huge open source community with the infinite number of gems and massive volume of documentation accumulated over years is unparalleled. Sure, Rails may eventually be eclipsed but I see no reason to switch now when my immediate goal is to ship fast with intense speed and fast iteration while focusing on the much more pressing business validation and business objectives of my company. Just my two cents on the topic.

316 points by mjbellantoni 10y ago

> Experienced people often forget the learning curve when they were themselves beginners, and at that time Rails was so attractive, so sexy. Remember that feeling? Of accomplishment in the face of the knowledge that some nice witch left super useful black magic behind? As one of those beginner programmers who had graduated from a development bootcamp, I fell in love with Sinatra much more than I did with Rails. Part of that love may be due to our curriculum...we have to master Sinatra first before you can start learning Rails. But I also liked the finer control that Sinatra provided to me. I suppose you can translate this to the current buzzword jargon of "hating Rails' magic", but writing out simple authentication using Bcrypt is just as much an accomplishment as using the Devise library. But your bigger point still remains intact. Passion should take a backseat towards choosing the right tool for the job. If you need Wordpress, use Wordpress. If you need Rails, use Rails. And so on and so forth. I may not like a certain tool...in fact, I may hate it, but I should still go ahead and use it anyway. You're here to complete a job. And you should make sure you do it well.

ascendantlogic 10y ago
I too like Sinatra but in my time writing Rails for both my day job(s) as well as various consulting gigs, I inevitably see Sinatra apps that start out with the best of intentions but always end up being just a shitty, hand-rolled version of Rails.
- wyaeld 10y ago
  The amount of time I hear - Rails, you ain't gonna need it, followed 6 months later by some version of "can we use this library to add a feature which OOTB Rails would have given us if we used it". What is bloat, and what is a useful feature you haven't quite grown into yet, is all a matter of perspective. I haven't yet found a project where you know 100% of what you're going to need upfront, so having a bit of depth in the toolbox is serving me well.
rubiquity 10y ago
Want to hear about an interesting project I heard of recently? Converting a Sinatra crap bomb into a Rails app.
busterarm 10y ago
As someone who didn't love Rails until I learned it "the right way", I'd argue that you have to thoroughly understand SQL joins and ActiveRecord before you can even attempt to architect a rails project. Very few bootcamps get this right, I feel, but a few do.

deleted 10y ago

[deleted]

kinkdr 10y ago

Nice read. I understand the sentiment but I find the "win declaration" a bit too weird. How can one say "Rails won"? It's not like people will stop making web frameworks. Like any other software it will eventually be made obsolete by something newer and better. Maybe I am just nitpicking.

vonklaus 10y ago
Yeah, I found that weird. However, if I think deeply about it, given the move to micro-services and soa type architectures I can see elixir winning longer term which is really railsy. regardless, rails has a ton of influence and some great usecases, but I would say nodejs is about as vogue as rails was and will dominate for another several years. as a nodejs dev, it is super annoying managing the asynchornicity of node and the horrifying dependencies. I suppose rails had stability issues as well. If you read rails is a ghetto by zed shaw, it is interesting (albeit super biased) look at how and why rails developed. edit: As noted, elixir isn't comparable to rails the framework in that arena is phoenix which is similar (at least in function). Thanks!.
- jghn 10y ago
  Elixir isn't comparable to rails, it's comparable to ruby. Phoenix is the thing comparable to rails Edit: I don't mean comparable as similar per se, but that one set are languages and the other are web frameworks
- deleted 10y ago
  [deleted]
- kinkdr 10y ago
  > rails is a ghetto by zed shaw Hilarious! :D
untog 10y ago
I think the "Rails won" sentiment is that 90% of the time, when you talk about a "Ruby job", it's a "Ruby on Rails" job. Not always, but the vast majority of the time. Now, that doesn't apply to any language other than Ruby. But this post might well be aimed at Rubyists exclusively.

vonklaus 10y ago

I haven't used rails in about 3 years (when I first started programming) and I only built 1 application which was a super shitty weekend instagram clone that didn't really work well. I didn't want to use rails anymore because it didn't feel like programming and nodeJS was getting hot. The thing is, I knew fuck all about programming then and now, I have the luxury of knowing very slightly less than fuck all. Which gives me the perspective that this article has, rails is pretty fucking awesome for building a crud application that uses a relational datastore. The author indicated ~80%. Wordpress is also something I swore off when I was learning because it straight up wasn't programming. I installed wordpress on a server for the first time last week to setup a blog. I browsed a few thousand themes, it took me a while to find a theme for a blog. The just a blogging platform is actually more ironic now, than it ever was. So, I agree with the author the design patterns shape the community and then the community shapes the design patterns. You can pretty much build any type of app with any language if you are motivated and talented, however, from my observation, the following languages seem to give you the highest leverage in the domains the community has evolved them for: PHP/Wordpress: Blogging sites & CMS building. Node/JS: Applications and APIs typically with a noSQL database. Ruby/Rails: Building CRUD apps with relational datastores. Python: Data intensive applications & programming. erlang/elixir: Never used this, but seems ideal for highly scalable concurrent architecture and highly scalable process choreography. So in essence, I agree with the author. I would love to switch from node to Rails as I like the framework aspect where you can just get productive super quick. I also see rails as going away, so I wouldn't make the time investment. I think learning node was the right thing to do ~3 years ago, but I wish I spent another 6 months using rails and got really comfortable with it first. > This is not serious programming/you aren't a serious programmer fairplay. I am a jr. web developer, explaining my conception of some frameworks/communities/languages, so I agree with you that I am not a particularly talented programmer (it isn't my core skillset) and I am not solving hard problems in this arena(as I don't conetend that I am). I disagree that I claimed any of the above was my definition of serious programming. Of the hard problems I will work on/what I think needs to be solved, I have spoken of at length elsewhere.

rubiquity 10y ago
> I didn't want to use rails anymore because it didn't feel like programming and nodeJS was getting hot. > Wordpress is also something I swore off when I was learning because it straight up wasn't programming > Python: Data intensive applications & programming. I would love to hear your definition of programming.

jaequery 10y ago

If we are talking about frameworks, I believe Padrino is a much better designed framework than Rails. It doesn't have any magic of Rails and architected in a very elegant way. I just can't tolerate ActiveRecord, so Padrino having Sequel support out of the box was definitely an important step in going away from Rails. Also being built on top of Sinatra, it is also much lighter and faster than Rails, another huge reason to switch. Yes Rails wins the popularity contest, but it doesn't mean it's the best thing for Ruby.

fieryeagle 10y ago

I suppose this is how you gain fame these days, writing sensational counter-arguments instead of coding? Oh right, the author is a 'Ruby Activist', he couldn't help it. PHP has won, Node has won and now yet another language up to debate? Having something with its own niche and cult doesn't mean anything if it's not suitable for work. It does help populate shortcut-seeking approaches such as Heroku and more CRUD apps than ever before so Rails has its places. Here's a piece to deflate any ego issues http://www.paulgraham.com/identity.html http://www.paulgraham.com/identity.html.

Ace17 10y ago
The article you linked is pure gold ;thanks for sharing!
- fieryeagle 10y ago
  Yeah, such a poignant read that cuts to the heart of the problem - our needs to associate and express.
deleted 10y ago
[deleted]

programmer1234 10y ago

Time saver: Just look at his company's website. Time waster: Rails has won in the same way that PHP and .NET "won" in the 2000s. There are a lot of problems with Ruby, it's sort of this isolated language that's useful for Rails only, and I wonder if python and django don't offer a suitable replacement for 80% of cases where you can choose between hiring Rails and Django engineers. Graphing "PHP", "Rails", and "Nodejs" on Google Trends makes Rails look like a fad and all the future money is going to be in maintenance work. The article's weakness lies in the fact that it argues against the assertion that "Rails has these big problems, it's no longer the best approach", by instead arguing that "Rails is good enough most of the time" in a way that doesn't quite live up to the title.

Bahamut 10y ago

"But I would never, ever, begin a new business that depends solely on Angular to survive. Why? Because Google doesn't need it. It didn't blink to give up GWT, it didn't have to think twice to decide to rewrite Angular 2 in an incompatible way to Angular 1, and so on." This is just wrong - almost 3/4 of Google's web apps depend on Angular from what I have heard from multiple Googlers. If a rare instance where an Angular release failure occurs, it shuts down Google's development process dramatically & costs millions in productivity. That rewrite is aimed at making Angular vastly improved - that doesn't equate to giving up on Angular, that is a poor analogy. In fact, Google decided to start investing vastly more resources into the Angular team, rapidly hiring and growing the team into a proper one, as opposed to it being a pet project of the Adwords team. In the next year or two, that ambition will bear much more fruit as mindshare grows with the realization of the technical problems solved & improved upon by ng2 - if React doesn't gear up to evolve, we'll probably see either a lot of defection to Angular, or a competitor that disagrees with the complexity that Angular introduces appearing to swallow React, just as React has done the same to grab disenchanted Backbone/Angular/etc. users. Otherwise, the article does a good job explaining a lot of things, but it is very defeatist, as if it is futile to try to improve upon things. I can't say I agree with that sentiment, it goes against the heart of research/trailblazing/experimentation/etc. It also makes some weak assertions, such as "One rarely benefits from big bang rewrites from scratch.", which is a generality being applied to every single situation, a fallacy. Confusing commonly accepted wisdom in development with an overextension of their meaning can lead to bad conclusions, as well as bad decision making.

educar 10y ago
> This is just wrong - almost 3/4 of Google's web apps depend on Angular from what I have heard from multiple Googlers. If a rare instance where an Angular release failure occurs, it shuts down Google's development process dramatically & costs millions in productivity. So you were quick to call somebody wrong based on complete heresay? Do you have any conclusive proof that they use it? Gmail? Analytics?
- ben_jones 10y ago
  Literally 5 seconds of Googling [1]. Turns out the app that allows Google's Ad customers (i.e. their main source of revenue) to use the Google platform is written in angular. It's also one of the oldest and largest Angular apps in existence. [1]: https://www.youtube.com/watch?v=62RvRQuMVyg https://www.youtube.com/watch?v=62RvRQuMVyg

EpicEng 10y ago

I'm sure I'm going to get piled on here, but whatever. I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it. "This framework's the best!" "No, this one is obviously better!" "My design pattern is better than your design pattern!" I don't know, maybe I'm a 32 year old curmudgeon, but I just don't see this in my area. I work at a lower level; robotics, image processing/analysis, and general systems level stuff. We worry about what technologies we use for a given task as far as it impacts our design goals, i.e., "which technology is best suited for the job" (and there are more options nowadays than there used to be). Our customers couldn't care less about how we got there as long as the final product kicks ass. Once we arrive at a conclusion we move on and spend the remaining 99% of development solving actual problems. Hard problems. Often times unsolved problems. Our number one priority is reliability and accuracy (ok, that's two priorities). Whether or not we used e.g. C++ or Python to do it is irrelevant. What matters is that we built a system which works as it is supposed to and was engineered correctly. I don't understand this 'programming for programming's sake' mentality. At the end of the day these are just tools, not an end goal. Help me to understand.

hliyan 10y ago
As a 36 year old curmudgeon, I agree. I think the overabundance of framework/tool choices is resulting in decision paralysis. The C++ world doesn't (or at least it didn't) have this problem -- there's usually few standard ways to do something and it takes a only a few minutes to pick one. The rest of developer energies are spent on actual implementation.
kinkdr 10y ago
> Help me to understand. Human nature, maybe? People seem to like to form groups based on some random similarity (supporting the same football team, driving the same car model, believing in the same religion, being of the same race, etc..) and start fighting the opposite groups. My favorite example is the following trivia from the "Planet of the Apes" movie: "During breaks in filming, actors made up as different ape species tended to hang out together, gorillas with gorillas, orangutans with orangutans, chimps with chimps. It wasn't required, it just naturally happened."

bascule 10y ago

I've been using Rails for a decade now, across many jobs, and one thing I've experienced fairly consistently is the worst Ruby web apps I have ever dealt with are the ones that weren't written in Rails. I've both seen and spent a lot of time rewriting overgrown Sinatra monstrosities with assorted non-AR ORMs. These apps were generally riddled with XSS since they didn't handle escaping correctly, often had unmaintainable code that sometimes was thousands of lines long crammed into a single file, and lacking any sort of basic structuring principles mixed parameter handling with business logic all over the place. I've seen several attempts to "build a better Rails" that's "more OO", but even frameworks that solve the problems I've just described in the previous paragraph have one huge drawback: Rails is a lingua franca for web development in Ruby, and whatever incremental gains you get from having a better framework are heavily outweighed by the costs of making people learn a new framework-per-project, the lack of features and documentation, and the lack of the library ecosystem that surrounds Rails. At points I've tried to keep three ORMs/DB libraries in my head at a time: AR, DataMapper, and Sequel, which just left me wishing I was dealing with AR (the devil you know...) ORMs need massive feature sets to jam the proverbial square peg of relational databases through the round hole of objects, and AR is the only one I've used that's both expressive enough to cover all the cases I'm interested in and mature enough to even have a story around database concurrency, even if most Rails developers are getting database concurrency wrong with AR (e.g. http://www.bailis.org/papers/feral-sigmod2015.pdf http://www.bailis.org/papers/feral-sigmod2015.pdf ) At least AR has any story around things like optimistic and pessimistic locking and lets you build apps where you can read an object and persist your changes without silently clobbering another requests's database writes with your locally cached copy of stale data. tl;dr: if you want to do web development but dislike Rails, your best bet is probably to switch to a different programming language than Ruby.

eropple 10y ago
> AR is the only one I've used that's both expressive enough to cover all the cases I'm interested in Have you never worked on a system big enough to need a service layer?
- bascule 10y ago

bdcravens 10y ago

These days, I'm finding a lot of joy in taking parts of a Rails app that feel clunky (meaning they usually aren't Basecamp-like, and I find myself using a lot of magic and config to make it fit a Rails-shaped hole), extracting it out as a stand-alone Sinatra app that uses Sequel instead of ActiveRecord, gemifying it, and then pulling it back into the parent monolith as an engine.

girishso 10y ago
Wow! I didn't know Rails engines can be written in Sinatra/Sequel. Wondering how that works exactly.
- bdcravens 10y ago
  Wrap your app in a class (extending Sinatra::Application or Sinatra::Base), require (I gemified it for componentization) then mount in routes: mount MySinatraApp => '/some_path' (you can also mount it as rack app in config.ru, but not sure if you'd get access to things like authenticated session, etc)
  - girishso 10y ago
    Cool. A quick search landed me on https://robots.thoughtbot.com/how-to-share-a-session-between-sinatra-and-rails https://robots.thoughtbot.com/how-to-share-a-session-between... it discusses sharing session using config.ru. Even after using rails for so many years, learning something new every day!

glasz 10y ago

> Rails can now be considered a "problem" for the very same reasons that made it popular in the first place. And this is bound to happen to any technology. so, we won't be jobless anytime soon.

holografix 10y ago

Ruby was the number 1 reason why about 6 years ago, fresh out of uni with a Java/C background, I chose to learn Python and Django. Ruby seemed rather useless outside of Rails and I really, really liked what I saw in the Zen of Python. Ie. less magic, explicit > implicit. Etc.

gamesbrainiac 10y ago
I have to agree here. Its a good thing that Django doesn't have the kind of overwhelming power that Rails has in the community, which is pretty awesome! There's a lot of diversity, like flask, pyramid and others; although Django does have a large part of the pie.
- dec0dedab0de 10y ago
  I think he was saying thay Django has a relatively small part in the overall Python pie.
  - elbear 10y ago
    As in web development plays a small part in everything Python. Python's scientific use comes to mind as a strong alternative.
saiprashanth93 10y ago
It's great that you learned Python and Django instead of Rails, but it seems pretty uncalled for to call Ruby useless outside of Rails. Programming languages take off because they show off their power by implementing a great library or by doing a better way of doing things which is what Ruby did using Rails. The impact of Rails on frameworks/libraries in other languages is also significant since a lot of Ruby developers moved to JS/Elixir/Go and started contributing and implementing the best patterns found in Rails/Sinatra etc.
- pluma 10y ago
  I think "useless" in this case is meant in the sense of "isn't used much". The Ruby community and ecosystem is dominated by Rails to a much greater degree than Python is dominated by Django. Django is merely one of the more popular solutions to a larger niche of what Python is used for. The closest equivalent to Rails in Python in terms of dominance is probably SciPy and even that comparison is a stretch. The Python ecosystem is much more diverse than Ruby. Not because Ruby can't be used for anything other than what Rails is used for, but because there are simply more people doing the different things Python can be used for. And ultimately the practical usefulness of a language depends not just on the suitability of the language itself for the given task but also on the availability of libraries for the common problems you encounter when solving that task. So the usefulness of a language (for a given task) is at least partially defined by how much it is actually used (to solve that task).

jeffehobbs 10y ago

There’s a lot of personification and anthropomorphism of technology in this piece that distracts. Use the best tool for the job.

deleted 10y ago
[deleted]
Jeff_Dickey 10y ago
Agreed, but I'll just point out that works both ways. Devs "identify" with their default tool of choice, and too many coulda-been-GREAT tools try to be the Swiss Army Nuclear Ginsu Chainsaw of Code rather than the sweet hammer they started out as. Sometimes this happens to dominant tools in a category (such as Rails within Ruby); other times, it's happened to entire languages (PHP, VB, and many others; I once had to maintain a terminal emulator written in COBOL.) As Larry Wall and countless others have noted, great programmers are creatively lazy. Mediocre-to-average devs are lazy in less creative ways, like sticking to one language/toolchain for years and not diversifying. Anything that lives, including your career, either grows or it dies. Anything that grows within an impenetrable walled garden will eventually crush itself to death within those walls. It's sad when I see people do that to their careers, and over nearly 40 years in this craft, I've had ringside seats to multiple such bouts.

izietto 10y ago

Periodically raise up such articles à la "Rails is dead, long live the Rails". Rails has won in the past because it was so more pragmatic than its alternatives, and in the end better designed, and still wins now because it is more mature than its recent better designed competitors (Phoenix, Hanami, ..), and its community is so a big speed up now. > People think that because something is "technically superior" everybody else should blindly adopt. But this is not how the market works. This is really the citation describing the web development of the last 10-15 years. No surprise it comes from DHH.

singularity2001 10y ago

Why can't ruby? http://poignant.guide/book/chapter-7.html http://poignant.guide/book/chapter-7.html

aswanson 10y ago

I never thought I'd hear myself say this, but the ASP.NET MVC/IDE is a better ecosystem than Rails now. No more missing bundle x, install devkit x,....just install visual studio 15 and get to work.

brianwawok 10y ago
As long as you agree with the choices Microsoft makes. If you have a different opinion? Too bad.
- Touche 10y ago
  Same with RoR, no?
  - gnuvince 10y ago
    Relevant username.
- deleted 10y ago
  [deleted]
- atonse 10y ago
  Eh... this stopped being true quite a while back. .NET has quite a vibrant open source ecosystem now, and it's only growing.
brightball 10y ago
The problem is that it basically locks you out of the ecosystem of Linux/Unix and that is significantly larger and more important than the ecosystem of Rails.
- aswanson 10y ago
  Ok. Imagine me a developer just trying to put up an MVP to see if the idea gets traction. Pitch me on why I should rely on a toolchain that has multiple versions, bundles, and a plethora of (possibly) compatible packages vs one ide with autocompletion and a built in package manager that automatically picks the jquery, json, whateverelse-supporting-javascript library I need etc with a single install?

rosalinekarr 10y ago

Rails isn't the fastest or the smartest framework. It has weird choices, confusing aspects and some downright terrible defaults, but for me at least, it is the best framework and it has been for years for one simple reason: DOCUMENTATION! Every few years or so, a bunch of these articles come out shouting from the roof tops, "Rails is dead!" and "Long live Rails!" They often like to praise some new framework, like Hanami, as the answer to all our woes, but they never seem to address documentation. In my opinion, documentation is where Rails blows every other framework away. I have never been forced to read Rails' source code to understand how something works (I have read some of the source, but for fun, not out of need), and I can't say that about any of the other framework I've worked with. There's always some obscure method or class somewhere in them that does something unintuitive that I always have to look up. In Rails, finding the documentation on that method is as simple as a Google search, but in django, expressjs, or any of the others I've encountered, that documentation usually doesn't even exist at all. Efficiency, scalability and reliability are all great, but when I'm starting a web app from scratch, they're really not that important. I can worry about those things once I have funding. In the meantime, I only need them to be good enough, and Rails defaults are usually good enough. What I really need when I'm starting a new project and I'm working on a shoestring budget, is speed. I need to build something fast so I can get funded. Once I'm funded, then I can think about implementing JRuby or splitting code out into microservices or rewriting with another framework, but by then, I'll have the money to take my time. Until then, Rails is the perfect framework for me and I'll keep using it until it's not.

brightball 10y ago
Elixir and Phoenix is what you're looking for. Most of the goodness of Rails for productivity, without the long term bad decisions that come with it to force eventual rewrites when the funding comes. There's a reason Rails core guys have put so much time into it. It gets every...single...dang...decision...right. I may never use another language unless forced because it's what I've spent years trying to find.
- jonstokes 10y ago
  If you discover a hot new language/framework that solves all of your problems, then here is what you've actually learned: you didn't have any hard problems. No tool is perfect for every situation, and if you find one that is perfect for every situation that you encounter, then that says a lot more about you than about the tool.

pcarolan 10y ago

Watching the Google IO keynote, I couldn't help noticing that their new instant apps could be accomplished in open webtools if they would have focused on browser integrations rather than native apps. I hope this doesn't mean native apps are shutting the door on the original idea of pure webapps ( remember that iPhone 1 keynote? ). I think it would take a major new platform doing exclusive html5/css3/js first and only to shift the paradigm. Then, follow that up with mobile browser improvements to make payments, contacts, hardware integrations better and we'd be on our way. Anyone know of a good app that is web only? Unfortunately, I think as native apps continue to dominate, there will be less incentive to build out mobile browser integration with open web platforms.

putzdown 10y ago

This article is a superb example of bad writing, of bad thinking. I have no skin in the Ruby/Rails game. I'm not a web developer. But I'm interested in the fates of languages and the merits of major approaches that define many jobs and decide the employability of millions, so I read it. The problem is: what in the world is he saying? What is his thesis, and what reason does he give us for believing his thesis? His opening section summarizes as: "I started to read a rant. It made me mad so I wrote a rant. Then I read the whole thing and felt better, so I wrote this." Okay, now try to summarize the second section. Something about Rails and Basecamp. Wordpress. Apple crushed Adobe. Finally: "Then there is the issue that Ruby's future is now tightly coupled with Rails." What issue? What is the point of all this? Sorry, OP, this is bad writing. It's bad thinking. It's saying "stuff" without knowing why. My advice: if you have skin in this game and need to make real decisions about what platform/language you use, find an article that reasons soundly about what the questions are and convinces you of its answers. Don't listen to this one. And if this quality of thinking is diagnostic of how Ruby/Rails developers think generally... well I'm glad that's a game my skin is safe from.

tboyd47 10y ago
I found it pretty coherent, actually. The author is trying to reset our focus from the technical details of how Rails works to the bigger picture of how the market for web technology has evolved over time. All the more important for those of us with "skin in the game," which I'm guessing means coders, because we tend to be myopic about our little world of symbols and tools, and often get caught clueless when the rug gets pulled out from under us by market forces that are indifferent to which design patterns are objectively better than others.
- justinwr 10y ago
  I concur. Coming from São Paulo, Brazil, I thought Akita's post was well written and derived out of positive, lightly spoken, opinion. Breath of fresh air against the backdrop of hostile tech machoism.
edbloom 10y ago
Ah now that's a bit harsh. I thought it was pretty clear. Perhaps not getting to the point as quick as possible - but clear nevertheless.

tboyd47 10y ago

> The most important change of all: 2010 saw the advent of the Walled Garden App Store, commercially available native applications for smartphone and tablets. Forget web development: mobile was getting it all. This is the real elephant in the room. Everyone is looking for the "next Rails." There will be no "next Rails" because the web is not what it was when Rails came out. It's not "dead" or "dying," but it is just not the same. > Experienced people often forget the learning curve when they were themselves beginners, and at that time Rails was so attractive, so sexy. I always like to say Rails is for those kids who used to read the players' guides and instruction manuals for video games first, so they know all the secret moves and bonus areas before they even start playing. Some people prefer the challenge and power of discovering and designing things on their own, and they are never going to enjoy Rails because they'll be too caught up negotiating with themselves about how they would have done it.

ninjakeyboard 10y ago

Where there is a need for dynamic languages, Ruby can be a good fit. For example, Ruby is used in devops world where there is a bit of a split between Ruby and Python. It's very short sighted to think that Ruby has no future.

braythwayt 10y ago

I recall a lot of articles like this about J2EE. And then a lot like this about MSFT technologies. There was an essay pg wrote where he said that Microsoft was Dead (http://www.paulgraham.com/microsoft.html http://www.paulgraham.com/microsoft.html). He didn’t mean dead as in “Dead," he meant dead as in “Nobody is afraid of them any more,” and the generalization of that is that it was no longer relevant. I think Rails is there. I think Rails is dead. Obviously, not dead as in dead, but dead as in, it is no longer revolutionizing anything. It is no longer making new things possible. People no longer adopt it and discover a productivity dividend they didn’t expect. It no longer swings business decisions (“How can we get this done in three months? What about using Rails? Let’s try it.”) I think that’s fine. I can quote “A new perspective is worth 80 points of IQ.” I don’t think that’s true of Rails today, but then again, I don’t think that’s what people want from Rails. If people want 80 points of IQ, they’re off looking at Elixir and Phoenix. Likewise, I can say that “A language that doesn’t change the way you think about programming isn’t worth learning,” but who is learning Ruby and Rails in order to change the way they think about programming? They’re trying to bang out CRUD apps, and they don’t want to think about programming, that’s why they value a stable community with widely adopted “best practices.” When you have a stable, mature language and framework, you spend more time thinking about your business and less time thinking about programming. And thus, Rails (and sorry, but Ruby too) is not for people who want 80 points of IQ or to change the way they think about programming. And thus, in the sense of being influential, in the sense of disrupting anything or changing anything Rails is dead. It has matured. It is mainstream. It is plumbing, it is concrete, it is rebar, it is infrastructure. Necessary and useful. But not something you want to spend a lot of time thinking about, just something you use if it suits your purposes.

pjc50 10y ago
“A new perspective is worth 80 points of IQ.” That's not how IQ works. It's not additive.
- braythwayt 10y ago
  The quote is from Dr. Alan Kay. I think he knew that when he said, it, and personally I think IQ is a racist, bullshit metric. But the general idea of the quote is still meaningful, and the thing I am saying when quoting it is that having gone mainstream, adopting Rails is no longer about adopting a new perspective. It’s tautological: You don’t get a new perspective, or an advantage, by adopting the mainstream thing and using it the mainstream way with the mainstream best practices, carefully writing your code to be familiar to the mainstream programmers. That’s not a bad thing, but it is a different thing from when Rails was first popping up in Reddit’s old days and HN’s early days.

websitescenes 10y ago

I'd agree that the initial approach of Rails is becoming dated but Rails is quickly moving away from this. Consider Rails 5. Native web sockets and an API mode make Rails an excellent backend for JS apps. You fail to recognize the evolution of the framework and where it continues to fit in today. If you're done with Rails it's probably because you failed to evolve with the framework.

deleted 10y ago

[deleted]

grandalf 10y ago

Rails was most influential in Rails v1 and v2, and after that it pretty much stagnated. In spite of that, millions of dollars have been spent upgrading Rails apps through subsequent versions, millions spent on developer training, etc. Sinatra picked up the REST torch from Rails (and from Camping) and sparked a significant change in how web apps are built and a cultural shift from monolithic frameworks to micro-frameworks. Node and Flask picked up from there, and gathered steam because both the Python and Node dependency management systems are less broken than Rubygems, allowing more practical use of smaller, orthogonal modules. Now Elm and React are focused on improving the reliability and reducing the incidental complexity of web applications. Aside from the occasional PR stunt rant from 37 Signals, Rails does not really have a thought leadership role in the development community anymore, aside from a loyal following of career rails programmers, who likely adopted Rails after v3 and would have been just as happy with nearly any monolithic framework and authoritative pundit. None of this is good or bad. Who knows what the future has in store. Rails pre v3 inspired a lot of the thinking that came after, but has not really embraced any of the ideas that emerged subsequently. I think the best analogy is Windows. It's a cash cow, it's not going to change quickly, and many people consider it the only sensible tool for the job.

mcguire 10y ago

"Basecamp-like apps are not too difficult to make, at least in terms of architecture. You don't need fancy super performant languages with super duper highly concurrent and parallel primitives. Also a reality is that 80% of the web applications are Basecamp-like (disclosure: my feelings for years of experience in consulting)." Someone once wrote something like, "An engineer is a person who can do for $1.50 what any damn fool can do for $5.00." I admit I don't actually have much experience with Rails itself; we had a couple of Rails apps that, after a couple of months of painful deployment and uptime teething, we moved to JRuby running on the same architecture as the rest of our apps. Then, after a couple of years of deferred maintenance and no updates (and a long list of security vulnerabilities) we rewrote them as plain, no framework, no ORM, Java and Javascript. But this quote rubs me the wrong way. Building small to medium web apps is what we do. A lot. We ought to be able to build them cheaply and quickly. But we also ought to be able to build them to be efficient and to not waste resources unnecessarily. In my experience, Rails succeeded because it's easy to go from nothing to a demoable proof of concept. And the Rails environment succeeded because it's possible to teach someone up from nothing to building a pretty application in six weeks. So why are we still fascinated with a tool that makes something easy that wasn't hard to begin with? That makes the first 10% trivial while leaving the other 90% alone, if not making it harder? That is optimized for the wrong thing? And it soaks up resources like crazy?

jrbapna 10y ago

As a rails / startup guy, I can run circles around developers who are using Node/Angular/React/etc. The huge open source community with the infinite number of gems and massive volume of documentation accumulated over years is unparalleled. Sure, Rails may eventually be eclipsed but I see no reason to switch now when my immediate goal is to ship fast with intense speed and fast iteration while focusing on the much more pressing business validation and business objectives of my company. Just my two cents on the topic.