10 ms·

Rails is FANTASTIC! I work on a hybrid React-on-Rails application and working on the React portions is so. fucking. painful. Seriously the shit people come up

by tomc1985 8y ago

Rails is FANTASTIC! I work on a hybrid React-on-Rails application and working on the React portions is so. fucking. painful. Seriously the shit people come up with with this "tool" makes corporate-hack Java programmers look good. I am always taking the backend Rails-y tickets if I have the chance

acmecorps 8y ago
I truly agree with you. I absolutely love Rails and what it has to offer, ever since working with it since Rails 2+. Truly one of the best bet I've ever made!
strken 8y ago
Blaming complexity on React is a bit like blaming complexity on ERB. The problem isn't React, the problem is the massive hole where React doesn't have an opinion. React improves the area around the hole so much that the technologies we use to fill the void look obviously deficient in comparison.
- mooreds 8y ago
  Have you used Vue? From reading it appears Vue has an opinion many places where react does not, but I have built nothing serious in either.
  - thoman23 8y ago
    As does Angular. That’s kind of its thing...full, opinionated framework.
- inapis 8y ago
  This is actually the bane of JS community's existence. JS developed so fast and so wildly that there was never a breather to form and write down best practices or opinions. This is jarring to someone coming from the Rails world where a lot of magic is happening, there are strict opinions (heck, it's in the subtitle of the copy) and strict conventions to adhere too. JS is wild west compared to that. This is not to say that JS is shit but both JS and Rails have their place. If you want flexibility, you need JS. If you want iteration speed and dev productivity you need Rails.
  - hombre_fatal 8y ago
    I don't understand. One is server application development, one is client development. They are two vastly different things. From this hot take on JS, I'd think people are suggesting that the development experience of all the other available clients are a lot better, but then I became an Android and iOS developer and that's not true either. Swift isn't bad, but the language isn't the only thing that dictates how hard client development is. I'd rather use React than UIKit abstractions, that's for sure. And CoreData is probably the worst and most outdated abstraction I've used across all platforms. And even if I think iOS development is the ideal way to write software... it only runs on iPhones and iPads. I mean, of course the Rails side of your application is probably nicer than the client side where you get to stay in your simple request -> response realm that runs on the same machine. If given the option, I bet almost every HNer would rather be the person paid the same to build the API endpoints vs the crapshoot that is client and UI development. But I see this perpetually confused as Javascript vs <my favorite language I use on the server>. For example, Ruby fares pretty poorly against Node if you forget the client, like Sinatra vs Express/Koa.
    - inapis 8y ago
      I think we're diverging. The mental model of a Rails developers is well formed and if you're a beginner then you can rely on a very strong community for opinions, best practices and conventions to follow. This greatly decreases cognitive load and immensely improves productivity. When you make a jump to a JS stack (whether client side or server side) you have a lot of options but no best practices or conventions to follow. You have to make a lot of choices which have already been made for you in RoR. Even though SPA frontend dev has settled between React and Vue, you still have to make a lot of decisions. React also bills itself as a view library. You have to make decisions about state management (if needed), routing etc etc. A vast chunk of these decisions are made for you in RoR so that you just work on the app. I think this is what the author was lamenting about.
      - tomc1985 8y ago
        Rails was somewhat unique at its birth with its opinionated-ness. Outside of that world, in "respectable" programming environments with smart people who were good at algorithms and O(n) notation and all that (which was not me) it was rare that I encountered the kind of insanity that I seem to run into daily with PHP and later JS.
