Dude - I never suggested that you don't need client-side code. That's not even a thing.
If that's what set you off, then I'm sorry for not being clear that we actually used to build real stuff before front-end frameworks were popular again. (Yes, before jQuery there was a first-wave of libraries competing for the same trophy. I'll bet that you've never had to suffer YUI, MooTools or Dojo, or remember when Google released their own library... Closure.)
Sharing elements is not really a serious feature now, is it? If you are committed to doing all of your state transformation on the client, you have to be able to move objects from one place to another. On the server, we just call functions and pass data structures around. We don't need to pass functions into props eight levels deep because we don't need to have an adversarial relationship between the different parts of our data model. It's that endless shuffling of concerns up to the parent that feels so wrong to me.
A really good analogy would be calling a meeting exclusively to schedule more meetings. There's an inherent design inefficiency that gets worse with complexity. Meanwhile, I can pass a collection into a partial and never spend a second of my day fretting about how some React component I pulled from npm is going to do a shit job of abstracting the browser's native functionality.
One thing Rails really gets right is that things are consistent and repeatable. We call it the principle of least surprise. It's what the client world is sorely missing.
Anyhow: I have 26 years of experience. That's perspective, wisdom or a demonic pact. I'm not claiming to be humble. My opinion is highly qualified.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Dude - I never suggested that you don't need client-side code. That's not even a thing.
If that's what set you off, then I'm sorry for not being clear that we actually used to build real stuff before front-end frameworks were popular again. (Yes, before jQuery there was a first-wave of libraries competing for the same trophy. I'll bet that you've never had to suffer YUI, MooTools or Dojo, or remember when Google released their own library... Closure.)
Sharing elements is not really a serious feature now, is it? If you are committed to doing all of your state transformation on the client, you have to be able to move objects from one place to another. On the server, we just call functions and pass data structures around. We don't need to pass functions into props eight levels deep because we don't need to have an adversarial relationship between the different parts of our data model. It's that endless shuffling of concerns up to the parent that feels so wrong to me.
A really good analogy would be calling a meeting exclusively to schedule more meetings. There's an inherent design inefficiency that gets worse with complexity. Meanwhile, I can pass a collection into a partial and never spend a second of my day fretting about how some React component I pulled from npm is going to do a shit job of abstracting the browser's native functionality.
One thing Rails really gets right is that things are consistent and repeatable. We call it the principle of least surprise. It's what the client world is sorely missing.
Anyhow: I have 26 years of experience. That's perspective, wisdom or a demonic pact. I'm not claiming to be humble. My opinion is highly qualified.