Rails, still? | Hacker News Reader

Rails, still?

blog.phusion.nl

239 pointsvinnyglennon224 comments

"Sinatra is Ruby with Rails in mind. You will find yourself using more of Rails in your Sinatra application over time and ask yourself why you're not just using Rails."

This is an important point. If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly.

To riff on Greenspun's Tenth Rule, "Any sufficiently complicated $MICRO-FRAMEWORK application contains an ad hoc informally-specified bug-ridden slow implementation of half of Ruby on Rails."

> This is an important point. If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly.

Not really. You want an ORM? choose an ORM library. You want templates, choose a templating library. You want to send mails, choose a mailing library. I don't see how big frameworks like Rails make all these things better, especially when they don't give you the choice as to what tool to use. If you ever developed a non trivial application, you also know that your first concern will be to avoid unnecessary bloat and complexity and only bring in libraries that are strictly required. And as we are moving from traditional html rendered server apps, big frameworks lost even more value since there is no need for a templating libraries, html form libraries,...

The improvement comes from someone else making all of those decision for you and as long as you completely ignore your design requirements and force your problems into the framework's mold then you're golden! You never actually need to think!

You also get a uniformity of understanding of your library and a support network.

Rails is tailored to a particular type of web application, and if your application strays far from this model it's probably not going to be a great fit. I don't think even the biggest Rails zealot would advocate building Google Maps in Rails.

The sweet spot that Rails covers, however, is a pretty common sort of web application - one in which you're primarily doing CRUD on different sorts of objects. If you treat every single application as a unique snowflake that needs a 100% bespoke collection of libraries to solve, you'll end up wasting a whole lot of time on architecture and library selection and not a lot of time on solving actual problems.

> I don't think even the biggest Rails zealot would advocate building Google Maps in Rails.

Rails excels at being the web layer in this situation. All the heavy lifting is done by the DB to spit back feature structures or do routing and native libraries to do image composition.

And indeed, openstreetmap.org is a Rails site (though key parts of the API have been rewritten in C++ for performance).

I actually consider Rails in its 3.x+ versions to be a pre-selected combination of smaller libraries - because it really is. Don’t need mail? Remove actionmailer. Don’t need a database? Remove ActiveRecord. The benefit is that when you do need those tools, they are there, they work together, and you don’t have to choose.

That’s not always perfect or suitable for every use case, but it’s not a bad thing.

Agreed; those days are when I worked on Rails, and that was a lot of the things that made 3.x different from 2.x. I wrote a blog post about it that’s one of my most popular ever: https://words.steveklabnik.com/rails-has-two-default-stacks

This sentiment also was a major theme of my forward to The Rails Way.

I’ve been thinking about this stuff a lot in the context of Rust...

> I’ve been thinking about this stuff a lot in the context of Rust...

Do you mind extrapolating further, or will that be the topic of a future blog post?

For now, what I’ll say is that I’ve seen how Node never really got a rails, and how Rust has a zillion microframeworks but no Rails either, yet. Do we need one? What would it look like? That kind of thing.

> Node never really got a rails

I'm, admittedly, out of the loop when it comes to Node, but I do remember Sails looking promising when it was first announced. I recently suggested it to someone (who uses Node regularly) as a possible solution for a project we're working on and they'd never heard of it. So, between that reaction and the fact that I haven't heard of anyone else using it (or anything similar), I think you're right that a Railsy solution never took off.

Elixir is an interesting counterpoint, though. It seems like Phoenix was released and saw broad adoption very early on.

I'm wondering if this dichotomy is a result of where people are coming to these newer languages from: people writing Elixir probably aren't coming from the FE/JS world, but there's a very good chance people writing Node are. Prior to the somewhat recent proliferation of JS client app frameworks, using a smattering of libraries was a very common approach to solving problems. (It arguably still is, albeit at a different level of abstraction in React/Babel/Webpack land.)

Anyways, I'll be looking forward to reading the post you alluded to above, should it ever come together.

I really don't care for Rails' components. But I think you are right when you talk about this -- monolithic frameworks allow you to get all these decisions out of the way and simply get on with developing your project. How much benefit are you really getting out of spending the time comparison shopping a bunch of serialization libraries instead of just picking on and moving on? Unless serialization is somehow a core part of what your application does, the benefit is probably quite marginal.

but in ruby rails dominates all of these components massively

> You want an ORM? choose an ORM library. You want templates, choose a templating library. You want to send mails, choose a mailing library.

But I'd rather spend my time creating business value than researching ORMs, templating libraries and mailers. And since I've never not been able to accomplish something with the ones Rails includes by default, I've never seen the need to use something else.

I'm surprised to hear that a person can efficiently create business value without knowing the ecosystem of the language they are using. Without a knowledge of what exists outside Rails, how do you know you're not wasting time and effort? (Not to ask how you're going to get your next job.)

> Without a knowledge of what exists outside Rails, how do you know you're not wasting time and effort? (Not to ask how you're going to get your next job.)

