React created roadblocks in our enterprise app • Hacker News Board

Re: React created roadblocks in our enterprise app

#191

Post by erlich » Fri, Jan 22, 2021, 10:48 PM UTC

I feel your pain. It was really too early for React until 2 years or so ago. Since hooks, things have calmed down a bit. I would be interested to hear from people who successfully navigated that past 5 years in JS world. I feel I would have been happier just being forced to use Ember or something until hooks came out. A ridiculous amount of time was spent on tooling, perf optimizations, and huge amounts of code is just going to go into the bin one day.

I have this feeling that 2010+ has been this massive story arc and one day we will end up very close to where we started, back to something similar to jquery and vanilla JS because the platform improved. Just like how a React platform feature like context hooks deprecated Redux.

For frontend, if Typescript is standardized and shipped with browsers...see ya later beefy compiler toolchains.

For backend, Deno.

That Typescript with its current popularity is not shipped in browsers within 10 years seems super unlikely.

The funny thing with TS is that to get good typing, you start to write everything similar to Java/.NET with dependency injection etc. I resisted it for such a long time, but when you realize you want things typed, classes and all those patterns become necessary - see Nest.js/TypeORM for an example. It just makes everything cleaner and is easier to standardize patterns.

The post seems to have a bit of a "holier than thou" when dealing with naive .NET developers. I think that .NET devs living outside of our JS bubble probably have a lot of interesting criticism to offer. The retort that pops in your mind is "you just don't understand...this is how its done", but if they critiqued any number of the features that have been deprecated in React - they would have been right and us wrong. And even the creator of React said that moving away from classes made it to difficult and would have preferred not to have done it. My point is that JS is a bubble and we shouldn't be so sure of ourselves.

Also the fact that Apollo is the top API library at the moment, and doing optimistic updates and working with the cache is insanely complicated when ultimately you just want something like ActiveRecord on the client like how we use to do it with Backbone models. Redux and friends is also extremely verbose and complicated for no gain. I miss the simple mental model of Backbone - yeh there were problems, but at the end of the day I just want to write `User.getPosts()` and `User.setPost()` and be done with it. 90% of the time I don't actually need GraphQL selective querying and such, its just got such a big momentum and community behind it that I use it. And REST with `react-query` and `swr` is still extremely complicated. Sorry for the rant.

So I wonder if anyone has taken the time to predict when all the tools we use today will eventually be deprecated.

Re: React created roadblocks in our enterprise app

#192

Post by mpolichette » Fri, Jan 22, 2021, 10:48 PM UTC

I don't think React is the problem here. I think communication and leadership is where fault lies.

1. Why hire a team of non-webdevs to do webdev. (on 2nd read, it appears they wanted to use the same team from the WPF app... ¯\_(ツ)_/¯)

2. If you build and treat React components and their APIs as the abstraction layer, then they're just components... who cares how they're implemented.

3. Just because the existing project is big, doesn't mean your new one has to be... split it up!

4. Redux... the root "technical problem"

My hot take is that the authors technical issues probably come from Redux and not React. Using redux as the core of your application is like pouring glue on a lego set. In an ideal world this is great because everything is strong and well defined. In reality, it prevents flexibility and applies hard constraints to the entire system.

That one choice of using redux effects the decisions you make in every component. You lose flexibility to encapsulate features and experiments. You're forced to bend over backwards to do things in specific ways.

Redux is the JS equivalent of the Windows Registry.

Re: React created roadblocks in our enterprise app

#193

Post by erlich » Fri, Jan 22, 2021, 10:51 PM UTC

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…

> Do not mess with the package.json

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.

Re: React created roadblocks in our enterprise app

#194

Post by erlich » Fri, Jan 22, 2021, 10:52 PM UTC

mpolichette wrote: post #192

I don't think React is the problem here. I think communication and leadership is where fault lies. 1. Why hire a team of non-webdevs to do webdev. (on 2nd read, it appears they wanted to use the same team from the WPF app... ¯\_(ツ)_/¯) 2. If you build and treat React components and their APIs as the abstraction layer, then they're just components... who cares how they're implemented. 3. Just because the existing proj…

> Redux is the JS equivalent of the Windows Registry.

Love it.

I find Dan Abramov a great guy, but it was he who brought us Redux and rose to such fame because of it, and its now considered a bad way of doing things (or maybe just a ridiculously verbose api) and caused a huge amount of pain for a lot of people (I am not blaming him tho!)

Now we have hooks as a collaborative effort involving the same guy, but they feel hacky in a way, and almost like they will not last either.

