23 ms·

React created roadblocks in our enterprise app

• yummybear 6y ago
  It does sound to my like all of these issues would be the same no matter what library/framework you chose. Working “against the grain”, choosing third party libraries, managing coding conventions and dealing with code bloat is common to all technologies. Unless all these points are adressed, you’re unlikely to achieve success with any platform.
  • cratermoon 6y ago
    I agree. This story could have been written any time in the last couple of decades, but replace React and .NET with any two wildly divergent software development ecosystems/paradigms/communities. I could tell you stories about an insurance company where I worked and how Java on Solaris (or was it z/OS?) and VB on Windows 95 fought to the death in a cage match. The were many programmer casualties.
• sergiotapia 6y ago
  I don't agree that React is not enterprise ready. The mistake OP made was reaching for Redux for some weird reason. Redux-saga, _thunks_? I guarantee this project used thunks of some kind because some blogger posted about it and it was popular and trendy. Pick boring tech that's objectively simple and not an exercise in genius. mobx, today: apollo-client (if you have a graphql api). I've never seen any other project stain a framework as much as Redux has done. Also, he had a ton of organizational issues that have nothing to do with the tech.
  • zumu 6y ago
    > I've never seen any other project stain a framework as much as Redux has done. Is there a good article that would summarize the backlash against Redux? While I don't do front-end much anymore, Redux was such a productive tool for me when I was a contractor. I found it incredibly powerful and easy to work with, if cerebral for the uninitiated. Meanwhile, I had the exact opposite experience with apollo-client and the apollo framework—very easy to get up and running, but a giant pita for doing anything complex.
    • nawgz 6y ago
      It sounds like GP drank the mobx juice to me. Honestly, after using mobx, it's almost impossible to understand why Redux is popular. MobX is more concise, more performant, has a crazy amount of built-in optimizations, and lets you forget about tracing your crazy graph of relationships just to update some view. Of course, mobx had "bad" (read: used decorators) syntax for a while, and only with MobX 6 did they clean it up, but boy oh boy is it clean now
      • erlich 6y ago
        How would you compare MobX vs. Apollo + React Context?
  • legerdemain 6y ago
    Given the choice of MobX vs Redux, I don't understand how a library with one ninth the number of downloads on NPM is the more "boring" one.
    • sergiotapia 6y ago
      use it, you'll know why it's qualified as "boring".
  • erlich 6y ago
    Agree! Redux is never needed and was always a bad choice IMHO. The goals of it seem so misaligned with developer productivity. It was small, elegant library for the sake of being small. Ultimate flexibility that can do everything, but then required building heaps of stuff on top of it, and favoring this immutable one-way flow that just complicated things riding on the coat tails of flux. > I've never seen any other project stain a framework as much as Redux has done. 100%
• ourcat 6y ago
  AngularJS was indeed a bit of a pain when we switched to Angular 2+ and beyond, but it was so worth it. I chose it because of the skillset that our current (small) team has. There's no way our 'designer' (more an HTML/CSS guy) could have wrapped his head around JSX, the way it mixes scripts with layout markup. The way Angular separates concerns for us is great. And the components are extremely flexible and reactive and useful for iteration. And lazy-loaded routings? Yes please. And with the Angular CLI and TypeScript typings and using VSCode it's an absolute joy to build sites with.
  • swsieber 6y ago
    Oof. I work on an angular app and the build is slow as molasses because it's big. And we of course don't want to move away from the official build tool because build time improvements are always "right around the corner".
    • ourcat 6y ago
      True. The build times are slow. But the recent versions (and updating is also a breeze - mostly) should be faster. And particularly if you drop support for ES5 browsers.
    • nkw 6y ago
      You might consider NX if build times are an issue. It is monorepo based and includes computation caching[2] and incremental builds, but under the hood uses the angular build tools. We've found it pleasant to work with. [1] https://nx.dev/latest/angular/core-concepts/computation-caching https://nx.dev/latest/angular/core-concepts/computation-cach...
  • nickthemagicman 6y ago
    JSX always seemed like a red flag to me. It was redesigning something that already exists to make it so that it uses non native browser functionality? Also the portability looked like an issue from it. I don't understand the use case for it. Vue and apparently Angular use basic browser friendly components.
• flyinglizard 6y ago
  First you made a bad choice by using React, then you made a bad choice by publishing on Medium which does not allow anonymous reading.
• poulsbohemian 6y ago
  I'm not really a React fan, but you could have encountered all of these problems regardless of what you'd chosen to use. Sounds like the writer had good intentions and worked hard to do the right things, but that there were fundamental misalignments beyond the technology. Could they have planned ahead for those conflicts? Maybe. But, as noted in one of the paragraphs, enterprise type projects have a way of taking on a life of their own even when all parties have the best of intensions - and in many projects, not all parties actually have the best intensions. Heck, I've seen projects get started and deliberately set up to fail as a counterbalance to some other project. Live and learn.
• deleted 6y ago
  [deleted]
• hertzrat 6y ago
  There are a variety of clips of Jonathan blows twitch stream where he talks about web development. He feels that it has gotten so inefficient and complicated that it now takes 20x as long to create something as it needs to. He suggested that it would be faster for most teams to create their tech stacks utterly from scratch. He further argued that once this efficiency problem gets figured out, most web jobs will disappear. This is coming from a guy who is creating his own programming language for his next game though, and who makes his own game engines Eg, here’s one example clip: https://youtu.be/yodWEPgn8NA https://youtu.be/yodWEPgn8NA
  • dntrkv 6y ago
    He sounds like someone that hasn't done any web dev at large scale. 90% of the web devs at my place of work just fulfill business needs day in and day out. Around 10% actually spend any time messing with the tooling. Sure, when you don't know what you're doing and you're working on a smaller project, you can get bogged down with the tooling aspect. But in every job I've worked with a healthy engineering culture, the tooling side of web dev is invisible to most of the devs to the point where they wouldn't know how to make a config change if they wanted. They just build shit.
  • stupidcar 6y ago
    I watched it. It was dumb. A textbook example of some major fallacies: The first is mistaking your level of desire for something to happen with the actual probability of it happening. It's clear he doesn't just think web programming is going to collapse, he wants it to happen. And it's distorted his estimation of its likelihood. I'm sure in 2030 he'll be making videos confidently predicting the collapse of web programming by 2040. The second is where an expert in one domain considers its complexity to be inherent and unavoidable, while assuming other domains, of which they are ignorant, are inherently simple. Then when they try to engage with those domains, they run into significant complexity and experience the uncomfortable and unfamiliar sensation of being an amateur again. Since the unfamiliar domain is, by their estimation, simple, they conclude that the complexity they've encountered is unnecessary — a result of people working in that domain being too stupid or inventing busywork. The third is the mistaken belief that our means will improve, but that our desires will remain the same. So, right now we have certain requirements, and in order to meet them requires us to do a lot of complicated, cutting edge stuff. But soon all that complexity will get figured out, the cowpaths will get paved etc., and we'll happily just pushing a single button to do everything we need. The reality is, of course, that our requirements will just get more complicated as well. Human civilisation has been on this treadmill since time immemorial.
