Back in April of 2014, I was vacillating between using Ruby on Rails, and Entity Framework on ASP.NET, for a new project. All other things being equal in programming or system administration, I like to sit on the intersection of functionality, for actual productivity, and popularity, for availability of reference material. To check on the relative amount of helpful documentation I could expect to find, I ran a comparison on Google Trends.

Disappointingly, Rails seemed to be losing ground to EF.NET, at least in terms of Google searches. I tried to console myself by saying that Rails was mature by that time, and EF was still struggling to find its niche, which both reflected in the results. Five years later, I stand by that interpretation.

For comparison, I wanted to see what the situation looked like today. Both technologies were trending down since the last snapshot. I took one guess as to why, and this is what I saw.

For the fun of it, I threw in another couple of terms…

Yikes. The popularity of React and Angular has stomped the axis of the graph. Clearly, Javascript-based front-end technologies have taken over web development mindshare.

I find this state of affairs to be morose. Some time ago, through a series of inescapable constraints, I was backed into a corner to write a new web application in Java/Javascript. Through other, defaulting logic gates, I wound up trying to use Spring Boot and Angular 2, in particular. I found them both to be tedious, laborious, and almost utterly devoid of helpful documentation on the internet. The only consolation I can take from the graph, above, is that React seems to be winning against Angular. I haven’t tried it yet, but it gives me hope that it’s better.

In the end, after literally weeks of reading and searching, I found exactly one, non-trivial example of how to use this stack, and that was only because I sent an email to the guy who seemed to be the chief evangelist of Java/JS on the internet. While that was great, his example was so out of date, I couldn’t reconcile how to translate his approach into modern idioms. Coming from the Oracle/Java world, this stack is intended to be all things to all people, and it shows. There is no commonly-accepted way of doing things with it that people seem to agree on.

If you’re creating some sort of enterprise-y, company-wide system, containing highly-important data, I could see breaking the backend and the frontend apart along language/framework lines, to facilitate having different teams coding them. (Even though the strict typing of a JS frontend is going to drive both sides crazy.) But for a tiny, departmental web app? Containing no sensitive data? That just tracks dates? Which might be used by a handful of people? Using a Java/JS solution for this is like using a nuke to get rid of a gopher in your back yard.

Rails shines the brightest when making small, line-of-business apps like this. Fifteen years after the first release of Rails, there is still nothing in the web development world that can touch it for productivity. Ruby’s interpreted nature — while prone to being slower, compared to typed, compiled languages — is precisely what makes it so easy to use, and so flexible in the role of a database ORM.

It seems that Entity Framework never really got off the ground. Most people writing about it recommend using something else, like Dapper or nHibernate. Dapper does so little for you that you might as well just write text-substituted SQL yourself, and nHibernate is really out of date, so I’d rather just put up with EF’s limitations. And, again, I’m sad, because I’m pretty sure I’m going to get backed into a corner of using ASP.NET for another project. I’ll do my best to make sure it’s .NET Core, for future-proofing, but, for the same reason, EF Core isn’t any better.