101–110 of 298 posts
Earlier quoted context omitted.
100% this. The moment you allowed the .NET devs to bring their mindset into a fundamentally different space you were going in the wrong direction.
I mean for a greenfield project sure but a port of an existing large application that is already coded in a specific style you likely want to preserve as much of that as possible to make the translation more mechanical.
You just got steamrolled by .NET OOP dinosaurs, React played no part in it.
The experienced .NET development team got blind-sided by a script kiddy with a Java Script package fetish.
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…
You are describing a job I really would hate: no inovation, no try. If you can't even change the package.json without getting everyone angry, it's a horrible team to work in.
Technology problems are usually just human problems behind a mask. In this case, the real problem was a poorly skilled team with bad leadership, and React just exacerbated the problems by giving the team enough rope to hang itself.
100% this. The moment you allowed the .NET devs to bring their mindset into a fundamentally different space you were going in the wrong direction.
Earlier quoted context omitted.
> 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…
This is again so dismissive of the author. He seems to have a substantial amount of experience with React. He isn't just some noob who jumped on some bandwagon and picked the latest sexiest thing for reasons. If anything, the entire team seemed to do far more due diligence in decision making than pretty much 90% of the move-fast and break things (TM) SV startups. > It's a feature, not a bug. Yes, a small, light-weigh…
The author did not convince me that they had above average due diligence. It's common to go through the motions of required processes/procedures like:
"create decision criteria, do research, validate findings by creating a proof of concept, present findings, document everything in the decision log"
and not generate much value from the process as a result.
Earlier quoted context omitted.
100% this. The moment you allowed the .NET devs to bring their mindset into a fundamentally different space you were going in the wrong direction.
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…
.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.
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.
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…
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 having the protocol gratuitously changed to the other protocol.
Earlier quoted context omitted.
I really can't understand what your objective is here. Frameworks are going to exist in every single language. Do Python developers say "I cant wait til Pandas isn't part of my workflow"? I also will challenge your sentiment that JSX locks you more into a framework than writing DSL extensions of HTML. JSX is supported by quite a lot of frameworks, so you aren't locked into React; additionally, React is the best UI li…
"JSX is supported by quite a lot of frameworks, so you aren't locked into React" Just not the browser natively.... Most backend frameworks don't need numerous layers of transpilation because they're on an actual OS and arent trying to work around an insane environment like the browser that's full of warts and incompatibilities. What's the churn on Pandas? It's been around over a decade. And it can probably be reliabl…
Most backend frameworks need literal compilation - all that's different here is that the target is a specific JS version, not machine code. Additionally, there's a bit of "naivety" here - browser vendors are the ones that implement native features, and that's clearly not a domain that a random developer can impact. Instead it's JS frameworks and associated tooling, which is all very strong now. The idea that Angular or Vue are somehow going to work in the browser directly is, once again, absurd, and please stop saying it.
> What's the churn on Pandas
I find it silly that you'll cite Pandas as not having churn when its parent language just underwent a large, painful, poorly received transition.
> It will be surprising if React is around in 5 more years
You are saying the same things people said 5 years ago about React. My React code from 2016 still compiles against the newest version of React, and works correctly.
Honestly, you're a classic example of this - you started developing not in JS, you felt some warts of JS, and now you hate JS and are ready to throw the baby out with the bathwater.
I'll be more surprised if "native web components" or "webassembly" are actually supporting production use cases in 5 years than if React is.
Earlier quoted context omitted.
100% this. The moment you allowed the .NET devs to bring their mindset into a fundamentally different space you were going in the wrong direction.
I'm still kind of stuck on the fact that they brought a team of .NET devs on to do a React project. What did they think was doing to happen when they used a team with no experience in the technology stack chosen? The conversation should have started with "What skills do the implementation team have?" before tech was chosen.
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…
> React now looks completely different from React from 1-2 years ago. Libraries fall in and out of favor. Is that true? Can you give me an example of what you're thinking of? I've used React since pretty much the beginning and the only "completely different" looks I can recall is class-based components -> functional components + hooks. And even that evolution was pretty comfortable and backwards-compatible.
If I was a full-time web-developer, I'd maybe be willing to live with the churn of the JS ecosystem, but as someone who enjoys software engineering and building fun projects, the churn is simply exhausting and a big turn-off. I spent a year doing a lot of intensive React + Electron + D3 + MobX and all the associated stuff (webpack, npm, node, etc) in 2018, and then at some point I realized its like being on a hamster wheel and you gotta keep going frantically just to stay up to date with the newest libs and toys and APIs and current group think. Meanwhile, a year spent just writing and learning good software in Python (for example), gains me so much more transferable skills to anything I touch as a software engineer in the future.
I still like the power of being able to make user-interfaces easily and there are plenty of things I enjoyed about developing web/electron-apps, but ultimately I was just turned off by how much continuing investment of your time it requires just to stay relevant in the field without imho adding any real value to actual software engineering skills.