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

141–150 of 298 posts

Re: React created roadblocks in our enterprise app

#141

Post by cratermoon »

TheCoelacanth wrote: post #130
predaking wrote: post #115

So many things here indicating both a strategic problem in the org and some issues with the approach. Context: I've used both React and Angular extensively on a variety of applications, for startups and the most "enterprisey" of entities claiming to be enterprisey (the government) and came from a .NET background prior. First - GRRR. What defined this as an "enterprise" app? Facebook is an enterprise app, dude, with m…

I wouldn't consider Facebook an enterprise app in the slightest. It's a consumer app. Enterprise apps tend to have much lower volume of users but a ridiculously long checklist of features.

The quintessential Enterprise app is SAP.

Re: React created roadblocks in our enterprise app

#142

Post by bastawhiz »

jorl17 wrote: post #121
bastawhiz wrote: post #120

I think some of the points are valid (.Net folks are not going to have a great time working on a React codebase). I think some of the problems are a result of the decision to use Redux. Redux was very much in vogue for a while, but in every project I've used it for, it really hampers DX when you start to get stuck in on a large project. To do stuff that involves async (read: everything), you need helpers (thunks, sag…

What do you suggest developers use instead of Redux?

For most products, you didn't need anything besides React in the first place. It's really only useful when you have a single blob of state which is displayed/sliced/etc. in different ways across a large number of views. But for the most part, many apps are largely read-only (you can use `Context`s to push data down your render tree), where mutations happen close to where the data is loaded, meaning the benefits of redux are lost.

The big pain point of Redux (IMO) is that you do you data fetching separately from managing the data in your data store. It means that you need to add this glue layer between the data that comes back from your API and the redux store—you need to re-model everything. Every time you get new data, you need to go out of your way to remember to update everything that could be affected by that data.

GraphQL (I'm fond of Apollo) gets this more right. You can still use REST APIs with GQL (usually not by default, but it's possible). What this means is that you model your data in the way that the API expresses it. Your back-end folks aren't going to be lost when they read your code, because it matches the shape of the data they're already familiar with. The client-side cache means you don't need to manually fiddle with your store to invalidate stale data (I've yet to need to manually reach into the cache to perform updates).

That's not to say GQL is without its own issues. It is yet-another-thing, but it's one example of a solution which doesn't get quite as hairy when you've got 200+ pages in your app.

Re: React created roadblocks in our enterprise app

#143

Post by marcosdumay »

mixmastamyk wrote: post #66
iamsb wrote: post #32

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

"old style" from the horse-and-buggy-olden-days of 2010+ :D.

It feels like a millennium if you have the attention span of a goldfish.

Re: React created roadblocks in our enterprise app

#145

Post by firebaze »

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

This is the most upvoted controversial, and in my eyes, trolling post i ever saw on HN. I'd at least expect a look-forward element, like "use Svelte" or whatever. But a simple and pure (and from my point of view totally wrong) flame just against React without mentioning any of the competing frameworks feels simply awkward.

One could substitute React with almost anything js-related, and the post would still incite flame.

Re: React created roadblocks in our enterprise app

#146

Post by UseStrict »

iamsb wrote: post #32

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

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.

Re: React created roadblocks in our enterprise app

#147

Post by WorldMaker »

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…

> And lazy-loaded routings? Yes please.

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.

Re: React created roadblocks in our enterprise app

#148

Post by crooked-v »

commandlinefan wrote: post #93
protonimitate wrote: post #74

Earlier quoted context omitted.

> 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, unwan…

In React's case, it's meant to pretty much entirely focus on the process of (input data -> output DOM nodes), plus the minimal set of wrapper functionality needed to handle user input and general asynchronous data loading (class-based component state, context loading, and most recently hooks). It intentionally doesn't handle a lot of stuff like dependencies (that's a job for your bundler), the actual data fetching, the actual specifics of your UI, centralized global data management, etc.

Re: React created roadblocks in our enterprise app

#149

Post by mmmeff »

firebaze wrote: post #145
_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…

This is the most upvoted controversial, and in my eyes, trolling post i ever saw on HN. I'd at least expect a look-forward element, like "use Svelte" or whatever. But a simple and pure (and from my point of view totally wrong) flame just against React without mentioning any of the competing frameworks feels simply awkward. One could substitute React with almost anything js-related, and the post would still incite fla…

I prefer the criticism raw and plain. No need to muddy the waters with a biased recommendation. The author’s criticism stands on its own.

Re: React created roadblocks in our enterprise app

#150

Post by ralmidani »

nawgz wrote: post #126
ralmidani wrote: post #114

Earlier quoted context omitted.

I agree people should take ownership over their decisions, but it's more nuanced than "don't cry": if someone makes a mistake/bad decision, shouldn't they warn others so they don't do the same? And frankly, let's stop pretending the JS ecosystem is not problematic. Can anyone in good faith argue for a JS project which offers the stability, refinement, and elegance of projects available for Ruby (Rails), Python (Djang…

>frankly, let's stop pretending the JS ecosystem is not problematic. Can anyone in good faith argue for a Node project React is a node project, so I can do so trivially. React is a top tier library when it comes to key features like stability, documentation, backwards compatibility, and extensibility / usability. I can also say TypeScript is one of the most amazing projects of all time. Last but not least - express i…

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 superset/transpiler. It makes working with Node/React/Express better, but it doesn't replace them.

With regard to Express, it's decent, but e.g. do we really need to torture newcomers by expecting them to know they'll need to also include/install and require body-parser? I mean, why would I be using a web framework, even a micro-one, if I'm expected to bring in a separate tool just for parsing requests?

Regarding the suggestion that I like Python more, I would gladly choose TypeScript over Python (the typing tools there are still immature) if there was less churn in the JS ecosystem. Deno is promising. :)

Post reply on HN