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

171–180 of 298 posts

Re: React created roadblocks in our enterprise app

#171

Post by renewiltord »

crooked-v wrote: post #160
renewiltord wrote: post #152

Is there a Rails for React? I use React+Redux+Typescript and it's nice but I always have trouble setting up a new project. Rails is magic in that it's all ready. React+Redux+Typescript is great. I just don't want to make decisions here. I want to just make a web app. Like how Rails defaults to ActiveRecord and friends, is there something like that for Rails+React+Redux+Typescript? I'm looking for: * Few decisions for…

Take a look at Next.js, which incorporates a general-purpose router, does all the Webpack stuff for you, has generally painless server side rendering support (but you can also build a purely client-side bundle), and has direct support for a long list of popular libraries. It doesn't handle global state, but has tested examples for Redux[1] and various other libs that incorporate the server-side rendering and static s…

Thanks for the tip! Also appreciate you had your BTC link up in your keybase :)

Re: React created roadblocks in our enterprise app

#173

Post by worik »

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…

"my code from 2016 still works correctly"

That is no time at all in "enterprise level software", being software with investment counted in millions of dollars.

What about your code from 1996? Will your React code word in thirty years?

Re: React created roadblocks in our enterprise app

#174

Post by drazvan91 »

prewett wrote: post #172

1200 dependencies?! Is this normal in web development? That sounds like a nightmare waiting to happen! I'm working with a rather large C++ project now, and it only has 40 dependencies, which I already consider pretty large.

Yes, but those 40 dependencies have their own dependencies ... Which leads to a few hundreds. Check node_modules

Re: React created roadblocks in our enterprise app

#175

Post by midrus »

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…

> If a big team is going to be working on it you need some strong opinions around it.

You are just stating the problem the article complains about.

Whose opinions are those? You need to take a lot of decisions.

Moreover, those decisions which seemed good (to you...or the one that dictates those strong opinions) at the time you took it, are not valid just months or years down the road. So you will need to reevaluate them periodically.

Moreover, even if you are happy with your decisions, you might be forced to take them again, because the library went out of fashion, unmaintained, or the developers just stop responding to issues and ignore you completely. This is already happening to a project I work with where the react-router developers just went to build their own nextjs competitor and stopped responding to issues. Same with styled-jsx from the same next.js team, not even themselves seem to be using it anymore.

This never happened to me using Rails. True some gem might go away, but at least it usually is some helper thing and not the core of my f*ng application. Same experience with django and many other uncool stacks.

So, yes. React is amazing if you are facebook, google, amazon, building a side project or just working for your own resume. It is not good for the average business. It is not good for enterprise applications.

In my own experience, at least.

Re: React created roadblocks in our enterprise app

#176

Post by worik »

nawgz wrote: post #122
_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…

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?

Re: React created roadblocks in our enterprise app

#177

Post by worik »

nawgz wrote: post #122
_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…

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.

Re: React created roadblocks in our enterprise app

#178

Post by midrus »

nawgz wrote: post #122
_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…

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.

Re: React created roadblocks in our enterprise app

#179

Post by bargl »

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…

This was my biggest take away from this article too.

When you have a big project, you have to keep a consistent architecture. You need to keep using the same tools and patterns so that you have cohesion in your code base.

The worst thing about new architects on long lived projects is you typically get 2-4 ways of doing the same thing. If you're going to do that it needs to be so good that you don't mix and match.

If you are going to mix and match, you need to have a solid approach to splitting your dependencies, one way I'd have looked at doing this is by splitting this into multiple sub SPA applications and each mini project would be able to conform to it's own standard as long as it could interface with the glue application, this is by no means foolproof, but it gets you a lot closer to a maintainable situation from my experience.

Why I like this approach is that I saw a comment from someone saying they'd hate to be on a team with a uniform style. I completely get that, innovation is super important, but you have to build boundary layers between the different styles so you don't end up building such a hodgepodge of dependencies that you can't get things to work anymore. It also keeps your build times down and reduces time to get started working on your module.

Again same comment you made, I've made mistakes, trying to learn from them, maybe my current approach is bad too and there's a better way.

Re: React created roadblocks in our enterprise app

#180

Post by lhorie »

janaagaard wrote: post #163
cratermoon wrote: post #107

Earlier quoted context omitted.

We have a private local package repo at my company. Some developers set up their npm registry, or had it set up for them, with registry= https:// .. Others have registry= http:// ... Regardless of whether or not Strict-Transport-Security is enabled on the server, npm will still record the protocol as-is in the package-lock.json file. Half the time a PR will include a package-lock.json with every "resolved" field havi…

We have a pretty similar issue at work where our package-lock file switches URLs between npmjs.com and our own npm registry. Can you elaborate a bit on what the issue is and how to solve it?

The issue is that some developers have configured the registry field in their .npmrc file incorrectly. Ideally, sending out a memo telling everyone to fix it should do it. If not, one way to fix it is to commit the .npmrc with the correct configuration (assuming it doesn't include secrets). If all else fails, an ugly hack is to make a preinstall hook that fixes the .npmrc file.
Post reply on HN