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.
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.
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.
> 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.
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
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.
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.
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".
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.
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.
Why does it really matter if the code you write is browser friendly or not? Everything is transpiled to browser code anyways, that includes Vue and Angular and JSX.
None of the code you write is ever really touched by a browser anymore. At the very least it's minified.
Something that needs 3 or more layers of transpilation...is not right. Typescript to Babylon to JS. Sass to css.
These are workarounds for native JS warts.
That's why Im excited about NATIVE web components and future releases of JavaScript becoming sophisticated enough that we can ignore all of this framework insanity.
Or even better...web assembly somehow taking over and making all of this pointless. Native Typescript. Yes please.
But to address your point, you're locked into JSX a lot more than someone writing in native browser code that doesn't need transpilation and can be ported between other frameworks at the end of the day.
> But to address your point, you're locked into JSX a lot more than someone writing in native browser code that doesn't need transpilation and can be ported between other frameworks at the end of the day
Not really, because at the end of the day you still have to write the HTML and CSS and everything to render anything in a browser, the JSX really just gives you a new way to compose it.
Now if you're using other styling frameworks that provide their own components, you might not have access to that HTML but that's not a JSX problem that's a "you are too reliant on outside dependency" problem.
Also, transforming code into a runnable form has been a part of programming since we first invented compiled languages. Your comments about transpilation seem really bizarre with that in mind.
Compiling has. Transpiling is much less common and seems to me to be an anti pattern or a sign that something's not correct in what you're building on top of.
I think in 10 years we are going to see a lot of stuff built into the web platform. Typescript definitely now that MS is using Chromium. Then we have Deno for the backend.
One day in the future a kid will be learning programming, and not realize the billions of lines of tooling, or the hundreds of thousands of hours of thought that was put into working around an inadequate platform. However, a lot of this will have been necessary to get to the end result. But also a lot will not have.
How is magically hydrating a DSL extension of HTML any better than using JSX? Arguing about "non-native browser functionality" doesn't make any sense to me, your Angular app doesn't work until it's com-trans-piled into the same HTML/CSS/JS output that JSX produces...
Oh I agree. It's all insane. Ready for native web components and/or web assembly to become mature and get rid of this JS framework, 5 layers of transpilation, nonsense.
But to address your point, you're locked into JSX a lot more than someone writing in native browser code that doesn't need transpilation and can be ported between other frameworks at the end of the day.
I really can't understand what your objective is here. Frameworks are going to exist in every single language. Do Python developers say "I cant wait til Pandas isn't part of my workflow"?
I also will challenge your sentiment that JSX locks you more into a framework than writing DSL extensions of HTML. JSX is supported by quite a lot of frameworks, so you aren't locked into React; additionally, React is the best UI library; additionally, JSX is pretty semantically clear with what HTML elements your functions are binding to and what events they're paired to, so in either case you have to rewrite code for your new DSL. Going between Vue and Angular isn't going to be simple.
"JSX is supported by quite a lot of frameworks, so you aren't locked into React"
Just not the browser natively....
Most backend frameworks don't need numerous layers of transpilation because they're on an actual OS and arent trying to work around an insane environment like the browser that's full of warts and incompatibilities.
What's the churn on Pandas? It's been around over a decade. And it can probably be reliably counted on to be around a decade more.
It will be surprising if React is around in 5 more years and hasn't been replaced by something else.
Is EmberJS still around? How much longer will webpack be around?
Stability in the browser ecosystem starts with stability in the browser.
I think instead of investing all this energy into browser frameworks we need to be devoting energy into making the browser do what we want it to do natively.
And as web assembly matures that's where I think this is headed.
Most backend frameworks need literal compilation - all that's different here is that the target is a specific JS version, not machine code. Additionally, there's a bit of "naivety" here - browser vendors are the ones that implement native features, and that's clearly not a domain that a random developer can impact. Instead it's JS frameworks and associated tooling, which is all very strong now. The idea that Angular or Vue are somehow going to work in the browser directly is, once again, absurd, and please stop saying it.
> What's the churn on Pandas
I find it silly that you'll cite Pandas as not having churn when its parent language just underwent a large, painful, poorly received transition.
> It will be surprising if React is around in 5 more years
You are saying the same things people said 5 years ago about React. My React code from 2016 still compiles against the newest version of React, and works correctly.
Honestly, you're a classic example of this - you started developing not in JS, you felt some warts of JS, and now you hate JS and are ready to throw the baby out with the bathwater.
I'll be more surprised if "native web components" or "webassembly" are actually supporting production use cases in 5 years than if React is.
> "JSX is supported by quite a lot of frameworks, so you aren't locked into React"
> Just not the browser natively....
Angular's *directive and [weird] (binding) [(choices)] will never be supported by the browser natively either. The fact that Angular uses an HTML file extension is a delusion (they really should have picked a different extension, it's such an ugly lie) that the templates will ever be more portable than they currently are. Sure, you generally have better raw copy/paste behavior of real HTML into Angular's templates than JSX, but if you think the mess that is the average Angular template will ever be portable to "native browser functionality", I may have a bridge to sell you.
I think it is a worse anti-pattern than JSX: JSX at least uses its own file extensions and doesn't pretend to be HTML. Angular uses the HTML file extension and in my experience confuses a lot of people into thinking the "Angular Template Language" is "just HTML" when it very definitely is not.
I hated JSX when it first came out and thought React wouldn't take off because of it, then I used React for 5 years, and I still hate JSX.
I write all my components like this:
const props = {foo: 1, bar: 1}
<MyComponent {...props}>
{children()}
</MyComponent>
function children() { return foos.map(b => <div>{b}</div>) }
Why do I have to use a weird language with non-standard JS stuff. Writing conditionals in JSX is horrible, and props are unnecessarily verbose when we have ES6 language features like structuring.
Full flexibility means full responsibility. If I write sh_t, it will be sh_t and no one can stop me.(well, you have the full power of a turning complete language). Unfortunately not every team can afford it without trashing their code base eventually. (And yea, I don't even have the confidence that I won't. And even I do, what about teammates?). I always thinks having too much flexibility here is sometimes cons instead of pros.
All the React routers I know of support lazy-loading well.
I'd argue far better than Angular handles it. React components tree shake extremely well out of the box and I've rarely had to worry about bundle size when lazy-loading in React. Whereas Angular's dependency injection framework and its "modules", in addition to being irritating busy work as soon as you realize you can't trust the CLI's scaffolding, do nothing but get in the way of proper tree-shaking and good webpack chunks/bundles.
Angular is opinionated and comes with batteries included. Not counting the AnguarJS mess, Angular has been extremely stable.
With a small and dynamic team that loves functional programming and reactive state management, React is great. But in larger enterprise projects with many experienced Java/.NET devs, Angular just seems to be the better choice to me.
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.
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
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.
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.
> 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
Like the data science guy I worked with who complained we were making authentication and access control complicated.
While I like your argument about requirements getting more complex in the future, if we are speaking of fallacies, the much of what you said is an ad hominem and mind reading.
The argument basically comes down to whether web development is or isn’t slower than it should be, and whether it will become dramatically faster to do in the future
Not to be overly dismissive, but I'm not all that worried about the opinions of a guy who works in a totally different branch of the discipline and also releases one product per decade.
> it would be faster for most teams to create their tech stacks utterly from scratch
I actually agree, but maybe not for the same reasons he gives. The problem with modern tech stacks is that, yes, they're insanely complex, and each of the dozen or so individual components has dozens if not hundreds of its own hidden expectations about what should be where and what it should look like. As long as you meet all of those expectations, everything works magically like it should, but as soon as you miss one, you'll be lucky if you even get an error message that you can google the solution for.
There are two efficient ways to solve this: 1) no dependencies, build everything from first principles that you already understand. Then, although there will be plenty of assumptions baked into the code, you'll know what they are and how to deal with them because you put them there. 2) take advantage of pre-built solutions, but actually read and understand the docs before you rely on them.
The second solution depends on two rarely present preconditions: one, the docs actually exist. Two, management understands that it takes more than twenty minutes to realistically absorb 500 pages of dense technical documentation.
What we end up doing as a workaround is using the off-the-shelf stuff without really understanding what it's doing (or are you telling me that you understand the 9000 files that are installed by NPM? I'm not exaggerating, BTW, go take a peek). We cross our fingers and hope that we got all the assumptions right, cut-and-paste solutions from stackoverflow, and let the horrifically inefficient solution take the place of actual engineering because the "timelines are aggressive".
The web is just a way of delivering software to users. I think the person speaking in the video is worrying way too much about putting developers into boxes. At the end of the day, there are many problems in the world that can be solved with software.
> What most web developers spend their time doing is useless busy work that is not actually objectively necessary in order to create the functionality. It's just dealing with a bunch of weird conventions by some other software that they are trying to use that are there because some other other weird conventions by some other software that they are trying to use. If you just strip all that crap out, you can be tremendously more efficient.
Not only is this a very arrogant sentiment, but his reduction of all web development down to manipulating "weird conventions" doesn't fit with my experience. I don't sit around all day messing around with Webpack configurations or leaning new frameworks. I deliver software that addresses business needs, that happens to be accessed via a web browser.
He also says that jobs with the title "frontend", "backend" and "fullstack" for the web are not safe jobs. Many game developers, operating system designers, and large desktop applications will also have "frontend" and "backend" separations of responsibility as well, because they often involve different skill sets or knowledge.
The guy's clearly a genius but he's also an asshole. Bigger projects across multiple disciplines require collaboration and communication, which inherently add complexity and cost. We're not all savants building indie games, so we use other people's work in things called libraries and dependencies.
Things got more complex because the problems got more complex. Creating a stack from scratch is something that a contractor would suggest to a company, so then they will have full bookings for fixing those. I was at couple of companies who were React/Angular/.NET shy and their CTO wanted to show off building ultimate framework that will make company millions. Every developer had to spend weeks figuring out how to use it and then they always f up something. One gone bankrupt another is rebuilding everything with React...
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.
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.
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.
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
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!
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.
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.
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!
I've worked on stacks with .NET backends and React frontends, and there's a ton of truth to this. You can't use .NET concepts to bridge into an understanding of React. If you need to carry over .NET's paradigms, don't pick React.
Personally, I think if you want a deep understanding of React you need to first get in a few cycles of working with DOM, JS, CSS, etc. directly. Maybe throw in a functional programming language too. Then try to pick up React.
This really does nail it. Despite React having a somewhat OOP approach to a lot of things (and Class Components being the de facto for years), React best practices have evolved to be a very functional approach.
.NET wakes up every morning to have OOP pancakes OOP eggs and OOP coffee and it can't possibly allow even a hint of that beatnik functional style near it.
> .NET wakes up every morning to have OOP pancakes OOP eggs and OOP coffee and it can't possibly allow even a hint of that beatnik functional style near it.
I agree for the most part. More specifically you're not going to write functional code in C# and feel particularly good about what comes out. F# is a different story.
Speaking from experience a .NET (C#) backend and a React frontend is perfectly viable. The key is to keep the paradigms in their respective lanes, and if you're going to write code for both, get used to switching your mindset instead of converging the tools.
Is this actually advantageous though over class components? The creator of React said he thought moving to functional components would make it harder for people to learn.
I've found that sometimes hooks can make things less flexible, more verbose, more error prone, and harder to reason about. Sometimes a class might have made things easier to understand.
I loved the fact that `useEffect` could modularize code that was otherwise split between `componentDidMount/Unmount/Update`...but couldn't a new class API also have solved this.
Maybe I just need to read the docs again to remind me. I'm all in for hooks, but it's rare that I think about what life could have been like if we kept class components.
The trouble that React has to deal with is that JavaScript lacks good built-in support for pure functions and immutable data. Hooks are an opinionated way to make React work more like FP, and there are still gotchas because of JS’s lack of enforcement.
“Advantageous” does not necessarily mean “easier to learn.” I’d say that for people coming from OOP, FP style is certainly unfamiliar and takes more getting used to. But for a front-end program that must always receive/send data to hand wave some other systems in order to do anything useful, it makes things much, much simpler. A whole class of problems disappears. The closer it gets to (state) => UI the easier it is to reason about and debug.
I still think that Reagent, the Clojurescript wrapper for React, is the best version of React available. All of the state management is handled by CLJS itself, and the language design prevents accidental mutation. You can still mutate things where appropriate, but it is always an intentional choice. A framework like re-frame takes this even further, with similar ideas as Redux but with better language support for and enforcement of the paradigm.
> Is this actually advantageous though over class components? The creator of React said he thought moving to functional components would make it harder for people to learn.
At the end of the day you just end up thinking of the chunks of JSX and how they map to parts of the DOM, and who cares if those chunks of JSX are wrapped into a function or a class...
I'm still kind of stuck on the fact that they brought a team of .NET devs on to do a React project. What did they think was doing to happen when they used a team with no experience in the technology stack chosen? The conversation should have started with "What skills do the implementation team have?" before tech was chosen.
Is there a frontend framework you can choose that suits .NET devs? Maybe this would have been a better choice if there was. Maybe Angular was better. Or Ember.
Well said. It was frustrating how little he talked about the actual problems with the codebase, instead choosing to handwave and blame it all on React. The dig on the React team in particular was bizarre:
> React’s team enjoy experimenting with new ideas, but this is killing the ecosystem! They should be brave and take the blame for it!
Have to make a lot of assumptions with this sort of thing, but I can't imagine that attitude results in high quality engineering work.
Maybe the team is a bunch of n00bs, so what? Wouldn't the perfect framework/language make it hard[er] to screw things up regardless of the lack of dev skill? For a big multi-year project it often strikes me that the best tools are those which are old, boring, and unlikely to change.
That being said, huge-multi-year development in _any_ js framework seems terrifying to me because of the churn in the general js/browser environment.
Also: I think the author doesn't cover this a lot, but it sounds like they REALLY saved their bacon by doing the boring due-diligence of carefully documenting the decision process behind all the choices they made. They probably would have had slowdowns and surprises and roadblocks no matter what, but someone's still got a job because they took time to get it in writing.
Does JS really churn more than other environments? I first saw React in production at work in 2015. That’s almost six years ago. Before React, sure, there was a lot of churn, but there has been a huge time period in which no one got fired for choosing React plus Webpack.
At that same job, our app team was switching to Swift for its new code, which no doubt has had considerable churn since then, since it was before ABI stability or SwiftUI or whatever (I’m not a Swift dev so just guessing from the outside on the specifics).
At some point one has to see the trend of all these people hanging themselves with this one platform and maybe there's something to the platform, ecosystem, or community that is lending itself to the hangings.
You're just making the author's point for them. A more opinionated framework that matched the team that was supposed to code with it would have worked better for them over the lifecycle of the project.
Most enterprise teams are poorly skilled with bad leadership. Modern frameworks and coding paradigms are a bad fit.
> A more opinionated framework that matched the team that was supposed to code with it would have worked better for them over the lifecycle of the project.
No it wouldn't, not for an enterprise application that is supposed to last a decade or more. Instead you want to use standards such as Web Components that will last essentially forever.
Now that's just silly. Longevity of the enterprise application is of no concern at all. The only things that matter is on-time and on-budget. If you can't deliver that, then you run into the problem the author of the article ran into, his bosses yelling at him and his career and job in jeopardy.
If the project develops issues after all the initial stakeholders have moved on, it's the new stakeholders' problem.
Not everything is a problem. If you design a language and only one human in the world it able to learn it. Then this is not a people problem but a language problem ! You can't control the skill of the team, this can't be the problem this is a fact.
Well said. I went through the whole article and it just seems to me that instead of asking .NET devs to build a react app, you could have just hired react devs and none of the problems would've existed. Or have the entire team go through a proper react bootcamp. As a dev, I can say for sure, devs not learning new things and keeping up to date are the worst. The ones you need are the ones who try new things and then create solutions that are best fit for the problem with a rational mindset. Pretty much everything else will slow your development eventually, be it react or something else.
Bootcamps are just ways to extract money from the pockets of Enterprises with more money than sense. I worked on a project with some COBOL programmers who went to through a "Java in 21 Days" program. They were decent COBOL programmers, I actually learned some useful things about that language and the IBM environment. But Java programmers they were NOT. https://thedailywtf.com/articles/The_Brillant_Paula_Bean
It actually depends. Sure there's plenty of ones that are complete garbage, but well structured ones work well, especially in two situations: 1. For people who have 0 coding experience to get introduced to how to start coding and where to look to learn more 2. Experienced devs who need a good overview of a new technology that they can further explore more on their own. It's not a bandaid, do a bootcamp and you'll be gods kind of a solution.
Yeah, but Enterprises with more money than sense aren't going to pick the good bootcamps, they're going to go with whatever gets the highest rating in Gartner's Magic Quadrant, or whatever one is run by the guy who golfs with the CEO.
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.
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.
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.
> Usually in combination with some babel plugin messing things up
To be honest with you, you can't really blame React in this situation - it is nonetheless immensely frustrating to be sure.
> Redux is quickly going out of fashion
Yes, when I say it's "king" I only mean in terms of popularity within the community. I personally never understood the point of Redux and have always greatly preferred MobX for exactly what you say - it is far too verbose.
I also don't really have a good read on how the future of these projects will go - I would have thought MobX would've won out long ago. Maybe now with MobX 6 moving away from decorators it can gain the steam it deserves. I think the key blocker has been / is that MobX is building a runtime graph, and people don't understand graphs (let alone dependency graphs) very well, so it feels like magic. It's really easy to use though.
With features like Suspense, I feel like React will continue to push for more concise ways to write your components, but I also wonder if even the one level of misdirection that Suspense shows will be enough to limit its adoption. So far, explicit and non-magic seems to be a strange community preference
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.
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.
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.
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.
Are you me? We had an (admittedly more complex) monolith application for customer contracts and billing. It wasn't ideal, and was getting long in the tooth (think Perl Catalyst and jQuery), so the powers that be wanted to build a new service. But instead of decomposing the monolith into a few more loosely integrated services, they went way overboard with 20+ microservices, every DB technology imagineable (Oracle RDBMS, Mongo, MariaDB), a full message bus via RabbitMQ, and some crazy AWS orchestration to manage it all.
What could've been an effort to split the existing service into manageable smaller services and rewrite components as needed turned into a multi-year ground-up effort. When I left they were no where near production ready, with significant technical debt and code rot from already years out of date libraries and practices.
IMO the real failure here was not having an internal administration website with all the auth and API plumbing already set up, which you could tack a new page onto with minimal fuss, and a backend to tack a new API endpoint onto with no hassle.
If you're building a new internal webapp from scratch for a small internal use-case, you just end up with a hundred different poorly-maintained apps.
But in the situation where you're adding a page to an internal app, it's trivial to make that new page a SPA React app, since the framework is already there waiting for a new component.
If you join an early stage startup today, it will only be a matter of time until a developer comes in who builds a microservice for what would normally be a single function calling a third party api and then discovers that Kubernetes is necessary. Its almost impossible to stop this happening because business folk want microservices, or they might have heard microservices were going out of fashion but still want Kubernetes...which is only really necessary for microservices.
Devs like to have fun, learn new things, play with complicated things - that's all it is. It counteracts the dull features that most developers have to ship.
I have met enough devs that don't necessarily love to make everything Dockerized microservices on Kubernetes, just that if we don't learn this stuff we risk becoming unemployable.
Sounds like my current project. I was tasked to start working on a project and was told I could use "whatever [I] want." So me and the other frontend guy started working using Clojurescript with Reagent and Re-frame (highly recommend). Save for a few hiccups along the way the project was stable and fast.
It went swimmingly right up until QA was more or less told not to file any issues found, and then those issues were used as a reason we needed to use a TypeScript and Material-UI app he wrote over a weekend and said was "almost done." The bugs in question turned out to be minor visual bugs, and like I said, none of them were filed or even mentioned until this replacement got dropped in our lap. In fact, no problems of any kind were reported until this moment.
Instead it took another 6-8 months to get to feature parity with the app we'd already developed and now thrown away (or feature "parody" as my boss put it), it was full of bugs, development is slow and pretty directionless, my boss gets bored and contributes code that runs in the O(n^12) range (yes, really) before languishing in a draft PR for months and then getting dumped on us to actually implement for real, and it's been a year and a half with no end even remotely in sight.
I really want to find somewhere else but that doesn't seem like a realistic goal right now. Not to mention my enjoyment of programming died years ago and I haven't written code for fun in as long as I care to remember.
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.
> 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.
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.
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.
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. :)
I love this way of phrasing it. I have these types of arguments with a particular type of colleague often, and this is a missing part of my explanation script.
It's been awhile since I've worked with npm, does it still do that thing where it changes package.json every time you `npm install`? I remember writing a script to discard package.json edits because my PR wasn't supposed to upgrade any libraries.
I never recall it doing that, you may be thinking of the `package-lock.json` which does get created still. It basically creates/records hashes of the packages that get installed when `npm install` runs. Shouldn't always be changes there but depending on how version flags are set in `package.json` an `npm install` could create new `package-lock.json` values if there's a newer version in the repo that gets upgraded/installed.
We have a private local package repo at my company. Some developers set up their npm registry, or had it set up for them, with registry=https://.. Others have registry=http://...
Regardless of whether or not Strict-Transport-Security is enabled on the server, npm will still record the protocol as-is in the package-lock.json file.
Half the time a PR will include a package-lock.json with every "resolved" field having the protocol gratuitously changed to the other protocol.
We have a pretty similar issue at work where our package-lock file switches URLs between npmjs.com and our own npm registry. Can you elaborate a bit on what the issue is and how to solve it?
The issue is that some developers have configured the registry field in their .npmrc file incorrectly. Ideally, sending out a memo telling everyone to fix it should do it. If not, one way to fix it is to commit the .npmrc with the correct configuration (assuming it doesn't include secrets). If all else fails, an ugly hack is to make a preinstall hook that fixes the .npmrc file.
you have to use `npm ci`, which was added a few years ago. my team ran into that kind of issue right after `ci` was added, thankfully, or we would've had to do something similar.
i now have this aliased to `ni`, so i get to say `ni` to the app often.
One of the keys for a successful migration is the strategy. It doesn't make any sense to re-write the whole platform and launch the new one after a year of work or so. Adoption is super important so an incremental migration is a key (you start coding as other teams get onboard in the migration). A microfrontends strategy could be a good idea.
Internal support from eng teams is a must, without that the migration won't work.
> If a big team is going to be working on it you need some strong opinions around it.
You are just stating the problem the article complains about.
Whose opinions are those? You need to take a lot of decisions.
Moreover, those decisions which seemed good (to you...or the one that dictates those strong opinions) at the time you took it, are not valid just months or years down the road. So you will need to reevaluate them periodically.
Moreover, even if you are happy with your decisions, you might be forced to take them again, because the library went out of fashion, unmaintained, or the developers just stop responding to issues and ignore you completely. This is already happening to a project I work with where the react-router developers just went to build their own nextjs competitor and stopped responding to issues. Same with styled-jsx from the same next.js team, not even themselves seem to be using it anymore.
This never happened to me using Rails. True some gem might go away, but at least it usually is some helper thing and not the core of my f*ng application. Same experience with django and many other uncool stacks.
So, yes. React is amazing if you are facebook, google, amazon, building a side project or just working for your own resume. It is not good for the average business. It is not good for enterprise applications.
I am a rails developer myself and I love rails, but this applies to rails too. Actually rails lowers this problems a little because it is an opinionated framework but you could same to Angular for frontend. In react case, you just have to build that yourself with the pros and cons.
the person who has the authority to call the shots and leads the project.
The error is right there in the article:
"After nine months, we have more than 50 pages created. The developers notice that function components are as good as class components and start using them. So, now the project no longer follows the original coding guidelines. It’s more like a personal choice for each developer. And for me, that is OK."
This is where the screw up happens. This is not okay, and as the person responsible for the architecture the author should have made a clear and concise decision and then get everyone to comply with it. You cannot let your developers run wild and then complain a year later when everything is a jumbled mess. Even more opinionated frameworks won't save you because the application is so large it likely would have happened regardless.
This was my biggest take away from this article too.
When you have a big project, you have to keep a consistent architecture. You need to keep using the same tools and patterns so that you have cohesion in your code base.
The worst thing about new architects on long lived projects is you typically get 2-4 ways of doing the same thing. If you're going to do that it needs to be so good that you don't mix and match.
If you are going to mix and match, you need to have a solid approach to splitting your dependencies, one way I'd have looked at doing this is by splitting this into multiple sub SPA applications and each mini project would be able to conform to it's own standard as long as it could interface with the glue application, this is by no means foolproof, but it gets you a lot closer to a maintainable situation from my experience.
Why I like this approach is that I saw a comment from someone saying they'd hate to be on a team with a uniform style. I completely get that, innovation is super important, but you have to build boundary layers between the different styles so you don't end up building such a hodgepodge of dependencies that you can't get things to work anymore. It also keeps your build times down and reduces time to get started working on your module.
Again same comment you made, I've made mistakes, trying to learn from them, maybe my current approach is bad too and there's a better way.
Use a monorepo with many `package.json` files. Then someone working on a data grid component for example can add the packages they need for that component and no one else's code will depend on it and it won't break anyone else's.
I’m sure you make this comment in good faith, but no - every React project I’ve been part of sounds very similar to this. The others, not so much, and I’ve been doing frontend for over a decade. There is a distinct amount of churn and excess of dependencies / eternally unsolved problems that is particular to the React ecosystem.
Note that your suggestions do not address the main problems: time spent upgrading libraries, brittle dependencies, and linear degradation of performance and stability. Code standards and code reviews cannot help when the problems come with the standards.
IMHO, there's a bit of an irony that I see with a lot of React projects: people often say that w/ vanilla JS, you end up reinventing wheels poorly, yet this is exactly what a lot of React projects I see look like: people that don't really have framework-building experience attempting to cobble up something similar in scope to Angular or Ember by using React + a bunch of other libraries (often libraries they've never used before).
There's certainly a case to be made about large teams being a problem of their own, but FWIW, a lot of projects _don't_ have large frontend teams (I'd say 1 to 3 frontend devs is fairly typical). Standardization _across_ teams can definitely be a problem, but at some point one has to wonder if it isn't more sensible to just have each teams develop separate apps that load in separate pages, or, you know, just use a more batteries-included, prescriptive framework.
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!
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".
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.
> “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.
297 comments
[ 5.0 ms ] story [ 283 ms ] threadPick 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.
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.
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
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%
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.
But the recent versions (and updating is also a breeze - mostly) should be faster. And particularly if you drop support for ES5 browsers.
[1] https://nx.dev/latest/angular/core-concepts/computation-cach...
None of the code you write is ever really touched by a browser anymore. At the very least it's minified.
I think the whole ecosystem is insane!
Something that needs 3 or more layers of transpilation...is not right. Typescript to Babylon to JS. Sass to css.
These are workarounds for native JS warts.
That's why Im excited about NATIVE web components and future releases of JavaScript becoming sophisticated enough that we can ignore all of this framework insanity.
Or even better...web assembly somehow taking over and making all of this pointless. Native Typescript. Yes please.
But to address your point, you're locked into JSX a lot more than someone writing in native browser code that doesn't need transpilation and can be ported between other frameworks at the end of the day.
Not really, because at the end of the day you still have to write the HTML and CSS and everything to render anything in a browser, the JSX really just gives you a new way to compose it. Now if you're using other styling frameworks that provide their own components, you might not have access to that HTML but that's not a JSX problem that's a "you are too reliant on outside dependency" problem.
Also, transforming code into a runnable form has been a part of programming since we first invented compiled languages. Your comments about transpilation seem really bizarre with that in mind.
Compiling has. Transpiling is much less common and seems to me to be an anti pattern or a sign that something's not correct in what you're building on top of.
One day in the future a kid will be learning programming, and not realize the billions of lines of tooling, or the hundreds of thousands of hours of thought that was put into working around an inadequate platform. However, a lot of this will have been necessary to get to the end result. But also a lot will not have.
But to address your point, you're locked into JSX a lot more than someone writing in native browser code that doesn't need transpilation and can be ported between other frameworks at the end of the day.
I also will challenge your sentiment that JSX locks you more into a framework than writing DSL extensions of HTML. JSX is supported by quite a lot of frameworks, so you aren't locked into React; additionally, React is the best UI library; additionally, JSX is pretty semantically clear with what HTML elements your functions are binding to and what events they're paired to, so in either case you have to rewrite code for your new DSL. Going between Vue and Angular isn't going to be simple.
Just not the browser natively....
Most backend frameworks don't need numerous layers of transpilation because they're on an actual OS and arent trying to work around an insane environment like the browser that's full of warts and incompatibilities.
What's the churn on Pandas? It's been around over a decade. And it can probably be reliably counted on to be around a decade more.
It will be surprising if React is around in 5 more years and hasn't been replaced by something else.
Is EmberJS still around? How much longer will webpack be around?
Stability in the browser ecosystem starts with stability in the browser.
I think instead of investing all this energy into browser frameworks we need to be devoting energy into making the browser do what we want it to do natively.
And as web assembly matures that's where I think this is headed.
Most backend frameworks need literal compilation - all that's different here is that the target is a specific JS version, not machine code. Additionally, there's a bit of "naivety" here - browser vendors are the ones that implement native features, and that's clearly not a domain that a random developer can impact. Instead it's JS frameworks and associated tooling, which is all very strong now. The idea that Angular or Vue are somehow going to work in the browser directly is, once again, absurd, and please stop saying it.
> What's the churn on Pandas
I find it silly that you'll cite Pandas as not having churn when its parent language just underwent a large, painful, poorly received transition.
> It will be surprising if React is around in 5 more years
You are saying the same things people said 5 years ago about React. My React code from 2016 still compiles against the newest version of React, and works correctly.
Honestly, you're a classic example of this - you started developing not in JS, you felt some warts of JS, and now you hate JS and are ready to throw the baby out with the bathwater.
I'll be more surprised if "native web components" or "webassembly" are actually supporting production use cases in 5 years than if React is.
For the last 5 years, I've heard about "Native Web Components", and for 5 years, the prevailing wisdom is to use react instead. :)
> Just not the browser natively....
Angular's *directive and [weird] (binding) [(choices)] will never be supported by the browser natively either. The fact that Angular uses an HTML file extension is a delusion (they really should have picked a different extension, it's such an ugly lie) that the templates will ever be more portable than they currently are. Sure, you generally have better raw copy/paste behavior of real HTML into Angular's templates than JSX, but if you think the mess that is the average Angular template will ever be portable to "native browser functionality", I may have a bridge to sell you.
I write all my components like this:
Why do I have to use a weird language with non-standard JS stuff. Writing conditionals in JSX is horrible, and props are unnecessarily verbose when we have ES6 language features like structuring.It could easily be just a nested tree structure.
All the React routers I know of support lazy-loading well.
I'd argue far better than Angular handles it. React components tree shake extremely well out of the box and I've rarely had to worry about bundle size when lazy-loading in React. Whereas Angular's dependency injection framework and its "modules", in addition to being irritating busy work as soon as you realize you can't trust the CLI's scaffolding, do nothing but get in the way of proper tree-shaking and good webpack chunks/bundles.
With a small and dynamic team that loves functional programming and reactive state management, React is great. But in larger enterprise projects with many experienced Java/.NET devs, Angular just seems to be the better choice to me.
Eg, here’s one example clip: https://youtu.be/yodWEPgn8NA
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.
Like the data science guy I worked with who complained we were making authentication and access control complicated.
The argument basically comes down to whether web development is or isn’t slower than it should be, and whether it will become dramatically faster to do in the future
I actually agree, but maybe not for the same reasons he gives. The problem with modern tech stacks is that, yes, they're insanely complex, and each of the dozen or so individual components has dozens if not hundreds of its own hidden expectations about what should be where and what it should look like. As long as you meet all of those expectations, everything works magically like it should, but as soon as you miss one, you'll be lucky if you even get an error message that you can google the solution for.
There are two efficient ways to solve this: 1) no dependencies, build everything from first principles that you already understand. Then, although there will be plenty of assumptions baked into the code, you'll know what they are and how to deal with them because you put them there. 2) take advantage of pre-built solutions, but actually read and understand the docs before you rely on them.
The second solution depends on two rarely present preconditions: one, the docs actually exist. Two, management understands that it takes more than twenty minutes to realistically absorb 500 pages of dense technical documentation.
What we end up doing as a workaround is using the off-the-shelf stuff without really understanding what it's doing (or are you telling me that you understand the 9000 files that are installed by NPM? I'm not exaggerating, BTW, go take a peek). We cross our fingers and hope that we got all the assumptions right, cut-and-paste solutions from stackoverflow, and let the horrifically inefficient solution take the place of actual engineering because the "timelines are aggressive".
> What most web developers spend their time doing is useless busy work that is not actually objectively necessary in order to create the functionality. It's just dealing with a bunch of weird conventions by some other software that they are trying to use that are there because some other other weird conventions by some other software that they are trying to use. If you just strip all that crap out, you can be tremendously more efficient.
Not only is this a very arrogant sentiment, but his reduction of all web development down to manipulating "weird conventions" doesn't fit with my experience. I don't sit around all day messing around with Webpack configurations or leaning new frameworks. I deliver software that addresses business needs, that happens to be accessed via a web browser.
He also says that jobs with the title "frontend", "backend" and "fullstack" for the web are not safe jobs. Many game developers, operating system designers, and large desktop applications will also have "frontend" and "backend" separations of responsibility as well, because they often involve different skill sets or knowledge.
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.
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.
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”
But yes, I prefer the microframework approach.
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!
Personally, I think if you want a deep understanding of React you need to first get in a few cycles of working with DOM, JS, CSS, etc. directly. Maybe throw in a functional programming language too. Then try to pick up React.
.NET wakes up every morning to have OOP pancakes OOP eggs and OOP coffee and it can't possibly allow even a hint of that beatnik functional style near it.
I agree for the most part. More specifically you're not going to write functional code in C# and feel particularly good about what comes out. F# is a different story.
Speaking from experience a .NET (C#) backend and a React frontend is perfectly viable. The key is to keep the paradigms in their respective lanes, and if you're going to write code for both, get used to switching your mindset instead of converging the tools.
Is this actually advantageous though over class components? The creator of React said he thought moving to functional components would make it harder for people to learn.
I've found that sometimes hooks can make things less flexible, more verbose, more error prone, and harder to reason about. Sometimes a class might have made things easier to understand.
I loved the fact that `useEffect` could modularize code that was otherwise split between `componentDidMount/Unmount/Update`...but couldn't a new class API also have solved this.
Maybe I just need to read the docs again to remind me. I'm all in for hooks, but it's rare that I think about what life could have been like if we kept class components.
“Advantageous” does not necessarily mean “easier to learn.” I’d say that for people coming from OOP, FP style is certainly unfamiliar and takes more getting used to. But for a front-end program that must always receive/send data to hand wave some other systems in order to do anything useful, it makes things much, much simpler. A whole class of problems disappears. The closer it gets to (state) => UI the easier it is to reason about and debug.
I still think that Reagent, the Clojurescript wrapper for React, is the best version of React available. All of the state management is handled by CLJS itself, and the language design prevents accidental mutation. You can still mutate things where appropriate, but it is always an intentional choice. A framework like re-frame takes this even further, with similar ideas as Redux but with better language support for and enforcement of the paradigm.
> Is this actually advantageous though over class components? The creator of React said he thought moving to functional components would make it harder for people to learn.
At the end of the day you just end up thinking of the chunks of JSX and how they map to parts of the DOM, and who cares if those chunks of JSX are wrapped into a function or a class...
> React’s team enjoy experimenting with new ideas, but this is killing the ecosystem! They should be brave and take the blame for it!
Have to make a lot of assumptions with this sort of thing, but I can't imagine that attitude results in high quality engineering work.
https://reactjs.org/blog/2015/02/24/streamlining-react-eleme...
Projection if I've ever seen it.
https://en.wikipedia.org/wiki/Psychological_projection
Given this kind of team and leadership, why does that still make React the best choice for them?
Maybe the team is a bunch of n00bs, so what? Wouldn't the perfect framework/language make it hard[er] to screw things up regardless of the lack of dev skill? For a big multi-year project it often strikes me that the best tools are those which are old, boring, and unlikely to change.
That being said, huge-multi-year development in _any_ js framework seems terrifying to me because of the churn in the general js/browser environment.
Also: I think the author doesn't cover this a lot, but it sounds like they REALLY saved their bacon by doing the boring due-diligence of carefully documenting the decision process behind all the choices they made. They probably would have had slowdowns and surprises and roadblocks no matter what, but someone's still got a job because they took time to get it in writing.
At that same job, our app team was switching to Swift for its new code, which no doubt has had considerable churn since then, since it was before ABI stability or SwiftUI or whatever (I’m not a Swift dev so just guessing from the outside on the specifics).
— Peopleware (1987) by Tom DeMarco & Timothy Lister
Most enterprise teams are poorly skilled with bad leadership. Modern frameworks and coding paradigms are a bad fit.
No it wouldn't, not for an enterprise application that is supposed to last a decade or more. Instead you want to use standards such as Web Components that will last essentially forever.
If the project develops issues after all the initial stakeholders have moved on, it's the new stakeholders' problem.
https://blog.carlmjohnson.net/post/2020/web-components/
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.
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.
To be honest with you, you can't really blame React in this situation - it is nonetheless immensely frustrating to be sure.
> Redux is quickly going out of fashion
Yes, when I say it's "king" I only mean in terms of popularity within the community. I personally never understood the point of Redux and have always greatly preferred MobX for exactly what you say - it is far too verbose.
I also don't really have a good read on how the future of these projects will go - I would have thought MobX would've won out long ago. Maybe now with MobX 6 moving away from decorators it can gain the steam it deserves. I think the key blocker has been / is that MobX is building a runtime graph, and people don't understand graphs (let alone dependency graphs) very well, so it feels like magic. It's really easy to use though.
With features like Suspense, I feel like React will continue to push for more concise ways to write your components, but I also wonder if even the one level of misdirection that Suspense shows will be enough to limit its adoption. So far, explicit and non-magic seems to be a strange community preference
> 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.
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.
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.
What could've been an effort to split the existing service into manageable smaller services and rewrite components as needed turned into a multi-year ground-up effort. When I left they were no where near production ready, with significant technical debt and code rot from already years out of date libraries and practices.
If you're building a new internal webapp from scratch for a small internal use-case, you just end up with a hundred different poorly-maintained apps.
But in the situation where you're adding a page to an internal app, it's trivial to make that new page a SPA React app, since the framework is already there waiting for a new component.
Devs like to have fun, learn new things, play with complicated things - that's all it is. It counteracts the dull features that most developers have to ship.
It went swimmingly right up until QA was more or less told not to file any issues found, and then those issues were used as a reason we needed to use a TypeScript and Material-UI app he wrote over a weekend and said was "almost done." The bugs in question turned out to be minor visual bugs, and like I said, none of them were filed or even mentioned until this replacement got dropped in our lap. In fact, no problems of any kind were reported until this moment.
Instead it took another 6-8 months to get to feature parity with the app we'd already developed and now thrown away (or feature "parody" as my boss put it), it was full of bugs, development is slow and pretty directionless, my boss gets bored and contributes code that runs in the O(n^12) range (yes, really) before languishing in a draft PR for months and then getting dumped on us to actually implement for real, and it's been a year and a half with no end even remotely in sight.
I really want to find somewhere else but that doesn't seem like a realistic goal right now. Not to mention my enjoyment of programming died years ago and I haven't written code for fun in as long as I care to remember.
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.
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.
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.
Regardless of whether or not Strict-Transport-Security is enabled on the server, npm will still record the protocol as-is in the package-lock.json file.
Half the time a PR will include a package-lock.json with every "resolved" field having the protocol gratuitously changed to the other protocol.
i now have this aliased to `ni`, so i get to say `ni` to the app often.
Internal support from eng teams is a must, without that the migration won't work.
You are just stating the problem the article complains about.
Whose opinions are those? You need to take a lot of decisions.
Moreover, those decisions which seemed good (to you...or the one that dictates those strong opinions) at the time you took it, are not valid just months or years down the road. So you will need to reevaluate them periodically.
Moreover, even if you are happy with your decisions, you might be forced to take them again, because the library went out of fashion, unmaintained, or the developers just stop responding to issues and ignore you completely. This is already happening to a project I work with where the react-router developers just went to build their own nextjs competitor and stopped responding to issues. Same with styled-jsx from the same next.js team, not even themselves seem to be using it anymore.
This never happened to me using Rails. True some gem might go away, but at least it usually is some helper thing and not the core of my f*ng application. Same experience with django and many other uncool stacks.
So, yes. React is amazing if you are facebook, google, amazon, building a side project or just working for your own resume. It is not good for the average business. It is not good for enterprise applications.
In my own experience, at least.
Making those sorts of decisions is supposed to be what the architect does. It sounds like the author did not do so.
the person who has the authority to call the shots and leads the project.
The error is right there in the article:
"After nine months, we have more than 50 pages created. The developers notice that function components are as good as class components and start using them. So, now the project no longer follows the original coding guidelines. It’s more like a personal choice for each developer. And for me, that is OK."
This is where the screw up happens. This is not okay, and as the person responsible for the architecture the author should have made a clear and concise decision and then get everyone to comply with it. You cannot let your developers run wild and then complain a year later when everything is a jumbled mess. Even more opinionated frameworks won't save you because the application is so large it likely would have happened regardless.
When you have a big project, you have to keep a consistent architecture. You need to keep using the same tools and patterns so that you have cohesion in your code base.
The worst thing about new architects on long lived projects is you typically get 2-4 ways of doing the same thing. If you're going to do that it needs to be so good that you don't mix and match.
If you are going to mix and match, you need to have a solid approach to splitting your dependencies, one way I'd have looked at doing this is by splitting this into multiple sub SPA applications and each mini project would be able to conform to it's own standard as long as it could interface with the glue application, this is by no means foolproof, but it gets you a lot closer to a maintainable situation from my experience.
Why I like this approach is that I saw a comment from someone saying they'd hate to be on a team with a uniform style. I completely get that, innovation is super important, but you have to build boundary layers between the different styles so you don't end up building such a hodgepodge of dependencies that you can't get things to work anymore. It also keeps your build times down and reduces time to get started working on your module.
Again same comment you made, I've made mistakes, trying to learn from them, maybe my current approach is bad too and there's a better way.
Use a monorepo with many `package.json` files. Then someone working on a data grid component for example can add the packages they need for that component and no one else's code will depend on it and it won't break anyone else's.
Note that your suggestions do not address the main problems: time spent upgrading libraries, brittle dependencies, and linear degradation of performance and stability. Code standards and code reviews cannot help when the problems come with the standards.
There's certainly a case to be made about large teams being a problem of their own, but FWIW, a lot of projects _don't_ have large frontend teams (I'd say 1 to 3 frontend devs is fairly typical). Standardization _across_ teams can definitely be a problem, but at some point one has to wonder if it isn't more sensible to just have each teams develop separate apps that load in separate pages, or, you know, just use a more batteries-included, prescriptive framework.
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!
You can't expect an application to remain easy to develop when people do not adhere to your development protocols.
That's actually a common practice. Files (modules, that is) are usually named after their principal export.