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

91–100 of 298 posts

Re: React created roadblocks in our enterprise app

#91

Post by legerdemain »

sergiotapia wrote: post #3

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…

Given the choice of MobX vs Redux, I don't understand how a library with one ninth the number of downloads on NPM is the more "boring" one.

Re: React created roadblocks in our enterprise app

#92

Post by ssijak »

gregoriol wrote: post #42
iagorodriguez wrote: post #36

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

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.

The tips that parent poster gave hold true in teams working with any different tech.

Re: React created roadblocks in our enterprise app

#93

Post by commandlinefan »

protonimitate wrote: post #74
_coveredInBees wrote: post #56

I read the comments here first before reading the blog post, and I was expecting a very different type of (and lacking) blog post based on the combination of dismissive and defensive attitude permeating a lot of the comments here. To be honest, there isn't a lot the author is wrong about. Sure, having a .NET team adapting to React is harder but nothing seemed egregious in the way they tackled things. The point about…

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

> It's a feature, not a bug

I'm not that familiar with React (although I have had the misfortune of working with Angular), but I've seen the horrific Spring "framework" defended that way: it doesn't actually include any functionality because it's designed to be open ended! What it turns out to be is the most useless thing that ever happened to programming: it's pure overhead, undocumented (surprising) behavior, unwanted defaults that you have to spend time working around without the benefit of actually simplifying anything. Not saying React is the same (like I said, haven't really spent much time looking at it), but it's adherents defend it the same way Spring's adherents defend it.

Re: React created roadblocks in our enterprise app

#94

Post by titanomachy »

The comments about node dependencies exploding and build times creeping up over time was painfully familiar. I now work at a large company that addresses this with strong library discipline and huge investment in build infrastructure, but when I worked on teams at small- and medium-sized companies we were always plagued by these kind of problems.

Re: React created roadblocks in our enterprise app

#95

Post by nickthemagicman »

nawgz wrote: post #73
nickthemagicman wrote: post #64

Earlier quoted context omitted.

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

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

Re: React created roadblocks in our enterprise app

#96

Post by TheCoelacanth »

Gaelan wrote: post #70
flowerlad wrote: post #59

> So I am not afraid of getting into a debate about why those are unusual patterns for React. I have seen some developers follow patterns just because they are patterns. Once the community starts doing things one way that's it, even if it is a dumb way, the herd mentality causes the dumb way to become established. Redux is one of those dumb ways. > Because 30% of the business logic was inside Redux-Saga, I marked it…

> Business logic should be written in POJO. Plain Old JavaScript Objects. Using a library such as Redux is a dumb way, but this is the community-embraced, herd-mentality way. Redux is really just a pattern for business logic using POJO - you have a function that takes an update and returns the new state. The library itself is about a hundred lines. > Use Web Components. Using the flavor-of-the-month JavaScript libs f…

True of vanilla redux, but people using redux-thunk or redux-saga tend to bake it deep into their business logic.

Re: React created roadblocks in our enterprise app

#97

Post by bluefirebrand »

nickthemagicman wrote: post #61
bluefirebrand wrote: post #24

Earlier quoted context omitted.

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.

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

Re: React created roadblocks in our enterprise app

#98

Post by drinkcocacola »

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…

Absolutely. Think about iOS or Android (native) development. Sure, the ecosystem is quite big, however you do not have the level of flexibility that the web has. You are limited not only in terms of languages, but also certain architectural decisions are bounded by the limits imposed by Framework (the Android or iOS SDK), so there are many decisions that _are already taken_, and for better or worse you have to live with it.

That is probably what I hate the most of front-end development compared with back-end or Mobile. There are too many options, and that certainly does not promote consistency within the project.

Re: React created roadblocks in our enterprise app

#99

Post by ezzzzz »

dragonwriter wrote: post #51

> Quick onboarding for new team members, especially for the .NET developers working on the old desktop application. Yeah, unless you have a sufficient base of React (or at least JS) devs to shepherd this, this is obviously going to be a problem for choosing anything that isn't .NET, and the further from their existing .NET experience it is, the worse it will be. .NET is a workable web app platform, even for isomorphi…

Judging by the article, this project likely started before Blazor was released, however, I have to agree that .NET should have been the obvious choice. Maybe the author wasn't able to decide this, but I wouldn't consider an SPA for an enterprise app unless there was a very good reason. Stick to boring stuff that works. Leave the bleeding edge stuff for side-projects and startups.
Post reply on HN