React created roadblocks in our enterprise app • Hacker News Board

Re: React created roadblocks in our enterprise app

#201

Post by jiofih » Fri, Jan 22, 2021, 11:08 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…

I’m sure you make this comment in good faith, but no - every React project I’ve been part of sounds very similar to this. The others, not so much, and I’ve been doing frontend for over a decade. There is a distinct amount of churn and excess of dependencies / eternally unsolved problems that is particular to the React ecosystem.

Note that your suggestions do not address the main problems: time spent upgrading libraries, brittle dependencies, and linear degradation of performance and stability. Code standards and code reviews cannot help when the problems come with the standards.

Re: React created roadblocks in our enterprise app

#202

Post by jiofih » Fri, Jan 22, 2021, 11:13 PM UTC

vinceguidry wrote: post #54

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…

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.

Probably that was before package-lock.json (version pinning) was introduced?

Re: React created roadblocks in our enterprise app

#203

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

andrewstuart wrote: post #88

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…

The problem is that the author most probably chose some libraries than went out of fashion or started stagnating and ran into some bugs or lack of documentation that drained time.

Its impossible in JS to not have made bad choices that didn't last or cost huge amounts of dev time to workaround.

The real key to politics is building up enough political capital to be able to survive when things go south. If you continuously make bad decisions you will inevitably be fired. Even if you were always learning from them each time.

I would say:

- communication - here is why and how we made these decisions and the assumptions we followed. if they turn out to be bad choices, here is where our assumptions were wrong. we are going to learn from them in the future.

- management buy-in - you need the CTO to buy into your decisions and reasons and not just to trust you to make them. let them make the decision. avoids the blame game in the future.

- avoid shiny things - you have to stick with what you chose and focus on delivering business value rather than always thinking about that re-write or the new shiny thing. work is going to be less fun and you will feel like saying "a rewrite to this library is going to make us more productive" but it rarely will and unless you have a strong CTO its always going to be hard to justify.

Re: React created roadblocks in our enterprise app

#204

Post by isubasinghe » Fri, Jan 22, 2021, 11:17 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…

https://github.com/isubasinghe/advanced-redux-patterns

This is Nir Kaufman's code. I think this makes Redux far more usable, it removes the need for thunks/saga etc.

Here is the talk: https://www.youtube.com/watch?v=JUuic7mEs-s

Re: React created roadblocks in our enterprise app

#205

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

Here issue is not with React but classic case of poor leadership, architecture and project planing. All issues and road blocks could be avoided just with adhering to a few guidelines.

Roadblock #1: I am not even sure why does it matter what is behind the curtain, only important thing are REST contracts, everything else is splitting team front-end / back-end. Everyone can have what ever naming convention they want. If project is enterprises it means that has more than 11 people or what is considered as a high number of SCRUM team, so spiting concerns is important and necessary. Everyone does it all (all full-stack devs) just does not work.

Roadblock # 2: This is due to experience, and it is up to UI team lead to decide, rest they follow. Sorry, in enterprise projects democracy does not work, maybe in the first few meeting but there you need to draw a line. Regarding dependencies, this is strictly role of one person, everyone else works on 'git pull' forbid everyone else to fiddle with package.json use lock file strictly and package versions, and you will not have any issues, each machine will have exact copies.

Roadblock # 3: This is not a blocker and Hooks have solution for any kind of pattern, it is still possible to use Redux pattern without issue.

Roadblock # 4: Machines can get slower, and in my team we had similar issues, but hey you cannot expect to work with 2GB in 2020, not realistic especially with Chrome sucking memory with 34 tabs open. Don't forget VS Code is built based on Chromium so basically you have two vampires on you computer. And having virtualized environment is even worse.

Roadblock #5: Saga in my case was relief, if you structure correctly Redux Actions and Reducers in neat way, and if you split your concerns, you do not have any issue, in fact it was working as a charm.

Again there are multiple approaches how to deal with this, even split project in multiple smaller SPAs if necessary, but at any point not issue with React but more case of PEBMAC :/sorry.

Re: React created roadblocks in our enterprise app

#206

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

nawgz wrote: post #53

maxfurman wrote: post #13

This mirrors my own experience with React. The core library itself is fine, and I love the way it bridges functional paradigms without forcing a ton of functional vocabulary on the team, but the ecosystem is a mess. And, because the React core is so minimal, eventually you need to interact with that ecosystem. JS dependency hell is real, and it's worse with React than any other framework that I've worked with.