So now you need to factor in research time. Then, continual research time, every time a new library or version of a library comes out. And if your research turns up that, no, in fact, version X or new lib Y is not substantively better (by whatever metric you're looking at), do you count that research time as 'wasted'?

> how do you know you're not wasting time and effort?

You look at the results of what you're doing vs what expectations were, firstly. You can then, periodically, look at your efforts, and compare reports from others who are claiming to do the same thing, and ... occasionally... spend time determining if a different approach offers radically better returns on the effort/results you have now. Switching to XYZ may also involve huge amounts of refactoring, upgrade, migration, etc. How do you know all that effort won't be "wasted" if new platform XYZ is abandoned 18 months from now?

"efficiently" doesn't necessarily mean "at maximum efficiency". Also, "business value" is almost always intertwined with hitting particular date/time goals, which often trump technical metrics.

Rails ain’t exactly new. It works pretty well for most things. I think most Rails developers generally stay abreast of large developments in the ecosystem, but the days where you would see significant benefits from being aware of every little library that comes out are long gone.

Yes, I agree that knowledge of the ecosystem is important to efficiently create business value. If I don't know that Devise exists and I roll my own auth library, that's a waste of time.

That's different than if I don't know that Sequel exists and I blindly use ActiveRecord. They're both ORMs. They can both read and write data from a database. And guess what — ActiveRecord is better for the vast majority of situations and everyone in the Rails community knows it, so my research into Sequel would have been time wasted.

Rails helps you avoid wasting time on this kind of stuff and pre-packages stuff that most everyone needs and where the alternatives are not substantively different.

And guess what? Let's say you have that file parser that runs faster in Go? Send that call from Rails to Lambda and bam! you don't have to worry about infrastructure either!

If you're building a CRUD app (most are), then any popular MVC (Rails/Django/Laravel/.NET MVC/etc) will likely do. If you're worried about "Twitter/Facebook/Google scale" when you're starting, then you're doing it wrong.

The world is filled with other people. IMO, the benefit you get from another person being able to immediately be productive in your codebase vastly outweighs any benefit you would get from hand picking an ORM, a mailer, a templating library, etc.

And, anyway, Rails is pretty modular; you can rip out and replace anything that isn’t to your taste.

The big value that Rails adds is that it eliminates valueless choices. Most of the time, which logging library, ORM, view templating language, whatever doesn't really make all that much difference in terms of effectiveness and essentially come down to aesthetics.

When working with a framework that doesn't make those decisions for you, you end up with two big downsides - you waste time and energy arguing over which of these low-value choices you want to take, and new developers take longer to come up to speed with your particular architecture, since they need to learn each of the choices and how they are integrated, whereas in Rails it's obvious where everything is and how it's configured if you're familiar with the framework.

Bloat is also over-emphasized, particularly for the backend. You'll load the gems in memory, sure, but they're a fairly small footprint on their own and it's not like Rails is calling the parts of the framework it's not using (save maybe middleware, although most of that is useful for most web applications).

A big benefit of how opinionated frameworks preempt debates about marginal issues is that it's an externally imposed decision, instead of one team member triumphing over the others.

It really helps team cohesion for DHH to tell you that you're using X instead of Y as opposed to the most domineering devs getting their way every time. In my mind this even compensates for some suboptimal choices Rails may make.

Choosing is much harder than it seems, and much more resource consumming. Then you have to integrate them. And of course test, maintain, document and update said integration.

All people I worked with that had your philosophy didn't so that last part, and it had important consequences for the whole project duration.

Every time - every single time - I have started building an application using Sinatra I have regretted not building it in Rails from the start.

I totally understand the desire for a minimal and clean codebase. If I’m not going to use 80% of Rails, why would include it, right?

But in practice, I have found there is basically zero cost to using Rails instead.

I agree, totally true even with some small trivial apps. The few places a Sinatra app have worked for me are highly specialized, single method and generally have been for performance reasons and could have been in any other framework due to them loading as SSI or AJAX call.

It’s been a few years since I’ve used Rails, but when I did, it always felt like within a year or two a new version of Rails would come out and I’d basically have to rewrite the site from scratch if I wanted to update.

I don’t know if the codebase has stabilized but the transition between 2.x to 3.x to 4.x was pretty rocky from my recollection. Hopefully it’s better, since Rails is probably the best framework to get a site up and running quickly.

Since v3 I’ve had no issues upgrading apps to the latest. As soon as a new release is available, I upgrade. V2 to v3 was pretty painful though..

Specifically the change in the default to escape strings and having to specify when you want to pass it through unsafely (html_safe / raw). Broke a lot of v2 apps, but ultimately I think it was definitely the right call. Same thing again when strong_params become the default. So mostly due to security improvements.

v2 -> v3 also was the merb merging and a pretty significant rewrite, so it's pretty impressive that we didn't have even more trouble IMO.

I've been using Rails since before 1.0 and the upgrade pain has decreased significantly over time. The worst upgrade I had was 3.0 to 3.1 where there was a performance regression that caused my test suite to go from 15 mins to about 8 hours on ruby 1.8.7, so I had to simultaneously upgrade to 1.9.3 at the same time. That involved YAML parser changes which I didn't catch before corrupting some serialized data in the DB.

Since that time both ruby and rails have stabilized their upgrades significantly. The biggest issue since then was updating to strong params, and that was only an issue for apps with a large CRUD surface area.

These days I think Rails is the perfect balance of stable and flexible for a wide swath of prototypes and apps. The areas where I'd look for an alternative would be web sockets, heavy concurrency (ie. needing more than background workers), or where raw compute is the bottleneck.

If you truly had to rewrite from scratch you did something wrong, the APIs are not vastly different.

> Every time - every single time...

Just thought I'd provide some counter data here. I've built small services in Sinatra, which did not warrant the usage of Rails and never had to change anything, having them in fully functional operation for years.

I could have built these little apps in Rails, but I did not need it, never did, and my code/deployment/etc. is cleaner and smaller because of it.

Also these services have always been quite small (a few endpoints or functions), which is what I think Sinatra is best for.

I second this. I use sintra for all those sites that are 75% static pages and few dynamic parts here are there and could not be happier.

Non optionated means that I can really easily setup the model that I want/need without having any framework in my way. Love it. One caveat: I am a senior engineer 7+ years of experience. I would not have been comfortable having to do those design choices earlier in my career and Rails would have been better suited then.

I still love Sinatra for back office and API stuff where you don't need to worry quite so much about authentication, exploits, web assets, permission hierarchies/matrices etc.

At the company I used to work for we built our invoicing system's API with it and it was fantastic, plain succinct Ruby with Sinatra, Sequel and not much else.

For public-facing apps that require signup, clever routing, image uploads and other non-trivial functionality, Rails definitely makes more sense.

Exactly.

I think the answer to 90% of these "framework A vs. framework B" discussions comes down to "use the best tool for the job".

For readers interested in a contrary anecdote, every time I've used Sinatra based frameworks, such a Express or Nancy, I've thought without a doubt it was the right choice over something MVC based.

The simplicity of these frameworks allows arbitrary changes with minimal friction, patterns, restrictions, and other people's opinions, i.e. conventions.

I think that's totally valid. As web applications grow you run more and more into the need for new features and the need for common solutions, things that Rails already give you. For example, when I wanted to try out jRuby for an application of mine, one point that made that impossible was the existing usage of the sqlite gem. Had I used activerecord I could have moved it over to the jdbc api with a simple added gem, Rails would have set me up for that solution. Or locales: The construction I added into my software basically re-implements how a Rails gem is used.

But that's also the value in it: After you constructed a big enough Sinatra application you understand why and how Rails is doing the things it does. I think that's very useful.

Same with flask and django. And the worst is that the flask version is often riddle with security holes (not flask's fault) that would have been prevented for free.

I actually always say that despite the apparent easiness of the micro framwork hello world, you have to actually be very skilled to use them correctly to do anything beyong a few pages. While a full feature framework will make a beginer produce a decent work by default.

What sort of security holes in Flask are you referring to?

Maybe that it doesn't sanitize the user input, but calling that security hole is a bit of a stretch. Sure you have the freedom to use some insecure libraries with flask but the same could be said about any framework.

Django protect you out of the box of xss, csrf, and click jacking while providing you with a proven robust extensible auth mechanism.

When using flask, you have to be able to make decisions about those. Many devs are not able to.

I'm ok with it: not everybody has to be an expert to be a great element in a company. But flask gives those profile a false sense of easiness.

Have you ever written a flask app yourself? It provides identical protections against xss etc. that you mentioned, as well as an auth plugin and tutorials on doing auth right... I think it's unfair to spread a negative opinion of Flask because you had to work on an app that used it badly.

I have seen a fare share of terribly written django apps, riddled with security holes that weren't so obvious at the first glimpse.

> But flask gives those profile a false sense of easiness.

It allows you to prototype very fast, not everyone needs nor wants the hand-holding that django provides.

Don't get me wrong I think django is fantastic at what it gives out of the box but saying that flask is insecure is just fud.

Also - try Pyramid, you'll never know when it suits your needs https://trypyramid.com/

They didn't say there are holes in Flask, but that the Flask version of an app is more likely to contain holes (presumably because you're less pushed into safe defaults).

Not flasks. Flask users code. The last flask app I worked on had a custom auth scheme with md5 hashed passwords.

You see because flask is so minimal, many beginers use it for an easy start, only to rewrite square wheels when the project gets real.

There are situations where Flask is good enough and very fast to deploy, while Django is overkill and more complicated to set up.

I agree that, should a system get significantly complex, eventually you will want Django; but a lot of projects simply never get there. That's why it's good to have a choice anyway.

Anything that requires auth or database access requires setup that a lot of dev will get wrong.

E.g : sqlalchemy sessions are very often badly handled. Of course you could write sql by hand, but then you loose the entire ecosystem of blueprints.

> you loose the entire ecosystem of blueprints.

Blueprints for models?

Yes. E.g : sqlalchemy admin.

Lately, I’ve used Flask with Connexion, JWT, SQLAlchemy, and Alembic did my microservice APIs.

Relatively few lines of code that comes with validation, API playground, and defined routes plugged in via the swagger doc.

The main I ssue is having a nice admin page, tbh. Flask doesn’t have one like Django but eh. Good enough I suppose.

There's Flask-Admin[0] which I found really useful.

[0] https://flask-admin.readthedocs.io/en/latest/

I completely agree! I worked with Rails 2+ years and it was really comfortable that everything I needed was at hand at the moment of scaling the application with new features or requirements.

After that, I needed to make some microservices orchestration and NodeJS (using Koa as the HTTP server wrapper) was a better tool to deal with all these asynchronous tasks.

But: Routing? Parsing JSON? Storing files in S3? Dealing with databases? Serve some static assets (e.g. Swagger)? Up to you! And good luck finding the up-to-date and standard library for your needs.

Overall, using workers, doing asynchronous tasks (e.g. starting a thread after hitting an endpoint) and coding orchestration endpoints (e.g. GraphQL) was a enjoyable experience where you have almost full control of what you were doing, but I still miss those days working with Rails where the community was so helpful in finding a friendly path to dealing with some common problems. My impression is that it feels less fragmented overall.

I haven't found myself an ORM as good and expressive as ActiveRecord or Sequel. Overall I think it has to do with all the metaprogramming tools you have available on Ruby. That's something amazing to deal with cookie-cutter problems, but also a problem when you need to do more granular control or get out of the typical CRUD problems.

My rule of thumb...

ORM, sessions, auth, administration, form validation, template rendering, API infrastructure, static file management, RSS feeds, ...

If you think your service will ever need more that 2 of these, use a framework. These will integrate well with each other and save time.

I have worked on a lot of ugly rails apps that would of been infinitely less painful as a thin Sinatra app.

Use the solution to fit your problem. Microframeworks for small composable problems.

For some reason rails devs see it as the hammer for every nail, screw, bolt, pipe fitting and joint.

Rails might not be perfect, but there's a 95% chance it'll be better than the custom framework you end up building on Node.

Is the holy grail of minimal enough to stay out of your way but maximal enough to handle all the common app needs really that difficult to reach?

> If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly.

I have developed very nontrivial applications with Modern, which can be thought of as Sinatra-like, without regretting the choice or without implementing a bunch of Rails things. The web application is an immutable spec and defined as such; state is offloaded to dependent services pushed into your HTTP action handlers. Done. But, then, in 2018 (or 2016 when I started its predecessor), "an application" no longer required bashing into it ERB templates or the like, so I'll grant that it's a little easier.

https://github.com/modern-project/modern-ruby

That said, in the Node world I do use Hapi over Express, as it conforms better to the way I think about things.

Copy from my previous reply

This is pretty amazing. Both GitHub and Shopify are huge, billion dollar companies running on the original apps made over a decade ago. And they now both on the latest Rails, helping to push the framework forward [1]

I can't wait for y'all to see what we upstream now that we're in a position to give back and improve Rails. My keynote; Rails 6.0: Scalable by Default [2] at RailsConf was just a small portion of our plans for Rails. [3]

There are also work from Discourse on Rails performance, Ruby is getting a Method JIT. [4] and working on more pref work. TruffleRuby is close to 1.0 and it is available on all ruby manager [5]. The Open Source build is now also available on macOS as well.

There are lots more, and all of them were years in making, It took a year for Github to get to latest Rails release. For the past few years, many have been writing off Ruby Rails, Ruby is comparatively expensive to scale ( and it still is ) , we expect other frameworks to catch up in terms of productivity, and will spell doom to Ruby Rails. Not only has such framework yet to appear, Ruby Rails continues to improve on all front.

I say the best days of Ruby Rails has yet to come.

[1] https://twitter.com/dhh/status/1030528476250562569

[2] https://speakerdeck.com/eileencodes/railsconf-2018-the-futur....

[3] https://twitter.com/eileencodes/status/1030461847256875008

[4] https://twitter.com/k0kubun/status/960112559343878144

[5] https://github.com/oracle/truffleruby/blob/master/doc/user/r....

Would you consider laravel to be that framework that allows rapid development increased speed and provides an easier way to scale.

Based on the following benchmarks, Laravel is slower than Rails. But still, both frameworks are much slower than .net/java/erlang based frameworks.

https://www.techempower.com/benchmarks/#section=data-r16&hw=...

FWIW those benchmarks are inconsistent. Usually it’s a matter of optimizing for direct calls to C libraries.

Laravel is a Rails clone written in PHP.

It started off as a clone but has it surpassed rails?

In what way? What is your metric? Laravel is slower, has less support in the community and uses PHP.. It also lacks webpack and SPA capabilities which are already baked into Rails. So in my opinion Laravel is actually behind.

Laravel comes with Laravel Elixir and it uses webpack2 since version 5.5.

Both frameworks have huge communities. The laravel community has seen a huge growth lately. I'm not sure it's an advantage anymore. In fact the popularity has grown in favour of laravel. https://www.netguru.co/hs-fs/hubfs/image1-4.png?t=1535725104...

Comparing php to ruby php is clearly faster https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I get the feeling that laravel has surpassed rails.

That’s cool, didn’t realize that webpacker was built in. How does Laravel handle SPA functionality? Is there a Turbolinks equivalent as well?

Just did some quick Googling and looks like there is a Laravel port of Turbolinks. It certainly does look like they’re catching up. Surpassed? Not convinced.

"catching up" = copying most of what Rails is doing, not innovating or having any original ideas of their own. That's not really a sign of a strong community, and people working in Laravel might start asking themselves why not work with the real thing instead of a clone.

You want Webpack bundled with your backend framework?

...Why?

AFAIK anyway, Webpack isn't automatically installed with every Rails app but is easily available via https://github.com/rails/webpacker. So it's not "bundled" necessarily all the time, but is quite trivially added to a Rails project.

If your question is more like "why the hell would you ever want to run Webpack and Rails simultaneously together":

You will increasingly find tools you want to use that more-or-less require Webpack (or a similar JS build tool). Because of things like e.g. the asset pipeline, it's extremely frustrating trying to get those tools to work in concert with each other as micro-services that know nothing about each other. It's much easier to use something like Webpacker so they can play nicely with each other.

I assume Rails in this case would be used in the “full stack” sense with an asset pipeline for frontends as well, instead of the Rails API-only mode.

Rails can be used without the asset pipeline and with Webpacker only. But yes, most likely you will not use API-only mode of using the asset pipeline or webpacker.

I get the idea, it just seems like a very "2013" way of doing web development. Things have moved on past the monolith for an endless amount of reasons.

endless amount of reasons, such as?

I used to believe the same as you and wrote quite a few web apps with dedicated backends and frontends. The overhead and amount of redundancy doesn’t seem worth it to me anymore though and I’ve turned to hybrid apps. Development time has dramatically improved and I’ve lost literally nothing.

It’s a great approach for hybrid web apps. I didn’t want to go with a React only frontend where routing is controlled by react-router. I’ve opted instead to leave the routing to Turbolinks. This has a number of advantages. I get the benefits of an SPA while still being able to render server generated Rails views. This frees me up to use React only where it’s advantageous; like on real-time super dynamic views. I have multiple React entry points and the data is tied together by a shared Redux store. I’ll admit this was not trivial to setup but it’s been working great.

The Laravel community and projects/products that are part of it are very attractive from a small business POV, everything seems to work well together, knowledge is transferable.

You have Laravel for web apps, the Statamic CMS for blogs and content heavy sites, Jigsaw for landing pages, Maizzle as email framework, all using tech and conventions that Laravel devs know. On the frontend they promote Vue and Tailwind CSS across the board.

They actually make it possible for smaller shops or freelancers to have everything under their control. It's basically like a polished Wordpress ecosystem.

I would say no. PHP currently has a speed advantage, and it may be easier to scale, and the Psy shell is a very comfortable REPL. However, PHP as a language is somewhat restricted in meta-expression, and the syntax is clunky by comparison. Laravel borrowed a lot of Ruby's Enumerable library, but there are still things that you will miss. Symfony and the Active* ecosystems are probably comparable? I feel like when I'm following the execution of something in Rails, I end up reading a lot of two-line methods whose purpose is not at all apparent from context, and in Laravel, I miss the ability to do absolutely anything in a single line of code. Both languages have pretty comparable web libraries. The Laravel ecosystem is newer, it's slightly less likely that a given package will exist, and it may be buggy. The Rails ecosystem is more mature, it's slightly less likely that a given package will be maintained, and it may be buggy. PHP is almost exclusively targeted at the web, and Ruby is slightly more general-purpose.

If Ruby/Rails is an option, you're sort of baking into the comparison the idea that being expressive at the cost of performance is an adequate tradeoff. Ruby is going to win over PHP on that metric every time. In general, trading performance for expresssivity tends to be good; Rails has succeeded in spite of its performance, not because of it.

I have been thinking about this quite a bit. Just so happened one of my favourite site was redone in PHP Laravel as Backend and Vue.Js. And they did the whole thing in less than two weeks! I than checked out larval, and I have to admit PHP Laravel is the closest thing to Ruby Rails in terms of productivity.

[2] is broken, should be https://speakerdeck.com/eileencodes/railsconf-2018-the-futur...

Thx and [5] too. Didn't realise it shortened the link on markdown and I just copy it directly over.

[5] https://github.com/oracle/truffleruby/blob/master/doc/user/r...

I wonder if microsoft will rewrite github with c#

It could also switch to React, since the MS Office team has switched over to it for the online platform. [1]

[1]: https://react-etc.net/entry/microsoft-office-rewrite-to-reac...

React is an in-browser component/templating/state management framework. Apples to oranges.

Furthermore, I don't see GitHub as a great application for an in-browser state management system. Rich state frameworks are great when you're making an system with a real load of state in the frontend. For example, a spreadsheet or a rich word processor or design layout application. For an application with little mutable user state in the frontend, all you do by using a full-on UI framework is add complexity and introduce a huge state-synchronization / distributed systems problem, as well as introduce the need for complex/hacky server-side rendering workarounds for users, snapshots, and search engines which don't have full runtime capability. Using React on your blog is almost certainly a mistake and using React for GitHub feels like it's right on the edge of being one as well.

They were probable referring to the web implementations of office, it's the only interpretation that makes sense in my mind. Were you aware there was an online version of office?

Highly unlikely. That would be a massive waste of resources.

It wouldn't be the first time though, I seem to remember they got bogged down in migrating HotMail after they bought it.

Disclaimer: I've worked with but dislike ruby and rails in comparison to other choices (whether language or ruby framework).

IMO people are still using rails because a bunch of orgs moved to it from Java years ago, or started with it after some successful hackathon. It's in wide demand because a large number of orgs mindlessly (or mindfully) chose it long ago. Basically all enterprise/large company apps I've seen have been in either Java or Rails. Some places are still using COBOL. Some places are still maintaining/starting codebases in COBOL. I assume that people will be able to make this same argument about NodeJS in ~2-5 years.

Also, the the point about micro-frameworks being bad being made in the comments because you eventually re-implement rails seems to be wrong or badly articulated -- that's exactly the point of using a smaller-yet-composable tool, you don't use any parts until you need them. Sinatra has also leaned into this by allowing pieces of rails to be loaded, and providing a path to transitioning to Rails proper.

I dislike rails because there's too much magic, and too many ways to do things -- it's precisely why I like micro frameworks. Also, the (request, response, next) middleware/handler paradigm is the most composable way to write server software I've ever seen.

There's a little big detail w/r/t java comparison: every company I've personally worked with who uses rails for their backend vs java moves WAY WAY WAY faster. So in terms of the "enterprise stack" dichotomy, there is a difference in kind between rails/java.

I get things done faster and more maintainably (for future me and other devs) when I do it in rails. Hopping into apps that rely on (request, response, next) always hits me with a learning curve every single time I come back to em, which gets worse as complexity rises. It could also be that I'm very bad at thinking in terms of pipes and need to practice that more.

I also find that in rails, there really aren't _that_ many ways to do things. And, in general, apps that age gracefully always figure out how to phrase their domain concepts through the smallest restful url's/resource mappings they need. There's a lot to be learned from the approach the smaller micro frameworks take, and you can get the best of both worlds in a lot of ways.

And there are some companies where you need to move fast while at the same time need to have high performance (100.000 req/s with 30-50 ms mean latency). In that case Java is the only option between Rails amd Java.

The gap between Scala + Play and Ruby + Sinatra (or cut down Rails) is not like it was in 2008. Ruby 2.5 is ~13x faster than Ruby 1.8. Now you're lucky to squeeze 3x the web throughput out of a Java/Scala service as opposed to CRuby and JRuby closes that gap further.

Can you point to me any performance site where Ruby 2.5 + Rails that backs your point? If you use JRuby than you are on the JVM already. In that case why Rails at all?

In terms of pure Ruby performance, there's a semi-official non-trivial benchmark called optcarrot. Ruby 2.4 is 14.3x faster than Ruby 1.8.7 here: https://github.com/mame/optcarrot/blob/master/doc/benchmark....

Rails performance relative to JVM+Scala+Play is tricky to measure but the closest thing to a decent benchmark I know of is this: https://www.techempower.com/benchmarks/#section=data-r16&hw=...

My own experience at ChartMogul with building production services in Ruby, Go and Rust is that the overall throughput of REST API type services increases a disappointing amount.

With JRuby you get to retain all the benefits of the Rails ecosystem. Most of the Go and Scala community is driven by much larger companies who do open source libraries but they don't really build frameworks to help developers build software quickly.

I’m not seeing how your complaint that there are too many ways to do things in Rails leads you to using a micro framework. Since Rails makes a bunch of choices for you ahead of time, there should be less ways to do things in Rails vs a micro framework.

I don't really have an exact example for you -- the last corporate rails codebase I touched was 2 migrating to 3/4, and the last rails guide I saw was 4 (rails is on 5 now?)...

I did a cursory google search and found:

https://stackoverflow.com/questions/29697787/rails-call-same...

More generally, my point was that smaller libraries have less space for multiple ways to do things/overlapping concepts. In the codebases I've worked with, I've found myself questioning whether to use one specific rails concept or the other and the resulting "right" choice seemed arbitrary -- like whether I should make a controller mixin or create a helper.

For example, if you look at a framework like sinatra, the smallest/simplest thing you use to respond to a request is just a function. How to use functions properly is pretty clear, there's not much else to debate over.

People that have the skills to pull off a complex site __correctly__ with just a micro framework are rare and expensive.

But people that can do it and make it easy for the team to scale are unicorns.

I've yet to meet one that stays on this kind of missions for long because they get a better offer, leaving the custom project to people without the skill to manage it.

And if you think all that is easy, you are not that unicorn because you don't have a perspective going beyong your code files.

I’d just like to chime in that myself and the other rails developers in my company use rails because we love it (in addition to it being the right tool for the job). I personally find ruby a beautiful language and using it every day makes me happy.

I didn't mean to say that no one uses rails because they like it -- I fully understand that rails was not only caused a watershed moment for web development (particularly server side), especially when what came before was java in large part. Also, having survived perl I've never seen a "scripting" language handle flexible syntax/paradigms as beautifully as ruby has -- it is certainly a beautiful language.

I think the increased productivity, beautiful language that rails is pushed everyone in the right direction, I just personally think stopping there is a bad idea, and that while rails is great it's not necessarily the reason it's in widespread use.

I didn't see any mention in the article of comparing install rates for rails versus other platforms (since of course this info is hard to get) -- and there are tons of rails-ish software out there (django being a huge one). If django had been the thing to break through and rails came after I think the roles would simply be reversed.

> I dislike rails because there's too much magic

This was a common complaint about Rails years ago. What are the "magic" parts in current-day Rails that you dislike?

(I disliked the dynamic finder methods, e.g. find_by_city_and_state, which you would now do using arguments to where(). I also disliked the default routing which made every public controller action routable, if I remember right. Those are now either deprecated or removed.)

These days I don't really work with rails codebases, so I don't have any recent examples in mind to call upon. There's just a bunch of stuff you need to know about how rails works before you can successfully read/understand rails code -- I just remember seeing all this stuff in code and I was just thinking "where the f did this come from", and then realizing that the version of rails we were on had this feature that tied together these two parts with some obscure method.

I haven't even looked at Rails 5 or worked in a recent Rails 4 codebase so I'm sure things are much better but the code I remember the feeling of being perplexed so often at how a worked in previously wasn't my own so I can't go back and remember what parts really made me angry.

How is that different from any new codebase you have to look at? If anything Rails reduces the confusion because it has a set of agreed to conventions. I can’t think of any decently complex codebase I’ve ever come across that didn’t have it's own weird abstractions that aren’t immediately clear.

Disliking Rails’s built in abstractions seems to come down to only liking abstractions your own devs created which sounds like not invented here syndrome.

It's more which tools are used to make abstractions -- I find that rails uses and encourages implicit (auto-created methods, stuff injected into a method's scope) abstraction creation rather than explicit (functions/higher-order functions) abstraction creation.

