19 ms·

Why I believe Rails is still relevant in 2019

• carmate383 8y ago
  There's nothing worse than flogging a dead horse, yet Ruby fan boys seem to love doing it. Just. Let. Rails. Die. Save the world from some Carbon and don't implode the sun by running that garbage.
  • carmate383 8y ago
    And here come the knee-jerk down votes.
    • everdev 8y ago
      I think the down votes are for spouting nonsense instead of having a rational discussion about the article.
      • carmate383 8y ago
        How does one rationally discuss an irrational conjecture?
        • nitrogen 8y ago
          Start with the principle of charity.
      • rapsey 8y ago
        And for toxic attitude that ruined /r/programming
        • carmate383 8y ago
          You think being open to true _facts_ implies a toxic attitude? You must really live in a small, limited world. Here's a graph displaying some factual and relevant information: https://trends.google.com/trends/explore?date=all&geo=US&q=Ruby%20on%20Rails https://trends.google.com/trends/explore?date=all&geo=US&q=R...
        • sergiotapia 8y ago
          Let people say what they want to say online - what is this culture of wanting to shut down everything.
          • rapsey 8y ago
            Shouting and insulting people is no way to have a discussion. Without moderation or some other mechanism this is what online communities devolve into and it destroys them. /r/programming used to have lots of great discussion. Now it's mostly a deserted wasteland.
            • sergiotapia 8y ago
              >Shouting and insulting people is no way to have a discussion. Says you! I don't enjoy the flaming, but things have gone too far to the other side where you can't anything online or you get CoC broken over it.
              • everdev 8y ago
                I think the forum matters. Want to insult people and get praised for it? Twitter and Reddit are the place to be. Just like in the real world, some language is appropriate at the library and some is better saved for the bar.
• rememberlenny 8y ago
  As an individual developer, I don’t know a platform and framework that lets me do more with my time. I used rails recently for a new project to act both as the backend for an iOS app, an auth management system, a asynchronous worker manager, an upload manaager, and BI tool. Combined with the mature gem ecosystem and clear mechanics for putting everything together, I was up and running immediately, and was able to continue adding features and refining without issues.
  • yedpodtrzitko 8y ago
    I replaced `rails` with `Django` in your statement (and maybe could do the same with Node.js), and it reads the same. Guess it's just about being familiar with a mature ecosystem you already know, and then you can achieve results.
    • nahtnam 8y ago
      You could also replace it with Laravel, or any other framework. What I've found is that if you want to be productive, stick with what you know. Don't try to solve problems you don't/probably won't have.
      • deleted 8y ago
        [deleted]
    • jypepin 8y ago
      Agreed. Although I do Rails and have no experience with Django I know Django is the same. To my knowledge tho, I do believe those are the only 2 framework that offer so many plug-and-play, trustable component for everything, allowing you to be up and running so fast. I've built similarly large systems both with rails, flask and nodejs. Nodejs environment was definitely the worst, on every front, and I coming back to something like Rails always feels like I have so much more power.
      • ramraj07 8y ago
        As someone who's built a few apps in flask that have gotten quite big (but still maintenable), I am curious to get your perspective on how big a difference Rails gives - I have explored ASP.net and Django as options before for projects and immediately (probably out of naivete) concluded that even for simple apps I'll have to start modding the behavior of the components sufficiently enough that it will give me a headache. Hence I have generally stuck to using Flask and just quickly building a custom version of any component that doesn't directly cause any security issues. Thoughts? Am I wasting my time ?
• mavdi 8y ago
  Every time I read an article about something still being relevant, it soon becomes irrelevant.
  • carmate383 8y ago
    Soon becomes irrelevant, or is already irrelevant?
  • joelbluminator 8y ago
    Naah Rails is here to stay - the momentum around the project is still huge and too many companies rely on it. Even if dhh did a Guido and left, there's a big army of contributors that would replace him. If I need to guess though, in 10 years dhh is still involved with Rails to some degree.
    • pankajdoharey 8y ago
      Staying power has less to do with relevance and more to do with legacy apps. There will always be some people working on any given technology. Be it Spring, Smalltalk, Common Lisp or ...some X technology. The question is, is it relevant? In an increasingly Multicore world where you try to extract more performance out of your CPU's Ruby may not cut it and by induction Rails. The future web devs would require writing better multithreaded code probably on the JVM. Clojure, Erlang or Go are the few awesome options that come to my mind.
• fouc 8y ago
  All the standard web technologies are still relevant. MySQL & PostgreSQL are still relevant. Redis is still relevant. Ruby on Rails is still relevant. Javascript is still relevant.
  • ramblerman 8y ago
    Some of those are even more relevant these days. - JS has only grown in ubiquity and maturity of the language. - postgres also seems to be on a comeback now the honeymoon phase of nosql is over.
    • rimliu 8y ago
      > JS has only grown in ubiquity and maturity of the > language. Well… if you say so. In my eyes a couple of sugarcoating patches do not make language mature. Standard library is still nowhere to be found.
    • cutler 8y ago
      JS - mature? It still has no standard library and probably never will.
  • lmm 8y ago
    Disagree with all of those except Javascript (and that only as an execution layer). All of the things that those technologies promised, we now have better ways of achieving.
    • robenkleene 8y ago
      Yet here we sit in entire thread that’s the perfect place to discuss these “better ways” of doing things and I'm seeing zero consensus about what those better ways might be. Are other people interpreting this thread differently?
      • lmm 8y ago
        There's no clear consensus on which way is best. That doesn't mean there aren't better and worse ways.
• revskill 8y ago
  Rails needs more opinionated decision on frontend story. Just pick ReactJS instead ? Not a bad idea. Or VueJS ? Neither a bad choice. It's the main reason i don't choose Rails over a universal Node.js stack for the HTML rendering part.
  • jmchuster 8y ago
    Their opinion is coffeescript + turbolinks, which turn out to be the first two defaults developers change.
    • revskill 8y ago
      I mean something like Typescript with an opinionated library/framework for client-side part.
      • peteforde 8y ago
        Okay, I have lots of good news for you. First, CoffeeScript is formally deprecated. Turbolinks sucked, but Turbolinks 5 is an entirely new beast and it rocks. You need to give it a second look. I recommend this talk, sped up to 1.5x: https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s Finally, there absolutely is an opinionated client library that is designed to pair beautifully with Turbolinks 5. It's called Stimulus and it rocks. https://stimulusjs.org/ https://stimulusjs.org/ You can play with all of these frameworks using the --webpack parameter: rails new future --skip-sprockets --skip-coffee --webpack=stimulus --database=postgresql --skip-test As a bonus for anyone starting a new Rails project today, you're going to want to bookmark https://gist.github.com/andyyou/834e82f5723fec9d2dc021fb7b819517 https://gist.github.com/andyyou/834e82f5723fec9d2dc021fb7b81... Let me know if you have any questions.
        • revskill 8y ago
          Thanks, it's an almost complete guide. But there's one important missing piece: Universal routing. How about taking the routing config which can be applied for both server and client ?
