ActiveRecord and the Rails Controller/Model/Routing system are as good as anything in the serverside framework world. A few years back people might have started saying that AR was in danger of being obsoleted by "modern" databases, but SQL (and particularly Postgres) has come roaring back, and AR remains one of the best (arguably the best) SQL ORM.
At the same time, there's a lot of mechanism in Rails that is aimed at front-end work; templates, different template engines, helpers, the inscrutable asset pipeline. This stuff, not so much anymore. The energy you'd put into learning how to do idiomatic front-end in Rails, you should instead put into something like React (probably: into React).
People with a visceral "No" reaction to your question are probably thinking of what would happen if you started with a couple Rails books and tutorials and just went to town building a 2012-era idiomatic Rails application. Don't do that! But as an API server backend, Rails is fine, and does some things better than other platforms.
For whatever it's worth: we see a lot more Django today than Rails. 5 years ago, it was the opposite. People probably wouldn't recoil at the prospect of you doing an idiomatic Django application, even though it's not that much different than an idiomatic Rails application.
https://thinkster.io/tutorials/what-exactly-is-react
It's major criticism: there is a kernel of truth in the joke that React is a dressed-up PHP (in the sense of how you put the components together)
Some other options are Vue and Elm.
"If you're at all familiar with the history of React, there's actually some amount of truth to this. React grew out of an internal PHP extension at Facebook called XHP. See the recent post describing React's history at https://facebook.github.io/react/blog/2016/09/28/our-first-5... for more details."
"That said, the parallels only go so far. PHP is frequently rather unstructured, while React lends itself to some very specific structures. I don't think I'd necessarily say that PHP typically involves "recursively breaking down parts of the page". But sure, some similarities. (Then again, just about anything that involves template-ish work has some similarities... )"
This has basically all been replaced by Webpack so I’m not so sure
To me, that gives me pause about the viability of ORM as an approach more than it vouches for Rails. ActiveRecord has so many limitations and footguns that using it as a serious production framework is...well, doable, if you're willing to do a lot of the work that ActiveRecord claims to save you from.
If you're going to try to tell me that there's a countervailing trend of people meticulously writing their own SQL statements and record serialization logic, I'm going to say no, I haven't seen anything like that in our client base, or in blog posts, or anywhere else.
Incidentally, lest I come off as a Rails partisan: I don't use it anymore; the last thing I built with Rails (Microcorruption) was in 2013. But I sort of do miss ActiveRecord sometimes.
I'm just not actually sure what problem ActiveRecord actually solves. If you don't want to write SQL and you're willing to live with a certain degree of inconsistency in your data, that's what NoSQL is for. If you actually want the benefits of a SQL database, ActiveRecord makes the easy things easy and the difficult things impossible unless you just give up and write SQL, which you could have just done in the first place and wouldn't have actually been that much harder.
It's entirely possible that everyone does the same thing that I did when I worked on Rails apps: manually add all the DB constraints the ActiveRecord documentation tries to talk you out of, write my own error handling code for when these constraints threw exceptions that ActiveRecord had no idea how to handle, liberally call 'connection.execute' or 'find_by_sql' when nothing I wanted to do cleanly fit into the ActiveRecord query interface, and so on. It's also entirely possible that some ORMs other than ActiveRecord does a much better job at these things, but I'm taking you at your word that AR is the best.
Most queries in a typical web application are much easier with ActiveRecord, others with plain sql. A decent rails developer would know to use the right tool for the right situation. Throwing out all of ActiveRecord is throwing out the baby with the bathwater, in my opninion.
What is this even supposed to mean? Are you suggesting that ActiveRecord, a way to model the data in your database and layer behavior ontop, gives you as inconsistent data as "NoSQL"?
That may be the weirdest thing I've heard on HN.
> the difficult things impossible unless you just give up
Like what?
After reading the rest of your post I just think it's that you haven't used Rails since 2006.
I used Rails on a full-time basis between approximately 2011 and 2015.
> Like what?
Did you actually read the rest of my post? I explicitly covered that:
> ...manually add all the DB constraints the ActiveRecord documentation tries to talk you out of, write my own error handling code for when these constraints threw exceptions that ActiveRecord had no idea how to handle, liberally call 'connection.execute' or 'find_by_sql' when nothing I wanted to do cleanly fit into the ActiveRecord query interface...
And while I haven't used Rails since 2015, a quick check of the documentation reveals that the same basic limitations still exist, which I've written about before:
> OK, what if you want to generate the SQL dynamically with attributes? connection.execute doesn't do sanitization for you by itself (though you can call a private method to do that). If the generation is more complicated than that, you also have to have code to concatenate together strings of SQL code. Not because Rails doesn't have a SQL generation library, just because it's tightly coupled to ActiveRecord and fuck you and the horse you rode in on if that isn't good enough for you.
> I generally advocate for find_by_sql and select_all, but think about what that actually does. It instantiates a bunch of ActiveRecord objects that have to be of a particular model (what if the query joins tables together and returns a result set that doesn't actually neatly contain the intended columns of a given model? I can't even use ActiveRecord::Base.find_by_sql, I have to choose an actual ActiveRecord model arbitrarily), has the columns of the result set dynamically bound to it as methods during runtime (slow), also has the methods of the model itself bound to it, which may have unexpected behavior based on the query (especially if we just choose an arbitrary model), and in exchange we get to treat the result set as an array of structs rather than an array of hashes (which admittedly has its performance advantages, but not if the fields have to be dynamically bound to each object as methods!). Oh, and if you're writing an INSERT statement you have to use connection.execute after all. Have fun!
https://news.ycombinator.com/item?id=11750676
> The expectation is that "validates :field, uniqueness: true" would validate that the value of the indicated field is unique among all rows in the table. However, this abstraction breaks spectacularly. Any web application, even a Rails app, is usually run over multiple processes, often on multiple different hosts. Uniqueness validation does a non-atomic check and set, which is a known race condition in this kind of environment. The guide does say:
>> ...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 both columns in your database.
> But what actually happens when we do this? The race condition where you would otherwise get non-unique values inserted into a column of unique values is instead a race condition where a database adapter throws a generic exception for "the DB complained" with an error message about a failed constraint, and your site throws a 500. Your only recourse is to capture an overly generic class of exception that's thrown by e.g. the MySQL adapter, pattern-match the exception text for a magic string like "uniqueness constraint failed" depending upon which DB you're using, and write your own custom code to recover from that.
> That's right: Rails has adapters for MySQL, PostgreSQL, etc, but "adapting" different SQL variants to ActiveRecord doesn't go as far as turning constraint failures, lock wait timeouts, etc. into generic, application-intelligible exception classes.
> ...
> In other words, something that Rails pretends happens in one line of code does not actually happen at all, and to make it actually happen, you have to write a whole bunch of code that has to resort to string-matching a bucket exception class for "the DB complained" for the specific exception text that your particular DB engine throws. This is probably the worst example, but it's illustrative. Rails provides the illusion of simple interfaces and enjoyable programming. After working in Rails for just a few years, though, the illusion has vanished for me and I spend far too much time asking questions like "how the fuck did THAT get set to nil?" and "what does does it take to turn this multiline string of raw SQL into objects I can actually use?".
> What I would do, given Rails' existing framework of "programmatically discover the table schema and magically generate logic from it", is set it up so that it observes uniqueness constraints and programmatically adds the validation when found. Also, the adapters should interpret server error messages, throw a custom exception class for "uniqueness constraint failed", and ActiveRecord should catch this exception class and turn it into a failed validation when you attempt to save a record.
> If that's too much work, just be fucking honest, remove the uniqueness validation (because it's completely useless), and be upfront with us that we have to roll our own solution for it.
I’d love to hear an insider perspective from anyone who might have worked on those things.
Also there is always an ecosystem influence issue with choosing databases
I switched largely because of the applications I wanted to build were very 'Reactive' and message/event driven. Elixir being an Erlang/Actor-Model derivative with the expressiveness of Ruby was a perfect fit.
Elixir's ecosystem and community hasn't had as much time to develop as Ruby, but it's still very capable and you're not going to run into scalability problems.
If your goal is to skill up and get a job asap, maybe Elixir isn't ready yet, but I'd pick it over anything else to build a greenfield application in.
- be very employable => JS/Express/[a-myriad-of-other-things]
- be able to do anything (including trending AI/ML) => Python/Django (you won't be as productive as with Ruby/Rails and won't the same happiness experience [in regards to web])
- be very productive in Web env & enojoy your time => Ruby on Rails
But that's not at all to say that learning Django or Python will get you a data science job; the underlying domain-specific data-science stuff is much harder to learn and qualify for than the Python is.
I'd recommend JS first if it weren't such a complicated world with so many options.
Ok, simply rails is a tool. It is a well worn tool. Can do a lot of things and a lot of people know how to use it. Learning how to use it has been done many many times before so the path to competence is really smooth and straight forward.
I think it is worth learning because: 1) the community, you would be hard pressed to find a more diverse, welcoming, non-neck beard programming community. 2) resources, there are a lot of them. You will not encounter a problem that someone hasn’t solved for 3) fun, ruby is really nice and doesn’t fight you. Some features are debatable (meta programming, everything is an object, it’s GIL implementation etc) and I think all dynamic languages downsides are most noticeable in large code bases. But for your stated use case it’s great.
I strongly recommend the hartle rails tutorial. I convinced a friend to drop out of his math PhD and go through it. Do I think he will stay a rails programmer? No, but picking up python is a cinch after rails and there is no equivalently good python tutorial for teaching technical fluency in web dev that I am aware of.
Best of luck!!
1. You will need to learn it anyways
2. It's powerful being able to use one language for both the front and back end. Context changes harm productivity.
3. Javascript & Typescript are the future and both are evolving really fast.
4. The Node.js ecosystem is already pretty mature with a lot of 3rd party libraries.
5. Performance is really good compared to languages like Ruby, Python, or PHP. For near the same simplicity and terseness, you get something with way better performance.
The only downside for beginners is that while the Nodejs world has a ton of libraries and frameworks, there isn't really a dominant framework similar to Rails that provides everything and the kitchen sink as well as a single 'right way' to do everything. The closest thing is Express, but it's really lacking; it's similar to Sinatra. Having to deal with a ton of possible choices and directions for development is just terrible for beginners, which is why Rails is still worth it to learn as your first framework.
I've been making screencasts for Rails developers at GoRails (https://gorails.com) showing how to build various features of websites in Rails.
If you're a beginner though, I would first recommend the Rails Tutorial - https://www.railstutorial.org/book
To address OP, Rails is now a boring tech and that's a good thing. I can move quickly and for every roadblock there's a community answer. It feels like React tutorials become obsolete after 4 months.
It's very fast to first real web app request (not just a hello world response) and many of the concepts will translate to another platform.
But in practice, I'm more productive will Rails than anything else. I've spent most of my time the past few years with other languages and frameworks, but I'm still more productive with Rails than anything else when making webapps.
Of course, there is a lot of understandable excitement these days around SPA tech like React, which you should probably use on the frontend. Just set Rails to API mode. The productivity of Rails is all of the useful backend features that have been packed in. Out of the box, you have database integration, migrations, data validation tools, email sending, web sockets, background jobs, file uploads, and a dozen other features, all wrapped up in a simple architecture. Simple to integrate gems can add pretty much any feature you need, like authentication, graphql, or search. On top of that, the wealth of documentation and example code is really incredible.
And since Rails projects all have the same core and architecture, most knowledge you gain on one Rails project is transferable to any other rails project. I wish I could say the same for my work in React projects, for example. React projects often use dozens of other libraries, and each project requires me to learn that project's unique set of libraries, their architectural decisions and so on.
If you want to get hired right now? Learn React, redux, and friends. But if you want to MVP a project and need something for the backend, Rails all the way.
* Do you like to be able to build things fast?
* Do you prefer not having to reinvent the wheel?
* Do you care if it's not the new hotness?
If you answered no to any of those, run away! Rails is mature-ish. It's boring now. Its ecosystem is stable. Your sanity won't be tested.
Reads...
* Michael Hartl's Rails Tutorial is probably the book you'll want to read to get a simple grasp on Rails (it can be overwhelming).
* 99 Bootles, POODR (Sandi Metz)
* some RSpec book
* Finish it off with https://rebuilding-rails.com/
Didnt know about the book, so I'm interested, but I can't tell if it's worth buying because of the above.
It never hurts to know a few tools, but at the end of the day if you need to crank out a webserver Rails is top notch.
When you're learning to find your feet with software engineering, I'd strongly recommend avoiding languages where the emphasis on everything being "magic". It doesn't help you learn how things actually work.
> teach... terrible habits imo
What will really help you the most is learning a second tool chain after the first. This will introduce you to new and differing patterns that allow you to see the pros and cons so many here are stating.
You'll find most people have changed frameworks and languages throughout their careers. You have to with ever evolving technology. So X vs Y doesn't matter too much. At some point both could be obsolete.
The goal you seem to be after is learning web development in general. While there could be any number of paths, I would recommend whatever one you have the most resources for.
If you know developers that you can have help mentor you and they use X... then use X. Because nothing beats having a 10 minute explanation when you are learning compared to a blog post.
If you don't have in person mentors, then find X framework that has the most resources. You'll find the more stable frameworks tend to have the most documentation, go figure.
I'd also start out with a full stack framework. This is because you will already be learning so much that it can be overwhelming. Don't lose motivation to continue learning programming by trying to learn every little piece of web development. Just get something simple working. Then use libraries to add functionality. You'll get more excited having built something. Then go start to see how the library works internally and start your deep dives into core functionally apps have to have. Like authentication, authorization, validation, databases, etc.
The biggest problem I see with new or prospective developers is analysis paralysis. Pick anything and build something. If you aren't having fun you won't keep at it.
As far as employability... it's the principles you learn from building something that matter more than the framework. At lots of companies you won't even find language or framework in the job posting. This is because they understand someone who had learned the strengths and weaknesses of patterns will be more valuable. Those are harder and take longer to teach than a second language to someone. While already knowing the toolset never hurts, it often isn't a requirement.
P.S. I'm biased... use Ruby and Rails
Update: corrected protective to prospective.
Rails is probably still the best implementation of a full-stack framework, and I agree that full-stack frameworks are are the best way to learn.
Despite working for a Rails shop for a long time, I would probably not recommend Rails itself for completely new programmers anymore, just because they would probably be better served learning Python than Ruby these days.
When you look for performance for microservices, Go or Scala are better. But that's when you are beyond the first 2 years and 25 developers and have the cash to invest
Don’t panic about it “losing popularity.” Tools and techniques learned using one framework are pretty generally applicable to others.
In particular with an EmberJS front-end if you like the EmberJS convention over configuration methodology.
306 points by bdcravens 49 days ago
333 comments
1. How to create a good experience for developers
2. Taking care to refine syntax, patterns, and architecture
3. If you understand how the Rails is put together, you'd generally know how many frameworks are put together.
1. Many Rubyists and Rails developers had jumped over to using Elixir and Phoenix; that platform
2. Others have started experimenting with Rust, Go, Crystal, etc. after knowing the flaws of the Rails platform
3. However, the Rubyists who jump to a different platform often bring in the things they learned from Ruby to apply to the new platform. For example, Elixir is primarily built around a powerful macro system that allows for refining the syntax, while taking advantage of what the Erlang/OTP environment.Honestly, I don't enjoy using the front end parts of Rails, and even on the back end side of things there's a lot of non-standard things that are good to do in order to make an actually scalable and long-lived app. But that doesn't mean it isn't worth using.
The answer that you will unconditionally see to this question will be "it depends"... I would get more specific with your question so that you can extract a bit of wisdom from the answers.
Rails is and has been a dominant web framework for the last ~10 years, dhh and the people working on it have crafted a wonderfully useful tool, with all sorts of lessons hidden inside the code. Ruby is a great language... and all of these things provide wonderful reasons to learn it.
With that being said, I don't use it anymore. and I'm not going to ever go back to it unless there something out of my control. ¯\_(ツ)_/¯
Do I recommend it? ... It depends
I'm mainly trying to do things with as little code as possible that are lightweight with almost no devops. Things like static site generators, Vue w/ Serverless Framework, Flask... which do have limitations... but they are tradeoffs that I'm comfortable with, and I know the work arounds.
At work for my last two W2/Employee gigs our main codebases were Laravel and Rails. Lots of advantages, but they come with tradeoffs.
My main recommendation is that you need to find what fits for your situation. Frameworks, IMO, are more than a set of technical choices they are cultures and shared sets of values. Which is why Rails didn't really fit for me. I'd argue that I'm a fair to mediocre developer... and I care more about the thing I am building rather that what I am building with. So I try my best to keep the code out of my way. JS kind of helps me do that because I don't need to flip my brain around so much between syntax, and it has arguably the most resources for getting over challenges. What I lose is speed (compared to Go, Java, C) and that I have to be really good at evaluating resources/ repos (Rails/ Laravel pretty much do this for you).
The big ideas from any of the popular web frameworks (rails, django, express, etc) will be shared between the rest of them. It's really more of a question about which language do you want to use.
If you already had experience with web MVC, I would recommend something more exotic like elixir phoenix instead (1.4RC released today)
There was a lot of hand wringing a few years back that Rails was quickly losing popularity, but gauging by my recent time on the job market it is still very hot. It seems like I had just as many recruiters contacting me for Rails positions as they did React. I somewhat suspect this is because many people transitioned to other things and it's harder to find experienced devs.
As many others have stated it's a mature ecosystem and there's plenty of great learning material out there.
Rails aside, what would be the best tool for "learning web development" starting from zero?
I ask because people ask me and so far I've been sending beginners to the Rails Tutorial.
Another framework that seems to have been burgeoning in enthusiasm lately is Phoenix, built in Elixir which is a Ruby like syntax. The neat thing there is that it introduces a ton of interesting OTP concepts borrowed from Erlang (both Erlang and Elixir compile down to bytecode for the same virtual machine, the beam).
It's up to you, what I will say, is Rails is (in my opinion) the easiest to get started with and easiest to maintain.
Focus on learning theory and standards (e.x. HTTP, websockets, MVC, security principals) and learning tools becomes easy enough you won't bother asking us if it's worth the time investment.
Basically it feels like php did back in 2012. There wasn't really a 'framework'... there were a few popular ones: codeigniter, symfony, zend -- but until the entire dev base flocked to laravel you really didn't have that community.
Then laravel kept just becoming stronger and stronger, and then vue came about and fit perfectly along side laravel. JS has no real backend that the entire community has adopted. I mean a large part of the js community doesn't even use backends they use serverless or BaaS like firebase, and there's definitely no really good full-stack frameworks esp since you now need to choose one that fits your 'flavor' (vue/react/angular).
Whatever you do, you WILL probably want to learn react or vue, I prefer vue, but that's just my preference. Vue/react are very employable skills right now. React more so, but vue is rising in popularity and I think will surpass react (I hope)...