Wouldn't it have been a better idea to break the giant app into smaller ones with well-defined interfaces?
React created roadblocks in our enterprise app
71–80 of 298 posts
Re: React created roadblocks in our enterprise app
#72I read the comments here first before reading the blog post, and I was expecting a very different type of (and lacking) blog post based on the combination of dismissive and defensive attitude permeating a lot of the comments here. To be honest, there isn't a lot the author is wrong about. Sure, having a .NET team adapting to React is harder but nothing seemed egregious in the way they tackled things. The point about…
> I would much rather take "boring", stable languages and frameworks
I would argue that you don't need a heavy framework to make maintainable JavaScript application. For large enterprise applications that must last a decade or more you want to use standards (such as Web Components) implemented by the web browser itself instead of third-party libs such as React.
Re: React created roadblocks in our enterprise app
#73Earlier quoted context omitted.
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.
Re: React created roadblocks in our enterprise app
#74I read the comments here first before reading the blog post, and I was expecting a very different type of (and lacking) blog post based on the combination of dismissive and defensive attitude permeating a lot of the comments here. To be honest, there isn't a lot the author is wrong about. Sure, having a .NET team adapting to React is harder but nothing seemed egregious in the way they tackled things. The point about…
> The point about React including so little that you become reliant on a ton of external dependencies that see even more churn than the usual JS framework landscape is a very valid pain point, especially when you are building a very large application for the long-term.
It's a feature, not a bug. Not understanding this is a red flag that you're going to run into problems.
> React now looks completely different from React from 1-2 years ago.
Does it? I've worked in React, at enterprise levels, for close to 3 years now. Except for the addition of hooks, there hasn't been a whole lot of churn. React today is still the react of yesteryear, but with extras.
Imo the biggest failure of the author was to jump headfirst into a stack they weren't familiar with it, and then blame it on the stack.
I know it's en vogue to hate npm/react/js "because the ecosystem", but at this point, picking the ecosystem and then blaming it is a self inflicted wound that I don't really have patience for.
Re: React created roadblocks in our enterprise app
#75I read the comments here first before reading the blog post, and I was expecting a very different type of (and lacking) blog post based on the combination of dismissive and defensive attitude permeating a lot of the comments here. To be honest, there isn't a lot the author is wrong about. Sure, having a .NET team adapting to React is harder but nothing seemed egregious in the way they tackled things. The point about…
You probably don't want to know about MEAN (https://en.wikipedia.org/wiki/MEAN_(solution_stack)) then.
Re: React created roadblocks in our enterprise app
#76It'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 “Simplicity is prerequisite for reliability”
React feels more like the Spring Boot response to Angular's J2EE. But yes, I prefer the microframework approach.
Yeah, that's a better comparison.
Re: React created roadblocks in our enterprise app
#77Technology 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.
> ... the real problem was a poorly skilled team with bad leadership... Given this kind of team and leadership, why does that still make React the best choice for them?
AMEN!
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.
Re: React created roadblocks in our enterprise app
#78Technology 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.
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.
Re: React created roadblocks in our enterprise app
#79The main problem I’m having here is that I can’t think of any JavaScript framework that has solved this problem. Angular is just too cumbersome, though it gets an honorable mention. Perhaps there is so much churn here because the correct way hasn’t been discovered yet?
The problem is how broken all of it is trying to work around browsers native warts. As future versions of native JS becomes better and web assembly takes over, things will probably improve massively.
Re: React created roadblocks in our enterprise app
#80Honestly my primary source of headaches is also the router, the redux, the sagas, the thunks.
It's always the fuckload of third-party libraries we think we need.