Interesting. I've honestly never heard the complaint about "magic" and abstractions made so concrete. I still believe many of auto-created methods are a good thing and generally done with the thinking that if you do X in 80% of cases the same developer also wants Y. Which makes perfect sense to me but I can also see how that would be surprising and/or annoying.

“And Phoenix would be the Rails to Erlang's Ruby (Elixir). The learning curve is steep, you will need to learn OTP. Which is probably why adoption lags."

The author has no idea what they are talking when it comes to the alternatives.

I was making simple CRUD apps in Phoenix (the types of apps I would normally use rails for) for a year before I even looked at OTP. You can become productive in elixir and Phoenix very quickly especially if you come from a ruby/rails background.

I recall a blog post by dockyard where they said they had new hires making commits within the first week.

The author isn't wrong. You need to learn OTP to know that you don't need it (at least in the very beginning).

When I was learning Phoenix, I spent a substantial amount of time learning Elixir as well and OTP is one of the first few things they put in front of you. Don't get me wrong, I loved learning about it personally, but I am not surprised that a lot of people would consider it too much effort.

> In summary, we 'still' use Rails as it works just fine.

PHP works fine. COBOL works fine.

Nobody ever said Rails doesn't work. Or doesn't work fine. That's a straw man.

It's just that Rails, and Ruby in general, is in clear decline. Not just because some new flavor of the month frameworks are coming out, but because a lot of the concepts Rails supports are antiquated, and Rails hasn't shown to be that adaptable to more modern front end trends after years of efforts from DHH.

