by andreiursan on 1/22/21, 5:50 PM with 290 comments
by iagorodriguez on 1/22/21, 7:30 PM
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.
by _coveredInBees on 1/22/21, 7:47 PM
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.
by iamsb on 1/22/21, 7:27 PM
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.
by andrewstuart on 1/22/21, 8:10 PM
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.
by hyperpape on 1/22/21, 7:50 PM
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.
by maxfurman on 1/22/21, 7:11 PM
by yummybear on 1/22/21, 7:06 PM
by hertzrat on 1/22/21, 7:09 PM
Eg, here’s one example clip: https://youtu.be/yodWEPgn8NA
by recursivedoubts on 1/22/21, 7:10 PM
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
“Simplicity is prerequisite for reliability”
by ourcat on 1/22/21, 7:07 PM
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.
by earthboundkid on 1/22/21, 7:10 PM
by samcgraw on 1/22/21, 7:29 PM
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.
by dragonwriter on 1/22/21, 7:45 PM
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.
by NiceWayToDoIT on 1/22/21, 11:22 PM
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.
by serpix on 1/22/21, 7:09 PM
by aeturnum on 1/22/21, 7:23 PM
> 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.
by predaking on 1/22/21, 8:36 PM
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?
by commandlinefan on 1/22/21, 8:11 PM
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.
by devmor on 1/22/21, 7:42 PM
You can't expect an application to remain easy to develop when people do not adhere to your development protocols.
by bastawhiz on 1/22/21, 8:42 PM
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.
by worik on 1/22/21, 10:39 PM
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".
by mpolichette on 1/22/21, 10:48 PM
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.
by atum47 on 1/22/21, 7:41 PM
by akamaka on 1/22/21, 7:51 PM
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.
by flowerlad on 1/22/21, 7:52 PM
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.
by poulsbohemian on 1/22/21, 7:08 PM
by vajrabum on 1/22/21, 7:16 PM
by renke1 on 1/22/21, 7:43 PM
That's actually a common practice. Files (modules, that is) are usually named after their principal export.
by Spivak on 1/22/21, 7:28 PM
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.
by titanomachy on 1/22/21, 8:15 PM
by satya71 on 1/23/21, 3:27 AM
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.
by rafaelturk on 1/22/21, 7:11 PM
by Chyzwar on 1/23/21, 10:12 AM
- 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
by tmpxgdqrcKFuG on 1/22/21, 10:29 PM
EDIT: forgot an important word
by dirtnugget on 1/23/21, 9:58 AM
by chociej on 1/22/21, 8:07 PM
by fuzzy2 on 1/23/21, 12:17 AM
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, …
by mattgreenrocks on 1/22/21, 8:06 PM
by viburnum on 1/22/21, 7:20 PM
by jlbooker on 1/24/21, 2:52 AM
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.
by ivanb on 1/23/21, 10:02 AM
by renewiltord on 1/22/21, 9:21 PM
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.
by victorbstan on 1/22/21, 7:19 PM
by prewett on 1/22/21, 9:59 PM
by joshxyz on 1/22/21, 8:03 PM
It's always the fuckload of third-party libraries we think we need.
by sergiotapia on 1/22/21, 7:06 PM
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.
by mcguire on 1/22/21, 8:00 PM
by franklyt on 1/22/21, 9:11 PM
by mrcartmenez on 1/23/21, 1:55 AM
by franklyt on 1/22/21, 7:53 PM
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?
by valand on 1/23/21, 1:40 PM
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
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".
by erlich on 1/22/21, 10:48 PM
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.
by moonbug on 1/22/21, 7:39 PM
by cccc4all on 1/22/21, 7:24 PM
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.
by flyinglizard on 1/22/21, 7:07 PM