I don't really understand what users are doing when they say things like this. What kind of features are you trying to implement? As a React dev since 2015, things were pretty bad initially in this way - but now you can literally build complete applications with React, react-router-dom (clearly the winner in this regard), and your choice of state management (mobx 6 is, to me, the best). Redux is king and MobX is the…

> debugging / error messages

I think its still quite bad for debugging. I get a lot of "look here" for errors, but there are still times I set breakpoints on the internals to try and figure out what is going on. Usually in combination with some babel plugin messing things up, or some webpack caching issue, etc. I still think more could be done here, but adding the necessary debugging stuff would bloat the core.

> Redux is king

Redux is quickly going out of fashion. Interested to hear your thoughts on how long you think it will remain around though or evolve. When I look at redux-saga/redux-observable projects, its incredibly verbose for such simple things. And there seem like very simple solutions on the horizon with suspense resource fetching stuff.

Re: React created roadblocks in our enterprise app

#207

Post by dragonwriter » Fri, Jan 22, 2021, 11:25 PM UTC

ezzzzz wrote: post #99

dragonwriter wrote: post #51

> Quick onboarding for new team members, especially for the .NET developers working on the old desktop application. Yeah, unless you have a sufficient base of React (or at least JS) devs to shepherd this, this is obviously going to be a problem for choosing anything that isn't .NET, and the further from their existing .NET experience it is, the worse it will be. .NET is a workable web app platform, even for isomorphi…

Judging by the article, this project likely started before Blazor was released, however, I have to agree that .NET should have been the obvious choice. Maybe the author wasn't able to decide this, but I wouldn't consider an SPA for an enterprise app unless there was a very good reason. Stick to boring stuff that works. Leave the bleeding edge stuff for side-projects and startups.

> Maybe the author wasn’t able to decide this, but I wouldn’t consider an SPA for an enterprise app unless there was a very good reason.

I’m on a team that has (I feel) been relatively productive with SPAs backed by serverless microservices in an enterprise environment, but its largely greenfield. And, frankly, at this point, the major SPA frameworks are really “boring stuff that works”.

Re: React created roadblocks in our enterprise app

#208

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

nickthemagicman wrote: post #18

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…

JSX always seemed like a red flag to me. It was redesigning something that already exists to make it so that it uses non native browser functionality? Also the portability looked like an issue from it. I don't understand the use case for it. Vue and apparently Angular use basic browser friendly components.

I hated JSX when it first came out and thought React wouldn't take off because of it, then I used React for 5 years, and I still hate JSX.

I write all my components like this:

    const props = {foo: 1, bar: 1}
    
      {children()}
    

    function children() { return foos.map(b => {b}) }

Why do I have to use a weird language with non-standard JS stuff. Writing conditionals in JSX is horrible, and props are unnecessarily verbose when we have ES6 language features like structuring.

It could easily be just a nested tree structure.

Re: React created roadblocks in our enterprise app

#209

Post by syndacks » Fri, Jan 22, 2021, 11:34 PM UTC

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 guy's clearly a genius but he's also an asshole. Bigger projects across multiple disciplines require collaboration and communication, which inherently add complexity and cost. We're not all savants building indie games, so we use other people's work in things called libraries and dependencies.

Re: React created roadblocks in our enterprise app

#210

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

nickthemagicman wrote: post #61

bluefirebrand wrote: post #24

Earlier quoted context omitted.

Why does it really matter if the code you write is browser friendly or not? Everything is transpiled to browser code anyways, that includes Vue and Angular and JSX. None of the code you write is ever really touched by a browser anymore. At the very least it's minified.

Agree completely! I think the whole ecosystem is insane! Something that needs 3 or more layers of transpilation...is not right. Typescript to Babylon to JS. Sass to css. These are workarounds for native JS warts. That's why Im excited about NATIVE web components and future releases of JavaScript becoming sophisticated enough that we can ignore all of this framework insanity. Or even better...web assembly somehow taki…

I think in 10 years we are going to see a lot of stuff built into the web platform. Typescript definitely now that MS is using Chromium. Then we have Deno for the backend.

One day in the future a kid will be learning programming, and not realize the billions of lines of tooling, or the hundreds of thousands of hours of thought that was put into working around an inadequate platform. However, a lot of this will have been necessary to get to the end result. But also a lot will not have.