Hell, I'm sure that even DHH himself would be very upset if people settled for something that "works just fine". He's just not happy that this time around, that characterization is being used to describe his creation.

How do you figure Ruby in general is in decline?

Not the person you asked, but it does seem like there was a drop in popularity over the past 6 months (according to TIOBE):

https://www.tiobe.com/tiobe-index/ruby/

> because a lot of the concepts Rails supports are antiquated

I actually see Rails as a framework that has managed to keep up with the times better than most. Django, for instance, has aged less well than Rails imo.

What alternative exists that’s better than “fine”? All of the popular framework options have major cons/arguments against. It’s almost as if some of the choices we make when picking software development ecosystems are subjective.

1) "a lot of the concepts Rails supports are antiquated" ...

2) "Rails hasn't shown to be that adaptable to more modern front end trends"

Would you mind elaborating? What Rails concepts are "antiquated", and what "modern front end trends" does Rails not adapt to?

I've never done any Rails development, but understand the general idea of how it works, so I don't have any skin in the game. I'm just honestly curious about what you were referring to.

I imagine SPA trends with frameworks such as Angular are leading to the parent’s conclusion. However, you can still use SPA frameworks and just use Rails as an API, or you can take a step back and realize a large percentage of web apps still don’t need a complex SPA framework and might get enough front-end functionality out of something like Vue. In other words, many developers fall into the trap of choosing tools they prefer even when they may take more time to use and not provide enough business value. Plenty of web apps would ship faster if built with Rails and be just fine.

