Live data from Hacker News

React created roadblocks in our enterprise app

medium.com

181–190 of 298 posts

Re: React created roadblocks in our enterprise app

#181

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…

Most criticism I see here is of the JS frame works generally, rather than React in particular.

I, for one, am glad to see the push back against the mad craziness that has dominated the Node.js/Framework word.

It is easier to speak than listen, easier to write than read, and easier to build than test... Hence Node.js, and JS Frameworks.

I do love programming in Javascript, have not done it for a while, as I cannot abide the ignorance and arrogance that goes with the ecosystem.

I love plain old vanilla JS....

Re: React created roadblocks in our enterprise app

#182

One of the core reasons software projects run into problems is politics - and this article is about politics. What should have happened ideally is that the blog post author would have said to the CTO: - we're going with React - you've chosen us to guide you in this - you now need to trust that my advice on standards and approach is correct - you need to get your developers to do it the way I say - if you don't, then…

Politics is the game of making incremental progress and always feeling like you left something on the table, its such and opposite skill of engineering, and yet it is the most important skill in engineering useful systems.

Re: React created roadblocks in our enterprise app

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

https://youtu.be/ljPFZrRD3J8

Re: React created roadblocks in our enterprise app

#184
post #175

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

I am a rails developer myself and I love rails, but this applies to rails too. Actually rails lowers this problems a little because it is an opinionated framework but you could same to Angular for frontend. In react case, you just have to build that yourself with the pros and cons.

Re: React created roadblocks in our enterprise app

#185

One of the core reasons software projects run into problems is politics - and this article is about politics. What should have happened ideally is that the blog post author would have said to the CTO: - we're going with React - you've chosen us to guide you in this - you now need to trust that my advice on standards and approach is correct - you need to get your developers to do it the way I say - if you don't, then…

"- you need to get your developers to do it the way I say"

You have a team of developers that have a collective experience of perhaps eighty years in your organisation.

Do as I say, me who just popped in and afterwards will pop out again....

That is how millions and millions of dollars are lost in this business.

Re: React created roadblocks in our enterprise app

#187

Earlier quoted context omitted.

I've worked on stacks with .NET backends and React frontends, and there's a ton of truth to this. You can't use .NET concepts to bridge into an understanding of React. If you need to carry over .NET's paradigms, don't pick React. Personally, I think if you want a deep understanding of React you need to first get in a few cycles of working with DOM, JS, CSS, etc. directly. Maybe throw in a functional programming langu…

This really does nail it. Despite React having a somewhat OOP approach to a lot of things (and Class Components being the de facto for years), React best practices have evolved to be a very functional approach. .NET wakes up every morning to have OOP pancakes OOP eggs and OOP coffee and it can't possibly allow even a hint of that beatnik functional style near it.

> .NET wakes up every morning to have OOP pancakes OOP eggs and OOP coffee and it can't possibly allow even a hint of that beatnik functional style near it.

I agree for the most part. More specifically you're not going to write functional code in C# and feel particularly good about what comes out. F# is a different story.

Speaking from experience a .NET (C#) backend and a React frontend is perfectly viable. The key is to keep the paradigms in their respective lanes, and if you're going to write code for both, get used to switching your mindset instead of converging the tools.

Re: React created roadblocks in our enterprise app

#188
I have spent my morning pleasantly reading the comments here after reading the article.

I am struck that a lot of us here start the comments with "I have been a React developer for [3, 4, 5] years"

I think this illustrates the fundamental weakness in the approach of people in the Javascrpt Frameworks world.

Billion dollar organisations build software that will cost tens of millions to develop want, or should want, more experience than that.

Javascrpit, and "Web 2.0", generally have been around long enough to meet the requirements, but this churn in frameworks is enough to make anybody with a stake in organisations shake with fear.

IMO plain old vanilla JS with a sprinkling of libraries for syntactic sugar (and they can be hand rolled - or use JQuery) is a much better proposition than all of these shiny and new stacks that keep getting deprecated.

Web front ends are a huge boon, and the settling of basic JS syntax and implementations makes some very good things possible that were not possible twenty years ago. But the whole industry is being held back by allways wanting "better", and not accepting "good".

Re: React created roadblocks in our enterprise app

#189

Earlier quoted context omitted.

> I would much rather take "boring", stable languages and frameworks I would argue that you don't need a heavy framework to make maintainable JavaScript application. For large enterprise applications that must last a decade or more you want to use standards (such as Web Components) implemented by the web browser itself instead of third-party libs such as React.

I suspect React has a much greater chance of being around in 10 years time than web components. Simply because there are a lot more people using React than web components. React is a boring, stable framework at this point.

> Simply because there are a lot more people using React than web components.

Couldn't you have said that about React vs Angular 5 years ago?

> React is a boring, stable framework at this point.

And that's why it won't be the most popular framework in 10 years time. React started off as a simple and straightforward library. The React team didn't want to stand still, so they improved it. The "improvements" are making React big, fat, bloated and complex, and failures and perf issues harder to debug

Re: React created roadblocks in our enterprise app

#190
post #188

I have spent my morning pleasantly reading the comments here after reading the article. I am struck that a lot of us here start the comments with "I have been a React developer for [3, 4, 5] years" I think this illustrates the fundamental weakness in the approach of people in the Javascrpt Frameworks world. Billion dollar organisations build software that will cost tens of millions to develop want, or should want, mo…

You might assume that, but operating at the level of DOM manipulations is too low-level for a large application.

They are huge productivity boosters. I agree that they are often used irresponsibly resulting in poor quality software. Poor software isn't limited to the browser, however. A lot of commercial software is garbage. Profit incentives seem to encourage software that is barely fit for purpose.

Post reply on HN