• dawhizkid 8y ago
  Aren't some large at-scale apps still on RoR? AFAIK Coinbase, Shopify, Twitch, etc...
  • joelbluminator 8y ago
    Github, Gitlab, Scribd. But shopify is definitely THE example for a Rails monolith. The team working on it, and the scale, are huge.
  • bjoernw 8y ago
    Having to support a legacy RoR monolith and being happy with it are 2 different things. How many of those companies are now supplementing the monolith with microservices in other stacks and are actively chopping up the monolith? I know at least 2 of those companies are doing just that.
    • fyfy18 8y ago
      Right, but that's just because those companies have grown to a certain point where it's hard to remain productive with a monolith. If you are starting to have scalability issues it makes sense to rewrite key hot code paths in a language faster than Ruby. That doesn't mean using Rails when they started out was the wrong choice though.
      • lmm 8y ago
        True as far as it goes, but does Rails offer a compelling advantage over higher-performance languages these days, even when starting out? Modern compiled languages have closed the expressiveness gap with Ruby a lot in the last decade or two. E.g. I find I'm just as productive in Scala as in Ruby - if anything more so - so I'd sooner work in Scala/Wicket from day 1 (for use cases where server-side rendering makes sense at all). (I still have the problem of services growing too large and needing splitting up - though the better isolation of a typed language means that point comes later than it would in Ruby - but it's still nice to be able to split out a module and keep the existing logic implementation rather than having to reimplement entirely)
• jmchuster 8y ago
  Rails is a great monolith framework, but a monolith will eventually reach its limits, due to size/complexity of the team or the task at hand. I think providing a better story around how to prepare for or handle that transition would definitely serve Rails a lot better in the long run. But, as long as the main target audience of Rails is Basecamp (a saas tool with 12 developers), I don't see it in the future.
  • dymk 8y ago
    The company I work at is transitioning from a rails monolith to many smaller rails micro services - it’s the best if both worlds.
    • joelbluminator 8y ago
      lol good luck with that. the main thing that makes this work is that the company trying micro services most likely grew large and now has a big engineering team. It also moves slower than it used to due the stage it's in. In that case any architecture would work really...you have a huge team of engineers that moves slowly and can troubleshoot whatever issues arise. yay to micro services!
    • batiste 8y ago
      I think the best is to have nicely designed modular monolith application. Sadly this something that Rails backwards conventions makes very hard to achieve.
• philwelch 8y ago
  As a former Rails developer, I figured it would be worth mentioning reasons I disagree. > Rails is not the fastest framework in the world… but I will argue that performance is the last thing you should worry about when you want to scale. > In my experience, NodeJS or projects written in other frameworks start to collapse architecturally after an alarmingly small amount of complexity is added to them. > More important than how many requests you can serve per second, is how your development team can maintain productivity over time. This is what we call dismissing the actual concern (performance) and instead going on an unrelated talking point (maintainability). And frankly, legacy Rails apps are not actually that great to live in. The Rails approach, which I can best describe a “precious”, contains a lot of abstractions that don’t actually abstract successfully, breaking down when faced with the real world in ways that require ugly fixes. > Where should we put files relating to our data model? /app/model! > Where should we put our config? /config > Our email code? /app/mailers > Decision made. Conversation over. Now let’s get back to our desks and write some code! If your backend consists merely of “data models” (with business logic and behavior bolted on in an inflexible Kingdom of Nouns sense), routes, mailers, jobs, and maybe response templates, Rails is opinionated enough. At least until your business logic is complex enough that you can’t just use active records as your sole method of abstraction. (Also, the active records themselves are poorly conceived, with obvious foot guns that persist to this day, though at least they’re better documented now. But more on that later.) I usually find that the architecture I get from Rails is neither necessary nor sufficient. Do I really need controller classes just to route endpoints to handler functions? No. Do I need an ORM? No. Do I need HTML templating? Also no. But I’m going to need more sophisticated design patterns than active records. Decoupling data access from business logic is one of the first and most important separations of concerns that exists, and Rails actively discourages that. Another crucial separation is between work that can be done locally (and hence unit tested) and behavior that entails a network dependency, which includes DB access! Rails really leads you down a bad path if you just naively follow the defaults, especially if your app is so monolithic that my mailers and asynchronous jobs are in the same artifact as my response handlers. (I’m not down on monoliths; Rails just does too much for a microservice and not enough for a monolith. Hell, Rails does too much for a macroservice let alone a microservice.) > Database management is hard. Managing database schemas and migrations is hard. > Rails provides you with a no-nonsense way of defining your database structures, as well as a full suite of CLI commands for migrating, resetting, seeding, dropping and creating databases across all environments. > Rails handles databases in a ubiquitous way. There are database drivers for almost every popular database, and schema management and Object Relational Mapping is handled the same way across all data stores. These are almost all false. * SQL isn’t hard to use for schema definitions or migrations. The Rails DSL for database schemas is marginally prettier than SQL, at the expense of adding an extra layer of indirection and making you learn yet another precious Ruby DSL when, if you’re worth your salt, you already understand SQL anyway. * Rails has an inbuilt assumption that your app connects to a single DB instance per environment. Cool, but why on earth would I connect to different RDBMS systems across environments (except maybe in-memory SQLite for “unit tests”, which is already an anti-pattern?). And given this constraint, what exactly does ActiveRecord get me? I can wake up one morning and just port my whole app to Postgres without changing a single line of code? That’s not bloody likely in the real world and we all know it. * Rails adds even more unnecessary brittleness to common DB access scenarios, which paradoxically means that the “simple” but broken Rails solution has to be augmented or replaced by ugly workarounds. For example, ActiveRecord validations are inherently prone to race conditions that make them both unnecessary and insufficient. From the current Rails guide: > 2.11 uniqueness > This helper validates that the attribute's value is unique right before the object gets saved. It does not create a uniqueness constraint in the database, so it may happen that two different database connections create two records with the same value for a column that you intend to be unique. To avoid that, you must create a unique index on that column in your database. OK, so the uniqueness validation doesn’t guarantee uniqueness if there are concurrent connections to my DB. Also, every real world Rails app is deployed so it runs as multiple processes. So it never guarantees uniqueness. Instead, I create a unique index, and ActiveRecord...sometimes throws an exception that’s distinct to the RDBMS but not distinct to the failure mode, so I still have to string match against my DB’s particular phrasing of “uniqueness constraint got violated” and handle that as an unnecessarily generic Ruby exception. Which is exactly the same amount of work that would exist if uniqueness validation just wasn’t a Rails feature to begin with. A thoughtful design would realize: at least some validation has to happen in the DB and not in the application code, and it will anyway, so let’s make patterns for living with that. Why don’t my models automatically detect my unique indexes and throw a “not unique” Rails exception when the DB complains? Why does it instead insist on doing a shitty job of trying to guarantee uniqueness itself? It gets worse and worse when you run into scenarios like, “I want to run SQL queries that don’t cleanly map onto ActiveRecord without monkey patching every damned column of the result set onto individual instances of a loosely related ActiveRecord class”. > Rails (and Ruby) Have a Deep Culture of Code Quality Hah. I think I’ve already debunked that one. Rails has a deep culture of precious, brittle abstractions that make easy things easier and hard things harder if not impossible. > Asset Management If your app is monolithic enough that you’re managing your assets in your Rails app, it’s probably big enough that you’ve run into the problems with Rails I’ve mentioned earlier. If it isn’t that big, odds are you’re in a microservice environment where your assets are most likely deployed in a highly decoupled way—perhaps from a separate repo owned by your front end devs. Maybe the asset pipeline is a perfectly reasonable way of managing a full-stack monorepo, and you can still deploy your Rails assets to a CDN and make it work. But that implies that your web app is a Rails monolith, and Rails monoliths need a lot of thoughtful design decisions above and beyond “put models in app/models”. > RSpec is quite simply the gold standard for behaviour driven development, and almost single-handedly created the BDD movement that is still raging in the industry today nearly a decade later. RSpec is nothing special. I actually find Spock a lot more featureful and self-documenting. > A Smorgasbord of Plugins The first plugin on the list he links to is activerecord-import, which only exists to work around a problem Rails itself creates in the first place. The rest are either generic things that every other language has and other instances of workarounds for Rails limitations. Rails (and Ruby in general) isn’t unique in terms of library support. Python has greater breadth, JVM has greater breadth, heck I bet you can still find stuff on CPAN that never made it into a RubyGem. > Heroku Works with everything; not a selling point for Rails. > ActiveAdmin Admittedly, something like this is one of the few redeeming qualities of an ORM, which is why Django always had this built in. Why not Rails? The article keeps saying that Rails is “batteries included”. “Your app behaves in a reasonable way without ugly DB-specific exception handling code if you run more than one parallel instance of it” didn’t count as batteries either, though. But I guess HTML templates did. Rails’ design choices would be logical if you treat Rails as a framework for prototyping, but isn’t that when you need admin screens the most? > Rails is battle-hardened and industry-proven. There is a long list of (very) successful businesses building their product with Rails. Starting with Twitter, which migrated away from Rails onto a JVM backend as soon as they grew up. If you want to go with “battle-hardened and industry-proven”, use the Spring ecosystem. You can even deploy it on Heroku.
• nitrogen 8y ago
  Popularity of a framework or paradigm seems largely driven by marketing and memes. With "Rails doesn't scale" as the almost-rhyme that sticks in people's minds, an entire tech cycle gets wasted on things that take significantly more developer effort. I've seen a Rails app handle Cyber Monday traffic for an ecommerce company just fine, and I've seen JVM-based apps crumple under a fraction of the load. Rails scales (see, that actually rhymes, so it must be true), Ruby is a really nice language to work in, and those things will remain true regardless of whatever frameworks exist or whatever earworm sayings stick in the minds of the next generation of developers.
  • rapsey 8y ago
    > Popularity of a framework or paradigm seems largely driven by marketing and memes. I think a whole lot of developers choose technologies because they are popular at the moment for two reasons: they lack the technical knowledge and experience or maybe just confidence and/or they avoid some responsibility this way (since everyone is doing it). Of course this is most acute in web development because it attracts younger developers. Also the words performance and scalability attracts developers like moth to a flame.
    • _hardwaregeek 8y ago
      Young developers (as one myself), tend to be overly focused on what makes them attractive as a developer. Kinda like an overly insecure teenager. So they pounce on any framework or tech that makes them desirable to an employer. Rails isn't hot, so it won't get them a job so they won't learn it.
      • Supernaut 8y ago
        That's flat out wrong. As a Rails developer, I have a weekly stream of recruiters trying to get my attention.
        • aedron 8y ago
          It's about perception. But the trend is what it is: https://trends.google.com/trends/explore?date=all&geo=US&q=ruby%20on%20rails https://trends.google.com/trends/explore?date=all&geo=US&q=r...
• anm89 8y ago
  I've never felt as dialed in and as productive in any other tool or framework as I have in Rails. It takes all the unimportant BS, places it off to the side, allows me to focus on what I want to build, and gives me the ability to dig in deeper on the details when I want/need to. The amount of projects I have seen go bad because someone did a bad job of solving some problem that would have been a non issue in Rails is staggering.
• dmitriid 8y ago
  In the past 14 years we somehow lost the ability to do “Your blog in 15 minutes” videos for any framework [1]. I wonder if that “do X in under 20 minutes” can be replicated in modern-day Rails. [1] https://mobile.twitter.com/dhh/status/492706473936314369?lang=en https://mobile.twitter.com/dhh/status/492706473936314369?lan...
• etaioinshrdlu 8y ago
  Does any free web framework have something more thorough than rails' Active Admin? Django admin seems pretty unfinished by comparison. Haven't seen anything actually better.
  • peteforde 8y ago
    I've tried to work with ActiveAdmin on several consecutive projects, and I do not understand the draw. It's a fussy DSL that requires you work with your data in a way that feels very un-Rails. You basically have to approach building out your UX from the perspective of what the tool is designed to do. This seems a shame, in the context of Rails - a framework that's actually pretty great at getting out of the way in the right places. Of course, there are people in this thread who prefer writing Rack endpoints over the thorny complexity of Sinatra. You really can't make everyone happy all of the time.
    • jypepin 8y ago
      I hate ActiveAdmin because of exactly what you say, but tbh it is indeed a very powerful tool and still allows you to very quickly spin up admin pages (to a certain limit, but this limit is pretty high). I yet have to find something similar.
      • peteforde 8y ago
        While it is not a 1:1 replacement for the end-goal of a drop-in admin, I've had some success with datagrid: https://github.com/bogdan/datagrid https://github.com/bogdan/datagrid A good way to think of it is as a drop-in for the index view of many admin modules, which is the filtering, sorting and pagination of tabular data. This is the specific pain I want to be abstracted away... not the entirely conceptual UX of my admin in general.
      • bshimmin 8y ago
        Have you tried RailsAdmin? It does a great job of getting you over the line with the basics (though configuring it can be fussy and customising it is pretty miserable).
• bjoernw 8y ago
  Build your app using whatever you're most comfortable with because in the end an existing product is better than no product. Will you enjoy spending an extra hour per day working with this framework over another? That's an hour more of progress. Personally I think Spring Boot with Kotlin is a way better choice today for monoliths that transition well to micro services. But if you're already deep in the RoR world just go with that. Running into stack or framework-related scaling problems is an honor and a huge accomplishment. Those are good problems and there are many ways to solve them, which will be extremely motivating at that point because people are actually using your thing.
  • cageface 8y ago
    Personally I think Spring Boot with Kotlin is a way better choice today for monoliths that transition well to micro services. What do you use for an ORM in this case? Is there anything comparable to ActiveAdmin?
    • bjoernw 8y ago
      Java has JPA (Java Persistence API) which is an abstraction layer over various ORMs. However, most people use Hibernate. Hibernate is nice because it also gets out of the way when you need it to, like when you're inserting or selecting a massive amount of data. It also supports the Stream API now, which is super convenient. I've found Admin interfaces on the same server to turn into liabilities and infosec in bigger orgs usually has strict rules around segregating admin access off into its own subnet with restricted access only to internal traffic. That said, for simple monololiths I use Jhipster, which auto generates Admin pages for you similar to ActiveAdmin.
    • jillesvangurp 8y ago
      I recommend to not use an ORM. Really, with a modern language, an ORM is mostly redundant. If on Spring boot, simply use JDBCTemplate and TransactionTemplate to deal with raw SQL queries and transactionality. Get rid of all the annotation magic around this. Then you need a bare minimum of mapping code. Mostly this boils down to a single line of code to call the relevant constructors while you extract columns from your rows in a type-safe way. Kotlin makes this stupidly easy. I'd argue this type of code is actually easier to maintain than misc annotation cruft all over your codebase. One way or another you end up expressing in some place that column foo is of type Int and goes into some property of a class MyLovelyFoo with a foo field. So MyLovelyFoo(foo=row.getInt("foo")) kind of does that in a really compact way and there's not a lot more to it. Of course Kotlin having default arguments, sane property handling, immutable data classes, etc. helps a lot. Mostly ORM made sense when people were doing JavaBeans on Java. The problem with many Java persistance frameworks is the amount of magic that happens that leads to hard to understand bugs, sub optimal joins, and other stuff that just isn't worth having. A side effect of using an ORM is also overengineered table structures because people are pretending they are doing OO and thus end up with way to many tables and columns, fragile and more frequent migrations, and a lot of silly joins. This magnifies all of the above problems. If you know what you are doing, you can actually fix this of course and do it properly even while using an ORM like hibernate. At this point you lose most of the advantages of using an ORM because now you are knee deep into framework complexity and trying to coerce it to do the right thing while spending disproportionate amounts of time inspecting and guiding all the magic it does for you. I've been parachuted in more than a few hibernate projects gone bad. The fix is always pruning back all the copy paste annotation magic propagated by juniors, vastly cutting down on the number of model classes, use of inheritance and the silly hacks that come with that, fixing the transactionality, etc.
• clessg 8y ago
  This article reads to me as more of a "Rails vs Node.js" piece, which seems almost too easy—I would be interested in a more thorough comparison of Rails versus other frameworks. Here I will attempt a comparison, limited in length as this isn't a blog. :) My personal favorite up-and-coming framework (and admittedly, my favorite web framework overall) is Phoenix[1], written in Elixir[2], a functional programming language with a focus on concurrency, performance, and developer productivity. In my opinion, Phoenix has almost all of the best parts of Rails without nearly as many of the warts, and adds a plethora of compelling features of its own. Despite what the author argues, I believe that raw performance and developer performance are equally important, and even intertwined. Why? A slow application results in lost customers and revenue, a fact that is well-documented. A default Rails application is going to be quite slow, requiring intervention. Of course, most larger Rails apps are not necessarily slow in practice—in my experience, this is largely because the code is littered with brittle caching logic and hacks requiring many human-hours to maintain and debug when things go wrong. Thankfully, Ruby is seeing improvement in the performance realm. Phoenix achieves massive scalability, raw performance, and developer performance, without requiring significant trade-offs and caching logic littered all over your code. It is an absolute joy to write Elixir. Phoenix is famous for consistently achieving microsecond response times without caching, and being capable of holding millions of websocket connections[3]. Granted, Elixir as a language is not computationally fast, but the typical web app is not performing expensive computations, but instead juggling IO, which Elixir handles extremely well. CPU-intensive tasks can be written in a different language if need be. Importantly, Phoenix is not your application—Phoenix's job is to provide a web interface into your broader Elixir application. Thus, Phoenix is more of a toolkit than a framework, and yet it provides everything you would expect in any web framework, with strong conventions based on the solid foundation of Elixir. You could migrate to a different framework with relative ease. You can easily integrate different interfaces into your application, such as a CLI frontend. This is in contrast to Rails, where Rails is your application unless you actively fight against the framework. Ruby and Rails are notoriously bad at handling concurrency and real-time features using e.g. websockets. This becomes progressively painful as using all CPU cores becomes increasingly necessary, and as websockets continue their ascension on the web & mobile. In contrast, concurrency and soft real-time communication are Elixir & Phoenix's bread-and-butter. As I mentioned, Phoenix brings compelling features of its own. The most interesting to me is the upcoming Phoenix Live View[4], which will allow developers to write rich, interactive, real-time applications without being forced to wade into JavaScript hell. Read the linked article for more information. I could be wrong, but I don't see something like Live View making its way into Rails, especially without significant downsides. One area where Ruby & Rails trounce Elixir & Phoenix is maturity. Although they have gained significant traction, Elixir & Phoenix are still comparatively immature. Thus, you'll have a harder time hiring, finding third-party libraries, and answers to questions. That said, Elixir is based on Erlang, which is extensively battle-tested and has a huge assortment of libraries available. (You can very easily and naturally use Erlang code in Elixir.) I could go on, but I think this has gotten long enough. [1] https://phoenixframework.org https://phoenixframework.org [2] https://elixir-lang.org/ https://elixir-lang.org/ [3] https://phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://phoenixframework.org/blog/the-road-to-2-million-webs... [4] https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera... (Repo: https://github.com/phoenixframework/phoenix_live_view https://github.com/phoenixframework/phoenix_live_view)
• mikekchar 8y ago
  I work on a Rails system. It's fine. Just like everything else is fine. I have problems, but I have problems with everything else too (sometimes different problems, but not always...). I think my main complaint about Rails is that it's pretty heavy weight. Lately we did a Sinatra app because we didn't really need anything that rails was giving us. Fairly quickly I realised that I didn't need anything that Sinatra was giving us either. Rack was fine. I think especially after your app gets to be a certain size, you are either writing your own framework, or fighting with the framework you chose at the beginning. It's just the nature of the beast. From there it's more of a training issue than anything else. You can hire "Rails developers" (or whatever developers), but you can't hire people who are specifically trained in a system you've built. Depending on the kinds of developers you hire, this may or may not be a problem. Personally, I like writing code and I like small, light systems that are easy to move around in. Usually that means trying to avoid large frameworks. However, not everybody I've worked with is comfortable with that experience, so normally we pick things people have worked with before. Either way it's not a big deal in the end.
  • _hardwaregeek 8y ago
    I've found it kinda weird how Rack isn't emphasized in the Rails tutorials. It's really one of the crown jewels (heh) of the Ruby ecosystem. I suppose Rails wants to abstract away all the nitty gritty request based stuff but it's really powerful if you know how to use it.
    • Kalium 8y ago
      You're absolutely right. Rack is incredibly powerful! Might it be possible that there is a subtle catch in "if you know how to use it"? The more powerful a tool is, the more potent a temptation it can present to those who might understand what Rack can do but who could perhaps also stand to possess a greater degree of wisdom in considering what the right tool is. A small number of very experienced, wise, and deeply skilled developers can be trusted to use their tools well - yet this may not describe all possible scenarios. Again, you're completely right. Rack is vastly powerful and immensely useful. Yet perhaps there might be good reasons for not quickly introducing people to all the glory and power of Rack.
• derekdahmer 8y ago
  Was anyone saying Rails wasn't relevant?
  • ck3g 8y ago
    https://www.google.com/search?q=rails+is+dead https://www.google.com/search?q=rails+is+dead
  • freehunter 8y ago
    All the people trying to sell you something else. I heard someone on HN call it "blog driven design". Tech blogs need something to write about, Udemy teachers need something new to sell, startups need some way to differentiate themselves from their competition, so they start talking about how awesome [insert new tech stack here] is. The cycle continues and in 6 months, [new tech stack] is old news and you can't build the modern web with it and it doesn't scale, so here's [even newer tech stack]. Meanwhile Ruby, PHP, Python, and Java are still powering all the sites that are telling you those technologies don't work anymore, and powering the site that takes your money when you buy another Udemy class to learn [even newer tech stack].
• mping 8y ago
  Rails is fine but didn't age well, specially the lack of strong functional programming support. Other nag is that it's hard to not do things the rails way - this monoculture reinforces the appearance that is fine because people looking to do something different just don't use rails. And when you "scale" rails is not really rails that scales as much as it is the architecture - it could be applied to other frameworks. Still if you are familiar you can write stuff really quickly.
  • mping 8y ago
    Feel free to downvote, but please present counterarguments so everyone can learn.
    • pankajdoharey 8y ago
      Tons of Rails FanBoi's here! I use to be one of them.
• lurker213 8y ago
  In my opinion, Rails / Ruby is nearly unbeatable in terms of productivity when you add trailblazer to the mix.
  • peteforde 8y ago
    I love that Rails is flexible enough for me to both agree completely AND be thrilled to not use Trailblazer, because I prefer interactor, state_machines, rolify, pundit and draper. Considering the talk about how heavy Rails is in this thread, I feel like I have all of the options in terms of customization and in a very mature ecosystem that still values developer happiness.
• hombre_fatal 8y ago
  I don't know how to quantify how relevant Rails is today, but I do think it's interesting to explore why Rails isn't as popular as it once was. I remember just eight years ago, Rails was on the HN frontpage almost daily. Some ideas: I think the most critical trend has been the dissemination of the Ruby ecosystem's most popular and best ideas into every other ecosystem, which I would summarize as a culmination/caricature of a movement that was already in motion thanks to other ecosystems like Perl and Python. Rails was such a massive hit because it was a stark contrast to the tropes of complexity that came before it like endless XML configuration and IIS. I think Rails was a symbol of this whole renaissance, not single-handedly, but because it coincided so well with a critical-mass milestone in our industry and hit so hard with this cult of "fun and easy". And these days were back when https://rack.github.io/ https://rack.github.io/ came out and Zed Shaw wrote Mongrel which was Twitter's first web server and one of Ryan Dahl's inspirations for Node.js. These represented identity-level changes in tech and its crescendo into the mainstream, not ideas that would merely spark and die in the Ruby ecosystem, so it's no surprise that Rails cannot command the same gravity over time. Another trend has been the popularity explosion of smaller and simpler solutions over monolithic frameworks. For example, trending away from things like GWT and ExtJS and Ember and Meteor. Trending towards things like React and Express. No Rails analogue caught on in Node or Go and nobody cares. There's also the explosion of Javascript which became such a viable alternative to other dynamically-typed languages (particularly Ruby in this context) that "why should I pick Ruby?" became a harder and harder question for beginners to answer. Finally, there's the explosion of choice. One back-end application framework just can't dominate HN anymore like it could in 2007. I think React is the modern repeat of Rails in the sense that it popularized a new paradigm of building applications. And I think React will go the way of Rails in the sense that its ideas will become so ubiquitous that React itself won't stand out anymore, like when we see UIKit2 adopt these sorts of unidirectional data flow and FP ideas as a core first-class abstraction. And we'll get so used to it that we'll wonder "so what was the big deal about React again?" Rails is certainly still amazing software and is clearly still improving. I generated a fresh Rails project half a decade ago after a long hiatus and was blown away when the error page in the browser had an embedded Pry REPL initialized at the error's stack frame iirc. That's some wtf-level polish. And I can only imagine how much better Rails has become since.
  • 8y ago
• _hardwaregeek 8y ago
  I think Rails could go far if DHH et al keep their ears to the ground about the state of web development and adapt accordingly. It still has some killer features that I've yet to see replicated with as high a level of ergonomics and elegance. For instance, GraphQL in Rails is smooth like butter. You define the types and the fields just resolve like magic based on your models. I wrote an API a while back and it was just stunning at how easy it was to write. Only issue? I wasn't using Rails. I was using all of the niceties of Rails like autoloading, ActiveSupport, ActiveRecord, associations, etc., without the actual, framework of MVC. If Rails could really invest in the API mode and get it working with say, GraphQL, I could see it working amazingly. Plus, you could take the DSL idea and expand it to GraphQL. GraphQL top level queries and mutations take similar forms (get all of resource, get one of resource, etc). You could easily abstract that into a DSL if you'd like. Authorization and authentication in GraphQL isn't amazing either. I'd really like to see someone making that simple and on by default. There's also some generic Ruby tooling things that'd be nice. Types, of course. The standard way would be a mypy/TypeScript esque annotations with erasure at runtime, but I actually feel like Ruby could do something really neat and really true to the language by developing runtime dependent type checking. Autoformatting would be nice (any thoughts on rufo[0]?) [0] https://github.com/ruby-formatter/rufo https://github.com/ruby-formatter/rufo
• smartstakestime 8y ago
  rails did the opposite of php , and I think its harder for it to pivot in its community. -php started with no framework , everyone just did super minimal strait to the db and template query stuff, very unorganized but you knew the underlying apis and tech because you were right up against them -rails started very ridged. separating programmers from the underlying apis and tech Now php devs had to create the ecosystem of organization but the experience of working with the the server and db was still useful particularly when doing something unique or when one needed special performance Ruby devs needed to learn to become leaner how to break away from the framework when performance was needed. This was completely new and I feel the community did not support scripting away from ruby. Mostly the community was focused around ease also at the same time PHP was improving the language. I dont think Ruby had the same improvement and some of the stuff I have heard about ruby makes me cringe. http://rubylearning.com/blog/2010/09/27/almost-everything-is-an-object-and-everything-is-almost-an-object/ http://rubylearning.com/blog/2010/09/27/almost-everything-is...
  • pjmlp 8y ago
    Also PHP benefited from Facebook's work and the commmunity actually cared about performance. Zend exists since the early days, now there there is the JIT migration going on. On the other hand JRuby doesn't seem to be having that much adoption, and the new pseudo-JIT via C compilation doesn't seem to be the best way to improve it.
• miki123211 8y ago
  how relevant is Rails in the age of SPAs? How well does it work with making JSON APIs and hosting static React apps?
  • manch23 8y ago
    Quite well. From Rails 5 there’s an API only init flag which removes the view layer and then you can just return JSON from controllers. Chuck nginx in front to proxy backend requests and serve your static front end bundle and you’re golden.
• sklivvz1971 8y ago
  > I will argue that performance is the last thing you should worry about when you want to scale. Oh boy, this is in one sentence almost everything that is wrong with Rails...
• fareesh 8y ago
  I feel like Ruby/Rails needs to introduce some way of eliminating bloat through some kind of optimization steps at the time of deployment.
• pankajdoharey 8y ago
  Sure its relevant in 2019, which is why someone had to write "Why it is relevant", the last time i remember i read something similar about Spring Framework and why it is still relevant https://www.theserverside.com/tutorial/A-Spring-summary-The-Spring-framework-is-still-relevant https://www.theserverside.com/tutorial/A-Spring-summary-The-...
• forty 8y ago
  I have this joke that I noticed ruby/rails developers seems to use a lot of their extra time (which they get with the high productivity you seem to get with rail) talking about how great ruby and rails are and how efficient they are with it ^^
  • ck3g 8y ago
    Take a look at how many non-rails developers spend their time proving that Ruby and Rails are dead.
    • mottiden 8y ago
      So true
    • freehunter 8y ago
      But that's not wasted time, they're just waiting for their async promises to finally return so the page actually renders.
• devin 8y ago
  Big no thanks on citing the wisdom of one “uncle bob”, but otherwise, yeah, the framework is relevant if not dominant, and that’s just fine. Live long and prosper.
• l33cher 8y ago
  Why are people saying stupid things like this? I'm doing rails 24/7 for the past 5 years in MANY different projects and I can say its the BEST and very relevant in 2019. I have to deal with other platforms written in different languages/frameworks like php/laravel and I can only pity developers that have to do that by choice.
  • Kiro 8y ago
    I very much prefer Laravel/PHP to Rails/Ruby and I'm mostly working with Rails nowadays.
    • move-on-by 8y ago
      PHP even has static types now. I think Ruby is missing out by not supporting static types. Python has it as well, and there are a couple different type systems for JavaScript- TypeScript being the most popular. I’m not saying all languages and projects need static types- but there are several great examples of scripting languages that have successfully added optional support for static types. After working on several large projects with Ruby, type-less Python, and JavaScript - I have a major appreciation for static types. I’m also a fan of compilers. Anyways, that’s my two cents on Ruby these days. I think it’s a cool language and has a neat ecosystem- but I think it could get a huge boost from static types.
• chvid 8y ago
  I think for what it is - for its paradigm if you will - ruby on rails is an extremely well-designed platform. But I think things have moved on and what was back then seen as the right way (or just fresh new way) is now seen differently. For example - is it really "better" to say 7.even? rather than isEven(7)? (Strict OO vs multi-paradigm/functional programming). Or is the article's example of a data model migration really better than a series of alter table sql statements? (Putting OO on top of a relation database using an ORM.) And why not go for a pure SPA rather than an AJAX-sprinkled compromise between a traditional server-side rendered html app and a SPA?
  • chvid 8y ago
    And PS: Everything is relevant today if you are stuck with it. The question is if you would start a new project on it if you didn't already had a lot invested in it?
    • rimliu 8y ago
      I am going to do exactly that. Why? Because of all alternatives I personally could use: PHP/Symfony, RoR or Node.js Ruby is the most elegant and pleasant language and Rails is best framework. Other my think differently, of course.
  • rimliu 8y ago
    > For example - is it really "better" to say 7.even? rather > than isEven(7)? Yes. And that has nothing to do with rails, it's just the Ruby way. > Or is the article's example of a data model migration > really better than a series of alter table sql statements? Yes. Migrations provide much more than just altering DB schema. > And why not go for a pure SPA rather than an > AJAX-sprinkled compromise I would love more people to ask themselves "do I really need SPA?" actually.
    • freehunter 8y ago
      >I would love more people to ask themselves "do I really need SPA?" actually. And I'd love if people asked "is anyone actually doing SPA" beyond what TurboLinks + a Vue frontend on a Rails backend would get you.
• pankajdoharey 8y ago
  Mostly an opinion piece, A few points to Observe : * According to the author NodeJS fails architecturally when small amounts of complexity is added to it. => Same applies to Rails aswell, anything beside a crud app and you start wondering which code goes where. * Rails is Opinionated... => Great if it were 2006, In 2019 rest apis are a norm, and more Nodejs apps get enabled everyday have the same feature. Infact serverless apps to have the same features. In my view firebase or similar apps is the right way to go when you are booting your apps, and then scale or rewrite when you grow. * Rails has a deep culture of code quality. => So does smalltalk, lisp and clojure. Infact ruby community has borrowed many ideas from both Smalltalk and Java communities. * RSpec .. => Rspec isnt the original invention its based on JMock. * Heroku, ActiveAdmin, Industry Proven ... => Straw-man arguments. I am as opinionated as rails and in my opinion Rails isnt relevant in 2019, they are running out of ideas, the latest "innovation" in rails is an inbuilt Rich Text editor called Trix available as ActionText. Yes you read it correctly a rich text editor is the latest relevant innovation in a web framework. I think for most startups a great way would be to start with a serverless setup like Lambda or Firebase .... and just write the relevant front end bits in Javascript, Coffeescript, Clojurescript or Elm. When the app outgrows such services just write the enough parts of backend service as you need it.
  • Retra 8y ago
    Are you really choosing web frameworks based on how 'innovative' they are?
    • pankajdoharey 8y ago
      Innovation implies improvement! My primary metric is ease of use and long term scalability, but so is constant improvement and upgradation in features. A rich text editor isnt improvement, its bloatware.
• danmaz74 8y ago
  Meta: I read this on the tube, and wanted to write a comment when in the office. Came here, and it's well out of the first page, even if there were many additional upvotes. I really wonder who hates rails so much to flag an article about it, and why.
• gumcreme 8y ago
  While reading this thread, it feels like a flashback from 2009 and now, I remember what was my biggest gripe with Rails (next to all the bad parts mentioned here in this thread): It is the culture. I really find the Rails culture odd or tbh, I utterly dislike it. I mean if met a Go guy, he tells me all good with Go, it gets the job done but it has its warts, the same with Rust, node, React and so on. People of other stacks like their stack but it's not about life and death. Only Rails guys have these issues and would start a flamewar right on the street and try to evangelize, yell at me why Rails is (always) the way to go and imply that I am not just wrong but also an incompetent developer. There were so dogmatic and when reading such posts in 2019, they are still this way. Edit: as expected I got downvoted and this is what I mean, they take this too serious, Rails is their religion, Rails locked them in. Downvoting doesn't bring your Rails back.
  • freehunter 8y ago
    Maybe this is because everyone has spent the last 10 years telling them that Rails is dead, they're stuck to a dead technology, and Go no wait Dart no wait Rust no wait Javascript no wait Node no wait React no wait Phoenix is better.
    • yebyen 8y ago
      Yes. Literally ten minutes before Amazon announced their Lambda support for Ruby at this year's re:Invent conference, one of our lead architects who was watching the livestream sent out (and I quote) > I guess if you want to know which languages will dominate the industry going forward, just look at what Lambda supports. > AWS Lambda supports code written in Node.js (JavaScript), Python, Java (Java 8 compatible), and C# (.NET Core) and Go. Tongue firmly inserted in cheek, aimed directly at our large cohort of Ruby developers, as if to imply that we're mostly irrelevant to the future of the industry, and it shows in Amazon's lack of support for our ecosystems. Then immediately following that message, Amazon announced they have added support for Ruby... and PHP, and Cobol. And suddenly it's "I guess AWS is out of the choosing business." I'm still salty about this, forgive me please. But the refrain is tiresome, and it continues even today.
• gashaw 8y ago
  Ruby is great, Rails is good enough. The main issue with Rails (it's the same with other frameworks) is that it discourages from doing proper design. The only design decision you make is where to put a piece of code, which is ridiculous ("Fat models, skinny controllers" is a bad design heuristic.) Following Rails conventions works for small (simple) applications, but over time you arrive at a point where no one understands the whole thing. At this point someone suggests moving to microservices, and all hell breaks loose.
  • richjdsmith 8y ago
    Adding a services directory with logic moved out from my models into POROs helped a lot for taming the mess.
    • notafrog 8y ago
      Yep. That has been my experience with Django as well.
    • yebyen 8y ago
      Can you share a link about what you mean by this? I went searching but came up pretty empty ... do you literally mean adding an "app/services" directory, is that all? Where you put classes related to external dependencies that aren't ActiveRecord?
      • nitrogen 8y ago
        I don't agree with the pattern discussed here and actually like smart models (I want to tell my model "do the thing", not write and babysit a bureaucratic coordinator service. But, since you asked, it's common in other frameworks like Spring to have a "service" layer that sits between your controller and model layers. The service layer has the logic, and the models are just storage.
        • gashaw 8y ago
          Don't you mind having 5000+ LOC model? Methods being redefined because the class is huge and the developer didn't notice the existing method?
• mark_l_watson 8y ago
  Off topic, sorry, but reading this article made me realize how much I miss using the Ruby language. Except for maintaining a legacy web app that uses Sinatra (and takes close to zero time to maintain/devops) work and customer preferences have driven me to other languages. Ruby really is a pleasure to develop in.
• shay_ker 8y ago
  Having worked w/ apps large & small on Django, Spring boot, and Rails, I'd say that Rails is the easiest framework to be productive in, especially to people new to it. This includes junior devs as well as senior devs - it's just easy to pick up. And it gets easier to use over time to rip out all the cruft, especially with things like Rails API. Like any language/framework, it has its warts and its weirdness. There are times when it can be very frustrating to deal with it all. But I've felt that feeling working across multiple paradigms, and I'm convinced it's just a reality of software development. If you're deep into microservices, Rails can be a tough choice, I'll admit. It really depends on your use case. A small-medium sized startup can get a lot done with just a Rails app if your workload is primarily IO based.
• Smithalicious 8y ago
  Heh, from the rise of Rails as the hot new thing to blog posts trying to justify its continued existence, it all went pretty fast.
  • richjdsmith 8y ago
    Just curious, do you think hell.js with its node_modules filled with (sometimes) thousands of unmaintained or non-versioned dependencies will age any slower?
• ausjke 8y ago
  These days for new projects you may just use flask/django depending on how complicated your application is. Python is top 3 language and its ecosystem is getting better daily, meanwhile it leaves many other scripting languages in the dust including ruby. Otherwise you can use a java framework or (maybe) node.js? Node.js no longer has a good framework anymore, express is "out of date", it still can't do async/await and Express 5.0 is not actively developed. The MEAN stack is pretty much gone. I wish there is something in the javascript/backend/nodejs field that shines like Django/Flask as a framework.
• Arubis 8y ago
  Rails is still fine and appropriately boring (in a good way). Its issues are well known by now, and it’s pleasant to work with for backend CRUD work. What TFA really appears to be writing about is that doing backend work in nodejs is a subpar experience. I have little trouble believing that. A more interesting comparison would be to Django (my gut feeling is that Rails compares favorably here), Phoenix (a different set of choices about how opinionated to be on the data model, different base language with some significant and relevant advantages), and other frameworks that one would deliberately learn to replace Rails.
• wrestlerman 8y ago
  I thought same in 2018 when I didn't use Phoenix. But after trying out Elixir and Phoenix, damn... Elixir and Phoenix give you so much, nice websockets, concurrency, fucking easy to read code with great docs. I was a bit sceptical about the praise Elixir was getting, but after working with it for a while... I started noticing a lot of stuff that is lacking or abused in Ruby and Rails.
  • cutler 8y ago
    Elixir looks great until you look at modulecounts.com where Erlang/Elixir libs total a mere 7900. Compared with Ruby's 150900 gems that's a lot more code you're going to have to write surely?
    • wrestlerman 8y ago
      That's a very valid concern. My personal opinion: Yes, the package system is pretty small. That's why it depends what kind of project you are gonna write and how much time you have. Ruby has a lot of gems, but many of them are buggy and deprecated... Proof: https://github.com/rubysherpas/paranoia https://github.com/rubysherpas/paranoia I think that Elixir is gonna catch up. If you write a project where you need to use a lot of external libraries probably Ruby is better. If you don't need to rely on the external dependencies too much and you want to/have to write your own code(libs), imo, Elixir is a better option. It also depends on a project, lots of external api calls, webhooks, real time chatrooms, etc. I think Elixir is gonna be a better option. One thing more, because Elixir's code is much easier to deal with, it's easier to fork and fix deprecated lib than in Ruby(Rails). It's just my opinion.
      • cutler 8y ago
        Another concern with Elixir is that, like Node, it is optimised for IO, not computation. Take chatbots, for which Elixir is supposed to be ideal - what if my chatbot connects to a computation-intensive AI/NLP model. I'm going to need something else for that, surely? Elixir and Node are good for the orchestration layer but lack the all-round capabilities of, say, the JVM platform.
• sidcool 8y ago
  I think Rails is fine. It gets you up and running super fast. GitHub, Heroku, Basecamp etc. run on Rails and they are doing great. It's popular because it's relatively 'low-code' than other language/frameworks. Ruby is quite simple to get started with and Rails' convention over configuration philosophy gives a lot out of the box. Having said this, it's not all rosy. Rails does buckle under scale, hence LinkedIn and Twitter had to gradually migrate to Scala(I think) based platforms. This is more a problem with Ruby than with Rails. A huge Ruby backend application becomes quite difficult to reason without a good type system. It's not impossible, just more difficult than say Scala or Haskell or Rust, that have very strong static types. I am sure I am missing a lot in this comment.
  • KurtMueller 8y ago
    > A huge Ruby backend application becomes quite difficult to reason without a good type system. It's not impossible, just more difficult than say Scala or Haskell or Rust, that have very strong static types. It also becomes difficult to refactor if you don't have a very good test suite. From personal experience, refactoring an Elm application is way way easier and more error-free than refactoring a Rails app.
• mmartinson 8y ago
  I worked on a couple of production apps in Rails at the start of my career. It was the first way I learned to make web applications. Rails works as advertised and is great at what it does, but I think ultimately the conventions-obsessed nature of the community, that is often so helpful, has settled on some patterns that make the Rails approach more bother than it's worth with other good options out there. Often touted for being able to scale business logic and developer productivity at the expense of runtime performance, I see some serious issues with the claimed strengths. - The powerful active record pattern and accompanying library makes it easy to pile on coupling between business logic and database access code. - Ruby doesn't give you a straightforward way to protect against mutation, which leads to some real debugging nightmares at the worst of times. - Rails conventions openly disregard low hanging fruit best practices of OOP like the SRP, and make it difficult to design code that follow these practices without straying outside the well trodden conventions (hi again Active Record). - Rails provides configuration-like interfaces that don't feel like you're calling Ruby code. They are convenient, but offload a big cognitive burden in the name of convenience whenever you need to problem solved something that's not a garden-variety bug. Ultimately I made the time investment to try some other approaches and have been finding that it's possible to get much of the productivity of Rails at the (arguably worthwhile) cost of a bit of extra typing up front. If you know Ruby well already and have some business goals with some urgency behind them, certainly a great move. If you are earlier career and looking to invest in a productive skills set, you may be better served to consider a few different options.
• nathan_long 8y ago
  I spent a couple of years dreaming of getting paid to work in Ruby and Rails and about 7 years doing so. There are many things I loved about Ruby, and Rails brought a ton of good ideas to web development, as this post describes (though I don't agree with all the highlights). I've since moved to using Elixir and Phoenix, and then even more recently, done some consulting on a Rails project. So the contrasts are on my mind. My perspective now is that the advantages Ruby/Rails have over Elixir/Phoenix (community size and number of libraries) are circumstantial, and the advantages Elixir/Phoenix have (fault tolerance, concurrency, speed, less requirement for external tools) are inherent in the VM. Yes, speed of development and maintainability matter. And yes, you can write good or bad code in any language. But if Rails taught us anything, it's that defaults matter. And the default pattern in Rails is to use ActiveRecord and rely heavily on model callbacks, which can get confusing quickly. ActiveRecord also has no way to turn off lazy loading as far I know, and chasing down N+1 queries to improve performance is something I spent far too many hours doing. My productivity also wasn't helped by the long test run times of Rails applications, or by wasting time trying to optimize view rendering on a heavily-used page. All of those are either non-issues for me now or at least greatly reduced - Phoenix view rendering is crazy fast, N+1 queries aren't possible with Ecto and it doesn't have callbacks, Elixir test suites are highly concurrent and generally fast (though driving a headless browser is still rather slow). Performance and concurrency do impact productivity. And I find that "functions in modules" is a great way to structure code and makes it easy to refactor. So does being able to run the entire test suite faster than I can get distracted. The best ideas of Rails, in my opinion, are present in Phoenix - things like structural conventions, English-like naming, and database migrations. But many of the pain points are missing. Phoenix and Elixir aren't the One True Way™, aren't the best for every conceivable software problem, etc. And surely they'll be superseded. But in my opinion, Rails already has been.
  • emptyroads 8y ago
    I agree with a lot of what you've described, but 7 years of working in Rails and you never figured out how to turn off lazy loading in ActiveRecord?
    • 8y ago
• StevePerkins 8y ago
  What is the Ruby community like in 2019? I've spent the past 20 years primarily working on JVM-based languages. Being told for about 19 of those years that my boring verbose tech stack stack is obsolete, and going away from the business world any day now. Most recently, that voice comes mainly from the Node.js community. But 10 years ago, it was a mix of Ruby and Python upstarts. I kinda saw those languages and communities as two sides of a coin: * The Python guys were the upstarts who leaned toward stability and practicality. Wore slacks and polos, or maybe t-shirts and jeans. * The Ruby guys were more of the "move fast and break things" school, and favored aesthetics over performance. Had numerous tattoos, and shaved with vintage German double-edged safety razors and a badger brush. It feels like Node took all the oxygen out of the room in terms of racing to be the Java replacement. But how have the shifts affected the identity of the Ruby community? Did they get older, mature, and come to resemble the Python community culturally? Or are there still a lot of young people disrupting things rapidly, and you just don't hear about it as much anymore?
  • KurtMueller 8y ago
    These are certainly broad categories you're putting people into. I'm a ruby developer who wears t-shirts and jeans on the regular, have no tattoos, and shave with a Gillette Mach 3 razor (lol). I'm definitely older and more mature now but I'd don't necessarily think that makes it closer to the Python community culturally nor that the two dev communities were ever that far apart to begin with.
  • dentemple 8y ago
    Stereotyping large groups of people doesn't make for a good argument. Not unless you're purposely trying to make JVM-stack developers look toxic.
  • eamike261 8y ago
    This attitude reminds of the old engineers who cling to svn and refuse to learn git.
• crb002 8y ago
  Rails will have a resurgence with a Data Driven Design generator like JHipster. So much time saved when you get front end client side validations generated automatically; and layout is 90% automated with UI constraints.
• gjmacd 8y ago
  The author took a bit of a pot shot at NodeJS (which I do understand why). But I think it's a bit naive to think NodeJS is any more complicated of a stack or problematic as a whole than Ruby -- it's simply not. As someone that's moved between many different stacks, once you're in that stack and being productive, you tend to realize "oh, this is why this is a good stack." From the outside, if you've never used the stack professionally, you tend to get skeptical. But for me these days, there's very little difference between stacks as to "what's better". For me it's mainly "best tool for the job and who are are your carpenters?" But these days, NodeJS seems to be the right choice for many of these jobs and it's hard to sit here and knock it. Why? Unfortunately, Rails suffers from what a lot of other Web stacks suffer from -- the browser requires some level of JavaScript marshalling that all the other stacks have transform to. When you can code on the server and on the client in terms of the same language. It just makes the process cleaner and far more manageable. When an object on the server is the same as the one on the client. Your life just becomes a little less stressful. And I love other stacks. I'm a Python fan. But It's really hard to not embrace NodeJS when you've got developers who work on the frontend (Maybe in React, Vue, etc.) and server developers who are on NodeJS and they can speak together, moreover, work within each others codebase and not kill each other. That doesn't mean Ruby is a bad stack, it just means like all the other stacks, you have to move data between the backend and browser and it's "Oh, I need this change on the server, I'll have to wait for..." -- no, you can do that, if you've got the ability to code in JS, and you're a fullstacker, you can do both.
  • dehrmann 8y ago
    > When you can code on the server and on the client in terms of the same language This was the promise of GWT.
• SnowingXIV 8y ago
  I also work on a Rails system. It does the job and the nice part about it is whenever I need to make tweaks I can easily dive into the code and implement said feature quite quickly. There are a few services I wrote that have a bit of overhead but that's my fault - these typically go untouched as they are part of the backbone. I run this system on two different instances and I will say the difference between a few thousand records and a few million records is noticeable. There isn't any memory leaks that I could detect or n + 1 queries, so I've kind of thrown my hands up. Most importantly though, it's been super reliable. I'll take the slight delay for robustness. Recently I went the other way and built something with Flask because I felt I only needed something tiny (plus python and ruby are both friendly to read) and kept hearing the negatives about monoliths. It started out refreshing because I only added in what I needed but eventually this started to get a bit annoying as it grew, I felt I was rewriting the wheel often, and I missed the organization and forced convention of Rails. Not to mention gems seemed to have more support and often were more recently updated compared to flask imports. I now want to convert this over to a Rails application. I think a lot goes into picking what to use, size of team, size of users being served, verasility, and development productivity. It's not always only performance at massive scale (you may never need to handle the traffic Twitter does and if you do I think you're doing pretty well and can weather that storm).
• JamesAdir 8y ago
  Some stats from Who is Hiring March 2019: Number of occurrences of the words: Rails - 25 Elixir - 13 Python - 76 Ruby - 29 Django - 20
• mrtweetyhack 8y ago
  Too bad we can't compile a Rails app...
• LyndsySimon 8y ago
  I see nothing at all wrong with Rails - I find it to be a perfectly valid choice in 2019, if that's what you want to use. That said, I'm not a huge fan of Ruby in general. I'm a Pythonist, and don't see that changing in the near future. Python seems more straight-forward and "shallower" than Ruby to me, and there's less "magic". I'll even contend that Ruby is a more powerful language than Python - but with the caveat that this in fact is its greatest weakness. The example that comes to mind for me is when I needed to flash multiple alerts to the user using Rails; I re-opened the class Rails used to implement the behavior and modified it to keep an iterable of messages instead of only one. It was easy, sure... but what happens when the Rails class changes in the next version? My changes not only weren't guaranteed to be compatible, they weren't encapsulated from the parent class, and didn't define and verify its behavior. I can totally see a circumstance where my class would appear to work without error, but the underlying implementation might have changed in subtle and unknown ways. With Python, I'd have subclassed the parent implementation and wired my subclass up to the application. RoR doesn't make this approach easy, and even if it did, it's not idiomatic for that language.
  • temuze 8y ago
    I agree 100%. Ruby follows Perl's philosophy of "there is more than one way to do it." That sounds terrible! When you scale an organization, do you really want everyone doing everything in their own unique way? Python has a more practical philosophy: > There should be one-- and preferably only one --obvious way to do it. While this sounds a little fascist, it enforces consistency. It means that a senior Python programmer will see code from another senior Python programmer and say to themselves "yup, I'd make it exactly this way if I wrote it myself."
• danenania 8y ago
  These days I find myself thinking of Rails as primarily a dsl for modeling data in SQL. I still don’t think anything beats it for this purpose. But all things considered, I think TypeScript/react/lambda with VSCode is now a better choice for developer and devops productivity in both the short run and the long run. It’s still a good idea to follow many of the Rails conventions though regardless of the language you use.
• geebee 8y ago
  This particular blog post did a fine job articulating the benefits of Rails, and these remain good reasons to use rails in 2019. I think there's another side of this discussion. There are reasons why rails itself is worth using, and then there are reasons why MVC frameworks + a sprinkling of javascript are still worth using. Personally, I feel that the latest trend toward heavy javascript front ends that are more or less detached from the middle tier or back end has led to a wildly overblown, over engineered state of constant technical churn. I quit web development over this. I got involved in a project for a while, but finally decided that if I had to write javascript in these constantly changing frameworks, I didn't want to be a web developer anymore. Fortunately, I have enough of a math and engineering background and work experience that I was able to move over to writing code for answers more than for applications, though code for answers can be used as a wing of an app. I largely stay out of the framework now. But I use python, not surprisingly. Ruby is a nice language, and Rails is an excellent framework. I think that rails plus a little bit of javascript is far more productive than the javascript churn, and for a lot of apps, you give up next to nothing in terms of functionality. But if I got back into web programming, I'd probably do what I described above, but in Python. Ruby, for whatever reason, just isn't a big player in data engineering, data science, scientific programming, machine learning, all that. I haven't programmed in Django before, but much as I enjoyed Rails, I'd probably stick with Python at this point. Alternatively, if the javascript framework hamster wheel dwellers want to handle that mess and let me write my wing of it in python and integrate it however they please, then, uh, sure. As long as management understands that when they quit, I won't be able to maintain it. A few people tried to get me to use node, but I won't do it. I feel secure enough that the scientific programming community will not be switching over to javascript so that we can keep our programming language consistent with the shit show that is modern web development.
  • andrei_says_ 8y ago
    Just so you know, agree on all counts :)
• belenos46 8y ago
  Man. I like two things. Boring languages/frameworks, and minimalism. Boring languages/frameworks Just Work, and are usually pretty secure. Minimalist --which is to say, making something as simple as possible, but no simpler-- means fewer moving parts which can break in production. 90% of what my places of employment and clients need is the same old shit, and I like to build it so that when something breaks, I can jump in and hammer out the broken thing and get the process moving again without needing a ton of research.
• tmm84 8y ago
  My personal love for Rails is recent. I had been trying in my one to two hours of spare time on weekends (I am busy with exercise/family/gaming/etc) to build a simple website for my wife's company (simple crud stuff mostly). I found that several ways I had attempted to build the site were time consuming to learn/compile/test/demo/repeat. Even though I program for a living, starting from scratch takes time and one/two hours per weekend is almost nothing when it comes to getting stuff done. When the PC I was using for building kicked the bucket and I got an old Macbook air, I tried Rails and within an hour I had got most of the base moved from Spring Boot to Rails. I can't complain about Rails. The time investment to usable results are there. I think Rails is going to relevant like other web frameworks for a good long time.