>a lot of the concepts Rails supports are antiquated

Can you provide some examples? Rails is quite forward thinking when you consider Action Cable and upcoming Active Storage.

As much as I like Rails, those are two examples of catching up. The approach from Active Storage has been the way uploads should have been handled for over a decade and Action Cable is good-enough-for-prototype but otherwise not scalable at all.

Over a decade? That long ago, we were storing image uploads in a BLOB column in Oracle! I used Heroku, AWS and GAE within a year of each of their debuts, and if I recall correctly, there weren't a lot of frameworks that had a handy dandy approach to generically storing uploads in <XYZ-CLOUD>. Were there any even?

And as for Action Cable, I hear anycable.io can give you a performance boost if you need it. I've used websockets in both Node.js and Java Spring and although it's awesome for some use cases, a majority of apps will never reach for it. So this is a good example of Rails focusing on things that will help most people without trying to cover every tool that everyone will ever desire.

This is still sort of the mainstream view on this, but I think a return to monolithic Rails-style frameworks is coming. Microframeworks and especially Node got a lot of popularity, and then all the microservice stuff started to get popular and overused as well, and ultimately this is leading a lot of people to do unnecessary work and ending up with a custom solution that isn't as good as what they could've had off the shelf.

As for modern front end trends, Rails is getting better in this regard, especially since 5.0. Most people typically have a separate frontend and backend codebase anyways, so in that sense Rails API is all you need, and that's baked in now.

> It's just that Rails, and Ruby in general, is in clear decline

[Citation Needed]

In my experience the demand for rails has only gone up within the last few years and rails is only getting better.

> Rails hasn't shown to be that adaptable to more modern front end trends

You clearly haven't been keeping up with rails .. Rails now integrates seamlessly with React, Vuejs,.. and has built in support for yarn and webpacker .

In addition, with the introduction of ActionCable, you can have websocket integration as well with Pub/Sub.

All in all, Rails remains a very mature, robust framework to build your business on.

https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F050...

Not apples to apples but I don't see the decline in Rails. I would say that I definitely see fewer job postings for Rails work overall and more for separate backend and React work.

There's a better chart here for sites using RoR: https://trends.builtwith.com/framework/Ruby-on-Rails

For comparison here's the one for express: https://trends.builtwith.com/framework/Express

From conversations with an experienced PHP dev who was recently looking for remote opportunities, all of the good and high paying options were in Ruby.

PHP suffers from an abundance problem where programmer opportunities are concerned. There are a lot of “PHP” developers with skill levels that are highly variable, from Wordpress devs to really hardcore programmers.

This is very true as a php developer myself I notice that there are a lot of low pay wordpress jobs available to php developers. At the same time you can get more serious jobs with equivalent pay as other languages in php but there seems to be a lot more competition for them.

I'm waiting for a framework that covers the whole stack and also makes it easy to make SPAs, if you wish. When that arrives I think it'll really take off.

For a while Meteor seemed to be that framework, but for a number of reasons — performance issues, lack of support for SSR - it hasn't taken off. While it's often good practice to separate the API and the frontend, for solo developers or small startups that's often overkill and adds complexity.

Or - get 90% of the benefit of SPAs but leave your business logic where it belongs (on the server). PJAX/Turbolinks/Intercooler or something similarly lightweight is probably all most people need when they reach for full-fat front-end framework.

Yes, for personal projects I've moved away from SPAs to backend frameworks and as little JS as I can get away with. I admit I don't know how easy Turbolinks or PJAX are. A while back when i played around with Intercooler in Django it wasn't seamless.

Turbolinks and PJAX are really what a lot of folks wanted before the web development community at large was introduced to client-side routing through SPAs post-Knockout.js days.

Django plus DRF?

