If you fight it, you are in a world of pain and that's even much worse if you don't the design choices they have made in Rails.
Having said that, if you jump into Rails the whole project structure will start to make sense after a while.
I completely agree on your impression of Ruby vs Rails.
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.
The essentials haven’t really changed so jumping in at 0.14.5 or 5.0.1 shouldn’t really matter.
Come on...
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.
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.
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.
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.
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.
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.
Any framework seems "Crazy" and "Magical" at first. But once you get to know it, it becomes clear.
Rails is an opinionated, full featured framework with plenty of bells and whistles.
The core of rails is convention over configuration which means you will have a hard time going against the it.
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.
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.
That said, could you perhaps elaborate on how studying the innards of PostgreSQL is relevant in relation to ActiveRecord?
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.
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 love AR, but there are use cases where you just need to create or optimize your queries manually.
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.
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)
Still quite easy to pull out.
Psyched to see Rails adding native webpack support though.