
Abstractions and the role of a framework - sotojuan
http://solnic.eu/2016/05/30/abstractions-and-the-role-of-a-framework.html
======
whistlerbrk
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.

~~~
jasim
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.

~~~
crdoconnor
>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](https://www.google.com/trends/explore#q=ruby%20on%20rails)

~~~
grn
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.

------
vinceguidry
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.

~~~
majewsky
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.

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

------
revskill
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.