DRF is nice, but what I'm looking for is something more radical where the frontend and the backend is more integrated. The way it's done now data structures are duplicated. Of course this has to do with how things are done with REST over HTTP. Meteor actually implemented their own websocket protocol -- it's ideas like that I'm looking for.

Of course you risk making monoliths with this approach, but like I said I'm primarily looking for something that makes it easy for solo developers or small teams.

Correct me if I'm wrong in understanding your wish but I believe the answer to your prayers is: rails!

It ships with webpacker and can generate a scaffolded React, Vue, or whatever-you-want app.

Imo Rails is currently the fastets most conevenient framework to develop in because of its comprehensiveness and maturity. But what I'm looking for is something more radical [copying my comment below] where the frontend and the backend is more integrated. The way it's done now data structures are duplicated. Of course this has to do with how things are done with REST over HTTP. Meteor actually implemented their own websocket protocol -- it's ideas like that I'm looking for. Of course you risk making monoliths with this approach, but like I said I'm primarily looking for something that makes it easy for solo developers or small teams.

I built a huge SPA application that is real-time connected by web sockets (Turbolinks which is included in Rails) with Rails. I did it in 3 months, alone. Hired our first engineer and we can tackle pretty much anything that comes up. I think Rails has worked incredibly well for a small team. The addition of webpacker allowed us to use React where it makes sense and Rails views everywhere else while Turbolinks holds it all together. Rails is the framework you describe.

You don’t really duplicate that much between server and client. Yes, you have models on both. But the models do different things. Server is all about validation and querying a database to generate responses. Client side is all about user interaction.

Meteor kind of has this vision, but it's not that popular anymore

You might be interested to look at Drab in the Elixir / Phoenix ecosystem. It takes advantage of the lightning fast view layer of Phoenix as well as Phoenix Channels to manage everything.

Approaching 1.0 it’s the most unique approach to the problem I’ve seen.

That is certainly interesting.

We’ve all seen the video where the Erlang guys live update the code on a telephone switch without closing any of the calls that are on-going.

Elixir runs on the Erlang VM.

Does Drab support hot code reloading? Does it handle modifications of templates without breaking existing client sessions?

That’s a good question. I haven’t played with it enough to know, just been watching from a distance til it hits 1.0.

Not an expert on this matter but I'm pretty sure it doesn't mess with that particular base feature of the programming language / runtime.

Drab is a hex package, so asking if it supports hot code reloading isn't the right question. As to the second question, the answer is yes assuming your server side hot code didn't break the client session, and didn't introduce an API mismatch.

I had the impression that time is in the past.

With Node+NPM you basically can take what you need and leave these bloated things behind.

But I have to admit, I've worked on many projects where devs build their own bloat with many small modules.

I try really hard not to use too much third party stuff, but am happy that I can easily add them if needed.

The whole Rails ethos is about admitting that your app isn’t really special and that what you’re doing is pretty similar to what everyone else is doing. So it’s better to decide on the best way to do things as a community so you don’t have to roll your own framework.

Somehow I had different experience. 50% of Rails was solving what you said, but the rest got harder because of all the constraints.

FWIW, my experience is different. I spend almost no time in Rails doing anything other than implementing the business logic that is unique to my app. But I’m a go with the flow kind of a guy.

You achieve the same thing with Rails and Turbolinks. Watch this presentation by Sam Stephenson to see what I mean.

https://www.youtube.com/watch?v=SWEts0rlezA

It has a high learning curve and basic tooling support but servant + miso (Haskell) allow you to share code between back and front-end.

https://github.com/FPtje/miso-isomorphic-example

Never tried it out - but Ur/web [1] sounds interesting.

[1] http://www.impredicative.com/ur/

Meteor dropped the ball so hard, it's a net loss for the world!

If only they had come out with routing baked into the project, and react baked in. They would have survived. None of this "we support 29 different routers but zero documentation on how to integrate it with meteor."

Now it's dead, used only by legacy apps or tinkerers. No real mass use applications are being written with Meteor these days.

I agree, it's a pitty, Meteor could have evolved to something very interesting.

Spring Boot. It has monstrous enterprise horsepower, supports many deployment models, scales horizontally and vertically, easily configurable as REST or MVC with built-in views or both concurrently, can be bootstrapped in 30 minutes.

We still use Rails and it's a good fit for getting projects off the ground quickly and validating ideas. It's a niche but it's an important niche.

Once Rails projects get beyond a certain size though they start getting exponentially more difficult to maintain. My sense is that Node is going to surpass Rails by sheer brute force eventually. When I work in JS now I'm just amazed at how much better the tooling and performance is than Ruby and ES6/7 is overall a pretty nice language to work with. And having something like Typescript is essential once a codebase gets big enough.

JS tooling better than Ruby's? Care to elaborate? Which Node.js framework comes anywhere near the productivity of Rails?

By tooling I mean things like code editing, linting, type checking, debuggers and runtime quality and performance. As far as I can tell Rails is still a lot more polished than any JS web frameworks.

The flowchart usually goes like this:

- Oh wow this framework looks great I wish rails had that. I am gonna try and use this when the opportunity arises

- Aha this is the perfect project for that framework I saw

- hmm how do I do... Oh. Well I guess I'll just build it myself.

- This plugin is the equivalent of paperclip, perfect! Great DSL, great documentation. Hmm what is this error. 3 hours later github issue time.

- Turns out this wasn't the right project for me to try out this framework, maybe the next one.

- Oh rails n+1 is out can't wait to try it

>>And Phoenix would be the Rails to Erlang's Ruby (Elixir). The learning curve is steep, you will need to learn OTP. Which is probably why adoption lags.

You don't need to learn OTP to become productive in Elixir/Phoenix. It's abstracted away from you, but also gives you the ability to dive in if you want/need.

Agree. You don’t need to learn OTP to use Phoenix anymore than you need to learn the entire Java ecosystem to use Kotlin.

Erlang has been around for 30+ years...there’s a lot. Doesn’t mean you need to use it all.

I think it's disingenuous to say you don't need to learn OTP. You need to learn the basics of it, or you will struggle, because you will be trying to solve problems in a way that doesn't fit with the underlying language and runtime. That said, learning the basics of OTP is super easy, and can be done in an afternoon (spawning processes, sending messages, supervision, understanding what applications are in Erlang/Elixir parlance).

It's like saying you can build a Rails app without understanding classes/objects - sure maybe you could throw something together because the tools are so friendly, but you would get lost pretty quick when trying to do something on your own. Learn those basics up front, and you can get a long way without having to delve into more advanced topics.

Basics, sure. I think you learn the basics just to learn Phoenix though.

One of the biggest and often overlooked features of Rails is rspec and db:migrate. For whatever reason, I have yet to find alternatives in other frameworks that have matched the elegance of these 2 indispensable tools.

Similarly, while I'm not a huge fan of ORMs im general, ActiveRecord is pretty hard to beat pound for pound.

People take for granted that Rails provides the closest thing to Aspect Oriented Programming that exists today (that I know of).

I don’t use rails regularly anymore, but I used it long enough to appreciate what it gives you. As long as developer efficiency and time to market is more important than than micro performance optimizations, Rails and other options that emphasize developer efficiency will continue to succeed.

Unless you’re in an established enterprise environment, that is generally going to be the story.

>And then there's the Phoenix framework. Chris McCord wanted this MVC framework for Erlang, where Elixir is based on Erlang, used mostly for large scale backend systems. And Phoenix would be the Rails to Erlang's Ruby (Elixir). The learning curve is steep, you will need to learn OTP. Which is probably why adoption lags."

This is false, you do not need to know OTP to be productive.

These days if I'm forced to work with Rails, I almost always write functionaly-kinda-ish Ruby code. Elixir sold me heavily on the idea of one input in, one input out and all the other good that comes from functional programming.

I probably no longer write idiomatic Rails code (40 methods in a ruby model).

