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.

Is there a good example (read: not todo) of an app designed like that? You mean using node through clojurescript when you mean a cljs backend?

There's a similar story with Scala and Scala.js

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.

So you jumped on early in the Rails timeline and we’re able to keep up. Seems you’re just proving that point.

No, I skipped 3 and 4 and didn’t keep up. Jumping back in was easy.

The essentials haven’t really changed so jumping in at 0.14.5 or 5.0.1 shouldn’t really matter.

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.

Come on...

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

If it still relies on CoffeeScript, it's a great argument against Rails.

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.