Rails is crazy. If you know it well maybe it's useful but it's very unapproachable. A new project, empty, involves tens of directories and files and at least two languages (coffeescript). That's been off-putting for me. But Ruby the language is quite pleasant IMO. I guess people confound their experiences of Rails and some other Ruby tooling with the language itself.
Every web application requires at least 2 languages (a sever side language and HTML). Virtually all of them also end up also including Javascript and CSS. And Javascript as a server side language is relatively new. That's not a great argument against Rails.
With clojure you get the frontend logic in clojurescript, backend logic in clojure (or even clojurescript itself) and due to the isomorphism between html and S-expressions, the actual page layout is also described as clojure data in a natural, unambiguous way.
I'm not really trying to make an argument against it anyways. IMO if you haven't jumped in early in the Rails's lifetime, it's really hard to catch up; this is what I'm saying.
I was an early Rails adopter, somewhere around 0.x and used it every day through 2.3. Somewhere just before 3.0 I stopped using it daily. I recently came back to 5.0 for a few applications and was pleasantly surprised that I was proficient in a day or so.
I wasn’t familiar with ActionCable, Asset Pipeline or CoffeeScript but felt they were all easy enough. All the basics were still there, the MVC application structure, DB migrations, etc.
I share the sentiment that JavaScript and many other languages used for web development are great but seriously lack some of the essentials Rails provides.
I realize I'm fighting an uphill battle here considering your username, but what you're saying is that it's just as easy to jump into Rails today whether you're a total n00b or you were an early adopter using it every day over ~6 years from 0.X to 3.0, skipping a couple versions, and then returning.
3 was pretty much a total rewrite of Rails, so you could argue that if you skipped 3 you are starting over from scratch. Pretty much everything changed apart from the higher-level concepts (even the opinionated stuff was diluted to a point)
Agree, Rails 3 absorbing merbisms introduced flexibility to the existing conventions making it easy to stray from the opinionated stuff. Rails 3 was still Rails but definitely made it easier to get yourself into trouble. And definitely changes any Rails 2 developer would have to learn.
I’ve experimented with most of the alternative frameworks and micro-frameworks. I have a real fondness for Sinatra. I’m happy most modern languages have their own Sinatra but I’m sad that most modern languages lack their own Rails.
Yeah I think it certainly helps that I have Rails experience coming back to it and easily picking back up. However learning it at 0.14.3 vs 5.1.4 doesn’t really make a difference. There’s no inherent advantage in the version you started on. Sure learning 5.1.4 helps if you have Rails experience but Rails today is as easy to pick up as it has ever been.
Ha so on the name, I’m transparent at least. I’m no longer a programmer but am a business customer for teams building on JavaScript. I think they have much opportunity and suffer from lack of convention in their day to day work.
Agreed re: that last bit, as a JavaScript fan. I think we’ll see a dominating convention or two emerge over the next few years. Maybe (selfishly, hopefully) not quite as opinionated as Rails but the current landscape is a bit of a mess.
I just learned Ruby (and rails) about a year and a half ago. I found it incredibly easy to pick up. Coming from a PHP/Java background I found that most MVC based frameworks that I already knew are fashioned from Rails in some way.
I think if you're new to most server side languages and javascript SPA's are your wheelhouse your experience will be very foreign and dogmatic feeling. I switch between the two worlds often and am still amazed at how productive I am in ruby/rails.
I started with Rails at 4.x, and having never written a line of Ruby prior it took me about two weeks to be fluent enough to handle most anything thrown at me in the course of "typical" webapp development.
That was about a year ago, and these days my biggest challenge is identifying and filling knowledge gaps. For instance: the mere fact that ActiveJob exists isn't obvious.
Not necessarily even html, you could write your HTML in a DSL of some sort, write functions that generate HTML, etc. Using that you could keep the backend homogeneous. For example, something like https://jaspervdj.be/blaze/tutorial.html
I think the kneejerk hate on Rails by Coffeescript proxy is a good example of why developer-hate on forums like HN is a pitiful metric for scoring an ecosystem.
It's such a non-issue.
In fact, what's impressive is how Sprockets (part of Rails asset compilation) can chain together arbitrary file transformations by looking at the extension. `file.coffee.erb.whatever` will get processed as with the tool configured for `.whatever` files, then it'll eval Erb's <%= ... %> tags, and then finally get processed as Coffeescript before being concat into the bundle.
I always thought that it was a really intuitive way to specify transformations.
But the thing is that you need Rails experience to appreciate a solution like that, and it's easier to write off Rails entirely because someone says that it depends on Coffeescript. In reality, Rails just shipped with the Coffeescript handler so that Sprockets could understand .coffee extensions if you chose to write .coffee files.
Technology-hate only serves to confuse beginners by making them think everything is black and white. And by making them think that they are making a mistake by learning one ecosystem over another when in reality everything has trade-offs and it's better to learn something over wallowing in the paralysis of indecision.
Half of these comments aren't even capable of comparing Javascript to Ruby without bringing up Webpack and the complexity of client-side bundling as if Ruby is a client-side language.
Rails doesn't rely on CoffeeScript. It includes support for it by default, but you don't have to use it, and you can never start using it by passing a flag to `rails new` or removing the `coffee-rails` gem from your Gemfile.
How do the default affect the ecosystem these days, though? I remember back when I used Rails and CoffeeScript was the standard, it took a bit of work to avoid it altogether. This wasn't difficult, to be fair, but it felt like pointless busywork nonetheless.
jQuery was removed in the latest version of Rails in favor of rails-ujs, essentially a vanilla js version of jQuery so `remote: true` and things like that would still work.
Erb / vanilla js is still the default stack for beginners. But they've started to move away from the asset pipeline and they've built in webpack.
I couldn't tell you, as I haven't been really involved in Rails for a while. I never used coffeescript for any serious project, even when this change was made back in 3.1, and I can't remember it ever causing trouble. YMMV.
Node.js was sth. I jumped on early. As soon as I saw the video of Ryan's talk, I tried it. I guess the first version I tried was <= v0.5. Then the community went... nuts. But it's quite different than what I view Rails to be.
Rails is like a culture. There are a lot of pre-baked things when you run "rails new blurb", but most of it is useful, and you'd create them anyways. But to a newcomer like me, that's a bit overwhelming. That's my lament about it. Wrt Node.js, that's just a product of lots of ignorance. All you actually need is a JS file, or a makefile with ".js.ps:\n\tpuppyscript -c $< > $@". But the wheel is reinvented with such pace and redundancy that it's a hell of a platform nowadays. Even its creator, which is a very smart guy, has said farewell.
Did you try a good tutorial? Rails is structured in a way that fits from very small to very big web projects, but it's not structured to be learned just from reading the automatically generated code - that for sure would make it look crazy at first.
Eg for "Hello World", you're not going to touch 99.9% of the auto-generated code. But you need to know where to look.
I did try some tutorials some years ago, but Rails is kind of library that wants you to know it well, and doesn't lend itself to an explorer type like me. The gap between hello world and production code is wide and I couldn't find documentation to help with that process. Probably that was my fault. Something like Flask or Sinatra does not require you to know an ORM before exploring what sort of data structures you'll want to use. I guess it's just that sth like Rails does not cater to people who like to learn their tools while actually using them, and never before...
My problem is that much of the time I don't know where to look. I'm not a great programmer, so maybe that's why, but the few times I tried to grok the innards of, say, ActiveRecord I gave up fairly quickly.
I think that a very few share of Rails programmers need to know the innards of ActiveRecord - I use and abuse it heavily, and never felt that need. When things get difficult to optimize, I fall back to hand-written SQL. I spent a thousand times more time studying the innards of PostgreSQL than AR :)
I think the point is, Active Record (like any orm) is a leaky abstraction that covers a small, but common percentage of what you can do with SQL. Any time I've run into problems fighting the "magic" of Active Record, my time was almost always better spent just taking back to hand written SQL (which isn't terrifically difficult with Rails).
Rails absolutely is a framework where you need to abandon some control and trust the framework though. If you need to know exactly how your abstractions work under the hood, it's a poor choice IMO. I doubt there a single person who has comprehensive knowledge of how every single part of Rails works.
Couldn't agree more. Invest a bit of your time gradually learning more SQL and your life will be easier no matter the backend / ORM.
SQL is really not going away anytime soon (it's demise has been falsely predicted many many times). It even fits the current language hype in that it's functional!
> I'm a bit of a control freak, so this lack of insight into the innards makes me (quite possibly unreasonable) uncomfortable
Ok, that could be the reason why you don't like Rails :)
Regarding postgres, its innards become relevant when you have partitioned tables with billions of rows and need to run queries on them for analytics purposes. In these cases you often need to manually create some complex queries from scratch; other times, you can use ActiveRecord "magic" up to a point, but then you either need to add special indexes (eg partial indexes, that saved my ass many times), or you need to replace the automatically-generated queries that ActiveRecord uses and which are good for small numbers, but become a bottleneck when scaling.
A while ago it was easier to get in (and the framework wasn't simpler), there was a lot of beginner-friendly materials (like the "do a blog in 15 minutes" video). If you started from there it was actually hard not to understand the file structure. (hint: rails/rake commands are your friends to quickly scaffold your models/pages).
I agree that a lot of people don't make the distinction between rails and ruby. I had interns who where quite surprised you could use ruby without rails, and that "it's actually a complete language!". Ruby on its own is charming indeed. Rails gets the job done: few other tools enable you to finish a functional MVP in a day or two. But if you start to add gems for everything it just becomes a pain in the ass.
edit: I was f*cking mad when they added coffeescript. fortunately it's simple to disable (just removing the gem and changing a setting for the file generators)
That's not true (regarding coffeescript), you could always used JavaScript for the front-end, they just installed coffeescript compiler as a default at some point. And there are not SO MANY directories, you actually care about like 3, maybe 4 ;-) (app, db, config, lib)
