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.
Having worked with many different languages and frameworks over the years, I have to disagree: when creating web applications, starting from scratch or from a minimal base is massively slower, more error prone and less safe than starting from a well developed and maintained framework, where so many of the things you're going to need have already been solved and battle tested.
A summary of my experience would be: libraries are good, frameworks are bad. (Indeed possibly the best "framework" I ever used was TurboGears which is very deliberately just a collection of dedicated libraries, all of which you can replace piecemeal as and when you need to).
Rails raised the bar for how little custom configuration should be necessary to do a simple, straightforward thing. But it turns out being a framework is not integral to that; modern libraries have been able to adopt the "opinionated" (which seems to be just a fancy term for having sensible defaults) approach of rails without having to grow into all-encompassing frameworks.
To be fair, Rails now makes it much easier to swap libraries if you need to, compared to how it was at the beginning. I agree that that's something useful, but personally I still think that having a sane reference combination to start from is much better than having to choose everything yourself.
Especially in the JS world, I could really feel a "library fatigue" when I had to evaluate so many different alternatives.
> I still think that having a sane reference combination to start from is much better than having to choose everything yourself.
That's why I'm such a fan of TurboGears - it's an easy starting point, but as soon as you want to step up to making your own library choices it's trivial to do so. I think the key insight is that no-one ever wants to go back to upgrading all of their different libraries in lockstep; a "platform" of libraries that are versioned together is a good starting point but at a certain point in the project lifecycle you want to unlock from that and after that trying to go back to the platform is only ever going to be pain.
Isn't that the same with any collection of libraries? If you don't use a framework and just pick your libraries, you'll still need to ensure that their versions work fine together.
If you pick a bunch of standalone libraries you can be fairly confident they're not going to interfere with each other - which version of your web templating engine you use has nothing to do with which version of your ORM you use, and you can upgrade each independently. When they're both part of a big overarching framework it's more likely that a subtle interaction has slipped in and not been noticed.
On a broad level, Turbogears is such a thing. (On an even broader level, so is my current preferred stack which is something like: Wicket, Akka-Http, Circe, Hibernate, Liquibase, and Scala's native ways of doing DI). If you're asking about Ruby specifically I'm not current enough to answer.
With frameworks you need a mental model of how the framework works. With libraries, you need a mental model of how your code works. On the balance of things, I would say that libraries often (not always) have less cognitive load here.
If you need the best library for the job, you can spend as much time as you like picking one. It's a matter of restraint to simply not spend that effort, and instead just pick a library because it meets your needs (without spending more than a moment evaluating whether it is better or worse than alternatives).
The team architect should set up the project structure, not a committew. Most languages have idiomatic conventions for writing framework-less code, so it's not going to look totally unique when they're done.
I prefer frameworks but sometimes there is a lack of fine grained escape hatches. Feature X covers 99% of the things I need. To get to 100% I have to stop using feature X and do everything myself. The solution to this problem is to make feature X more flexible, not to rip out the rest of the framework too.
It certainly can be. It doesn't have to be thought. It really depends a lot on your team. I've worked on teams where building large scale, but minimal, well tested systems was their bread and butter. I've also worked on teams where hooking up existing frameworks was what they were comfortable with and any footstep taken outside of that activity was marked with considerable rancour. Not invented here syndrome is also a real thing and sometimes people sit there building "game engines" instead of "games" ;-) On the other hand "Invented here" syndrome is also a real thing and sometimes people completely panic when faced with the thought of writing something novel. You need to go with your team.
I think it was Alan Kay who summed it up best: If your team is capable of building a compiler, you must build a compiler. If your team is not capable of building a compiler, you must not build a compiler. That matches my experience exactly ;-)
right there... if I could vote you up a thousand times, I would. I can place a bet that most home grown apps have no security measures against CSRF or XSS in place.
CRSF is not an issue for JSON API endpoints, since cross-origin requests are disabled by default.
XSS in my experience is best solved by a reasonable templating language. The same way you don't use string concatenation to insert user data into HTML documents, you don't use string concatenation to insert user data into SQL queries. Frameworks don't add anything here that you don't already have, and a lot of frameworks let you choose your templating system anyway.
This was a big reason to use frameworks in past days, though.
Most modern apps use api/json based endpoints where csrf is not needed (cookies are no longer used for auth) and xss is massively simplified since html is rarely returned by backend.
In other words most web frameworks that help with rendering html on the server and writing forms to database are not needed either.
> when creating web applications, starting from scratch or from a minimal base is massively slower
Because every web app is the same CRUD app, right?
Things evolved the last years, I build you any app as fast and create more maintainable code with my stack which consists of small libs than any Rails dev. Don't forget that also a lot of work moved to the front-end, so your daddy's Rails won't help you on that anymore. Web apps are not developed like ten years ago.
> 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.
I agree with this, but I end up at the opposite conclusion. This post about JavaScript frameworks [1] by Tom Dale puts it nicely:
> I have heard from many developers who have told me that they accepted the argument that vanilla JavaScript or microlibraries would let them write leaner, meaner, faster apps. After a year or two, however, what they found themselves with was a slower, bigger, less documented and unmaintained in-house framework with no community. As apps grow, you tend to need the abstractions that a framework offers. Either you or the community write the code.
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.
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.
Well framed and this is what we all learned and moved to: There are new paradigms out that just make so much more sense and which are followed by the majority. When I read the original submission, I mean just the title, I was facepalming in my mind.
Rails had its time and there were reasons why people liked it. But when I see that people post that Rails is still great in 2019, I'd like to stress following issue because those people might confuse newcomers who have to decide which ecosystem they gonna join.
The problem is that being in a big or biggest and still growing ecosystem makes life much easier. Once an ecosystem is on the decline you get less good libs or libs are not actively maintained anymore and the best people who shape tech are also moving to new ecosystems. I don't want to bash Rails but just an example, I didn't see any proper http/2 support in Rails-land. Now, you could say who needs http/2 (it makes a huge difference btw). But the point is that it arrived in one of the biggest ecosystem just recently and not every lib there supports it out of the box. And that's just one of many examples. People repeat that Rails has so mature 'gems' but I don't see a lot of new stuff or a big variety, tech moved on but without Rails. Just accept it.
The real problem behind all these discussions and threads. Imagine there was a time, where Rails-guys were rare and Rails was the biggest thing. I had to pay such guys $200,000/yr (8yrs ago and not in the valley), not because they were outstanding. Actually, there were average, they were ok in Rails but missed a lot of other checkboxes (often devops or SQL). But the market demand forced us to pay such salaries. Rails brought them a good life and imagine demand was declining, so they had to get into other tech, start again at zero or smaller salaries OR went to forums and rant/try to convince people why Rails is so great.
Depending on the use case you leave out nginx sometimes, eg. when doing microservices. Not that nginx is bad but with other stacks you very often don't need nginx and/or connect directly to the CDN reducing complexity in a stack.
nginx transparently proxies using http2 to client and http1 to server. In a standard setup at any scale with a load balancer it doesn't matter that Rails doesn't support all of HTTP2. The client still gets all the benefits of header compression etc.
What is a standard setup in 2019, there is none? There is also no standard in using nginx as front facing entity.
In my prior comment I was friendly and gave an example why some might not have nginx in their stack and BTW the discussion is about Rails lacking http2 and you try to convince me that this is expected and right.
This is pure ignorance paired with incompetence, maybe in your small world things work this way. Let's just stop here and go back to your legacy stack.
Something using AWS or GCP LBs, nginx or Apache covers 99.99% of the modern web app hosting scenarios. All support HTTP2 to the client with HTTP1.1 to the server.
This is why nobody is rushing out to rewrite Rack to support HTTP2. Ruby web apps already benefit from almost all of the advantages of HTTP2.
Would you like to work on a custom-built project of someone else, decent-sized, in a language you grasp poorly?
Because that's what your "small, light system, out of large frameworks" will look like to someone who dabbles in ruby/rails and looks for a job (most of the force never reaches mastery, let alone wants to).
That's not good even if somebody is very proficient in the language. Custom projects not founded on some fairly common framework are always a nightmare. Business owners should forbid developers to go that route unless they have a permanent in house development team. And still, it should be the exception, not the rule.
Which highlights one of the bigger problems with Rails, your app _is_ Rails. In frameworks like Phoenix your application is a separate entity, completely ignorant of whatever UI framework you're using to talk to users.
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.
> 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.
Not going to defend choosing what’s popular just because it’s popular but the main argument for using something popular IMO is that most of the sorts of things you want to do is likely to have been done by someone else already and some of those other people will have written about their solution or made libraries etc that you can reuse. Whereas if not many people are using something then the amount of information you can find, even in the official docs, is likely to be lacking. So you can save a lot of time by using something even moderately popular compared to using something that few other people use.
However, the caveat of course is that if you blindly choose something just because it’s popular, or in spite of your own skepticism towards it because you let the hype get to you, then it is very much possible that you end up using something that is unfit for what you are trying to do and which even though someone else has used it for the same purpose is going to lead you to implement something that has poor performance, is too inflexible and/or has other undesirable properties.
But really, the proper way to choose frameworks and libraries is to look at the docs themselves and benchmarks and make your decision based on that. Not to lazily use popularity as a proxy for estimating suitability/ease of use.
"popular tech is safe because someone will have done what you want to do"
is phrased negatively in this excellent opinion piece:
with a new technology/tool, you don't know what can go wrong.
With boring technology, there's enough community experience around it.
https://mcfunley.com/choose-boring-technology
It also seems like 'boring = popular & old', 'hype = popular & new'.
> the main argument for using something popular IMO is that most of the sorts of things you want to do is likely to have been done by someone else already and some of those other people will have written about their solution or made libraries etc that you can reuse.
Yes but this holds true for something older that was popular at some other time (like Rails) and is no longer as widely promoted. Those are way safer choices.
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.
I think a lot of developers focus on learning newer technology stacks because they are hot and tend to pay more. But less popular doesn't mean it's not in demand.
I know 2 COBOL programmers who are being paid a ton of money because of critical banking systems running it and candidates are hard to find.
If you look at the trend for 'rails' it's much more level and googling 'rails' three of the top four results are for the framework. It may be people no longer have to type 'ruby on...'.
I don't like ruby or rails. But I feel not liking it has really hurt my career. The amount of job requests I get for Ruby on rails or ruby is significantly higher than my typcial stack.
Additionally a majority of the remote jobs I've seen have been Ruby as well. So despite it not being hip. It is still very much a requirement.
Your post is a bit misleading. Rails can scale but to get there is different than with other stacks. Some would say, it's much more challenging or complicated, some would call it just a PITA and if you really, really want to scale, like e.g. a porn site, Rails is the worst choice you could ever take. Or you would just completely rewrite it but what is then the motivation to take a framework? Maybe frameworks are wrong...?
However, I think dev productivity is more important since scaling is a requirement which is very often not needed and introducing it too early is just premature optimization.
Still, I dislike if people spread false information. Rails can scale to a certain (limited) degree but it never was easy, just the deployment then without Docker was a big mess (I didn't know one Rails guys who could deploy anything without Heroku).
So let's just forget about Basecamp, Github, AirBnb, Hulu, Kickstarter, MyFitnessPal, Twitch and all the other Rails sites and continue to pretend Rails can't scale and won't work for the modern web.
Basecamp is always on the latest or beta version of rails, Rails 6 at the moment. GitHub has recently updated to version 5 and are merging a large mount of their scaling gems for version 6.
There are some podcasts and keynotes where DHH talks about their stacks.
Hulu was, and possibly still is, a Rails site. Streaming video is no problem for a Rails based application because the application server just prepares a URL for nginx to stream.
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.
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.
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.
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.
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 ?
Coming from Rails, I spent some time with Django and Flask applications in the last few years. There are noticeable differences between the two of them but both are much lower level than Rails. The developer has more choices and can make more mistakes. Projects can look totally different.
On the other side all Rails projects look pretty much the same and this make onboarding much simpler.
To answer your question: you're probably wasting customer's money (unless you're the customer) by implementing your custom components. You should use as many existing components as you can find: they are probably better engineered (dozens of teams at work vs one person - that included bug reports), better documented and maintained and will live longer. Then you have to adapt much like we adapt buying stock cloths, furniture, etc. But it's cheaper, faster to deliver and usually good enough.
basically less available gem/packages for Flask, and when available less quality or less plug and play.
The difference is felt especially when doing basic stuff that most web app needs such as auth, routings, request/response parsing/building, etc.
Even for things like user authentication system with session management, etc. in Rails with Devise you add Devise to your gem file (1 loc) then run `rails generate devise:install` and you basically have an auth system with sessions, login, etc. We are talking a few minutes and boom, your app has a fully auth system.
> 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.
From my experience, it really wouldn't read the same with Node.js. Maybe some framework on top of Node could reach a similar level of productivity and maintainability, but for now we're far from that.
I suspect that the JS world being always in a state of flux doesn't help reaching that goal.
Just to share for anyone interested in the Rails gems I'm using.
An asynchronous worker manager is helpful for handling cron jobs, mail tasks, and various batch processes that can be loaded into memory (mostly Redis) but processed later.
I use the gem Sidekiq which, as is, provides a UI and API that I rely heavily on. I might just not know the best practices, but I definitely find this valuable.
The BI tools are not something found in most ecosystems. Not to mention dead simple setup. I use two gems, Ahoy and Blazer, which together provide a simple API for event tracking and saving database queries.
I know what an async worker and what sidekiq is. But apparently you don't know that in modern stacks you don't need this anymore and it was an oddity because of RoR.
I am on mobile and don't have time to write down why, please just go to StackOverflow and ask people why something like Sidekiq is not needed in stack x.
I'm currently working in the JVM and find myself wishing I had Sidekiq. Learn at least two stacks to some degree so you can contrast and know what you are missing when you inevitably have to learn a third and a fourth and a fifth.
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.
Hmmm, I don't want to assume too much (because of course everyone's project needs are different), but that just sounds like a terrible idea. I guess there are solutions like goldiloader (I've never tried it), but 99% of the time I'd rather not load associated records unless I use them. When I need to load/use them along with many parent records, it seems pretty obvious that I'll want to include those associations (eagerly loaded) in my AR query to avoid N+1 queries as you mentioned. Then again, maybe I've just spent too long taking those assumptions for granted where newer devs might not.
EDIT: After looking more into your claim that "N+1 queries aren't possible with Ecto", I think I have a better idea for what you might mean. Perhaps you don't want everything eager loaded, but you want an exception to be raised if you try to access an associated record that hasn't been preloaded. I suppose that's a fair point (probably good practice if having any N+1 queries will be a major problem in your project, or if subpar performance really is your biggest threat), and no, I don't know of a way to do that in AR.
> Perhaps you don't want everything eager loaded, but you want an exception to be raised if you try to access an associated record that hasn't been preloaded.
Yes, exactly.
> When I need to load/use them along with many parent records, it seems pretty obvious that I'll want to include those associations (eagerly loaded) in my AR query to avoid N+1 queries as you mentioned. Then again, maybe I've just spent too long taking those assumptions for granted where newer devs might not.
You know that and I do too, but legacy Rails apps tend to be full of N+1 queries in my experience, and it's a major cause of slowdowns.
The bullet gem has helped me solve this problem in specific applications before, yes.
My higher-level problem is that having lazy-loading on by default allows N+1 queries to creep in to a code base and you need a third-party gem to find them. I've had to spend significant time finding and fixing this after joining teams with large legacy apps.
"Disable lazy loading globally" should be an ActiveRecord setting and it should be on by default IMO; people who need lazy loading should have to turn it on per query, something like `query.allow_lazy_loading(post: :author)`. I suspect that a very small fraction of queries would use this, since many apps don't do server side rendering, many who do SSR don't use Russian doll caching, and even those who do both still execute many queries that should prefetch all the associations they use.
Yep, I used it extensively on one project, configuring it to raise exceptions if it detected an N+1 query and gradually enabling it test by test as I fixed them. It's very helpful.
The problem I had with the bullet gem however is that some times you actually want N+1 queries. Especially with Russian-Doll caching.
I want my cache key to be lean, only fetching one record without its associations, because if the data is cached, I don't need any further queries anyway. If I "fix" my N+1 queries and load all associations, I actually negate the benefits of the nested caching and incur a cost I can avoid.
> The problem I had with the bullet gem however is that some times you actually want N+1 queries. Especially with Russian-Doll caching.
I know it sounds like I keep beating the same drum, but to me this problem seems like "we have slow views, therefore we need to sprinkle conditional caching logic everywhere, therefore we need to allow lazy loading, therefore we need to watch for N+1 queries."
> By contrast, by compiling templates to functions, Phoenix automatically and universally applies this simple view caching strategy: the static parts of our template are always cached. The dynamic parts are never cached. The cache is invalidated if the template file changes. The end.
With fast views, no lazy loading is needed and no N+1 queries need to be possible. I don't think this is a problem inherent to Ruby, just to the way ActionView and ActiveRecord currently work.
If the query was expensive and could be run periodically, I'd either create a materialized view that gets refreshed as often as necessary (maybe by https://dockyard.com/blog/2017/11/29/need-an-elixir-dependen...) or use a GenServer process for caching that data (as you might do with Redis otherwise).
I don't think the view rendering itself would ever be a performance issue, but rendering a view is just a function call in Phoenix, so I could take a similar approach there - store it in a GenServer.
I love how every time there is a post about Rails, someone preaches the holy grail of Elixir/Phoenix.
I think you are missing the forest of the trees, regardless of whether or not the success of rails is circumstantial, the fact remains that Rails is in the lead position because you can build a business on top of it.
It is a solid, battle tested, mature framework that one can use and scale it (up to a certain point) and beyond that, it might get harder but scaling is never easy and I am sure you would agree that Phoenix is not a magic bullet when it comes to scaling.
Again,I don't have to recount the number of services built on rails that thousands of people depend on today: Shopify, Github, Gitlab,..
Us engineers think the only thing that matters is your rendering time.. but it's not , the main thing that execs care about is the bottom line and how fast we can push products to production.
All that being said, I agree that Phoenix is great but let's not kid ourselves, we are here to make cash first and foremost.
To any young devs out there, I strongly encourage you to not pick a framework by its hype but evaluate it based on your system needs / maturity.
> I love how every time there is a post about Rails, someone preaches the holy grail of Elixir/Phoenix.
I can understand how you might feel that way. I tried to make clear that I don't think it's the perfect answer to everything forever, but to specify ways in which I've personally seen it as an improvement. And given that the OP is about the continued merits of Rails, don't you expect some commenters to express disagreement?
> the main thing that execs care about is the bottom line and how fast we can push products to production
True. But that matters not just on day 1 but for years to come. Sandi Metz in the Ruby community teaches that point well.
I've seen Rails patterns like ActiveRecord callbacks lead to buggy, confusing code, greatly hindering progress on feature work and requiring significant debugging effort.
Certainly lots of businesses have succeeded with Rails, and I've worked for some of them. Lots of businesses have succeeded with Python, Java, .NET, PHP, and Node, too. That in itself doesn't argue for which one to pick when starting a new project.
After experiencing difficulties with my Ruby tech stack, I started looking around, and Elixir is where I landed. At this point I'm invested and biased, just as the OP is. But bouncing back and forth between the languages recently has confirmed for me that I prefer Elixir for the reasons I gave above.
> To any young devs out there, I strongly encourage you to not pick a framework by its hype but evaluate it based on your system needs / maturity.
I'd suggest young devs pick tools based at least partly on job postings, and on that measure, Rails will win by a landslide. But keep your ear to the ground. When I started as a developer, I was using PHP, but I kept hearing how Rails was better. Learning it and moving to work in it was a great career move for me.
Something will come after Rails. Something will come after Phoenix. There will always be a new something. Don't get too caught up in the hype, but don't get too attached to your current tools, either.
Hey, I am so glad to hear this. My sentiments are somewhat similar. My Elixir project didn't get traction so I am back to Rails and some other tech, but definitely Elixir is the future.
Now as far as Rails go, this can be my super power.
I see a lot of Nodejs project struggle and reinvent things that people in Rails community take for granted. Like Nuxt.js for example.
I haven't used Node, but I think it's funny how they tout asynchronous IO via callbacks. Meanwhile the BEAM has that plus asynchronous computation - you just write synchronous code and let the scheduler pause your BEAM process as needed.
If you don't have to write code to deal with the computer pausing your unix process to run a different one, and you don't have to write code to deal with the VM pausing your code to run garbage collection, why would you have to explicitly write code to deal with a pause for IO?
Callbacks suck, so write service functions for complicated CRUD. Working around ActiveRecord defaults is like the 2nd thing you learn to do at a serious Rails shop. I'm afraid you may not have been working with sophisticated Rails engineers, because we certainly modify defaults in our applications.
Elixir is hot, but it's hard to learn and will always have a barrier to entry that Rails won't. Rails and .NET will live longer than us.
> Callbacks suck, so write service functions for complicated CRUD. Working around ActiveRecord defaults is like the 2nd thing you learn to do at a serious Rails shop. I'm afraid you may not have been working with sophisticated Rails engineers, because we certainly modify defaults in our applications.
I'm not sure why you feel like you need to demean my experience to discuss this. Callbacks are extremely commonly used in Rails apps and not at all the province of Rails newbies. Here's DHH in 2018 telling you about how Basecamp uses callbacks: https://www.youtube.com/watch?v=M3JPTOTqsnE
And even if you don't like callbacks and never use them, at some point you're going to change jobs or consulting clients and land in a code base that's full of them.
> Elixir is hot, but it's hard to learn and will always have a barrier to entry that Rails won't.
Maybe so. I can't predict to what extent it will catch on, but it's paying my bills. If I get to stay in a happy little niche, that will be fine with me.
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.
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.
Really? I'm doing Java contract work for a living (thankfully not only Java) and, while it pays the bills, I'd use almost anything else (except .net which is just Java without the ecosystem). I think the whole Java stack, with its myriad of metaprogramming silos, overreaching build pipelines, outdated HTTP libs and paradigms, absurd class loader configs and layers of module systems, unsound abstractions, and third-party libs, many of which are starting to reach EOL, really stinks and sends you into a world of incidental complexity. It might not be so obvious if you're coding greenfield Spring "microservice" apps or, good forbid, Spring MVC apps in 2019, but believe me it'll hurt you down the road once you need to update your project to newer versions of third-party libs.
The problem with Spring isn't that it's badly developed (it isn't, and usually gives you good diagnostics, though your stack traces gets spoiled with Spring's ugly-as-sin reflection shite). The problem is that there are people who think Spring has a reason to exist in the first place. Spring Boot is a config framework on top of the Spring framework to make it bearable - that alone should tell you to stay away from it.
I know all too well ); Only three years ago I contracted for an insurance company for JSF, and worse, using portlets under Websfear. Well, it payed the bills.
I use Grails which is very similar to Rails and a lot easier and productive than Spring Boot. Good defaults makes application building a much smoother experience. Grails is still Spring Boot, and you can still code like it was a pure Spring Boot application.
Grails has its own ORM called GORM, which can use several different backends like Hibernate/MongoDB
Groovy is a great language, with the best from dynamic languages and yet still very similar to Java. I would say there is no learning curve for Java developers with Groovy.
Grails has also been highly optimized the last few years and runs great on systems with 1 vcpu and 256MB RAM. Grails also has a great and friendly community, come and say hello in our Slack channel https://grails-slack.cfapps.io/
I've had some not-so-great experiences developing web services with Spring Boot, Hibernate, Groovy itself, Grails.
We now stick to plain old Java with no annotations, Ratpack, jOOQ, etc.
In my experience, and opinion: Lack of static typing is a good way to make shooting yourself in the foot easy. Annotation-driven magic sucks. Just Writing Queries causes fewer headaches than using an ORM. Basically, libraries over frameworks. YMMV.
I do understand why you feel like that, I've been there too. No framework is a silver bullet, but over time you will see the value in them.
One thing though, with Groovy you can choose between dynamic and static typing. These days everyone agrees that you should use static typing with Groovy as much as possible. Use dynamic typing when static typing becomes hard, for example when working with JSON objects.
And Hibernate is really flexible with how close you get can native queries, the documentation however is not convenient there. But Hibernate developers like Vlad Mihalcea is working hard to document how you can do this and is writing blog posts and answering questions on Stack Overflow. I am really grateful for the effort he puts in helping everyone.
I'll second the thought on Kotlin, and in fact I just trained a diverse team of PHP, RoR, and Python developers on Kotlin with Spring Boot, and our platform migration project to Kotlin massively reduced our LoC and increased each engineers understanding of the platform. We broke off a couple pieces into microservices which need to scale independently, and it was a great experience. I'm hoping Kotlin continues to grow in adoption.
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.
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.
I have dynamically generated queries that span over 200 lines. Doing this without a query builder is pure madness. It doesn't matter how modern your language is, manually concatenating SQL shouldn't happen in 2019.
100% this. Whenever folks recommend simpler options like JDBI, I have to shake my head. Rolling your own query builder with string templates feels like an SQL injection attack waiting to happen. If you know 100% going into a project that you won't have to modify the structure of your queries based on user input, then it's an acceptable option. But it's quite common, at the very least, to have user input that results in variable number of terms in where clauses.
Hibernate is quite powerful and the tooling in IntelliJ (or Eclipse) catches many common mistakes at edit time. Where most folks get themselves into trouble is with all the caching setup. Not surprising, but if you want to just use Hibernate as a cache-less mapper there's always the StatelessSession interface.
I also don't get the oft-repeated notion that ORMs result in bad table design. You can map any tables you can dream up. And if you insist on doing inheritance, Hibernate has 4 different strategies for mapping to classes. Certainly one of those has the performance characteristics you're looking for.
Do those queries need to be that long or is that just a limitation of your ORM tool and the table structure it generated so you can pretend to have an object database? I've simplified quite a few domain models to fit the querying needs and gotten rid of lots of tables, joins, etc. in the process. There's no wrong or right here but my observation with ORM is that it leads to needlessly complicated table designs, which in turn makes querying the database needlessly hard.
Often long queries with convoluted joins are a good sign something is wrong with your table layout. ORM lets you get away with some bad design but it always catches up with you eventually.
If you're going this way I would still recommend a library like jOOQ.
It gets out of the way and is very low-level, but it still allows you to build type-safe SQL instead of having to randomly concatenate strings in order to build your query.
This is especially useful if you have dynamic joins and things like that, which can get hairy fast if you're building them manually.
+1 for jOOQ. I prefer to Just Write Queries than muck about with quirky ORM magic that gets turned into queries. jOOQ lets me do that with safe query building and type checking through to the DB level (with code gen).
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.
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.
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.
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.
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?
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
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).
In addition, Elixir libraries tend to be very high quality in my experience. This is not the case with gems; I'm always very hesitant to add a new dependency in my Ruby applications.
Of course, the quality disparity exists in part because there is a much wider pool of developers with varying levels of experience in Ruby, similar to Node.js. But I believe Elixir encourages and even enforces a certain level of code quality, without introducing fragile mutable state, security issues, and package incompatibilities. Thus I expect the quality of Elixir libraries will remain high even as the pool of Elixir developers grows.
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.
Elixir definitely comes up short on raw computation. However we've been very satisfied with it for implementing a database. Use data oriented design (you want that anyway) and move any CPU intensive part into a native function. It's pretty straightforward to bind a C/C++/Rust library.
Considering the massive growth in AI that makes Elixir only half a solution then unless you're good with low-level languages such as C/C++/Rust. Scala and Clojure, on the other hand, are good for both computation and IO so I don't really see the advantage of Elixir.
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?
My point is rather if you are doing that (a hybrid app) wouldn’t doing a full spa actually be simpler? And allow you to use a less complex framework / a framework which doesn’t have to support that legacy.
You're going to need to define a "full SPA". Every SPA needs a backend, and Rails is as good as any. In fact, Rails + Vue is, by any definition, a "full SPA" as Vue is a SPA front-end framework and SPA only refers to the front-end design. You can launch Rails in API-only mode so there is no "legacy" anything, just a backend framework that has all the benefits of Rails while still giving you the SPA front-end you're looking for.
I wouldn't even call it a hybrid, nor would I say it's any more complex than anything else. Every SPA needs a backend, and Rails is as good as any.
By full spa i meant something where all ui is rendered on the client side and the server only serves static files and a set of web services for whatever business logic that has to run on the server.
> 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?
Not every app needs to be or should be a SPA. IMHO, unless you're creating an actual web application like Pivotal Tracker or Google Docs or etc, then maybe you should go with meat and potatoes server-side rendered html and javascript.
The company I'm at right now uses a SPA for both static and interactive things. On the static side, it's comedically slow and complex for what should be an HTML file with resources. On the interactive side, the load time is abysmal (and that's on a corporate network), and it does work well once you try to open a new tab. On the other hand, it makes for cleaner code.
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?
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.
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.
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?
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.
That's common in Rails too. Except I don't think it's necessary to make it a go-between.
Where controllers have simple interactions with models (which represent database structures, and may have logic in them) you let the controller have direct access to the model.
Models can grow to be too complex, this is where having a concept of named "Concerns" can come in handy, even if you won't use them in another model, it can lift some complexity out of your model and put it into a logical group.
Services, in my view, are akin to models. Some of them may use models behind the scenes. More of them actually represent an external service, which might be an external database that lives behind a web service, an API. Or it might be an LDAP service. (Or it might be a command pattern)
I agree with smart models, if the complexity does belong to the model, then why not let it live there. It sounds like the service layer you're describing is a needless ceremony for "managing complexity" – I'll bet it was a concept that was introduced to your group by an architect.
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 ^^
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.
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.
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.
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."
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.
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.
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
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.
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).
I have worked with Django a few years and I only use the Django Admin initially, to confirm a couple of things and maybe experiment with a data model. Within a few days I usually remove it. There is no need for a production system to retain the Django Admin, in my opinion, but others may disagree with me here.
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?
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.
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.
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.
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.
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.
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.
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.
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)
That's quite hard to measure, how do you measure expressiveness? Or easiness to grasp and get into? Take a CS graduate and have them build an app either with Rails or with Scala, in which stack will they be more productive? That to me will say a lot about a stack's productivity - because quality of documentation, community, stackoverflow questions, 3rd party libraries, general framework architecture etc etc etc..all those things are crucial for productivity.
> That's quite hard to measure, how do you measure expressiveness?
How much code it takes to express a given idea. I was just talking about my subjective impressions, but I'm sure one could count lines of code.
> That to me will say a lot about a stack's productivity - because quality of documentation, community, stackoverflow questions, 3rd party libraries, general framework architecture etc etc etc..all those things are crucial for productivity.
Depends on what kind of organisation you're in; in the kind of environment I'm working in, how easy it is to get up and running for a quick prototype has surprisingly little to do with longer-term productivity. To the extent that you're actually doing novel programming work, how familiar the syntax is and how available libraries are is actually much less important than how clearly you can think about the problem you're actually solving, and I'd far rather be using a cleaner language with fewer frameworks available. Of course in other cases you're doing things that can mostly be solved by frameworks (indeed that's the original idea behind Rails - it started out as a tool to make stamping out repetitive crud apps easier, and it's very good at that) and in that case the availability of those frameworks is the higher priority.
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.
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.
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?
I don't know the kind of work you do, but in the work I do, postgresql offers a lot of bang for your buck and works for me in the majority of all my web apps. The fact that I have one backend that can accomplish so much at good performance is a win for me.
The problems I have with postgresql in a web backend context are:
Limited support for master/master replication (for availability); there are various approaches but none of them is really first-class in terms of driver support etc.
Limited support for async (non-blocking) connection in a lot of languages. Again, it's often an option but not really first-class.
Limited support for working with non-square-table data (even just simple things like having a "column" that holds a collection). Again supported by the server but often not really first-class in the driver etc.
Rarely clear what the performance behaviour of a given query is going to be - you can write a query that looks exactly like an indexed join (fast) but it will silently decay into a table scan (very slow).
Performance is slowed by mandatory transaction functionality that hardly ever makes sense in the context of a web app. You have to have a lot of indexes (otherwise you'll get aforementioned silent slow queries) but Postgresql will insist on updating all of those indexes before it will ever acknowledge a write. The overwhelming majority of the time, what you really want in a web app context is a "deferred index", but Postgresql doesn't have those; your only options are to wait for all index updates to happen or to do a fire-and-forget write without getting an acknowledgement at all.
The design encourages you to run reporting queries/aggregations without any separation from your "live" operational updates. Because of the aforementioned mandatory transaction isolation that you're almost certainly not actually getting any value out of, it's very easy for those reporting queries to block, deadlock, or slow down your live operations. The tooling around tracking and restricting slow queries is very limited, and because of the aforementioned unclear performance it's not always obvious which queries are going to be slow ahead of time.
Aggregation has to be done in a horrible pseudo-English query language where it's impossible to compose more than one query together. Also, even simple key lookups use this language, meaning a lot of time wasted in parsing (I once saw profiling results that something like 3/4 of the time taken to process a simple pkey fetch was spent parsing the query).
A lot of serious engineering effort goes into these systems, but most of it is wasted in a web backend context. (Indeed for a long time the most popular RDBMS for web backends was MySQL, despite it (at the time) having very little support for all the supposedly-important RDBMS features like ACID). If the RDBMS was invented today I don't think anyone would use it for a web backend - it just makes the wrong tradeoffs for that context.
If you have a problem for which relational is a good fit then Postgresql is definitely a better choice. I've yet to actually encounter such a problem though.
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.
> 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.
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.
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).
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.
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.
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.
> 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.
What is likely though is that one day you'll want to use a gem providing feature X and because it's based on ActiveRecord, you can use it... whatever the backend is. There may be a few special cases where it really matters, but in general, instead of finding X-mysql-gem while you're using postgres, you'll find X-gem which uses ActiveRecord.
> If you want to go with “battle-hardened and industry-proven”, use the Spring ecosystem.
Well, uh, there it is. </Goldblum>
As a Rails fan who was forced to use Java for a web application at a previous job, I've been all over this whole topic, and even ranted about it on this site a couple times. This is the conclusion I came to: some people like to have things done for them by a framework, valuing the tradeoff of time vs. specificity, and some people like to write a lot of extra code themselves, valuing the precision that affords, at the expense of time.
The working example I took away from the exercise was that writing a simple edit page with a nested model. It took me 3 lines of code in Rails, with a few dozen more from the generators. (Cocoon is freaking magical.) In Java/Spring/Node.js, it took me 160, and I still wasn't done. I needed repeated classes, controllers, and services in 2 languages in 2 stacks. One of the arguments I see a lot in this field is how people are fans of strict types in the Java world. OK, but it seems to be a requirement to keep Java and Javascript sorted, and is a non-trivial amount of work to keep in sync.
Some people get hung up on, say, race conditions of database validations, or mock database transparency as useless, or argue about which ecosystem has more plugins (Node "wins!"), and some people think it's ridiculous to duplicate 90% of the plumbing, or hate having to deal with migrations manually, or find it inconceivable that there's not one single canonical example of a working Spring/Node CRUD app in a current version of the stack available on the entirety of the internet.
To the last point: THAT is how fragmented the "Spring" world is to learn and apply. THIS is the tradeoff in NOT being opinionated. In nine months of pulling my hair out, I never once found 2 examples that did ANYTHING the same way, and NOTHING was current and complete, not even stuff by Matt Raible. I even contacted him directly, and the best he could do was point me at a GitHub project I had never been able to bubble up with Google, which was 3 versions out of date, and would no longer work the same way with current versions of the stack.
To each their own. Horses for courses. Your milage may vary. Terms and conditions may apply. It's almost like a "right-left" dichotomy of politics.
Anyway, I leveled up my career, and now I get to pick what tools I use. But, yes, I'm still bitter on this topic. ;-)
My point wasn’t to use Spring, my point is that it’s ludicrous to refer to Rails as “battle-tested” when most people who test it abandon their Rails prototype eventually anyway. My actual advice is probably that every stack sucks, but some stacks at least get out of your way.
> The working example I took away from the exercise was that writing a simple edit page with a nested model. It took me 3 lines of code in Rails, with a few dozen more from the generators....
> Some people get hung up on, say, race conditions of database validations
Because those race conditions mean that your cute three-line edit page is eventually going to turn into a hundreds-of-lines monstrosity if you actually try to put it into production. Rails is a great rapid prototyping framework, granted, but once you try and run a Rails app in production, you’re still face-first in all the complexity Rails pretends to handle for you when it’s just localhost:3000.
I've made at least a dozen LOB Rails apps for internal use at companies. I also worked at a bespoke consultancy that made Rails sites for startups, and I've seen dozens of Rails apps "in production," out on the open internet, and making money for their owners. I think there may be some conflation here between "production" and "Twitter- or Facebook-scale production." And I wouldn't trust ANY framework to applications at that scale.
Even for internal use, you have to worry about data integrity a lot of the time.
> I also worked at a bespoke consultancy that made Rails sites for startups
Ah, so didn't have to handle the maintenance burden afterwards. I did. Rails is awesome if you can just dump the maintenance burden on someone else and move on.
Wha...? Honestly, the presumption on this board sometimes. I was one of the 2 people who maintained the apps on AWS. There were no issues. I guess we've just had VERY different experiences.
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.
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.
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.
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.
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.
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.
Elixir and Phenoix absolutely blow away Ruby and Rails in terms of performance and capabilities, and in my opinion, is just as elegant and productive (José was part of the Rails core team, after all). I still appreciate Rails (it allowed me to enter the industry), but just don't see the point of starting a new project with it these days.
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].
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.
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.
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]?)
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.
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:
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 ?
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.
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/ 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.
I think that most folks would be completely shocked to realize that they can run a command like: rails new future --skip-sprockets --skip-coffee --webpack=react --database=postgresql
Although, I would argue that they should check out StimulusJS instead of defaulting to React... it pairs up beautifully with Turbolinks 5. All preconceived notions about earlier versions of TL need to be discarded because it's actually pretty awesome now.
> ... it was a stark contrast to the tropes of complexity that came before it like endless XML configuration and IIS.
DHH has stated that he started Rails because of frustrations with the Java web app development ecosystem, and this rings true for me from my own experience. What surprises me about the illustration of the contrast of the two worlds is that, after 12-15 years of Rails, and the success its had in addressing its stated objectives, the Java "world" seems to only be adding to the complexity of their "standard" stack. Sure, you get install JHipster, and generate a boilerplate site now, but that process took FORTY-FIVE MINUTES on my work laptop, and I don't know half of the stuff it installed.
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?
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.
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.
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.
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.
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.