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

161–170 of 298 posts

Re: React created roadblocks in our enterprise app

#161

Post by djcollier »

hertzrat wrote: post #8

There are a variety of clips of Jonathan blows twitch stream where he talks about web development. He feels that it has gotten so inefficient and complicated that it now takes 20x as long to create something as it needs to. He suggested that it would be faster for most teams to create their tech stacks utterly from scratch. He further argued that once this efficiency problem gets figured out, most web jobs will disap…

The web is just a way of delivering software to users. I think the person speaking in the video is worrying way too much about putting developers into boxes. At the end of the day, there are many problems in the world that can be solved with software.

> What most web developers spend their time doing is useless busy work that is not actually objectively necessary in order to create the functionality. It's just dealing with a bunch of weird conventions by some other software that they are trying to use that are there because some other other weird conventions by some other software that they are trying to use. If you just strip all that crap out, you can be tremendously more efficient.

Not only is this a very arrogant sentiment, but his reduction of all web development down to manipulating "weird conventions" doesn't fit with my experience. I don't sit around all day messing around with Webpack configurations or leaning new frameworks. I deliver software that addresses business needs, that happens to be accessed via a web browser.

He also says that jobs with the title "frontend", "backend" and "fullstack" for the web are not safe jobs. Many game developers, operating system designers, and large desktop applications will also have "frontend" and "backend" separations of responsibility as well, because they often involve different skill sets or knowledge.

Re: React created roadblocks in our enterprise app

#162

Post by crooked-v »

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?

Most cases I've seen are just using Redux as a de facto global cache, where it can be easily replaced by a library like Apollo or SWR (https://swr.vercel.app) to just have every component make whichever requests it needs for data directly (and the library then deduplicates requests and serves data from cache).

Re: React created roadblocks in our enterprise app

#163

Post by janaagaard »

cratermoon wrote: post #107
chairmanmow wrote: post #82

Earlier quoted context omitted.

I never recall it doing that, you may be thinking of the `package-lock.json` which does get created still. It basically creates/records hashes of the packages that get installed when `npm install` runs. Shouldn't always be changes there but depending on how version flags are set in `package.json` an `npm install` could create new `package-lock.json` values if there's a newer version in the repo that gets upgraded/ins…

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?

Re: React created roadblocks in our enterprise app

#164

Post by firebaze »

mmmeff wrote: post #149
firebaze wrote: post #145

Earlier quoted context omitted.

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.

Fair enough. The js ecosystem has quite some room for improvement, this is what I definitely agree on.

Re: React created roadblocks in our enterprise app

#165

Post by firebaze »

andybp85 wrote: post #154
vinceguidry wrote: post #54

Earlier quoted context omitted.

It's been awhile since I've worked with npm, does it still do that thing where it changes package.json every time you `npm install`? I remember writing a script to discard package.json edits because my PR wasn't supposed to upgrade any libraries.

you have to use `npm ci`, which was added a few years ago. my team ran into that kind of issue right after `ci` was added, thankfully, or we would've had to do something similar. i now have this aliased to `ni`, so i get to say `ni` to the app often.

Made my day :) Guess we'll adopt this.

Re: React created roadblocks in our enterprise app

#166

Post by crooked-v »

rafaelturk wrote: post #39
viburnum wrote: post #23

220 pages! That alone makes React a poor choice.

Not at all, react handles this quite well. Just use code-split per route, webpack manages this with a few lines of code

Also, various libraries like Next.js will do this kind of code splitting along routes out of the box.

Re: React created roadblocks in our enterprise app

#167

Post by twobuy »

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?

This is likely referring to the .npmrc registry field.

Re: React created roadblocks in our enterprise app

#168

Post by bpodgursky »

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…

IMO the real failure here was not having an internal administration website with all the auth and API plumbing already set up, which you could tack a new page onto with minimal fuss, and a backend to tack a new API endpoint onto with no hassle.

If you're building a new internal webapp from scratch for a small internal use-case, you just end up with a hundred different poorly-maintained apps.

But in the situation where you're adding a page to an internal app, it's trivial to make that new page a SPA React app, since the framework is already there waiting for a new component.

Re: React created roadblocks in our enterprise app

#169

Post by ralmidani »

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…

Stability is not just about backward-compatibility; it also means promoting concepts/idioms which are consistent and long-lived. Django has been around for about 3 times as long as React, but has not undergone the same amount of churn that React has. If someone wrote React code in 2016 and left the scene for a couple of years, can they come back and build new React projects without significant re-training?

Regarding Django templates, I know how they work, but actually prefer building an API with Django, and connecting to that with an SPA (preferably one built with Ember since, as you can probably tell, I prefer batteries-included frameworks).

I'm really not as anti-JS as you inferred from my initial post (or as I unintentionally implied), but saying the ecosystem is not problematic makes it harder for it to get better.

Re: React created roadblocks in our enterprise app

#170

Post by worik »

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…

"Does it? I've worked in React, at enterprise levels, for close to 3 years now..."

So you are a beginner.

Post reply on HN