I commented elsewhere already, but you do need to know _some_ OTP to be productive. But those basics (processes, messaging, supervision) can be learned easily in an afternoon.

In my opinion, OTP is not the reason why the learning curve is steep. If anything, the learning curve is steep for those trying to switch from something like Ruby to a functional programming language for the first time. A language with immutability as the default, no concept of classes or objects (though viewed through the Alan Kay lens, processes could be seen as "true" objects). If it is your first FP language, most of one's object-oriented experience is not going to help, so there is a lot to absorb before you even get to Phoenix or OTP.

You don't need to know _any_ of these to build a fast, working, business-helping CRUD app.

processes, messaging, supervision

In 2007, Rails was the hot new fad like Node.js became a decade later. Now it’s the boring legacy app, like Java was in 2007 and Node.js will be around 2020. Looking back, all this effort now seems like mostly-pointless reinvention.

You have to remember how people were writing web apps in 2007 in order for this to be contextually correct.

Yeah, I guess I should have written about Perl or PHP rather than Java.

Spaghetti code is no fun, but you can still write that same style today in .erb files.

I'd like to say that Node.js has staying power mostly because of JavaScript, but I'm seeing Go pop up here and there.

No one avoids Ruby/Rails because it's old, we avoid it because it locks you in to conventions that most other modern languages / frameworks considered bad practice, like magic, metaprogramming, one process per request, locked in to OO, the concept of "controllers," separating templates from view logic, and doing everything at runtime.

I can see how some of those things could be controversial, but there are quite a few popular tools out there that do everything at runtime. Also, didn't know most frameworks consider "controllers" to be bad practice. And since when is it so terribly harmful to separate templates from view logic?

That, and generally ORMs are out of practice as well. Using rails without ActiveRecord is almost pointless to me.

Even when I was programming primarily in rails in it's hay-day (2010 - 2013), I was always swapping out my inefficient AR queries with just custom SQL. I am generally a "performance doesn't matter that much" kind of guy, especially when people try to micro-optimize, but one place it matters a lot is with your data. These days I just go straight for SQL and save myself a lot of trouble. There will always be impedance mismatch between your data store and models, and ORMs in their ambitious attempt to serve every use case, at times, generate some really inefficient queries. ORMs really like to stay within relational SQL databases as well, with half-baked support for a couple NoSQL stores like Mongo, but then get into Cassandra or Dynamo territory and they are useless.

The usual amount of snarkiness I've come to expect from the Ruby community. What a smarmy tweet: "Lol 20 something developers using new tools when they could just use this ancient slow dynamically typed OO language I allied myself with doing the exact same thing 10 years ago"

Ok I'll bite:

- Because it had it's milkshake drunk by nodejs which has better support for modern front end workflows and great languages like typescript built in top of it. And is faster and better supported.

- because it's slow and difficult to scale

- because it has years and years of baggage

- because I prefer elixir it golang or rust or Scala

- because it's not a perfect fit for every project

- because I do not like stateful object oriented languages with magic so I can trust my intern and Jr devs to write something decently maintainable

1. Node on the server does not have a comprehensive framework that compares to rails. You'll roll your own, and it will suck.

2. It's not any more difficult to scale than Node, you'll just need more servers to handle the load. Horizontal scaling works basically the same for both platforms.

3. Well understood baggage is better than baggage only a handful of people in your company know about as a result of your custom web framework.

4/5 of course nothing is a perfect fit for every project and everyone has their preferences, but this can be said for any language or platform so it's sort of a non argument.

6. Good luck finding interns and junior devs who can be productive writing in some esoteric functional language.

    extend ActiveSupport::Concern

    attr_accessor :foo

    class << self
        included do
            def method_missing(name) do
                define_method(:after_save) do |bar|
                    ...
                end
            end
        end
    end

What do you mean? This stateful, first class mixin OO metaprogrammed magic, implicitly globally mixed in to your application, makes it super easy to understand the flow of your application and the capabilities of your system. It's also super easy to see where things are defined, and the structure of methods/classes/object doesn't depend on luck / the order your program _executes_ in! Fat models are the way to go, there's obviously no problem with stateful mixins to "separate" model logic and make sure your model can do absolutely everything, because what is data, really?

Perfect for junior and senior devs alike.

edit: I forgot to include `method_missing`, which definitely isn't a design flaw, and there's absolutely no fundamental community problem that Ruby developers don't see any problem with using it.

This is sarcastic right? I really can't tell. And you either deserve and upvote or a downvote and I can't tell which because of it.

Essentially, this article gets written every year.

That should tell you something, no?

It tells me that some people want Rails to die way more than it actually is dying.

Since discovering Clojure in 2013 my biggest regret is that the Clojure community is not interested in building a Rails equivalent. I don't mean an MVC clone but a full-featured web framework supported by the wider community rather than someone's personal curated list of libraries like Luminus. I think Rails set the bar for whether a new language can transition to mainstream adoption.

I only did a short stint in web dev between undergrad and grad school for about a year. We used Rails. This was about 7 years ago. Are the reasons Rails has fallen out of favor technical or faddish? Or a little of both? I'm not intending to start a flame war of any sort. I'm just curious, having been out of the field for a while.

I'm not sure it has fallen out of favour but there is more competition now especially from javascript stuff.

The annual "is rails still relevant" post :D

I have a few Rails apps. Team now wants to move to nodejs. I made a few apps in nodejs. It's such a mess, yarn vs. npm, webpack setup. I guess nodejs community is still searching for their holy grail (Rails.)

The node community is that xkcd comic about standards in human form. Nothing is ever settled, always a new way to do something.

I want to build an ecommerce website, are there alternative JavaScript that can replace RoR and the Gems ecosystem?

Wait, when did Rails become old or uncool?

>Wait, when did Rails become old

It was released in 2004. Youtube and twitter didn't even exist then. The iPhone and Android were still 3+ years away, which means mobile internet as we know it today wasn't around then either. ROR has been around the block.

seems like very strong confirmation bias

After all this time?.... Always

Sinatra is frustratingly limited in some ways. I would describe it as easy, but not simple. It’s easy to use it to bang out any use case the authors foresaw. But now I’m going back and reading the code all the time to figure out how to accomplish certain things. And that reading is difficult, because like some other Ruby things it’s more focused on providing a pretty DSL for the user. How-to docs for basic things are easy to find, but reference docs aren’t, and often just list methods without any description of what they do.

If Rails is in decline it's because almost all languages now have some sort of MVC framework on par with Rails now. Since C# is used in the enterprise it's just natural to go with ASP.NET MVC Core instead of trying to get Rails to run on Windows. In my opinion, I feel one of the big mistakes that Rails made was not focusing on getting it to work officially on Windows.

Why rails should bother? There are plenty of other ruby gems and their developers who don't care about Windows. Even if Rails works, you can't convince community to make every single gem compatible with Windows. So it makes no sense.

You can easily run Rails on Windows via Docker. We have a few devs doing that where I work to much success.

As we transition to a more multicore, multi threaded environment Ruby cannot perform well. And thus by induction Rails. An interesting way forward is functional programming, because of its composable nature can perform really well in such environments. I dont see where Rails ideal niche exists going forward, is it in Large Apps that need really scalable apps that exist on multicore environments? Does it lie in small SPA like apps for which it has virtually no support? or Does it lie in the middle where you just throw more hardware at the problem before rewriting the whole app? In the last one yr i have seen more enterprise apps being activated in Nodejs than in Rails. Why does the enterprise Like Nodejs while Rails is on its downward spiral? i suspect it has to do with Nodejs being Beginner friendly. I left the Rails ecosystem 3 yrs back never looked back, and i dont see why i would ever go back.

Enterprise moves over to Node mainly because of hype, sometimes performance. Node is very library based, there is no framework that can compete with Rails there. In the wild Node web projects often lack a coherent structure because there is no agreed upon way to do things. Rails is perfect for e.g. inhouse websites in the enterprise.