• serpix 6y ago
  You just got steamrolled by .NET OOP dinosaurs, React played no part in it.
  • rafaelturk 6y ago
    This is also my understanding. Like most Enterprise projects front-end is the one to blame for problems that are actually in the backend.
  • worik 6y ago
    The experienced .NET development team got blind-sided by a script kiddy with a Java Script package fetish.
    • dumbfoundded 6y ago
      The best choice is always what the team has the most confidence with their skill set on delivering. Your framing is unhelpful. You can build amazing things with both React and .Net patterns. If you're on a deadline, you should probably stick with what you know. Every language and framework has different tradeoffs.
      • worik 6y ago
        True. My framing is unhelpful. I was reacting, emotionally, to the blaming of the old guard. I do think that Java Script frameworks would be great if they were stable. And for enterprise software - for any sensible definition - stability is a very important criterion. But it is easier to write than it is to read so they keep reinventing the wheel, keep making new, not better, things.
        • dumbfoundded 6y ago
          I think the benefit of the new javascript frameworks, in particularly React + Typescript, enables complicated webapps. Facebook is probably the best example of enterprise scale. The problem with the javascript ecosystem (other than javascript itself) is that browsers constantly change and webapps are expected to be increasingly sophisticated. The stacks can't really settle down until our expectations of what they should do stabilizes. I feel that's why we seen much less churn on the backend.
• recursivedoubts 6y ago
  It's funny, react reminds me a lot of J2EE (and other enterprise frameworks) in many ways. A very large and complex framework, with lots of moving parts and additional stuff that needs to be glued in to make it all work. There is a reaction against this happening right now. You can see it in hotwire from 37signals, Alpine.js and my own response to it: https://htmx.org https://htmx.org “Simplicity is prerequisite for reliability”
  • lostcolony 6y ago
    React feels more like the Spring Boot response to Angular's J2EE. But yes, I prefer the microframework approach.
    • recursivedoubts 6y ago
      Yeah, that's a better comparison.
  • zach_garwood 6y ago
    I recently tried advocating for using htmx for our frontend, but had a hard time even articulating what it is. Calling it a framework seemed disingenuous because, well, HTML+HTTP is the "framework," htmx is just an extension on top. At the end of it all, we went with InertiaJS with a component library -- not a bad alternative in its own right -- but I was hoping to do away with the frontend/backend distinction entirely. I hope I get to use your library in production someday, tho! Nice work!
• earthboundkid 6y ago
  Technology problems are usually just human problems behind a mask. In this case, the real problem was a poorly skilled team with bad leadership, and React just exacerbated the problems by giving the team enough rope to hang itself.
  • bluefirebrand 6y ago
    100% this. The moment you allowed the .NET devs to bring their mindset into a fundamentally different space you were going in the wrong direction.
    • Spivak 6y ago
      I mean for a greenfield project sure but a port of an existing large application that is already coded in a specific style you likely want to preserve as much of that as possible to make the translation more mechanical.
      • majormajor 6y ago
        If you're porting between two languages/frameworks with radically different approaches, preserving the original project's approach in the new code is going to give you something that's probably worse than the original! Now when you hire someone new you're going to be looking for React experience but then having to re-train them to think in .NET, or looking for .NET experience but training them to write React... and any time you have dependency upgrades, you're gonna be fighting more impedance mismatches. Most tech debt that slows down feature development has more to do with the code structure than with the language or framework, so if you're intent on preserving the structure and style I don't know that you should be doing a rewrite at all!
        • cratermoon 6y ago
          As the old saying goes, you can write FORTRAN in any programming language: https://blog.codinghorror.com/you-can-write-fortran-in-any-language/ https://blog.codinghorror.com/you-can-write-fortran-in-any-l...
• rafaelturk 6y ago
  This very misleading. Looks like .NET and OOP dinosaurs are the real culprit in your project.
• maxfurman 6y ago
  This mirrors my own experience with React. The core library itself is fine, and I love the way it bridges functional paradigms without forcing a ton of functional vocabulary on the team, but the ecosystem is a mess. And, because the React core is so minimal, eventually you need to interact with that ecosystem. JS dependency hell is real, and it's worse with React than any other framework that I've worked with.
  • nawgz 6y ago
    I don't really understand what users are doing when they say things like this. What kind of features are you trying to implement? As a React dev since 2015, things were pretty bad initially in this way - but now you can literally build complete applications with React, react-router-dom (clearly the winner in this regard), and your choice of state management (mobx 6 is, to me, the best). Redux is king and MobX is the slightly more adventurous challenger. I have built an absolute plethora of applications and I do not have any external dependencies beyond those two, TypeScript, D3, and the occasional helper library (date formatting, deep-equals, etc). Speaking to some other points as well, the React core is not really minimal at all anymore, since the advent of hooks you can actually completely bypass external state management and just use hooks and your own context. I've done this on a couple smaller applications lately and the hooks `useState` and `useEffect` are actually insanely powerful. Last but not least, React has insanely strong error messages and linting warnings. Things like non-unique key errors, debug symbols knowing the actual source of errors, stack traces enumerating thru the actual React tree so you can see your error, dependency array validation for useEffect, and more that I can't recall at the moment - it's the top library for UI for a lot of reasons and I think your opinion sounds a few years old.
    • erlich 6y ago
      > debugging / error messages I think its still quite bad for debugging. I get a lot of "look here" for errors, but there are still times I set breakpoints on the internals to try and figure out what is going on. Usually in combination with some babel plugin messing things up, or some webpack caching issue, etc. I still think more could be done here, but adding the necessary debugging stuff would bloat the core. > Redux is king Redux is quickly going out of fashion. Interested to hear your thoughts on how long you think it will remain around though or evolve. When I look at redux-saga/redux-observable projects, its incredibly verbose for such simple things. And there seem like very simple solutions on the horizon with suspense resource fetching stuff.
• vajrabum 6y ago
  I'm think I'm not able to read this story without paying. Medium seems like they are becoming increasingly a pay to read only service.
  • worik 6y ago
    Try private mode....
• victorbstan 6y ago
  Would love see people go back to posting in their own blogs instead of Medium. I get paywalled or app walled. Where I have to either log in or use the native mobile app to read the article. Medium is not a good place to share information.