- tomc1985 8y ago
  I'm not so sure about that... maybe I'm just old but React provides very little of anything compelling other than shadow DOM and databinding. It seems like every opinion it has outside of those two very narrow areas is INSANE
  - peteforde 8y ago
    The funniest part about the enthusiasm for React masochism is that the best parts of the library are better accomplished with a combination of Turbolinks 5 and Stimulus. Not a coincidence that they're all Rails extractions. For me, the more interesting question in all of this is where did this fervour for JS-and-the-way-down actually come from? My hypothesis is that it's the natural result of a huge mess of new talent - fresh out of various overpriced Bootcamps and told that their 9-week educations give them a credible opinion in true post-modernist fashion - all being released on the world at the precise moment that a predictable police lineup of over-promised technologies were all at the top of their respective hype cycles. Humans have a predictable tendency to assume that the thing they are thinking about at the moment is far more important than it actually is. If you have a very short institutional memory and everyone you know in your bubble has been programming for a relatively short period of time, pretty soon you can start to believe that if everyone is doing it, you couldn't all be wrong.
    - tomc1985 8y ago
      I think it's that, and the general accessibility of Javascript. Before this JS craze you saw the same shit with PHP and Visual Basic, though for the most part people weren't trying to build and rebuild the same platforms nearly as much as now
      - peteforde 8y ago
        I know that it's 2008 calling, but seriously: when did Heroku, Github and the bundler/gem ecosystem stop qualifying as accessible? Deploying an MVP Rails app with sophisticated functionality is so effective that it still qualifies as erotic. For me, the most compelling example of progress coming from the JS camp was my shallow investigation of the Expo platform for React Native. It has some genuinely sexy developer ergonomics features which I'd love to see make their way back into Rails.
- continuational 8y ago
  Not quite true - React confuses inputs with outputs by taking in callbacks as props instead of just emitting events. This makes shouldComponentUpdate very error prone, and memoizing callbacks to work around it is a mess. This is a large contributor to complexity and bugs in React apps.
- wwweston 8y ago
  That's a great observation -- one that's true of, say, jQuery too, which handled the problems of cross browser compatibility, over-verbose interfaces, and DOM manipulation so well that... we got to really take a hard look at the problem of doing everything we wanted by direct DOM manipulation.
fny 8y ago
Honestly, I just wish Rails had some degree of static typing (a la TypeScript.) As a Rails code base grows and patterns are required beyond the basics, it becomes a nightmare to tell what comes from where. You'd probably gain some mileage from that in your React codebase.
- hombre_fatal 8y ago
  Static-typing seems so at odds with Ruby/Rails that I can't even imagine what that would look like.
  - ehsanu1 8y ago
    It would ideally look pretty similar to typescript. There's actually a few projects adding typing to ruby, but they seem to be mostly trying to catch issues at runtime, which to me is pointless. Or the syntax is onerous, using decorators and/or separate type definitons. I'd be really interested in a typescript like superset of ruby, and I've even thought about building a prototype of it, though it's quite outside my area of expertise.
    - hombre_fatal 8y ago
      I don't mean the syntax, I mean the abuse (ostensibly a language feature) of method_missing that's incumbent in the ecosystem. What would be the type signature of Active Record?
      - favorited 8y ago
        Aren't your ActiveRecord models basically the only place in a Rails app where you do specify the types of your properties?
        hombre_fatal 8y ago
        I'm referring to things like dynamic find_by_* messages since more people might be familiar with that. But I don't know why you'd say that. ActiveRecord models are one of the main places you'll see a bunch of `use SomeGem::Thing` that introduce a bunch of magic methods on model instances. And my point is that we aren't talking about method composition here that you can statically analyze with a bolted-on type system. Ruby's metaprogramming runs so deep that it's a substantially bigger challenge than other dynamically-typed languages. One clue is that humans even have a hard time with it. The first shock that people have with Ruby is when you see a method or identifier and grep shows up with zero results. Aside, I can kinda tell that Ruby is entering Perl territory when there are no beginners around to chime in with their gripes.