It may not be just hype, Javascript is fashioned like C, most normal devs feel comfortable around C like languages. Infact a good testament to this is the growth of Typescript which makes both C# and Java crowd feel at home.

I'm not sure I agree with this, you can always achieve parallelism with multiple processes and IPC, and can do so fairly efficiently if communication is light.

Rails' biggest problem is that it isn't JavaScript, and thus code is not portable between client and server.

I have rarely seen the mystical pattern of "sharing Javascript code between client and server" actually work in a scalable and maintainable way outside of having a shared "enums" file.

Things like lodash, moment, validation logic, and http libraries are the big benefit of this. It is generally less of business focused code and more of utility type code that is easy to share. I do this on a daily basis, and have been for years.

If that were so true why would people rewrite apps in Go or use a JVM Language? Process based parellelism is memory intensive and you a=have no control, the best one can do is hope that the scheduler of the OS will take care of everything. Also code portability is not the issue, it is about what gets you started quickly scale well for a long time and dont ask for rewrites. Rails doesnt fit the bill, you cannot get started fast, It doesnt scale well unless you throw more hardware, MVC breaks with slightly complicated apps.

Ruby IS a JVM language today via JRuby. You get JIT, thread parallelism, and all the usual compacting GC goodness etc.

The GIL in CRuby means you need one process per core but that's also true of NodeJS.

Processes and threads aren't as different as you think. Linux pthreads are "just" processes which are allowed to write into the same memory. PostgreSQL remains process based to the day, although it does give them a little pain.

Out of curiousity, where have you found it useful for code to be portable between client and server?

I've been using Node.js/React together for a while, and I haven't found code reuse across client and server to be as important as I initially thought. The only code that I've tended to share is validation and a handful of utilities, which are a tiny proportion of the total, and even for those the business rules aren't always the same.

I've made a few multiplayer games where players need to keep a game state synchronized with the server. I used redux for state and game logic, and it's been really nice to be able to share the reducers between server and client. This made it so all I had to do to keep all clients in sync was share actions across clients as they happened.

I've also found it useful to have TypeScript on client and server to be able to share types between them.

Also, when using React, Node on your server makes server-side rendering a lot easier.

Personally not so much in model code, but in typescript interfaces/DTO which are used by both routing-controllers on the server side (additionally generating swagger api docs along the way) and by mobx on the frontend.

Rails is optimal for the web-tier which is traditionally scaled by being stateless, so you have one process per core (or thread if you are using JRuby) and you are done. It's ironic you list Node as the path forward since it is also single-threaded. Obviously it is more efficient on the baseline with async IO, but it still requires the same number of processes to saturate multiple cores, and you can also trivially eat into the IO overhead in ruby with green threads via Puma.

Rails has a problem most are aware of, When i started rails few yrs back, they said skinny controllers fat models, but in a few months our Models became 3000 lines, so they said external loading libraries, then came concerns, then they took concern back because it doesnt work. Then another solution came in the form of gems, people thought lets make more gems we have tried so many different ways to do this. If that is not all there is a problem in rails that exist purely because of the way the framework works. The mass assignment problem, this problem literally doesnt exist in any other framework. What we do with this is a patch to restrict an action, but it really exist because of the nature of the framework. This is a code smell if your program due to its very nature creates problems that needs patching is probably not doing something right. In my opinion best is to go back to simpler ways of organising code. Rails is too much an abstraction that creates its own unique problems.

> Clearly an easier way to start developing small crud apps is JS or (Your favourite transpiler for the front) + Firebase

Are you being serious?

I found getting into MVC stuff back in the days rather cumbersome and in 2009 many of my friends did internships as Rails devs, they went in hyped and came out disillusioned.

It always occupied a strange niche between stuff like WordPress and SPA/PWAs (sinatra+front-end fw)

Let me make sure I follow you: you think Rails, the top framework used by startups, occupies a "niche" between wordpress and SPA's; and you think sinatra + any JS frontend the bees knees?

"the top framework used by startups"

Wat?

Seriously though, the only problem firebase solves is the question "what infrastructure decision can I make right now that I will regret as soon as possible?"

I'm being facetious but then I feel like this whole thing is a joke, so it's kind of fitting.

I've known a lot of people get started quickly with firebase and then proceed to have to yank it out for the nonsense they run into. I also question the real value/merit of firebase.

Heroku did this properly imho. They are a perfect example of how one can provide hosting that actually is helpful and sophisticated where it needs to be but gets out of your way when you don’t need to care (for 99% of applications that don’t need to scale beyond a certain point).

The people want postgres, give them Postgres.

Firebase excels for real time/multiuser/shared data scenarios. It gives you things out of the box that are not trivial to implement from the ground up.

You can also use something like Firestore if your backend is primarily a place to store data. Combined with e.g. Next.js you can develop quite quickly with it.

I actually noped out of a contract when the client wanted to bet his entire infrastructure on firebase. Data, documents, authentication etc. Now I'm not familiar with Firebase, but I am familiar enough to know when to bow out. Their company in for a wild ride.

> MVC in rails breaks for larger apps.

This. Rails is perfect for fast development of CRUD in MVC, but if you're building anything complicated, you need something that supports more options than MVC. People can laugh at PHP all they want, but a framework like Symfony runs circles around Rails. You can do both simple and complex in it. I haven't tried Hanami yet, but while the frameworks concept seems much more promising than Rails, it's community is much smaller.

Still Rails is very populair, also here on Hackernews. Probably because the things we need to do in real life are actually not that complicated as we often make them out to be.

> Symfony runs circles around Rails

Ok Which circles, specifically, does Symfony run around Rails?

Speed, periformance, scaling.

But rails can be more fun.

Probably, the ability to dump arbitrary 3000-line classes into arbitrary directories. If you happened to start out working with Zend and then moved to Symfony, you might have strange ideas about how Rails is structurally too opinionated.

I've not used Rails, but I don't think that the idea that one can place an arbitrary file in an arbtrirary directory is strange at all.

How much of that do you think is a good thing? Zend was essentially an unstructured collection of arbitrary classes which were more-or-less interoperable. Class names needed to be globally unique, and namespaces didn't exist, and there were no conventions about where third-party code should go, or a very effective class registry, and dependency management often meant PEAR, which was like CPAN, but terrible. The idea of having arbitrary files in arbitrary places is something that any framework should be able to accommodate, but having some sort of well-defined folder structure is really quite necessary (in my opinion). It was not really the norm in Zend, and the tools and libraries and conventions and language are all much improved since then, but it's still possible to write ad-hoc-structured code using Symfony, and there are developers who prefer this.

Yes, ActiveRecord is not a good pattern for large-scale apps. The reason it's in Rails is because it's very good for simple cases and prototypes. But there is absolutely nothing in Rails stopping you from adding a service layer in whatever shape you see fit, I'm a fan of interactors (https://github.com/collectiveidea/interactor), but use whatever you want, it's easy to plug in new directories into the app structure and get magic loading and spec running automatically.

I agree that Rails enables a lot of messes, but I don't think the solution is to make your framework prescriptive about every single detail. I'd rather have the flexibility and enforce some standards per project than expect the framework dictate everything, because once you hit scale you have to do your own thinking and architecture anyway.

They all need a certain amount of knowledge to start.

I actually don't think MVC (the way Rails implements it) is a very good fit for web development. A project shouldn't be divided by file types, but by features. Django does it a bit better. The way it's done with Pages apps in .NET Core 2 is also interesting.

I wish Rails developers would listen and understand real flaws in the ecosystem instead of downvote. I happily admit major flaws in all languages I prefer to work in. Skinny controllers and fat models are both solving problems that never needed to exist in the first place.

Reply on news.ycombinator.com