• viburnum 6y ago
  220 pages! That alone makes React a poor choice.
  • rafaelturk 6y ago
    Not at all, react handles this quite well. Just use code-split per route, webpack manages this with a few lines of code
    • crooked-v 6y ago
      Also, various libraries like Next.js will do this kind of code splitting along routes out of the box.
  • cesarvarela 6y ago
    Gatsby and Next solve this issue quite elegantly.
• aeturnum 6y ago
  I mean, this feels like a classic example of not choosing the best technology for the situation. Picking a more opinionated (or more batteries included) framework likely would have streamlined a lot of the problems he described. That doesn't reflect badly on React - certainly there are teams that could have used it to implement a project of this size - but it reflects badly on the author. > I will not encourage using it for enterprise applications. Almost like large-scale projects have different requirements and the tools generally used on large scale projects (like .Net) have adapted to reflect those requirements.
• cccc4all 6y ago
  Just reading the initial scope of the requirements. This project was guaranteed to fail, no matter what tech stack was utilized. There's no future proofing in Software Development. As soon as an application is deployed to prod, it's obsolete. It must be on constant maintenance/upgrade schedule. And, the replacement project must be scoped out quickly.
• iamsb 6y ago
  As a counter point, I was almost fired for not choosing to build a SPA for an internal app which was going to be used by 3-5 people, 5-10 times a month, if that many. I worked at large accounting software provider, and internal billing system used static pricing which was changed once a year. The company wanted to move to a more flexible system where pricing can be setup based on few rules like customer type. For this the ui and backend system needed to be developed. Design I proposed was a single "monolithic" service which did everything including UI and UI was supposed to be a old style mustache templates and some minor jquery. Instead they went with pub-sub systems, 4 different microservices, a react based UI, api which used json-schema, even to send data back to UI. When I left a team of 6-7 people was working full time on this and they were about 20% done.
  • mixmastamyk 6y ago
    "old style" from the horse-and-buggy-olden-days of 2010+ :D.
    • khalilravanna 6y ago
      come hop up on the horse with yer pappy and let me tell you about the days of server-siiiide renderin’ child’s eyes widen in wonder
      • sli 6y ago
        Oh the long lost days before "server-side" needed to be added.
    • marcosdumay 6y ago
      It feels like a millennium if you have the attention span of a goldfish.
    • worik 6y ago
      https://youtu.be/ljPFZrRD3J8 https://youtu.be/ljPFZrRD3J8
  • UseStrict 6y ago
• Spivak 6y ago
  I'm surprised that you didn't pin and vendor your dependencies at the start of the project and declare that any additional dependencies must be compatible with them. Enterprise applications are behemoths that without question will take longer to develop than the current webdev lifecycle and the most important thing for developers writing business logic is structure. Coding against a moving target is a recipe for failure.
• samcgraw 6y ago
  > And I am not even considering the time that each developer spends on learning all those third-party libraries. I never saw two React projects with the same dependencies, project structure, and guidelines. This means the knowledge is not transferable from project to project, as can be the case in Angular or Vue. For a developer just looking to make the thing their design team sent them as quickly as possible, this makes good sense to me. And I get that project/file structures can be wildly jarring to an uninitiated dev - I remember looking through a Java repo for the first time :shudders: But! Isn’t there a necessary step of understanding why decisions were made the way they were? In my experience as a front-end eng, even if a previous project involves other-worldly dependencies or FS compared to the one I’m on now, if I understand the trade-offs of the approaches for the previous project, no amount of knowledge is untransferable.
• iagorodriguez 6y ago
  The problem is not about react or not react, the problem is how to align big team to create an application. If a big team is going to be working on it you need some strong opinions around it. Do not mess with the package.json. I cant stress this enough. Actually, the most important file in your whole application is the package.json. Almost nobody should be allowed to add additional dependencies because is the main point to generate chaos and problems in the long term. Also, the design system matters a lot. Have a small team working on the UI components to tailor and extend the design system. Dont allow the rest of the teams to extend the ui components with new libraries. Stick with the design system as much as you can. The rest of the teams should minimize the amount of CSS they have to write to components placement. Usually the datagrid is the soul of any enterprise application. Choose it wisely and be sure it covers as much functionality as you can and also that it is customizable on an "easy" way. There is always a team with the need of a datagrid that sorts, groups, filters the data with dynamically adjustable cells and multi header items without pagination. Welcome to hell. Use one pattern: hooks, central store, whatever you want. If at some point you have to change it you have to know which teams are using which one. Dont allow team members of the same team follow different patterns. Code reviews must take care of this. Hope this small tips help one or two teams out there. I have worked on the migration of 5 big enterprise applications from angularjs to react or from legacy desktop application to react or from server pages to react. I made a lot of mistakes that costed a lot of dollars. I have tried to learn from them. Also, dont take me very seriously, I am pretty sure I am about to discover another mistake I have made.
  • gregoriol 6y ago
    You are describing a job I really would hate: no inovation, no try. If you can't even change the package.json without getting everyone angry, it's a horrible team to work in.
    • iagorodriguez 6y ago
      Innovation doesnt come from adding a library to the package json. You are a member of a big team, not a single dev on a pet project. Innovation is on the product, not in your developer experience (unless you are creating a developer tool). Consensus to make big decisions is not the way to limit your developer skills is the way to align a team to achieve a common goal. :)
• moonbug 6y ago
  web tech really is bollocks, isn't it.
  • kansface 6y ago
    I don't understand this sentiment at all... even approximately. I've been doing this for about 15 years now. I started in the days of "This website works best in IE5" (read, only works in ie5). I wrote Macromedia Flash Apps to make animations, because that was the only option. It was awesome! I spent hours or even days making rounded corners via chopping up images and table hacks, because rounded corners seemed really important. Just laying stuff out correctly on the page and stupid browser hacks was most of the job. I personally went from spending probably 60% of my time fixing cross compatibility bugs to spending a few hours a year on it. We went from manual coding for cross browser support, to polyfills, to telling webpack to dynamically include polyfills to target the subset of browsers I care about with 2 lines of configuration. I can now determine the exact tradeoff between file size and audience reach. Yes, that came with some complexity. Yes, that tradeoff is 100% worth it. No, you do not have to use it. This is how I feel about React. I've unintentionally built my own, shitty version of React at least half a dozen times over the last decade. The last time, maybe 4 or 5 years ago now, was an online file system browser which could contain tens or possibly hundreds of thousands of folders/files. The naive implementation wouldn't load. A less naive implementation took a few weeks to implement and seconds to load. The React rewrite took a day or two to write and loaded in milliseconds. It was less code, easier to understand, and a couple of orders of magnitude more performant! Other languages don't have crazy build systems because they don't have to run the same code on multiple platforms made by multiple competing vendors on multiple operating systems for hardware ranging from a M1 to a refrigerator. If that's not you, not a problem, you can just write vanilla JS. If you don't have thousands of objects that you dynamically load that need to be turned into DOM Nodes, don't reach for React... If you just want a library that renders some DOM Nodes, thats fine too, use React and nothing else - you can even write react.createElement by hand and eschew JSX if so desired! I would not choose to go back to the halcyon days of web dev where we didn't have dependencies and dependency management because we couldn't. At this point in my career, changing web tech has lead to a productivity increase of probably 10000%. There are some pain points, but we're working on it! Web tech, fuck yeah!