jho406 8y ago
Try this out: https://github.com/jho406/Breezy https://github.com/jho406/Breezy, its a library i wrote that makes working with the React/Redux portion feel like a classic Rails app. Its inspired by turbolinks and doesn't require APIs to work.
jaxn 8y ago
We are doing Rails/Vue. Both sides are pleasant to work with. I prefer working with Vue, but don't see any reason to remove Rails from the backend. (but yeah, ActionCable was a no-go. We use Pusher instead)

acmecorps 8y ago

I truly agree with you. I absolutely love Rails and what it has to offer, ever since working with it since Rails 2+. Truly one of the best bet I've ever made!

strken 8y ago

Blaming complexity on React is a bit like blaming complexity on ERB. The problem isn't React, the problem is the massive hole where React doesn't have an opinion. React improves the area around the hole so much that the technologies we use to fill the void look obviously deficient in comparison.

mooreds 8y ago
Have you used Vue? From reading it appears Vue has an opinion many places where react does not, but I have built nothing serious in either.
- thoman23 8y ago
  As does Angular. That’s kind of its thing...full, opinionated framework.
inapis 8y ago
This is actually the bane of JS community's existence. JS developed so fast and so wildly that there was never a breather to form and write down best practices or opinions. This is jarring to someone coming from the Rails world where a lot of magic is happening, there are strict opinions (heck, it's in the subtitle of the copy) and strict conventions to adhere too. JS is wild west compared to that. This is not to say that JS is shit but both JS and Rails have their place. If you want flexibility, you need JS. If you want iteration speed and dev productivity you need Rails.
- hombre_fatal 8y ago
  I don't understand. One is server application development, one is client development. They are two vastly different things. From this hot take on JS, I'd think people are suggesting that the development experience of all the other available clients are a lot better, but then I became an Android and iOS developer and that's not true either. Swift isn't bad, but the language isn't the only thing that dictates how hard client development is. I'd rather use React than UIKit abstractions, that's for sure. And CoreData is probably the worst and most outdated abstraction I've used across all platforms. And even if I think iOS development is the ideal way to write software... it only runs on iPhones and iPads. I mean, of course the Rails side of your application is probably nicer than the client side where you get to stay in your simple request -> response realm that runs on the same machine. If given the option, I bet almost every HNer would rather be the person paid the same to build the API endpoints vs the crapshoot that is client and UI development. But I see this perpetually confused as Javascript vs <my favorite language I use on the server>. For example, Ruby fares pretty poorly against Node if you forget the client, like Sinatra vs Express/Koa.
  - inapis 8y ago
    I think we're diverging. The mental model of a Rails developers is well formed and if you're a beginner then you can rely on a very strong community for opinions, best practices and conventions to follow. This greatly decreases cognitive load and immensely improves productivity. When you make a jump to a JS stack (whether client side or server side) you have a lot of options but no best practices or conventions to follow. You have to make a lot of choices which have already been made for you in RoR. Even though SPA frontend dev has settled between React and Vue, you still have to make a lot of decisions. React also bills itself as a view library. You have to make decisions about state management (if needed), routing etc etc. A vast chunk of these decisions are made for you in RoR so that you just work on the app. I think this is what the author was lamenting about.
    - tomc1985 8y ago
      Rails was somewhat unique at its birth with its opinionated-ness. Outside of that world, in "respectable" programming environments with smart people who were good at algorithms and O(n) notation and all that (which was not me) it was rare that I encountered the kind of insanity that I seem to run into daily with PHP and later JS.