It really feels like this reinvention for the sake of reinvention. I can easily imagine the API I would like for managing my data layer, but its seems like we are trying to shoe-horn something into the React way when maybe it isn't the right fit and we need something else.

Re: React created roadblocks in our enterprise app

#195

Post by Matthias247 » Fri, Jan 22, 2021, 10:56 PM UTC

mpolichette wrote: post #192

I don't think React is the problem here. I think communication and leadership is where fault lies. 1. Why hire a team of non-webdevs to do webdev. (on 2nd read, it appears they wanted to use the same team from the WPF app... ¯\_(ツ)_/¯) 2. If you build and treat React components and their APIs as the abstraction layer, then they're just components... who cares how they're implemented. 3. Just because the existing proj…

I don't think 1) is any issue. I worked on desktop apps as well as web apps, and overall I think it's mostly the same. You have some widgets, state, actions, etc - and need to connect all things together.

However I could totally imagine that a team which is familiar with advanced patterns for "connecting everything together" are unhappy with the bare minimum Redux approach. MVVM can be pleasant to work with, and isn't necessarily as much of a ceremony and chore as the redux stuff.

Angular 2 (or whatever version number it is now on) might indeed have made them happier.

Re: React created roadblocks in our enterprise app

#196

Post by nawgz » Fri, Jan 22, 2021, 10:59 PM UTC

midrus wrote: post #178

nawgz wrote: post #122

Earlier quoted context omitted.

As a React dev for half a decade, I strongly disagree with many of your points. > React [includes] so little that you become reliant on a ton of external dependencies React, since hooks, includes a full state management solution - Context, Provider, and hooks. Second, even if you want an actual state management library, both mobx and Redux are quite stable. Applications I have built in 2016 are still running and buil…

> Context, Provider, and hooks Which is the biggest foot gun I've seen in my life. There is a surprisingly high number of developer that still don't get it and will make those beautiful applications where, thanks to a naive usage of this, will create applications that rerender the entire application on every keystroke.

Yes, which you can fix by moving a singular key of the context to component state. The beauty of hooks.

Re: React created roadblocks in our enterprise app

#197

Post by erlich » Fri, Jan 22, 2021, 11:04 PM UTC

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…

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.

Re: React created roadblocks in our enterprise app

#198

Post by nawgz » Fri, Jan 22, 2021, 11:05 PM UTC

worik wrote: post #176

nawgz wrote: post #122

Earlier quoted context omitted.

As a React dev for half a decade, I strongly disagree with many of your points. > React [includes] so little that you become reliant on a ton of external dependencies React, since hooks, includes a full state management solution - Context, Provider, and hooks. Second, even if you want an actual state management library, both mobx and Redux are quite stable. Applications I have built in 2016 are still running and buil…

Five years is not long. "Facebook is powered by React. Large, complex, enterprise, and fully powered by the cutting edge of JS frameworks" A very bad example. Most software of significant cost and size is serving a industry, and not the industry itself. Facebook can break things. If your insurance company or bank break things... Get my point?

I’m sorry, but this comment is a total goalpost mover, and complete BS.

The goalpost moving: the initial article is talking about porting a desktop client based program with a reasonable amount of views to the web. Now Facebook scale and quality UI isn’t good enough to demonstrate that React is a strong front end tool.

I also don’t see how the UI is particularly likely to cause issues to an insurance or banking company.

The BS: “most software of significant cost and size is serving a industry, not the industry itself”. This sounds smart but it has virtually no relationship to the main drivers of complexity behind the UIs in discussion, which is number of developers and number of pages. You cannot reasonably tell me Facebook doesn’t show React scales for UI engineering.

Re: React created roadblocks in our enterprise app

#199

Post by nawgz » Fri, Jan 22, 2021, 11:07 PM UTC

worik wrote: post #177

nawgz wrote: post #122

Earlier quoted context omitted.

As a React dev for half a decade, I strongly disagree with many of your points. > React [includes] so little that you become reliant on a ton of external dependencies React, since hooks, includes a full state management solution - Context, Provider, and hooks. Second, even if you want an actual state management library, both mobx and Redux are quite stable. Applications I have built in 2016 are still running and buil…

"the entire ML ecosystem has been reinvented in the last 5 years" Fifteen years, maybe, but because of new technology. Actual physical machines that did not exist earlier. The churn in JS frame works is because because because, no better reason.

“We judge ourselves by our intentions and others by their actions”

Re: React created roadblocks in our enterprise app

#200

Post by darth_avocado » Fri, Jan 22, 2021, 11:08 PM UTC

cratermoon wrote: post #137

darth_avocado wrote: post #84

Earlier quoted context omitted.

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

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.