• atum47 6y ago
  well, I'm on the opposite side: I failed two code interviews (before the job I have now) because I did not used React. One comment I will never forget from the feedback I got back from one of the reviewers: JavaScript vanilla is HARD to read. Another one was that I used a "global" css file, instead of having CSS in the same file as the "component".
  • deleted 6y ago
    [deleted]
• devmor 6y ago
  This had nothing to do with react, and everything to do with you rolling over and accepting what other people wanted to do differently irrespective of your project guidelines. You can't expect an application to remain easy to develop when people do not adhere to your development protocols.
• renke1 6y ago
  > “Why are file names dash-case when class names are PascalCase? It should reflect the class name, so from now on, we will name them SomePageComponent.tsx.” That's actually a common practice. Files (modules, that is) are usually named after their principal export.
• dragonwriter 6y ago
  > Quick onboarding for new team members, especially for the .NET developers working on the old desktop application. Yeah, unless you have a sufficient base of React (or at least JS) devs to shepherd this, this is obviously going to be a problem for choosing anything that isn't .NET, and the further from their existing .NET experience it is, the worse it will be. .NET is a workable web app platform, even for isomorphic apps via Blazor. If immediate onboarding of .NET devs was a key requirement, .NET was the obvious answer.
  • ezzzzz 6y ago
    Judging by the article, this project likely started before Blazor was released, however, I have to agree that .NET should have been the obvious choice. Maybe the author wasn't able to decide this, but I wouldn't consider an SPA for an enterprise app unless there was a very good reason. Stick to boring stuff that works. Leave the bleeding edge stuff for side-projects and startups.
    • dragonwriter 6y ago
      > Maybe the author wasn’t able to decide this, but I wouldn’t consider an SPA for an enterprise app unless there was a very good reason. I’m on a team that has (I feel) been relatively productive with SPAs backed by serverless microservices in an enterprise environment, but its largely greenfield. And, frankly, at this point, the major SPA frameworks are really “boring stuff that works”.
      • switch007 6y ago
        By major SPA frameworks you mean e.g. Angular?