tomc1985 8y ago
I'm not so sure about that... maybe I'm just old but React provides very little of anything compelling other than shadow DOM and databinding. It seems like every opinion it has outside of those two very narrow areas is INSANE
- peteforde 8y ago
  The funniest part about the enthusiasm for React masochism is that the best parts of the library are better accomplished with a combination of Turbolinks 5 and Stimulus. Not a coincidence that they're all Rails extractions. For me, the more interesting question in all of this is where did this fervour for JS-and-the-way-down actually come from? My hypothesis is that it's the natural result of a huge mess of new talent - fresh out of various overpriced Bootcamps and told that their 9-week educations give them a credible opinion in true post-modernist fashion - all being released on the world at the precise moment that a predictable police lineup of over-promised technologies were all at the top of their respective hype cycles. Humans have a predictable tendency to assume that the thing they are thinking about at the moment is far more important than it actually is. If you have a very short institutional memory and everyone you know in your bubble has been programming for a relatively short period of time, pretty soon you can start to believe that if everyone is doing it, you couldn't all be wrong.
  - tomc1985 8y ago
    I think it's that, and the general accessibility of Javascript. Before this JS craze you saw the same shit with PHP and Visual Basic, though for the most part people weren't trying to build and rebuild the same platforms nearly as much as now
    - peteforde 8y ago
      I know that it's 2008 calling, but seriously: when did Heroku, Github and the bundler/gem ecosystem stop qualifying as accessible? Deploying an MVP Rails app with sophisticated functionality is so effective that it still qualifies as erotic. For me, the most compelling example of progress coming from the JS camp was my shallow investigation of the Expo platform for React Native. It has some genuinely sexy developer ergonomics features which I'd love to see make their way back into Rails.
continuational 8y ago
Not quite true - React confuses inputs with outputs by taking in callbacks as props instead of just emitting events. This makes shouldComponentUpdate very error prone, and memoizing callbacks to work around it is a mess. This is a large contributor to complexity and bugs in React apps.
wwweston 8y ago
That's a great observation -- one that's true of, say, jQuery too, which handled the problems of cross browser compatibility, over-verbose interfaces, and DOM manipulation so well that... we got to really take a hard look at the problem of doing everything we wanted by direct DOM manipulation.

fny 8y ago

Honestly, I just wish Rails had some degree of static typing (a la TypeScript.) As a Rails code base grows and patterns are required beyond the basics, it becomes a nightmare to tell what comes from where. You'd probably gain some mileage from that in your React codebase.

hombre_fatal 8y ago
Static-typing seems so at odds with Ruby/Rails that I can't even imagine what that would look like.
- ehsanu1 8y ago
  It would ideally look pretty similar to typescript. There's actually a few projects adding typing to ruby, but they seem to be mostly trying to catch issues at runtime, which to me is pointless. Or the syntax is onerous, using decorators and/or separate type definitons. I'd be really interested in a typescript like superset of ruby, and I've even thought about building a prototype of it, though it's quite outside my area of expertise.
  - hombre_fatal 8y ago
    I don't mean the syntax, I mean the abuse (ostensibly a language feature) of method_missing that's incumbent in the ecosystem. What would be the type signature of Active Record?
    - favorited 8y ago
      Aren't your ActiveRecord models basically the only place in a Rails app where you do specify the types of your properties?
      - hombre_fatal 8y ago
        I'm referring to things like dynamic find_by_* messages since more people might be familiar with that. But I don't know why you'd say that. ActiveRecord models are one of the main places you'll see a bunch of `use SomeGem::Thing` that introduce a bunch of magic methods on model instances. And my point is that we aren't talking about method composition here that you can statically analyze with a bolted-on type system. Ruby's metaprogramming runs so deep that it's a substantially bigger challenge than other dynamically-typed languages. One clue is that humans even have a hard time with it. The first shock that people have with Ruby is when you see a method or identifier and grep shows up with zero results. Aside, I can kinda tell that Ruby is entering Perl territory when there are no beginners around to chime in with their gripes.

jho406 8y ago

Try this out: https://github.com/jho406/Breezy https://github.com/jho406/Breezy, its a library i wrote that makes working with the React/Redux portion feel like a classic Rails app. Its inspired by turbolinks and doesn't require APIs to work.

jaxn 8y ago

We are doing Rails/Vue. Both sides are pleasant to work with. I prefer working with Vue, but don't see any reason to remove Rails from the backend. (but yeah, ActionCable was a no-go. We use Pusher instead)