Hacker News Reader

Comment by rhizome31 | Hacker News Reader

Because nobody has yet invented a compelling way to write JavaScript applications, so people keep trying. We're still waiting for the Ruby on Rails of frontend development.

I'm not saying Ruby on Rails is the best backend framework (I don't use it anymore), but when it came around everybody understood that it was getting something right. It popularized a new model for server-side web development that all other communities started to follow and improve. When it came out, most developers who were already working with the web could see that it would be very useful, it solved real-world problems they had, it just made sense.

This is much less clear with JavaScript frameworks. They usually have a tough learning curve and the benefits are not always coming as expected. So people keep trying to find a model that works well.

View on HN

I remember the, well, "rage" I had at Sun when I stumbled across RoR. I had completed my Java web certification the year before. The Java stuff seemed clumsy and repetitive. One year later, saw Rails. "Why couldn't you geniuses have done something like that, instead of this mess you gave us?!?"

Plenty of people (including me) took one or two looks at RoR and dismissed it, too. I don't think it was the slam-dunk you're making it out to be. React seems to be doing pretty well these days, but it is too soon to say if it is going to dominate the field.

On the contrary; Rails was a massive innovation because it proved that opinionated, reasonable defaults ("convention over configuration") is how most people actually want to write software. For a CRUD app, Rails was a shining beacon of light, because it allowed you to crank one out in mere hours, instead of days of fiddling with repetitive glue code that you would've had to write instead in literally any other web framework of your choice. It meant average coders could be productive instead of overwhelmed, and competent coders could move on to different projects faster.

The GP post has a point. Almost every MV* JS framework starts from scratch because they all believe their slight variation of the paradigm is better than everyone else's, but the greater scheme of things they are more similar than different. When one comes out with a framework that in earnest changes how JS development is done -- and achieves some staying power -- things will be different from the myriad of near-equivalent-but-totally-incompatible choices.

> how most people actually want to write software.

[citation needed]

Honestly, Rails wasn't the first or last RAD platform and I don't think a randomly-selected subset of programmers who have used it would describe it as a shining beacon of light.

JS frameworks are actually pretty diverse, and if you think the ecosystem is a bunch of MV* variants just waiting for something innovative to come along, with respect, you just aren't familiar with what's out there.

Can you tell something about your favourite alternative to RoR way?

> [citation needed]

Okay. The year is 2005. PHP5 was fresh out of the oven and most people were still on PHP4. From PHP's point of view, there's rumors of something happening in the Ruby community that will be big, and should be talked about [1].

Then Rails 1.0 drops at the end of the year. From this Slashdot thread [2] on the announcement you can gauge the contemporary reaction; comments detail the fact that Rails was breath of fresh air from the configuration-heavy Java frameworks of the day -- represented by Struts [3], but others weren't much different in this regard, as these books from 2002 and 2004 about alternatives to Struts show [4][5]. Several ASP developers, detail their positive experiences in switching their web development to Rails [6][7][8]. The PHP world is forever changed -- by 2006, frameworks inspired by Rails abound [9]. "Ruby on Rails" becomes a popular phrase, some frameworks borrow the naming scheme along with the ideas: "Groovy on Grails" [10] tries to bring Rails' ideas to the Java world, "PHP on Trax" (formerly "PHP on Rails" [9]), "ColdFusion on Wheels" [11].

I'd say Rails made quite the splash.

[1] https://blog.phpdeveloper.org/2005/12/31/25/ [2] https://developers.slashdot.org/story/05/12/14/0034219/ruby-... [3] http://weblog.rubyonrails.org/2005/2/22/comparing-struts-to-... [4] https://www.safaribooksonline.com/library/view/programming-j... [5] https://www.safaribooksonline.com/library/view/programming-j... [6] http://weblog.rubyonrails.org/2005/6/28/asp-net-vs-rails-ana... [7] http://weblog.rubyonrails.org/2005/12/20/neters-tell-scoble-... [8] http://weblog.rubyonrails.org/2005/7/5/not-knowing-where-it-... [9] https://h3rald.com/articles/rails-inspired-php-frameworks/ [10] http://grails.1312388.n4.nabble.com/Groovy-on-Rails-is-no-mo... [11] http://cfwheels.org/blog/how-oo-almost-destroyed-business/

> Groovy on Grails

The source you quote says "Groovy on Rails", which was the official name until it was contracted to "Grails" due to the insistence of the Rails crowd that "on Rails" not be used in any other product names. The "Groovy on Grails" phrase you wrote was a later unofficial but intended mispronunciation of the earlier name put out by the Grails crowd to make it sound like "Ruby on Rails" as a snipe at the Rails crowd. To those of us who thought Groovy would make a good language outside of its use in Grails, the mispronunciation made it sound like someone in the Grails crowd thought Groovy's only use was for scripting Grails.

I think we disagree on two points. First, I don't think the influence of RoR was as sweeping as you do. This is probably just a difference in perspective or preference.

Second, regardless of that, I think the JS ecosystem is well-enough explored that the chances that some single new idea or platform is going to dramatically change everything doesn't seem very likely to me. For reasons I've mentioned in my top-level comment on this page, I think diversity of the JS ecosystem is going to be with us for a while.

> We're still waiting for the Ruby on Rails of frontend development.

Well, there are the people who have moved on to React and are raving about it, and then there are the really hip people who have moved on to Elm from React and are raving about that: http://elm-lang.org/

I think a lot of that has to do with the language changes that came about with ES2015. Before, we were basically stuck with ES5 and ES3, which aren't that great to work with and limited what you could do (easily, at least).

The stuff coming down the pipe (mainly modules, but a lot of ES2017) is really going to get the language to the level where it's going to be natively capable of even supporting a framework on the level of Rails.

I would say react is the way to write large data driven applications, but JavaScript, without a tool like Google closure, is not suitable for 100k lines of source code app that is being actively developed. Personally I am playing around with typescript and webstorm and that seems to me to be good enough.

The trouble is that it's very difficult for a single tool to meet the use cases of everyone who uses JS.

How about Sails? It's pretty damn good for Javascript as a Rails alternative, even uses some of the same context.

...the whole Sails thing is currently a hot mess. At least one core contributor has bailed and moved on to Trails.js. Accusations of incompetence, malfeasance, character assassination, etc., abound.

As far as I know (GitHub is down, cannot confirm) Sails is still running Express 3 (the maintainers are supposedly upgrading to 5), has a variety of other major issues with respect to its ORM, Waterline, and is a bit lacking on the "contemporary best practices" front. Long story short, it's broadly (perhaps unfairly, perhaps not) considered dead or dying.

There aren't any viable Rails alternatives for Node. (Flask, Sinatra, on the other hand? — sure. You'll have no trouble finding a good micro-framework.)

ThinkJS, Adonis and Strapi are the only entries I've seen in the Rails/Laravel/Django space, but they all have problems too -- to wit, ThinkJS recommended hashing passwords with MD5 (!!!) on their front page until quite recently, Adonis is aggressively NIH, and Strapi uses Waterline, which is (by many accounts) bad at just about everything.

There's also Nodal, which I've heard good things about, but it's limited to APIs with Postgres.

https://news.ycombinator.com/item?id=10821986

http://thinkjs.org http://adonisjs.com http://strapi.io http://nodaljs.com

Reply on news.ycombinator.com