I work as a senior engineer at a FAANG and this whole road started with The Rails Tutorial. It isn’t hyperbole to say that Mike Hartl changes lives. Him and the old RailsCasts dude deserve to be in the Rails Hall of Fame.
Thank you Michael! I will forever be grateful for your work on Rails Tutorial, it started me on my path to becoming a developer and the Learn Enough series has been super awesome.
I also am a senior engineer now because of this tutorial :) I'd taken a mess of CS courses in college but had never done professional web development.
Along with many, many other things, this tutorial taught me the basics of TDD, which for me was the big unlock, keeping me out of the debugger for every little thing.
Cool! After a hiatus from Rails, I threw together an internal tool this week with 6.0.0.rc2 - breath of fresh air in a world of microservices and complex architectures.
Good job rails team!
===
Edit:
P.S. - Thanks rails community too! Was super simple to build thanks to the vibrant community...
- Corporate SSO via devise + omniauth
- CSV uploads (activerecord-import gem)
- pagination (will_paginate gem)
- external API integration
- DB seeding
- audit logging on edited/created data (audited gem)
Conventions in rails are so strong, that I quite possibly know how to seed and migrate your database, can integrate additional omniauth providers and know how to pull audit data even without looking at your code.
on a whim...do you know of any good guides for integrating an external API? i'm new to rails and working on a rails project that needs to communicate with a third party api -- there are a lot of messy guides, particularly for oauth
If I was starting out fresh, I'd probably try and check out some of the guides that services like stripe and github have for interacting with their own api's if you'd like some real world experience.
I think the pattern of making generic classes that leverage the httparty gem is solid. Depending on your preference have another layer of classes between that and your models. Or have the apis called directly from models or controllers
I don't know of a library for external API integration (so I'll be watching this space), but for OAuth specifically, Omniauth has been invaluable. It supports a lot of various strategies [0] which is what it called various OAuth2 implementations.
I've been working with Rails for several years. First, it was fullstack rails, then we got a giant mess of jquery, tried to solve it by moving to an SPA with Vue... and since then our productivity really dropped.
While Vue works, I miss the productivity of having a single server app to maintain, instead of two. I'm considering moving back to Rails only, with the aid of some library like Unpoly for the nice ajax unobtrusive javascript helpers.
Congrats on the release, and thanks for helping to keep alive the model of server-rendered apps, while everyone else appears to be moving to SPAs.
How is that possible if you're comparing the same data loaded on the client vs the server? Server has a faster Internet connection and connects to the DB directly (not over HTTP).
Sure, clients load "faster" if you mean they don't actually load everything. Apples to oranges.
If a page needs to make 5 DB queries to present a bunch of data, those 5 DB queries will be faster on the server than from the browser. So will parsing the response and transforming it into HTML.
If you're creating a desktop application in the browser, a SPA is the way to go or the experience will be nightmarish for both users and developers. For anything else a classical server rendered web app is OK. Example: Amazon is not a SPA.
You can do the first render without loading everything from the DB, then load your more expensive data while the page is loading.
Or do infinite scrolling and only load 10 rows from the DB, where you would have to render more rows to be usable if you didn't have infinite scrolling.
Been doing Rails for the past year coming from a C# and ColdFusion background. God I love what you can accomplish in a short amount of time with Rails.
ColdFusion became a nightmare since there is NOTHING for it any more.
I'm a long term ColdFusion developer (since 1999) - about 5 years ago we (the company I work for; I have autonomy to choose the stack and tools) switched to Rails (from CF) for the ecosystem.
We still support old code we haven't rewritten, occasionally adding some features, but generally speaking, no, we haven't looked back. The core of our business logic (a lot of background processing) has long since moved from a hand-rolled CFML approach to Sidekiq. The eventual goal is to retire CFML completely.
That's our goal also. We just ported a site over to WordPress with a Rails admin backend. We're hoping to move off of ColdFusion completely by next year.
Though you can do ALOT with Wordpress and Woocommerce, the Wordpress "framework" just feels icky. Not to mention that WordPress is a beast and can slow down considerably with only a few people in the admin area.
That said we use a Rails admin backend to mange all aspects of the stock and categories. We sync up to Woocommerce with the API and ActiveJob.
This really isn't anything ground breaking, it's using the right tools for the right areas to bring things together.
Thanks for elaborating — that does sound like a good compromise that would be easy for someone/a team familiar with both Rails and the WordPress JSON API to set up.
I switched from .NET to rails. agree with the other comments about rails tutorial. It is excellent but don’t forget the rails guides (guides.rubyonrails.org).
If you already understand MVC (for example if you’ve worked with .NET’s MVC offering) reading rails guides will serve you very well.
> I’m considering learning rails for a new project. Also coming from a .NET background. Any good resources you can recommend?
Yes, learn anything else other than Rails or Ruby. It was never good, just well promoted. I haven't checked on it recently, and I'm sure there are improvements, but there are so many better options today (e.g., .NET, Python, Node), it's hard to see a good reason to take up Ruby or Rails.
I think I have a good enough reason. I’d like to pursue a remote job as a backend engineer. Most interesting job listings are for rails or go. I’m not particularly fond of go, so I’m trying out rails. Who knows - maybe I’ll hate it.
Rails has been the joy of my web developer life for the past five years. Went through native development, SPAs, etc. – and happily came back to Rails in the end. The productivity of it is just fantastic.
Congrats for shipping, and to many good years to come!
Started a new project with Rails 6.0.0.rc2 the other day. Great experience, up and running quickly and enjoyed all the new little touches (object allocations in the logs is great). The multi database[1] thing is also great to have built in - the new app has an analytics database and a web app database that it needs to query, so it is great to be able to use the new functionality for that!
Say what you will about performance, but Rails continues to be the most productive framework for building a database backed web application or (non-trivial) REST API. It's secure by default, includes optional peripherals (ActiveJob, ActiveStorage, ActiveMailbox, etc.) to handle most common tasks and has excellent documentation.
Congrats to the Rails team on this release and for continuing to plug away after all these years.
I hated on Rails forever. It has its flaws for sure. And granted, I now have 5 years of experience with it, but there is nothing that compares to it for whipping something together quickly.
Don't get me wrong, Python is a great language. And Django is a great framework. There's lots of good languages and Frameworks.
But Rails has the right magic of incredibly stable tooling, a huge community, and tons of documentation & guides written for beginners. It definitely has a unique (and valuable) place in the world / businesses.
What?! Rails has been announced as dead at the release of almost every new MVC framework. The last major proclamation was when Phoenix was the new hotness.
All of the ones I’ve seen have been “dead” in the sense of “there is some new hotness that has replaced it for new projects” not “no one is still maintaining Rails”.
A new release contradicts the latter, not the former.
If dead means not the new hotness, then yes, Rails is dead. If it means the project has stopped releasing major features and improving the code base top to bottom, it isn't.
Eh, no. The whole MVC pattern is obsolete and every web project I've worked on less than 5 years old is a SPA. It's gone the way of PHP. It will always be around in legacy stuff but hardly anyone is building new project with it.
What are you using for the backend? A SPA has no value without one. Unless you're using something like Firebase, pretty good chance your backend is an MVC app. (I think you're confusing server-rendered apps with the MVC pattern)
If you're using graphql for the backend, is it still MVC?
Even if you can stretch the definition to fit, is it still useful to organize your code along those terms instead of what's natural in the new ecosystem? (data source resolvers, type schemas, queries/mutations)
Amazon still runs a bunch of Perl in the back. Just because you're stuck with some design choice doesn't mean that framework has a solid future. People still write plenty of COBOL but you don't see any new applications using it
Plenty of new mainframe code is written in corporate settings. Legacy modernization is strong as ever and for some companies that doesn’t mean moving off mainframe - it means upgrading, cleaning up and cloning legacy COBOL code bases and some times writing new.
I'm convinced RPC frameworks are the future of REST. It's too crufty without them. Most of the rails stack just isn't involved in those calls, so there's not much purpose using it.
MVC is way bigger than "server-rendered websites". It applies to anything with an interface - native apps, SPAs. Arguably even services that don't have GUIs. It's a method of separating concerns that has remained remarkably popular through many different technology cycles. You're saying a lot of words but I don't think you know what they mean.
Right on. My concept of MVC just helps guide me on how I’m going to go about building some particular web functionality, irregardless of whether or not the end result is more or less SPA in nature or not. Some parts of my app are nearly completely Ajax driven and server side rendered, other parts are just static web pages. The model means, what classes or methods do I need to build to store the data/state. The view means how am I going to present the to the client side, with a mix of html/template engine working with a backend view class/methods. The controller is how am I going to network the model with the view, and that is generally with forms and other supporting logic. The level of people on this thread that are talking very confidently about things with which they are clearly novices, is pretty shocking. I haven’t seen such a thread on HN in a long time. I’m a python guy using Flask, but congrats to the Rails users and thanks to the developers for continuing to drive it! You’ve made the web a better place.
Assuming your API follows REST, I find the MVC pattern to be immensely helpful. Even if the "V" part is just an object serializer, it's still a great pattern.
That's stupid implementation. You can _easily_ build static websites that load near instantly and are tiny. Also if you choose to shut off javascript that's your choice, but don't complain the web does not work.
If nearly every implementation of a technology is broken, I wouldn't blame the implementors. I would blame the technology.
Hell, Facebook basically invented reactive Javascript and they still have loading bars everywhere, broken content sections, and requires a full reload every now and again to get content to show. Reddit is even worse. Those are two major implementations of SPAs and they're both horribly broken.
It's nothing to do with if Javascript is enabled in your browser. If Facebook and Reddit, two of the most popular sites on the Internet, can't get SPA right, I'm blaming the technology.
Strictly speaking, the V is still there. The View doesn't have to render HTML; it's still there, rendering JSON, in a Rails API.
You can even build an SPA using the MVC pattern. I think nullwasamistake's comment was misusing buzzwords, and they were rather comparing server-rendered apps vs client-side SPAs.
> In fact, GitHub, Shopify, and Basecamp, as well as plenty of other companies and applications, have been running the pre-release version of Rails 6 for months and months in production.
Test suites are nice and all but nothing beats having tons of real world production workloads thrown at something to really test it and iron out a good developer API. There's just a massive amount of confidence you have that you won't be the one having to pioneer some weird edge case bug.
Can someone list at least 1 other popular web framework that has multiple individual sites pushing billions of page views through it before it hits a stable release?
I would not be surprise if there was a PHP framework that rivals that in page view. But I don't think there will be any other framework that gives as much confidence to developers as Github and Shopify.
I think Cookpad wants to test Rails Pre-Release in the future as well, that is a site possibly bigger than Github.
I wonder if Apple Music is still on Rails.
Yeah, when I think Shopify, I think mission critical SAAS app where your customers have customers and there's tons of payment transactions happening. Reliability is of the upmost importance while running at massive scale.
There's just a huge amount of goodness in being able to piggy back off a bunch of sites' engineering teams to ensure by the time you use a release, it's been through so much testing.
I really never got that feeling from any other framework. I wish Phoenix had more success stories like that.
Very exciting. While in medical school, I taught myself a decent amount of Ruby and learned the Rails framework due to an old mentor of mine.
The same app that I learned with is now a full fledged startup, with thousands of future doctors using it, and one of our DB tables has nearly 1m objects.
Kudos to the rails team, really. I know a lot of titles and headlines talk about "is Rails dead?" and this should put it to rest. It might not be the most cutting edge technology, but it's proven.
Rails provides a way to make sure that at-least for first two seconds after the write operation, read requests are handled by the write instance. This assumes that your read replica will get updated within 2 seconds with the live data.
How does that work though? If you have multiple instances that are serving the same traffic, how do one know about the change made by the other? Is it a global timer? i.e. any write affects reads, or it knows and only works on the same table?
Why not keep dependent operations within the same transaction? If that would be done by rails from the start then I could just easily split read/write through pgpool.
We've been doing this for years on a Rails 3 app. We yield from a `slave` method, with the connection pointing to the replica DB until yield returns. It's just a short method. It's great if Rails now supports this directly, but a shame if people have been waiting for it.
For people who are making the switch from Rails 5 to 6, or transitioning from Sprockets to Webpacker, I strongly urge you to bookmark what I consider to be the missing manual for everything that falls through the cracks:
My only complaint with v6 is that we didn't take the opportunity to make a clean break from the Asset Pipeline. I know that there are gems that would break etc. Luckily, the process moving CSS to Webpacker is made easy via this document.
Tips!
If you're using Sass, make sure you switch from sass-rails to sassc-rails.
Stimulus is an awesome solution for your JS needs. Don't even think about React again until you've at least considered the power of a well-cached backend fronted by a Stimulus + Turbolinks solution.
Try to get an early handle on the multiple ways that import can be used in your JS files. There are three different forms and they all have subtleties that can bite you:
import 'library'
import { x, y, z } from 'library'
import * as Library from 'library'
If your JS has require() directives, convert them to import directives. import is the future.
Finally, don't ever let anyone shame you out of using jQuery. jQuery rocks and is an incredibly powerful tool that still brings superpowers to the table. Anyone who suggests it's simply "bad" is not bringing good arguments to the table. (But when things get hairy, take a good look at Stimulus!)
A lot of web apps in Debian are depending on Ruby on Rails 5. Right now, I'm making their transition for 6.0.0 with its RC1 [1]. So glad to meet its stable release now.
Rails 6 coupled with a starter template like Jumpstart Pro, and you can literally have a complete MVP SAAS app up running (payment support, team support), within a few hours.
Rails continues to win in the productivity category.
They mentioned in the PR that it seems like an adapter for rspec/cucumber needs to be added for that to work out--I, too, am hoping that such a thing comes to fruition.
Would someone more familiar with Ruby mind explaining what Zeitwerk is/does? I think I have a vague idea, but both the announcement post linked to from this one and the project's README assume a lot of prior knowledge about the use case.
Sure, I can try! One part of the Rails "magic" that the framework tries to abstract away from an app developer is code loading. So, instead of each file in your app needing to explicitly specify using "require" statements which other files it needs to run, Rails uses Ruby to automatically "require" files for you. This system is dependent on constant names and namespaces matching file names and directory structures. So, a constant (Rails model) like "Sports::Player" used in a controller might be found via lookup automatically in "app/models/sports/player.rb".
A system which does this has been a part of Rails for a _very_ long time, and Zietwerk is an upgrade to it by a longtime Rails contributor that fixes some of the previous downsides and gotchas.
Ruby classes usually need to explicitly require the other classes and modules which they use. Rails implemented a different way to achieve requiring dependencies using a method called "const_missing" which requires the missing dependent when it is not found in the known constant list.
The problem with this is that if your classes and modules do not adhere to a strict arrangement within your source code directories then Rails can sometimes not find the file you are looking for, or worse find the wrong file.
Since "require" has an effect on the loaded constant namespace, the order of requiring dependencies can make a difference in the presence of bugs related to which code has been required.
Congrats to the Rails team ! I can't praise Rails enough. Such a huge boost in productivity for prototyping or full production app. I use it for both work or side project. I can't imagine a world without it. Long live Rails !
Great news, and a hearty congrats and thank you to all the contributors!
As a frontend designer, I'd been hoping for some mention of faster SASS/SCSS compiling, but it looks like it's the same asset pipeline for that. Can anyone recommend a current resource for decreasing compile times?
I love designing in a Rails app, but my non-Rails projects all seem to inject CSS changes into the browser almost instantaneously, whereas with Rails there's often a wait of up to 10 seconds. The lag is pretty disruptive to the design workflow. I'm pretty new to Rails so any tips on what I might be doing wrong would be appreciated :)
Definitely switch over to sassc-rails, which should give you a massive speed boost.
I also run an instance of bin/webpack-dev-server which handles all of my dev-time Sass pushing needs.
One thing I'm a little sad about is the decision to continue using sprockets (aka Asset Pipeline) for CSS and images. My understanding is that a lot of gems would break if they changed but I can't help feel an opportunity was lost to bite the bullet and do the big switch all at once. I guarantee you that it's coming.
Use Webpack for SCSS (and if necessary enable PostCSS, though I am pretty sure Rails' Webpack config supports SCSS by default) and enable livereload, the problem will fix itself.
Framework that works. If you are building a business - use it. If you are into developers masturbation - use something that was released a month ago and got lots of GitHub stars/HN upvotes.
Congrats. Unfortunately my favourite PR [1] Model error as object didn't make it into Rails 6, but it will be in Rails 6.1
Active Storage still needs work [2], ( I really wish paperclip had stayed a little longer ), but the update should really be good enough for general purpose usage.
And hopefully someday Action Cable would really work without switching over to Any Cable, the latency are way too high.
And I heard Stimulus 2.0 [3] is coming too.
And with Github and Shopify taking more hands on approach in development, Rail's future is brighter than ever.
Thrilled about this. Haven't written rails in a few years because I've mostly been backend at a FAANG co, but if I had to build a small-medium size site again I'd go back in a heartbeat.
In short, to do this feature family properly and in an opinionated, predictable way means that you have to cover a number of non-trivial cases. Multiple primaries and their replicas is just the beginning:
- automatic connection switching on a per-model basis
- Automatic swapping between the primary and replica depending on the HTTP verb and recent writes
- Rails tasks for creating, dropping, migrating, and interacting with the multiple databases
Sharding, cross-cluster joins and load balancing replicas are coming soon.
I think what's important here is that every site over a certain scale previously needed to implement their own take on this, and there were a lot of thorny edge cases, race conditions and heisenbugs to do so. It's kind of like the old chestnut that if you find yourself writing original crypto code, you're probably doing it very wrong.
The fact that any project can uncomment a few lines and get all of this for free is properly awesome.
Zawinski's Law
“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
---
Action Mailbox routes incoming emails to controller-like mailboxes for processing in Rails. It ships with ingresses for Amazon SES, Mailgun, Mandrill, Postmark, and SendGrid. You can also handle inbound mails directly via the built-in Exim, Postfix, and Qmail ingresses. The foundational work on Action Mailbox was done by George Claghorn and yours truly.
It sounds like you are implying that web developers are beneath you. Building web based software is more complex than slapping together some HTML, JavaScript and CSS.
I am absolutely not saying that. What part of any of that says they are beneath me?
When a European tells an American that they're not the only ones on the internet you people don't jump down their throats. When I do it you people lose your collective shit.
When a European preemptively tells an American that they're not the only ones on the Internet based on stereotypes about Americans, then yeah, that's kind of offensive. You've insulted Americans based on stereotypes, insulted web developers based on stereotypes, and when people point it out to you, you keep doubling down on it.
Let this Ugly American suggest to you that perhaps you should consider following the First Rules of Holes: when you're in one, stop digging.
Even then, that level of bloat is unique to certain types of development. In more regulated industries, like medical devices, more code can translate to high regulatory costs.
My previous competitors will not put code to email people inside medical devices. It was hard enough to not get a lawsuit with core code going haywire.
Someone said that I need to get over myself. If I told you that how would you feel?
Someone said that I look down on people. I dont have the energy to look at people in any way, down or up. It's an attack on my character to say otherwise.
I'm saying you should just disengage, and not stress yourself out by overthinking and overreacting. Your life will be simpler and better for doing so. :)
Where is anybody attacking your identity? What the hell does that even mean. After 24 hours, your comment can no longer be downvoted. There's only one other comment in a different thread capable of being downvoted, and it looks like you're being downvoted for a similar reason there too. You're participating in some fabricated outrage.
I was downvoted into oblivion to the point where people are downvoting comments in other threads that had positive upvotes for awhile; told to get over myself; told that I look down on people. I've had my identity attacked for what? Because I pointed out that their field is messier than others? If someone told me something wrong with my field I wouldn't attack their identity, I would go you know what you're probably right or say you know, I think you're not considering x y and z. I wouldn't outright attack their identity. You people are honestly being bullies right now to the point where it's borderline abusive.
They're internet points, they mean _nothing_. You are freaking out over a joke grandparent comment, and you're being downvoted here because of your overreaction. You wrote a paragraph to my simple comment of suggesting you disengage, but perhaps you really do just want this outrage. Good luck.
I'm sorry that this comment got downvoted because I actually think this is a valid point even if I'm about to offer my perspective on why it shouldn't be a concern. We shouldn't be so thin-skinned.
Nothing you weren't expecting, but: like many libraries which shipped with Rails, you can easily turn it off with a single comment character and never have to think about it again. In this sense, it's a tempest in a teapot. I never got excited about CoffeeScript, so I just commented it out.
Big picture, Rails is often mistaken for a product but it is quite literally just a set of useful abstractions from Basecamp that hit critical mass when Basecamp launched. If other people find it useful, great - but that's never been the MO.
Now, obviously Rails also has a life of its' own, and that's where the idea of convention over configuation kicks in. Basically, DHH has strongly-held opinions about the way things should be done to maximize the experience of building. The new multi-db support is another example of something that people have been building their own versions of since forever; by offering an opinionated generalized take on how the experts would do it, we all benefit from not having to reinvent the wheel.
I honestly believe that this is why Rails is both successful and enduring. I love seeing all of the comments from people who were seduced by SPAs and are finding their way back to SSR Rails. The productivity and ease of hiring is just unparalleled, and commenting out ActiveText or whatever else you don't need takes away none of that.
Oh, get over yourself. That quote doesn't have anything to do with web development (and for that matter, it hardly has anything to do with mailboxes, except as a tongue-in-cheek example of an extraneous feature) so I have no idea why you feel the need to take a swing at another discipline that you clearly don't know the first thing about.
What is the lightest weight, best practice / pattern for using rails, not django/flask, to call python-based programs (e.g. python machine learning inference such as tensorflow/pytorch, or other scientific computing like scikit or numpy) on a lean server (keeping costs down)?
I think Node.js is the better choice for this than Rails. You want your Python number-crunching API accessed async leaving Node to take care of auth, logging and database reads. With your Python API returning JSON I would imagine Rails serialisation would slow down performance relative to Node.
I’ve been using Rails since 1.2, and somehow it has never lost it’s magicalness for me. These days I might eventually end up using something different to build a production app, but Rails is always still the first tool I reach for. It is absolutely incredible to me how much value DHH and the core team have created with it. I’ve got a new project starting Monday, so this is great timing! Thanks to all the Rails contributors that made this happen!
Do you plan to run something more serious than github, basecamp or shopify? Usually it is not rails, which is the bottleneck, but the architecture of your application.
As a matter of fact, yes. Not as big as GitHub, but bigger than Shopify. So the choice of application server matters, as well as how easy it is to scale and provision that server.
Shopify has 800,000 customers, 4,000+ employees, and handles over $40,000,000,000 per year. And you're building something from scratch, starting today, that is going to be bigger than Shopify in a fast enough timeframe that your Rails server today is the biggest concern?
Something doesn’t add up: You have have a high profile project that is bigger than Shopify (!) but you ask a question that seems like the first question you should type into google to research this if you were interested.
Any server is fast enough. If your web app is literally doing anything other than rendering empty pages the time a request spends in the web server will be an insignificant fraction of your total response time.
I don't know if it's the fastest, but I've had good success using Puma with Ruby on Rails in a real-world production site. That said, if performance is your goal, then the web server is only a small part of it. In my experience, the way to get a high-performing Ruby on Rails application is primarily through fragment caching and using a CDN. You can get excellent performance with very little effort that way.
https://news.learnenough.com/ruby-on-rails-6
You can join the Learn Enough/Rails Tutorial email list to receive a notification when it’s ready:
https://news.learnenough.com/email-list/