• _coveredInBees 6y ago
  I read the comments here first before reading the blog post, and I was expecting a very different type of (and lacking) blog post based on the combination of dismissive and defensive attitude permeating a lot of the comments here. To be honest, there isn't a lot the author is wrong about. Sure, having a .NET team adapting to React is harder but nothing seemed egregious in the way they tackled things. The point about React including so little that you become reliant on a ton of external dependencies that see even more churn than the usual JS framework landscape is a very valid pain point, especially when you are building a very large application for the long-term. Granted, a lot of that criticism holds true for the entire JS scene where the churn is simply ridiculous and you have to cross all your appendages and hope for the best before you try to build a year old project. But React is especially problematic in that regard only because there are so few batteries included (which is great for small/mid sized projects, but the opposite if you are looking for stability). Ultimately though, I just shudder to think about writing large, complex, enterprise Apps in the latest and greatest JS/front-end frameworks due to the crazy levels of churn in frameworks, libraries and APIs. React now looks completely different from React from 1-2 years ago. Libraries fall in and out of favor. Some keep up with the ever changing API of the parent frameworks, others die off. It's like an entire ecosystem that has ADHD and as someone who has built several small to mid-size React and React + Electron apps in the past, that ultimately turned me off the entire endeavor (I'm an ML Engineer, but I love software engineering and building stuff for fun). I would much rather take "boring", stable languages and frameworks and spend my time honing skills that actually matter and help me as a software engineer throughout my career, rather than spend a week trying to get webpack figured out, till the next big webpack update when I'd start over from scratch again.
  • interlocutor 6y ago
    > I would much rather take "boring", stable languages and frameworks I would argue that you don't need a heavy framework to make maintainable JavaScript application. For large enterprise applications that must last a decade or more you want to use standards (such as Web Components) implemented by the web browser itself instead of third-party libs such as React.
    • 6y ago
• hyperpape 6y ago
  One thing that I realized recently is that if you have a mantra of making "data-driven decisions", then you have raised the cost of making a decision. What you then need is a tool that minimizes the number of decisions you have to make. Gartner, Rails, Spring, each try to do some of that in their own ways. That's where his 3 weeks of decisions about libraries reveals a real mismatch between React and the enterprise way of doing things. React requires a lot of decision making, and enterprises are bad at making decisions. Ultimately, the fault is with the enterprise. Sometimes you don't need official data, you just need someone with good taste to make a decision (and if your developers cannot usually "disagree and commit", that's a people problem). Save the data for the big picture stuff.
  • drinkcocacola 6y ago
    Absolutely. Think about iOS or Android (native) development. Sure, the ecosystem is quite big, however you do not have the level of flexibility that the web has. You are limited not only in terms of languages, but also certain architectural decisions are bounded by the limits imposed by Framework (the Android or iOS SDK), so there are many decisions that _are already taken_, and for better or worse you have to live with it. That is probably what I hate the most of front-end development compared with back-end or Mobile. There are too many options, and that certainly does not promote consistency within the project.
  • franciscop 6y ago
    You could also make decisions not based on data but on your experience. That's how most arts and craftmanship works, and thus why software is often argued to be somewhere between engineering and craftmanship.
• akamaka 6y ago
  I’ve built successful large enterprise apps in React, and would recommend it. Here’s how we avoided some of his pitfalls: * Small team of talented developers who didn’t always agree on libraries and methodology, but worked through disagreements to reach a consensus * Recognizing that libraries would change over a two year project, and being ready for major library migration and refactoring * Writing our own state management tools when needed. Redux is a tiny library. On a two year project, why not create your own custom state management system from scratch, one which makes the .NET people comfortable and has the features that match your project’s needs? It boggles my mind that many devs consider state management libraries to be something sacred, like a compiler, which you would never consider reimplementing yourself on an enterprise project.
  • erlich 6y ago
    > why not create your own custom state management system from scratch Normally "roll-your-own" is bad advice. But in enterprise apps I can see all you needing is an API client with normalized caching (Apollo or `react-query` for REST), and store as much of your page state in your query string, and the rest in React Context. I would reach for Recoil if React Context performance became an issue. But rolling your own comes with so much personal risk if things go wrong - not good for politics.
• flowerlad 6y ago
  > So I am not afraid of getting into a debate about why those are unusual patterns for React. I have seen some developers follow patterns just because they are patterns. Once the community starts doing things one way that's it, even if it is a dumb way, the herd mentality causes the dumb way to become established. Redux is one of those dumb ways. > Because 30% of the business logic was inside Redux-Saga, I marked it as a high risk. Business logic should be written in POJO. Plain Old JavaScript Objects. Using a library such as Redux is a dumb way, but this is the community-embraced, herd-mentality way. > I will not encourage using it for enterprise applications. Use Web Components. Using the flavor-of-the-month JavaScript libs for a large application that must live years or decades is not justifiable.
  • Gaelan 6y ago
    > Business logic should be written in POJO. Plain Old JavaScript Objects. Using a library such as Redux is a dumb way, but this is the community-embraced, herd-mentality way. Redux is really just a pattern for business logic using POJO - you have a function that takes an update and returns the new state. The library itself is about a hundred lines. > Use Web Components. Using the flavor-of-the-month JavaScript libs for a large application that must live years or decades is not justifiable. How is web components not just another flavor-of-the-month JavaScript library, and an unpopular one at that? Sure, it's part of the browser instead of something you load externally, but I'm not sure that changes things in any meaningful way. You're still tightly binding your code to something which may or may not remain popular.
    • TheCoelacanth 6y ago
      True of vanilla redux, but people using redux-thunk or redux-saga tend to bake it deep into their business logic.
• franklyt 6y ago
  The main problem I’m having here is that I can’t think of any JavaScript framework that has solved this problem. Angular is just too cumbersome, though it gets an honorable mention. Perhaps there is so much churn here because the correct way hasn’t been discovered yet?
  • nickthemagicman 6y ago
    The problem is how broken all of it is trying to work around browsers native warts. As future versions of native JS becomes better and web assembly takes over, things will probably improve massively.
    • franklyt 6y ago
      To me, it seems like the concept of the DOM might be the problem.
      • nickthemagicman 6y ago
        One of the numerous warts. Didn't many front-end frameworks create shadow doms to work around this?
• deleted 6y ago
  [deleted]
• deleted 6y ago
  [deleted]
• mcguire 6y ago
  Wouldn't it have been a better idea to break the giant app into smaller ones with well-defined interfaces?
• joshxyz 6y ago
  Honestly my primary source of headaches is also the router, the redux, the sagas, the thunks. It's always the fuckload of third-party libraries we think we need.
• mattgreenrocks 6y ago
  Unsatisfying read. It wasn't React's fault. PM was looking for blood. Dumping a bunch of devs who have little experience with the tech onto the project. Little notion of process and conventions for the app. Only reason I'm commenting is that the three questions posed by the CTO are entirely valid questions and I wished they'd been answered.
• chociej 6y ago
  That was a very interesting read and described a lot of interesting, very valid, and very realistic challenges that I could see myself running into in a similar situation. However I don't agree with the conclusion that React shouldn't be recommended for enterprise... instead I found myself thinking, gee, there just happen to be other mindsets, skillsets, management styles, and general ways of doing things, and they collided poorly here. Enjoyed reading this but a bit offput by the FUDdy punchline.
• andrewstuart 6y ago
  One of the core reasons software projects run into problems is politics - and this article is about politics. What should have happened ideally is that the blog post author would have said to the CTO: - we're going with React - you've chosen us to guide you in this - you now need to trust that my advice on standards and approach is correct - you need to get your developers to do it the way I say - if you don't, then we will be building a frankenstein React project which is built like a .NET application - the success of the project is at risk And the CTO would have been wise enough to agree and pull his people into line and give the blog post author the authority to demand things be done as he says they should be done. But that's politics and hard to do.
  • scsilver 6y ago
    Politics is the game of making incremental progress and always feeling like you left something on the table, its such and opposite skill of engineering, and yet it is the most important skill in engineering useful systems.
  • worik 6y ago
    "- you need to get your developers to do it the way I say" You have a team of developers that have a collective experience of perhaps eighty years in your organisation. Do as I say, me who just popped in and afterwards will pop out again.... That is how millions and millions of dollars are lost in this business.
    • andrewstuart 6y ago
      If a CTO engages an external company to lead them into a project using new technologies for that team, then that CTO would be well advised to accept that their supplier has the right knowledge to advise them.
    • d0100 6y ago
      Just like Riot has 200 years of experience doing their game and shit still hits the fan on a timely basis
  • erlich 6y ago
• commandlinefan 6y ago
  > the new technology’s way of doing things what I find, with virtually every "new technology" that's come out in the past 20 years is that the "way of doing things" is not only completely undocumented, but also not agreed on by any two people. I can't remember the last time I found technical documentation that even bothered to describe what problem the technology was actually designed to solve in the first place - or was even written by somebody who seemed to understand why that would be important.
• titanomachy 6y ago
  The comments about node dependencies exploding and build times creeping up over time was painfully familiar. I now work at a large company that addresses this with strong library discipline and huge investment in build infrastructure, but when I worked on teams at small- and medium-sized companies we were always plagued by these kind of problems.
• deleted 6y ago
  [deleted]
• predaking 6y ago
  So many things here indicating both a strategic problem in the org and some issues with the approach. Context: I've used both React and Angular extensively on a variety of applications, for startups and the most "enterprisey" of entities claiming to be enterprisey (the government) and came from a .NET background prior. First - GRRR. What defined this as an "enterprise" app? Facebook is an enterprise app, dude, with millions of transactions a day. Just because an app is big doesn't make it an "enterprise" app. architect was hired from outside to create a proposal for a team that had no one capable of operating in that role (and apparently the CTO as well) "He already has a development partner in India, but they lack experience in building web applications." - this is a massive red flag architect was sent away to do proposals without anyone talking to the development team to get any buy-in architect got the background of the dev team from the CTO but neither architect or CTO talked to the development team (who would be implementing) prior to doing a proposal "the technical lead ambushes me" - this is the first time the tech lead and the "architect" interacted. There's no "ambush" here; it's a failing on the CTO+architect's part to communicate to the team in advance, and perhaps at least involve the team lead CTO is against angular but his outsourced team is familiar with .NET and Java; why is there even a need for an "outside architect" to make this choice when it's only between React and Angular? "the CTO is backing his team, which is normal. He had known me for just two months, while he had been working with his team for many years." - Why is no one on the CTO's team, after many years, capable of investigating and making these decisions? Why did they need to go outside? If the plan was to continue using this outsourced team, why didn't anyone invest in their training to be self-sufficient vs a direction from on high? Why was there zero training plan? "And that’s how we end up with three ways of doing things. There is no consistency anymore." Where is the CTO during all of this?
  • predaking 6y ago
    Adding to my comment: no mention of any sort of design system for a component based library (kind of key in either Angular or React or any other component-based UI framework), no mention of the CTO or the architect or the dev team establishing consistent standards and being responsible about their use...anyway, not every problem is "technical" in nature. Sounds like this project (and company) had a lot of issues going well beyond the tech.
• bastawhiz 6y ago
  I think some of the points are valid (.Net folks are not going to have a great time working on a React codebase). I think some of the problems are a result of the decision to use Redux. Redux was very much in vogue for a while, but in every project I've used it for, it really hampers DX when you start to get stuck in on a large project. To do stuff that involves async (read: everything), you need helpers (thunks, saga, etc.) which introduce their own quirks, and require their own tools. Soon, you're up to your eyeballs in boilerplate. As for the (build-time) performance concerns, I think there's some work here. They have a _big app_. And if you're compiling a 220 page app in a single build, it's going to get slow. You'd have the same problem, though, with a native mobile app or a very large C++ app: at some point, you need folks focusing on the infrastructure bits part time. With a relatively small number of changes, they can probably make some big wins: adding build caching for local development, using an NPM proxy (to avoid downloading 600MB of deps over the public internet on every build), looking at alternative hot reload plugins, etc. That's not to say React is without problems, but I think it's worth considering that _almost any_ technology of the scale of React is going to have drawbacks, especially if you don't have someone in-house who has really significant experience making it work well. Companies like Airbnb, Facebook, Uber, etc. all have whole teams ("JS Infra") dedicated to this stuff, in the same way there are teams like Ruby Infra, etc.
  • jorl17 6y ago
    What do you suggest developers use instead of Redux?
    • brlewis 6y ago
      Not the OP, but I'd suggest using what's built into React, i.e. keeping shared state in a parent component, until you hit one of the reasons the Redux docs enumerate for using it: https://redux.js.org/faq/general#when-should-i-use-redux https://redux.js.org/faq/general#when-should-i-use-redux
    • jeroenhd 6y ago
      It all depends on the scope of the project, but if you use Redux as a way to keep a cache of backend data so you don't need to request everything every again in every component or pass everything down in props, then you could consider a system like graphql. One project I'm working on part time is switching from class based components + Redux to functional components + graphql and I must say I'm enjoying graphql a lot more than I was writing actions, sagas and reducers. I don't have any recommendations for pure client side applications though, but for those you can probably get away with using contexts and hooks for quite a lot of the state management.
• franklyt 6y ago
  An unopinionated ecosystem will soon become known a mistake in a similar vein as dynamic typing was.
• renewiltord 6y ago
  Is there a Rails for React? I use React+Redux+Typescript and it's nice but I always have trouble setting up a new project. Rails is magic in that it's all ready. React+Redux+Typescript is great. I just don't want to make decisions here. I want to just make a web app. Like how Rails defaults to ActiveRecord and friends, is there something like that for Rails+React+Redux+Typescript? I'm looking for: * Few decisions for me to make * It's relatively popular enough that there is a community around the whole thing It's a huge productivity enhancer with Rails to be able to google "Rails do x" and someone has an answer to that. If I had to google "Ruby with X library and Y other library" I think I might commit suicide because the Rust experience is like that: "Use actix-web". Ah, and how do I use that with this other tokio based library. Oh you can't, because you need to make sure the runtimes are compatible. I don't want all that.
  • crooked-v 6y ago
    Take a look at Next.js, which incorporates a general-purpose router, does all the Webpack stuff for you, has generally painless server side rendering support (but you can also build a purely client-side bundle), and has direct support for a long list of popular libraries. It doesn't handle global state, but has tested examples for Redux[1] and various other libs that incorporate the server-side rendering and static site generation functionality that Next.js has. [1]: https://github.com/vercel/next.js/tree/master/examples/with-redux https://github.com/vercel/next.js/tree/master/examples/with-...
    • renewiltord 6y ago
      Thanks for the tip! Also appreciate you had your BTC link up in your keybase :)
    • midrus 6y ago
      Yep, next is great. It leaves you only with the following decisions to take: How to do css, css-in-js etc How to build the api, rest graphql or what How to access your database How to do background jobs How to send emails How to organize the project structure How to do validations How to do translations How to do migrations Other than this, it is great.
• prewett 6y ago
  1200 dependencies?! Is this normal in web development? That sounds like a nightmare waiting to happen! I'm working with a rather large C++ project now, and it only has 40 dependencies, which I already consider pretty large.
  • drazvan91 6y ago
    Yes, but those 40 dependencies have their own dependencies ... Which leads to a few hundreds. Check node_modules
• tmpxgdqrcKFuG 6y ago
  Why not split the frontend and the backend apps into separate applications? That would help with the future proofing since if you wanted to switch to another javascript framework, you could do that. EDIT: forgot an important word
• worik 6y ago
  I have spent my morning pleasantly reading the comments here after reading the article. I am struck that a lot of us here start the comments with "I have been a React developer for [3, 4, 5] years" I think this illustrates the fundamental weakness in the approach of people in the Javascrpt Frameworks world. Billion dollar organisations build software that will cost tens of millions to develop want, or should want, more experience than that. Javascrpit, and "Web 2.0", generally have been around long enough to meet the requirements, but this churn in frameworks is enough to make anybody with a stake in organisations shake with fear. IMO plain old vanilla JS with a sprinkling of libraries for syntactic sugar (and they can be hand rolled - or use JQuery) is a much better proposition than all of these shiny and new stacks that keep getting deprecated. Web front ends are a huge boon, and the settling of basic JS syntax and implementations makes some very good things possible that were not possible twenty years ago. But the whole industry is being held back by allways wanting "better", and not accepting "good".
  • ficklepickle 6y ago
    You might assume that, but operating at the level of DOM manipulations is too low-level for a large application. They are huge productivity boosters. I agree that they are often used irresponsibly resulting in poor quality software. Poor software isn't limited to the browser, however. A lot of commercial software is garbage. Profit incentives seem to encourage software that is barely fit for purpose.
    • worik 6y ago
      I the 1990s, when I started out as a working computer programmer it used to be said that 90% of software projects failed. I have no idea what the figure is now, and now I have more experience, seen abject failure defined as tremendous success I would not be surprised if it si worse in fact and better in annual reports.
• erlich 6y ago
  I feel your pain. It was really too early for React until 2 years or so ago. Since hooks, things have calmed down a bit. I would be interested to hear from people who successfully navigated that past 5 years in JS world. I feel I would have been happier just being forced to use Ember or something until hooks came out. A ridiculous amount of time was spent on tooling, perf optimizations, and huge amounts of code is just going to go into the bin one day. I have this feeling that 2010+ has been this massive story arc and one day we will end up very close to where we started, back to something similar to jquery and vanilla JS because the platform improved. Just like how a React platform feature like context hooks deprecated Redux. For frontend, if Typescript is standardized and shipped with browsers...see ya later beefy compiler toolchains. For backend, Deno. That Typescript with its current popularity is not shipped in browsers within 10 years seems super unlikely. The funny thing with TS is that to get good typing, you start to write everything similar to Java/.NET with dependency injection etc. I resisted it for such a long time, but when you realize you want things typed, classes and all those patterns become necessary - see Nest.js/TypeORM for an example. It just makes everything cleaner and is easier to standardize patterns. The post seems to have a bit of a "holier than thou" when dealing with naive .NET developers. I think that .NET devs living outside of our JS bubble probably have a lot of interesting criticism to offer. The retort that pops in your mind is "you just don't understand...this is how its done", but if they critiqued any number of the features that have been deprecated in React - they would have been right and us wrong. And even the creator of React said that moving away from classes made it to difficult and would have preferred not to have done it. My point is that JS is a bubble and we shouldn't be so sure of ourselves. Also the fact that Apollo is the top API library at the moment, and doing optimistic updates and working with the cache is insanely complicated when ultimately you just want something like ActiveRecord on the client like how we use to do it with Backbone models. Redux and friends is also extremely verbose and complicated for no gain. I miss the simple mental model of Backbone - yeh there were problems, but at the end of the day I just want to write `User.getPosts()` and `User.setPost()` and be done with it. 90% of the time I don't actually need GraphQL selective querying and such, its just got such a big momentum and community behind it that I use it. And REST with `react-query` and `swr` is still extremely complicated. Sorry for the rant. So I wonder if anyone has taken the time to predict when all the tools we use today will eventually be deprecated.
• mpolichette 6y ago
  I don't think React is the problem here. I think communication and leadership is where fault lies. 1. Why hire a team of non-webdevs to do webdev. (on 2nd read, it appears they wanted to use the same team from the WPF app... ¯\_(ツ)_/¯) 2. If you build and treat React components and their APIs as the abstraction layer, then they're just components... who cares how they're implemented. 3. Just because the existing project is big, doesn't mean your new one has to be... split it up! 4. Redux... the root "technical problem" My hot take is that the authors technical issues probably come from Redux and not React. Using redux as the core of your application is like pouring glue on a lego set. In an ideal world this is great because everything is strong and well defined. In reality, it prevents flexibility and applies hard constraints to the entire system. That one choice of using redux effects the decisions you make in every component. You lose flexibility to encapsulate features and experiments. You're forced to bend over backwards to do things in specific ways. Redux is the JS equivalent of the Windows Registry.
  • erlich 6y ago
    > Redux is the JS equivalent of the Windows Registry. Love it. I find Dan Abramov a great guy, but it was he who brought us Redux and rose to such fame because of it, and its now considered a bad way of doing things (or maybe just a ridiculously verbose api) and caused a huge amount of pain for a lot of people (I am not blaming him tho!) Now we have hooks as a collaborative effort involving the same guy, but they feel hacky in a way, and almost like they will not last either. It really feels like this reinvention for the sake of reinvention. I can easily imagine the API I would like for managing my data layer, but its seems like we are trying to shoe-horn something into the React way when maybe it isn't the right fit and we need something else.
  • Matthias247 6y ago
    I don't think 1) is any issue. I worked on desktop apps as well as web apps, and overall I think it's mostly the same. You have some widgets, state, actions, etc - and need to connect all things together. However I could totally imagine that a team which is familiar with advanced patterns for "connecting everything together" are unhappy with the bare minimum Redux approach. MVVM can be pleasant to work with, and isn't necessarily as much of a ceremony and chore as the redux stuff. Angular 2 (or whatever version number it is now on) might indeed have made them happier.
• NiceWayToDoIT 6y ago
  Here issue is not with React but classic case of poor leadership, architecture and project planing. All issues and road blocks could be avoided just with adhering to a few guidelines. Roadblock #1: I am not even sure why does it matter what is behind the curtain, only important thing are REST contracts, everything else is splitting team front-end / back-end. Everyone can have what ever naming convention they want. If project is enterprises it means that has more than 11 people or what is considered as a high number of SCRUM team, so spiting concerns is important and necessary. Everyone does it all (all full-stack devs) just does not work. Roadblock # 2: This is due to experience, and it is up to UI team lead to decide, rest they follow. Sorry, in enterprise projects democracy does not work, maybe in the first few meeting but there you need to draw a line. Regarding dependencies, this is strictly role of one person, everyone else works on 'git pull' forbid everyone else to fiddle with package.json use lock file strictly and package versions, and you will not have any issues, each machine will have exact copies. Roadblock # 3: This is not a blocker and Hooks have solution for any kind of pattern, it is still possible to use Redux pattern without issue. Roadblock # 4: Machines can get slower, and in my team we had similar issues, but hey you cannot expect to work with 2GB in 2020, not realistic especially with Chrome sucking memory with 34 tabs open. Don't forget VS Code is built based on Chromium so basically you have two vampires on you computer. And having virtualized environment is even worse. Roadblock #5: Saga in my case was relief, if you structure correctly Redux Actions and Reducers in neat way, and if you split your concerns, you do not have any issue, in fact it was working as a charm. Again there are multiple approaches how to deal with this, even split project in multiple smaller SPAs if necessary, but at any point not issue with React but more case of PEBMAC :/sorry.
• fuzzy2 6y ago
  > Angular would have been a better choice in this case because of similar design patterns. Well sure maybe superficially. There’s classes and then… that’s it. I don’t really see any other part of Angular that would help a (somewhat) experienced (pure) .NET developer in any way. There’s no batteries-included state management either. Technology switches are hard. I don’t think the problem is with .NET specifically but with developers that stopped longing. Longing for new technologies, new algorithms, …
  • pas 6y ago
    Angular has built in dependency injection, recommends to use services to encapsulate state. Built-in services use RxJs for propagating changes by default, and following that pattern gets you very far. Especially for an enterprise app. https://angular.io/guide/singleton-services https://angular.io/guide/singleton-services
    • fuzzy2 6y ago
      Hm, right, forgot about DI. Still, RxJS is the one thing many of my peers just cannot seem to grasp. So IMHO that's actually a minus.
      • pas 6y ago
        I'd pick RxJs over Redux, naturally if a team should use whatever they're happy with.
        • dirtnugget 6y ago
          RxJS is not a replacement for redux, in fact ngrx is a redux implementation based on RxJS and Angular. It brings everything, including effects with their own plugins and it is quite a pleasure to work with.
          • pas 6y ago
            I'm aware, I'm saying that using (a few singleton) services for managing state plus RxJS to effectively propagate (state) changes into every other component/service provides a comfortable development workflow/mindset. (I find redux-like patterns unnecessarily complex.)
• mrcartmenez 6y ago
  The problem was not React it was .Net developers. Angular is worse in this regard because the .Net developers feel more confident and charge ahead writing terrible code that is only == to shite rather than === to good. Learn the fucking language first you ahhgsvsvsgsjdhwbdksbdvrievevdjajavsgwgdvshsvevejahahagagagagahgagagagagagagagjgjghgahhagagagahahhahaha
  • deleted 6y ago
    [deleted]
• satya71 6y ago
  > Indeed, React is mostly backward-compatible, but the ecosystem around React is not. Developers and third-party libraries will always use the latest features and architecture patterns, while old experiments will be left behind to die. This should not be a problem for small and medium-sized projects because you can adapt much more easily. But for big multi-year projects, these experiments can be a deal-breaker. I really wanted to use React for my current project and it would have sped up development. But I was afraid of this attitude of breaking things that pervades the ecosystem. I'm using HTML + Alpine.js. It's more work, but no breaking changes in libraries so far. I'm still not sure I made the right call. Only time will tell.
• dirtnugget 6y ago
  It’s sad that Angular still has a bad reputation from AngularJS. Basically all the pain points the author mentions (deciding on router, DI, http client, working in multiple teams, reliable hot-reload, deciding between class or functional components, whether or not to use hooks) are all things in which angular shines. They could have saved a ton of money here by choosing Angular over react. In fact in comparison over the last 5 years, angular has been much more consistent whereas react has become a scattered mess.
• ivanb 6y ago
  Some of the performance problems on Windows are related to always-on antivirus. Exclude your project directories from antivirus scan and you'll see the difference. JetBrains IDEs now even have an auto-suggestion and an option to do it directly from the IDE.
• Chyzwar 6y ago
  In my opinion you need to have a dedicated Tools engineer in teams above 10 people. Most developers are poorly prepared to debug build/perf issues. A lot of author issues could be reduced by using right tooling. - eslint for style - Webpack Externals/Module federation for build times - Dependabot/renovate for automatic dependacies - codemon for automated refactors - WSL2 or vagrant VM + docker-compose for local dev You need someone that like tinkering with this stuff instead of doing Jira points game. Give that person autonomy and your team would move faster.
• valand 6y ago
  https://news.ycombinator.com/item?id=25874105 https://news.ycombinator.com/item?id=25874105 The article pictures conflicts from different programming cultures. There isn't any attempt of acculturation mentioned in the article. Acculturation is important to keep everyone in the same page on what's the added value of React. You don't need people from .NET to get culture conflict, frontend dev that haven't got any previous experience with React and the likes, those who operates with jquery and left frontend world, for example, will also introduce culture conflict. In the near beginning, "Where is the dependency injection? What do you mean by ‘There is no need for one?'". The React developers seem to also not aware what's the significance of dependency injection, therefore the culture acknowledgement goes both way. While the term came from heavy-OOP environment, dependency injection can take a different form. In React's world, it can utilize context or types from common module. Dependency injection is crucial in flattening deep components surfaces, which in turn makes them testable. And it's not exclusively for the React part. Testable code (with actual tests at STRATEGIC PLACES) makes it easy to increment on, because validating if the added code takes less effort. (Although automated tests at NON STRATEGIC places can make it worse). “Why is the development slowing down?”. I can imagine the author's frustration when "They want to use the .NET guidelines and design patterns in React". I've been in and out some cultures, React, NodeJS, Java, C#, C++, Golang, Android, Game development, Game Engine, Ecommerce, Identity management, Crypto, LL/system programming, infra. I can say that without running around and having enough persistence to break and remake cultures while avoiding ineffective compromises, things will not work. CTO losing his temper and blaming for what's decided 2 years prior seems like either things have gotten a bit out of control or the environment is a bit toxic. That is if the story is told accurately. Maybe CTO has been constantly reminding the author along the way but only the climax is told because it is peak emotional. Either way, observability and control over the project is lacking. Also the added values of React and other dependencies being included in the project as the main UI library is not communicated well. There are a lot of "should we use [x] lib" going on. The easiest principle is if a module changes a lot, don't depend on any lib that locks it in. "Redux-Forms, Formiq, or Final-Form?" This smells, just because without delving deep into the library, Redux-forms seems to tightly couple redux state with, well, forms, which is, in React environment, usually closer to the UI side rather than the core logic side, and you want UI and logic layers to be able to change a lot relative to each other even if they don't. On Redux: Redux itself was a weird long-running phenomenon. Its placement relative to other components is a big misunderstanding. It's supposed to be a state container that can be either local or global, but the default `connect` API stamps it as a god object permanently in the eyes of the ecosystem. Not to mention countless of medium articles that encourage the pattern. Its "middlewares" such as thunk makes stories hard to write as a single top-to-bottom functions. In one project we identified the risk of misunderstanding as a problem early in the project, therefore redux is removed. We didn't even got to touch redux-saga. We had to find a replacement, which is unstated and custom typed event emitter. This buys us code explicitness, loose-coupling, less processes on increments, more accurate types (redux doesn't play nice with typescript's type system), but we had to pay with writing a lot of types (we are using typescript). It teaches us the concept of message passing ala kafka/rabbitMQ, as well as the importance of immutability, which is the core of redux, without redux API bureaucracy. On React hooks: React hooks was a departure to a more (a bit forced) functional programming. Some concept introduced is good as it encourage us to write in automata-based programming style. Automata-based programming https://en.wikipedia.org/wiki/Automata-based_programming https://en.wikipedia.org/wiki/Automata-based_programming But it has bad API design too. For example `use*` can't be written inside `if`. So are custom hooks. We have to be very careful to not place any hooks inside `if`. Writing with hooks needs either: 1.) experienced hooks developers, 2.) linter. You can install/write the latter as long as you become the former, which is a paradox. Had it introduced hooks as below things would be a bit better. ``` const SomeComponent = makeComponent( ({ context, props }) => { // context supplies useState and useEffect like APIs return ( <ChildComp /> ) }, { [stateName]: defaultValue } // the default state ) ``` The worse part of hooks introduction is that React's culture diverge, and so its users. A company can have people with and against hooks. About the title, it should be "Using React the wrong way created roadblocks in our enterprise app".
• jlbooker 6y ago
  > He already has a development partner in India, but they lack experience in building web applications. That was never going to go well. > They want to use the .NET guidelines and design patterns in React. Yes, you have .NET developers trying to be web developers. Totally different skill set. That's not going to go well, or quickly.