<story><title>React I love you, but you&apos;re bringing me down</title><url>https://marmelab.com/blog/2022/09/20/react-i-love-you.html</url></story><parent_chain><item><author>exclusiv</author><text>&amp;gt; Some part of your organizations chaos is going to reflect in code, and honestly I&amp;#x27;d rather it be in a big ball of frontend than in the data models, infrastructure, etc.&lt;p&gt;I disagree. I like my frontend to be as dumb as possible. It gets data and reacts to it as simple as possible. Seen too many frontends with a lot of data logic and it becomes extremely brittle, harder to test.&lt;p&gt;These are the ones where the frontend devs are getting data from the API and creating new structures, transforming it, conditionals everywhere, etc.&lt;p&gt;It requires way more discipline to ensure that frontend devs aren&amp;#x27;t recreating the wheel and writing duplicate code as the app and components evolve, and it&amp;#x27;s worse for larger codebases of course.&lt;p&gt;They need to build some new component and go - ok I got the data from the API and now I need to do the thing that&amp;#x27;s already been done by another frontend dev for another component because we&amp;#x27;ve allowed the frontend to be responsible for transforming the data. But if they aren&amp;#x27;t aware of this, then you get a lot of dupe code.&lt;p&gt;Just have your backend API provide the contract. Setup resources&amp;#x2F;transformers as needed on the backend instead of littering the frontend with that logic.</text></item><item><author>corytheboyd</author><text>I&amp;#x27;ve worked in a few roughly-the-same-size (~50 engineers) web development shops. It&amp;#x27;s always the same. Doesn&amp;#x27;t matter if it&amp;#x27;s React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc.&lt;p&gt;The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each other, half-finished move-to-new-framework initiatives.&lt;p&gt;I just mean to say that when I hear &amp;quot;it&amp;#x27;s because React&amp;quot; or &amp;quot;it&amp;#x27;s because rails views&amp;quot;, any other of the infinite variations of this, I kind of just tune out. Some part of your organizations chaos is going to reflect in code, and honestly I&amp;#x27;d rather it be in a big ball of frontend than in the data models, infrastructure, etc.</text></item></parent_chain><comment><author>tikiman163</author><text>I primarily agree with you, but his primary point is mainly regarding the tendency for projects at large organizations to have a substantial number of unfished attempts to rework existing applications, which often results in serious headaches for whoever owns the code.&lt;p&gt;What I mean is that even if you&amp;#x27;ve followed a specific set of programming principals, code practices and design patterns consistently across the life time of the application, there will still have been initiatives to change how things are done. Maybe they want to use a &amp;quot;better&amp;quot; authentication library, or add a material framework that has capabilities they need. The exact initiative, and how valid the request or decision is doesn&amp;#x27;t matter. These initiatives may occur one at a time, or be competing with each other for priority while being incompatible without anyone noticing. But some of them will fail to be completed, and someone has to back out the changes that shouldn&amp;#x27;t go to prod. Inevitably something will get left behind. Over 5-10 years this can have a shockingly large impact on the code base in ways engineers frequently notice but don&amp;#x27;t understand how the code got to the state its in.&lt;p&gt;This frequently means dead code, unused dependencies, comments that don&amp;#x27;t make any sense, properties on objects that are never displayed or referenced by business logic, and multiple classes&amp;#x2F;services which accept the same inputs and produce the same outputs but do the job just differently enough you can&amp;#x27;t be sure it&amp;#x27;s the same. That, and over abstractions (any piece of code which branches based on the context of &amp;quot;who&amp;#x27;s asking&amp;quot;).&lt;p&gt;And frankly few things any me more than someone who felt the need to implement their own logging implementation, especially in C# (yes I know we&amp;#x27;re talking about React, but people do the same stupid crap in that case as well). Reinventing the wheel has to be done on occasion, but you need to ask yourself if it has to be you that makes it happen,and whether it already has been.</text></comment>
<story><title>React I love you, but you&apos;re bringing me down</title><url>https://marmelab.com/blog/2022/09/20/react-i-love-you.html</url></story><parent_chain><item><author>exclusiv</author><text>&amp;gt; Some part of your organizations chaos is going to reflect in code, and honestly I&amp;#x27;d rather it be in a big ball of frontend than in the data models, infrastructure, etc.&lt;p&gt;I disagree. I like my frontend to be as dumb as possible. It gets data and reacts to it as simple as possible. Seen too many frontends with a lot of data logic and it becomes extremely brittle, harder to test.&lt;p&gt;These are the ones where the frontend devs are getting data from the API and creating new structures, transforming it, conditionals everywhere, etc.&lt;p&gt;It requires way more discipline to ensure that frontend devs aren&amp;#x27;t recreating the wheel and writing duplicate code as the app and components evolve, and it&amp;#x27;s worse for larger codebases of course.&lt;p&gt;They need to build some new component and go - ok I got the data from the API and now I need to do the thing that&amp;#x27;s already been done by another frontend dev for another component because we&amp;#x27;ve allowed the frontend to be responsible for transforming the data. But if they aren&amp;#x27;t aware of this, then you get a lot of dupe code.&lt;p&gt;Just have your backend API provide the contract. Setup resources&amp;#x2F;transformers as needed on the backend instead of littering the frontend with that logic.</text></item><item><author>corytheboyd</author><text>I&amp;#x27;ve worked in a few roughly-the-same-size (~50 engineers) web development shops. It&amp;#x27;s always the same. Doesn&amp;#x27;t matter if it&amp;#x27;s React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc.&lt;p&gt;The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each other, half-finished move-to-new-framework initiatives.&lt;p&gt;I just mean to say that when I hear &amp;quot;it&amp;#x27;s because React&amp;quot; or &amp;quot;it&amp;#x27;s because rails views&amp;quot;, any other of the infinite variations of this, I kind of just tune out. Some part of your organizations chaos is going to reflect in code, and honestly I&amp;#x27;d rather it be in a big ball of frontend than in the data models, infrastructure, etc.</text></item></parent_chain><comment><author>cercatrova</author><text>That&amp;#x27;s why I like GraphQL, you get exactly the data you request, no transformation necessary.</text></comment>