Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React created roadblocks in our enterprise app

medium.com

Post reply on HN
Print view View original

241–250 of 298 posts

Re: React created roadblocks in our enterprise app

#241

Post by dmt0 »

erlich wrote: post #211
bluefirebrand wrote: post #106

Earlier quoted context omitted.

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.

> evolved to be a very functional approach 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 tha…

> > evolved to be a very functional approach

> 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...

Re: React created roadblocks in our enterprise app

#242

Post by nickthemagicman »

franklyt wrote: post #139
nickthemagicman wrote: post #79

Earlier quoted context omitted.

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.

To me, it seems like the concept of the DOM might be the problem.

One of the numerous warts. Didn't many front-end frameworks create shadow doms to work around this?

Re: React created roadblocks in our enterprise app

#243

Post by nickthemagicman »

WorldMaker wrote: post #153
nickthemagicman wrote: post #95

Earlier quoted context omitted.

"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 reliabl…

> "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 th…

Well I can't comment because I've never used Angular. Sounds like it's as much of an anti-pattern as JSX.

Re: React created roadblocks in our enterprise app

#244

Post by nickthemagicman »

nawgz wrote: post #108
nickthemagicman wrote: post #95

Earlier quoted context omitted.

"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 reliabl…

> Just not the browser 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.…

Well we can revisit this in the future and see what the status of React is!

Re: React created roadblocks in our enterprise app

#245

Post by nickthemagicman »

bluefirebrand wrote: post #97
nickthemagicman wrote: post #61

Earlier quoted context omitted.

Agree completely! 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 taki…

> 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 styl…

Transforming code.

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.

Re: React created roadblocks in our enterprise app

#246

Post by nickthemagicman »

mmis1000 wrote: post #231
nickthemagicman wrote: post #18

Earlier quoted context omitted.

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.

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 inste…

Entropy applies to all things not just front end software. A very strict and structured dev environment seems to always lead to better software.

Re: React created roadblocks in our enterprise app

#247

Post by atom_arranger »

nawgz wrote: post #156
ralmidani wrote: post #150

Earlier quoted context omitted.

React is stable? React.createElement -> Sub-classing the Component class -> "just use hooks everywhere" in the span of a few years? Sure, Django went from function-based to class-based views, but the change was far less abrupt, and you can still use functional views if you want to. As for TypeScript, I agree it's amazing, but it's neither a framework nor a library for building web applications. It's more of a superse…

>React is stable? Yes. Despite what you're trying to imply about them "updating" too often, my code from 2016 still works correctly against the newest versions of React. That's pretty much the definition of stability to me. > the change was far less abrupt, and you can still use functional views if you want to So you are hating on React because you don't know this, but this exact optional progression has always been…

The other thing is that anyone who isn’t oblivious has seen the writing on the wall (React docs and changelogs) saying that class components are not the happy path of React development. This has been clear since late 2015.

The only people I could see not noticing or ignoring this are people new to React or people who are emotionally attached to classes.

Re: React created roadblocks in our enterprise app

#248

Post by lytefm »

ourcat wrote: post #4

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 a…

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.

Re: React created roadblocks in our enterprise app

#249

Post by franciscop »

hyperpape wrote: post #57

One thing that I realized recently is that if you have a mantra of making "data-driven decisions", then you have raised the cost of making a decision. What you then need is a tool that minimizes the number of decisions you have to make. Gartner, Rails, Spring, each try to do some of that in their own ways. That's where his 3 weeks of decisions about libraries reveals a real mismatch between React and the enterprise w…

You could also make decisions not based on data but on your experience. That's how most arts and craftmanship works, and thus why software is often argued to be somewhere between engineering and craftmanship.

Re: React created roadblocks in our enterprise app

#250

Post by dirtnugget »

It’s sad that Angular still has a bad reputation from AngularJS. Basically all the pain points the author mentions (deciding on router, DI, http client, working in multiple teams, reliable hot-reload, deciding between class or functional components, whether or not to use hooks) are all things in which angular shines. They could have saved a ton of money here by choosing Angular over react. In fact in comparison over the last 5 years, angular has been much more consistent whereas react has become a scattered mess.
Post reply on HN