They were pretty gung-ho about Ruby and Ruby on Rails between 2005 and 2010 or so. Then their hype moved to JavaScript and Node.js quite rapidly. It'll very likely move on to something else soon enough.

The second web/healthtech startup I was an early engineer and engineering lead on, and we used Node and C/C++. I initially wanted to backport practices from Ruby and Rails--and did so making some view helpers and other things--but eventually I came around to really enjoying Javascript as a functional-C-with-closures-and-associative-arrays. Almost all of my subsequent hacks and prototypes were in JS, going as far as Angular until it was rolled back for simpler-to-maintain pure JS.

Nowadays I wouldn't bother doing any server-side stuff not in Erlang or Elixir, because the community is a bit mature and conservative and because the languages don't have a lot of magic and are still quite performant. My best-tested web application would probably be an Elixir message board.

All things I didn't know how much I relied on until I moved to NodeJS and found them non-existent.

Sure there have been changes in both Ruby and Rails since then, but nothing like maintaining javascript.

Unless the only purpose to this is to just not write javascript.

In web development today, JavaScript gets to be the default language by virtue of being in the browser. JavaScript is a very good language, but it has a lot of warts. (See http://wtfjs.com/ for some great examples) Some of these can introduce bugs, others are just difficult to deal with. JavaScript was rushed to market quickly and standardized very quickly. Ruby was used by a small community for years while most of the kinks were worked out. Ruby also has some great concepts such as uniform access, mixin's, duck typing, and blocks to name a few. While many of these features can be implemented in JavaScript in userland, few are standardardized and the solutions are seldom eloquent.

Uniform access and duck typing provides us with the ability to make reactive objects that have the exact same interface as a normal object. This is a big win, nothing new to learn to do reactive programming.

--

Also, just as a side note, Opal does a great job of compiling ruby to JS. The code is easy to understand, supports source maps so chrome for example can bring up your ruby code in the console and show line numbers in the ruby code. While many gems won't work without some porting, a lot do. Opal currently runs rspec (a very complex ruby project) with only a few patches. Really though, typically front-end solutions do different things than backend solutions.

- Thanks to the proliferation of Rails and similar frameworks, most Ruby apps at least have something that resembles an MVC structure. With JavaScript, once you move past the basic TodoMVC examples you are pretty much on your own. It gives you enough rope to hang yourself, all you colleagues, and everyone in the building next door.

- The expect vs should change in RSpec is nothing compared to how fast things are changing in JavaScript. I think there are now 7 different ways of just defining a module.

- The stdlib of Ruby is pretty sensible. JavaScript has many inconsistencies (take Array.slice vs Array.splice - one modifies the original array, and the other does not), and you usually need to rely on third party libraries, or write the code yourself, to do pretty basic operations.

- The JavaScript community seems to have the opposite of NIH syndrome, so that even basic functionality is offloaded to a third-party modules (see leftpad). The project I'm working on has over 1000 modules in it's dependency tree.

I don't have time to go into much depth right now, but basically the ascendent languages don't seem to offer many compelling technical advantages. For example, I've yet to hear a compelling reason why JS makes a better serverside language than Ruby for most use cases. To be fair, Node and some of the JS libraries for a long time offered advantages over the Ruby ecosystem for things like websockets (EventMachine used to swallow stack traces in a really annoying way). But that has more to do with the ecosystem than the languages themselves.

I think part of the problem had to do with how dominant Rails was/is in Ruby. I wish a framework that better catered to emerging app design trends had gotten traction in Rubyland in, say, 2012.

As for specific complaints about JS, well, it's a perfectly fine language, but I don't think it's an improvement in any way over Ruby. It has a number of quirks and compromises - prototype inheritance, basically no support for modules, clumsy typing, to name a few - which people have been patching over and working around in lots of different ways over the years. You end up with a forest of different solutions to things that wouldn't have been a problem in other languages. Now some fairly dramatic changes are being introduced, which is probably good, but it means the ecosystem is even more complicated. Working with the JS ecosystem feels like working with a poorly maintained legacy codebase - there are lots of places where people have come up with workarounds to things that shouldn't have been a problem in the first place; it makes you tired just thinking about all the mental energy spent solving all the little unnecessary problems.

I think JavaScript’s core foundation is changing because its use cases have rapidly changed. Like C++ or PHP though, it likely has a lot of legacy cruft.

Are any Ruby experts able to chime in if its language/runtime changed much after Rails hit the scene?

E: I don’t even hate JS it’s fine, just not a great investment of time for a lot of apps. And the ecosystem and getting it deployed is an absolute chore.

Why add another layer of complexity and error proneness? What happens when a different js programmer needs to review your code? Or when you need to write some Node.js code and forgot all about syntax?

"The main motive is to have a decent standard library for JavaScript" - jQuery works just fine.