3 ms·

I'm glad this is the case. I've been a Rails developer for close to 10 years now, but 3 or 4 years back I got sucked into the React world. I bought right in and

I'm glad this is the case. I've been a Rails developer for close to 10 years now, but 3 or 4 years back I got sucked into the React world. I bought right in and my company quickly adopted the "React on Rails" pattern. Looking back, it was one of the worst professional decisions I've made in my career. Now we're back to server side rendering and StimulusJS on the front-end when needed. Productivity is way up, and developer happiness is way up. With new tools like https://docs.stimulusreflex.com https://docs.stimulusreflex.com and https://cableready.stimulusreflex.com https://cableready.stimulusreflex.com I'm very excited about what can be accomplished with minimal JS. (Note: I still think React is an awesome library! I'm sure there are devs that are super productive with it too. It just wasn't the best fit for me and my company)

cvshepherd 6y ago
i've been using nothing but rails for the last 10 years, without missing anything. though had i known that tech like cableready/stimulus was on the horizon, i probably would have missed that. i'm always amazed when i read tech blogs focusing on the complexities, intricacies, and pitfalls of modern day JS development. then i look at the value it brings the visitor/customer, and 99% of the time i'm shaking my head in disbelief.
wlll 6y ago
A company I contract to for backend and server stuff made the jump from static HTML to client side rendering with react. They did it because the consulting company they went to receommended it "because it was the future", and I am sure in no small part because that was what the consulting company specialised in. It was the worst decision they have ever made. The site they ended up with was incredibly slow, and given the relatively few pages on the site you never really make for that initial load in time saved later. It's also incredibly hard to write well, requires a special third party service to show anything in Google and is incredibly hard to manage. They don't realise this of course, and are now attempting to solve the management and initial load issues by splitting the app up into three distinct apps. It won't help.
kingdomcome50 6y ago
I think the problem here is less about choosing to utilize a client-side rendering implementation and more about choosing to adopt the “SPA” paradigm - where everything is smashed together in a single application bundle. React + React DOM is something like 35kb gzipped. That’s not nothing (don’t forget caching) and pushing the initial render to the client (though not strictly necessary) does incur a bit of a penalty, but I think the benefits outweigh the drawbacks in many more use cases than people give credit. The real problem is two-fold: The first, as I stated above, is wrapping the entire application in a client-side implementation. As many people are pointing out this is often unnecessary. You don’t need to go full “SPA” in order to benefit from the vdom. The second (related) reason is when developers just start adding 3rd party dependencies without considering their impact (or if they are necessary). React is a library, and for the features you get it’s really not that big. If that’s all you are using to add that extra sparkle to some of your pages I firmly believe you are getting the absolute most “bang for your buck”.

cvshepherd 6y ago

i've been using nothing but rails for the last 10 years, without missing anything. though had i known that tech like cableready/stimulus was on the horizon, i probably would have missed that. i'm always amazed when i read tech blogs focusing on the complexities, intricacies, and pitfalls of modern day JS development. then i look at the value it brings the visitor/customer, and 99% of the time i'm shaking my head in disbelief.

wlll 6y ago

A company I contract to for backend and server stuff made the jump from static HTML to client side rendering with react. They did it because the consulting company they went to receommended it "because it was the future", and I am sure in no small part because that was what the consulting company specialised in. It was the worst decision they have ever made. The site they ended up with was incredibly slow, and given the relatively few pages on the site you never really make for that initial load in time saved later. It's also incredibly hard to write well, requires a special third party service to show anything in Google and is incredibly hard to manage. They don't realise this of course, and are now attempting to solve the management and initial load issues by splitting the app up into three distinct apps. It won't help.

kingdomcome50 6y ago

I think the problem here is less about choosing to utilize a client-side rendering implementation and more about choosing to adopt the “SPA” paradigm - where everything is smashed together in a single application bundle. React + React DOM is something like 35kb gzipped. That’s not nothing (don’t forget caching) and pushing the initial render to the client (though not strictly necessary) does incur a bit of a penalty, but I think the benefits outweigh the drawbacks in many more use cases than people give credit. The real problem is two-fold: The first, as I stated above, is wrapping the entire application in a client-side implementation. As many people are pointing out this is often unnecessary. You don’t need to go full “SPA” in order to benefit from the vdom. The second (related) reason is when developers just start adding 3rd party dependencies without considering their impact (or if they are necessary). React is a library, and for the features you get it’s really not that big. If that’s all you are using to add that extra sparkle to some of your pages I firmly believe you are getting the absolute most “bang for your buck”.