3 ms·
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 feeli
by whistlerbrk 10y ago
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 10y agoI 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 10y ago>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 10y agoI'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.
- grey-area 10y agoThe 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.