121–130 of 298 posts
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…
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 [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 building with no pain points today, except maybe that the tooling is way better now.
Third, all this noise about "the JS scene has so much churn" is kind of crazy. I don't know what kind of library evaluation techniques everyone else has, but React is backwards compatible with techniques they've been saying they'll deprecate for years, version pinning works perfectly fine, and with TypeScript there's less and less churn and mystery than ever before.
> Ultimately though, I just shudder to think about writing large, complex enterprise Apps in the latest and greatest
This is a comical take. Facebook is powered by React. Large, complex, enterprise, and fully powered by the cutting edge of JS frameworks.
> React now looks completely different from React 1-2 years ago
But still fully supports the previous way of working, meaning not only has none of your knowledge been invalidated, but you have additional tools at your disposal.
> Libraries fall in and out of favor
react-router-dom has been my goto for quite some time, as has mobx. Again, you can version pin and stick with any solution as long as you want to - my things powered by react-router 3 are fine still.
> I would much rather take "boring", stable languages and frameworks
> I'm an ML Engineer
Is it not true the entire ML ecosystem has been reinvented in the last 5 years? My React code still builds & runs from 2016. I really feel like this is a case of "external person overestimates complexity in external domain, underestimates complexity in internal domain" because everything you're saying sounds like you dipped your toes, and didn't actually build applications.
Final thoughts: you don't need to update Webpack to resume building your old project. Your build scripts work just fine. Better yet, don't eject from Create-React-App or some other build provider and you never even need to think about this stuff. React is boring and stable, speaking as someone who has used it for half a decade and sees no reason why that won't just become a full decade.
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…
This seems like a problem that could be solved with one email.
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…
Internal support from eng teams is a must, without that the migration won't work.
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…
Earlier quoted context omitted.
> 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. Right, but this still isn't the fault of React. My gripe with this article, and view points like this, is that instead of taking ownership it's again the tool that gets blame and just further perpetuates the "js bad" meme. > And I'm not entirely convinced that…
I agree people should take ownership over their decisions, but it's more nuanced than "don't cry": if someone makes a mistake/bad decision, shouldn't they warn others so they don't do the same? And frankly, let's stop pretending the JS ecosystem is not problematic. Can anyone in good faith argue for a JS project which offers the stability, refinement, and elegance of projects available for Ruby (Rails), Python (Djang…
React is a node project, so I can do so trivially. React is a top tier library when it comes to key features like stability, documentation, backwards compatibility, and extensibility / usability.
I can also say TypeScript is one of the most amazing projects of all time.
Last but not least - express is super easy to use. I don't know what "dev-friendly" means, as a criteria though. Keep in mind, though, since it's JS, it's really easy to wrap and extend. To me, you have to justify how Flask is superior to Express; I think you just like Python more.
It does sound to my like all of these issues would be the same no matter what library/framework you chose. Working “against the grain”, choosing third party libraries, managing coding conventions and dealing with code bloat is common to all technologies. Unless all these points are adressed, you’re unlikely to achieve success with any platform.
Earlier quoted context omitted.
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.
Unilateralism != innovation.
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…
This attitude smells of "you're attacking my way of doing things, therefore you're wrong". While there's truth in both your claims and the GP's, there _is_ churn and there _is_ a ton of garbage in the ecosystem, that much is very true.
The nuance is that the distribution is not uniform: lodash has been stable for ages, axios is perfectly fine for HTTP requests, etc. Where it gets sketchy is when you get to the fringes of what a framework is expected to do. But at that point, not even Angular or Ember can save you.
As for framework-specific churn, React itself is not the only cog in the equation. As part of my job, I see a lot of React codebases from various periods in time and honestly, yes, there's a lot of churn. Looking only at React's API churn, we have code using hooks, class components, HOCs, render props, heck even React.createClass.
And then there's hipster libraries that willy-nilly break APIs to match each new React idiom, libraries that just can't make their minds about what their API looks like, abandoned libraries that uses the old Context API, libraries that depend on componentWillUpdate, libraries that read the shape of the virtual dom node, libraries that depend on those libraries, and on and on goes the rabbit hole. React Router, for example, is both extremely popular and notorious for having given people migration headaches.
On top of that, there is of course the self-inflicted pain: redux-saga messes that no one wants to go near, misguided attempts at "functional programming" and other forms of over-engineering, etc.
But here's the rub: Angular _has_ idioms for forms. You don't wrangle w/ random breaking changes in react-form there. Angular has a router. No need to worry if your favorite router lib will break APIs when Suspense comes along. Angular has HTTP requesting. No bikeshedding over axios vs isomorphic-fetch or whatever. Angular has state management idioms; no fussing over where async stuff goes in redux (assuming you're not still arguing redux vs mobx). Pluralization? Hope what you picked is maintained. CSP support? Yeah, go google that, I can wait. Etc.
You can definitely become a competent React dev and spend many years on good, well maintained projects in React-land, but that doesn't mean there aren't problems directly attributable to the React's limited scope as far as "frameworks" go.
So many things here indicating both a strategic problem in the org and some issues with the approach. Context: I've used both React and Angular extensively on a variety of applications, for startups and the most "enterprisey" of entities claiming to be enterprisey (the government) and came from a .NET background prior. First - GRRR. What defined this as an "enterprise" app? Facebook is an enterprise app, dude, with m…
Enterprise apps tend to have much lower volume of users but a ridiculously long checklist of features.