Abstractions and the role of a framework | Hacker News Reader

Abstractions and the role of a framework

solnic.eu

51 pointssotojuan9 comments

His original article received so much attention because anti-Rails sentiment has reached an all time high and people are looking for confirmation of their feelings against it. But in so doing the same people are misattributing the actual source of their modern application building woes.

It isn't Rails. Its that REST is a terrible and clunky foundation upon which to build your client-server architecture for a complex and changing UI. It might be great for an API, but as we are all apparently rediscovering your UI is a tree extracted from the graph which is the entirety of your data. If your UI components can tell you what data it needs you can build up to root a graph-like query.

I would venture to say Rails suffers because its phenomenal popularity means people reach for it out of familiarity to solve their problems, get decently far and then hit diminishing returns when they find they have to write their app twice, in JS and in Ruby.

Rails provides no way, out of the box, to share a model between client and server. It provides no way for your views to describe their data dependencies and the mutations they allow. Because of this, there is no way to parse an actually expressive query (i.e not query params) and direct that, after security/authentication toward whatever datastore you choose.

It was phenomenally productive 5 years ago when the problems being solved were simpler. At this point I can really only imagine using it to build APIs and that for me is only because I know it so well.

I subscribe to this perspective. REST thinks of the web as discrete resources, for which it provides a sufficiently good model. But that model makes it hard to build complex GUIs that deal with a lot of hierarchical data. Such applications can't afford to treat every node as an independent resource sitting across the network. Yet we use the old ways of thinking to build complex new beasts and that unsurprisingly turns out to be a kludge.

Also, if the anti-Rails sentiment has reached an all time high (has it?), it would be because Rails adoption itself has reached an all time high. We do need a web framework that lets us build applications by seamlessly weaving both the front-end and back-end, and unfortunately nothing like that exists. In the absence of such an alternative, Rails remains the web development framework out there with the most bang for the buck. For front-end heavy apps, the easiest approach right now is a `rails new` with Devise and jsroutes, throw in a complex rails-react setup with server-side rendering, write almost all the views in Javascript, and many hundred API endpoints, and after thousands of tests to just validate the inevitable connascence, we have something that works. Something that took us months, which could've been done in VB6 or FoxPro in a week.

GraphQL and Relay promises to fix this, and even if they themselves don't, the conversation has started, and something great will emerge in time.

>Also, if the anti-Rails sentiment has reached an all time high (has it?), it would be because Rails adoption itself has reached an all time high.

I really doubt that:

https://www.google.com/trends/explore#q=ruby%20on%20rails

I'm not sure whether we can draw conclusions about _adoption_ from this chart. A simplistic model could assume that

    adoption = integral of popularity over time

The peak adoption is where popularity is zero. This model doesn't include software that's been decommissioned or migrated to another platform.

The problems you describe are nothing to do with rest (which is merely a guideline anyway, not an prescription), or rails. They are the problems of trying to split an app into server side and client side parts.

Rails without an active record ORM model isn't really Rails, if that's what you want then you're probably not doing CRUD and you really should just pick another framework.

I'm all for lots of frameworks. But please please please don't take away my Rails by forcing it to be ORM-agnostic. Please don't turn my cruiser into a crotch-rocket.

Not every CRUD app uses a local database. For example, I'm working on a web frontend for a collection of microservices right now. The web app is just CRUD for the largest part, but the model is a custom implementation that translates .find_by, .save etc. into REST calls. Took us quite some effort to make this look like ActiveRecord enough to play nice with the rest of Rails.

You should absolutely release your work, a translation layer for REST APIs -> ActiveModel would be awesome.

Using Rails as your application is not creativity. Using as a tool to implement your thought is. If Rails is not enough or not what you want, build another foundation. Never blame our tool, it has its use for its existence. Learn from it.

Reply on news.ycombinator.com