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 point to generate chaos and problems in the long term.
Also, the design system matters a lot. Have a small team working on the UI components to tailor and extend the design system. Dont allow the rest of the teams to extend the ui components with new libraries. Stick with the design system
as much as you can. The rest of the teams should minimize the amount of CSS they have to write to components placement.
Usually the datagrid is the soul of any enterprise application. Choose it wisely and be sure it covers as much functionality as you can and also that it is customizable on an "easy" way. There is always a team with the need of a datagrid that sorts, groups, filters the data with dynamically adjustable cells and multi header items without pagination. Welcome to hell.
Use one pattern: hooks, central store, whatever you want. If at some point you have to change it you have to know which teams are using which one. Dont allow team members of the same team follow different patterns. Code reviews must take care of this.
Hope this small tips help one or two teams out there. I have worked on the migration of 5 big enterprise applications from angularjs to react or from legacy desktop application to react or from server pages to react.
I made a lot of mistakes that costed a lot of dollars. I have tried to learn from them. Also, dont take me very seriously, I am pretty sure I am about to discover another mistake I have made.
> 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 them periodically.
Moreover, even if you are happy with your decisions, you might be forced to take them again, because the library went out of fashion, unmaintained, or the developers just stop responding to issues and ignore you completely. This is already happening to a project I work with where the react-router developers just went to build their own nextjs competitor and stopped responding to issues. Same with styled-jsx from the same next.js team, not even themselves seem to be using it anymore.
This never happened to me using Rails. True some gem might go away, but at least it usually is some helper thing and not the core of my f*ng application. Same experience with django and many other uncool stacks.
So, yes. React is amazing if you are facebook, google, amazon, building a side project or just working for your own resume. It is not good for the average business. It is not good for enterprise applications.
the person who has the authority to call the shots and leads the project.
The error is right there in the article:
"After nine months, we have more than 50 pages created. The developers notice that function components are as good as class components and start using them. So, now the project no longer follows the original coding guidelines. It’s more like a personal choice for each developer. And for me, that is OK."
This is where the screw up happens. This is not okay, and as the person responsible for the architecture the author should have made a clear and concise decision and then get everyone to comply with it. You cannot let your developers run wild and then complain a year later when everything is a jumbled mess. Even more opinionated frameworks won't save you because the application is so large it likely would have happened regardless.
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.
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.
IMHO, there's a bit of an irony that I see with a lot of React projects: people often say that w/ vanilla JS, you end up reinventing wheels poorly, yet this is exactly what a lot of React projects I see look like: people that don't really have framework-building experience attempting to cobble up something similar in scope to Angular or Ember by using React + a bunch of other libraries (often libraries they've never used before).
There's certainly a case to be made about large teams being a problem of their own, but FWIW, a lot of projects _don't_ have large frontend teams (I'd say 1 to 3 frontend devs is fairly typical). Standardization _across_ teams can definitely be a problem, but at some point one has to wonder if it isn't more sensible to just have each teams develop separate apps that load in separate pages, or, you know, just use a more batteries-included, prescriptive framework.
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/installed.
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 having the protocol gratuitously changed to the other protocol.
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?
The issue is that some developers have configured the registry field in their .npmrc file incorrectly. Ideally, sending out a memo telling everyone to fix it should do it. If not, one way to fix it is to commit the .npmrc with the correct configuration (assuming it doesn't include secrets). If all else fails, an ugly hack is to make a preinstall hook that fixes the .npmrc file.
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.
This was my biggest take away from this article too.
When you have a big project, you have to keep a consistent architecture. You need to keep using the same tools and patterns so that you have cohesion in your code base.
The worst thing about new architects on long lived projects is you typically get 2-4 ways of doing the same thing. If you're going to do that it needs to be so good that you don't mix and match.
If you are going to mix and match, you need to have a solid approach to splitting your dependencies, one way I'd have looked at doing this is by splitting this into multiple sub SPA applications and each mini project would be able to conform to it's own standard as long as it could interface with the glue application, this is by no means foolproof, but it gets you a lot closer to a maintainable situation from my experience.
Why I like this approach is that I saw a comment from someone saying they'd hate to be on a team with a uniform style. I completely get that, innovation is super important, but you have to build boundary layers between the different styles so you don't end up building such a hodgepodge of dependencies that you can't get things to work anymore. It also keeps your build times down and reduces time to get started working on your module.
Again same comment you made, I've made mistakes, trying to learn from them, maybe my current approach is bad too and there's a better way.
Use a monorepo with many `package.json` files. Then someone working on a data grid component for example can add the packages they need for that component and no one else's code will depend on it and it won't break anyone else's.
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.
Innovation doesnt come from adding a library to the package json.
You are a member of a big team, not a single dev on a pet project. Innovation is on the product, not in your developer experience (unless you are creating a developer tool). Consensus to make big decisions is not the way to limit your developer skills is the way to align a team to achieve a common goal. :)
I love this way of phrasing it. I have these types of arguments with a particular type of colleague often, and this is a missing part of my explanation script.
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 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. Granted, a lot of that criticism holds true for the entire JS scene where the churn is simply ridiculous and you have to cross all your appendages and hope for the best before you try to build a year old project. But React is especially problematic in that regard only because there are so few batteries included (which is great for small/mid sized projects, but the opposite if you are looking for stability).
Ultimately though, I just shudder to think about writing large, complex, enterprise Apps in the latest and greatest JS/front-end frameworks due to the crazy levels of churn in frameworks, libraries and APIs. React now looks completely different from React from 1-2 years ago. Libraries fall in and out of favor. Some keep up with the ever changing API of the parent frameworks, others die off. It's like an entire ecosystem that has ADHD and as someone who has built several small to mid-size React and React + Electron apps in the past, that ultimately turned me off the entire endeavor (I'm an ML Engineer, but I love software engineering and building stuff for fun). I would much rather take "boring", stable languages and frameworks and spend my time honing skills that actually matter and help me as a software engineer throughout my career, rather than spend a week trying to get webpack figured out, till the next big webpack update when I'd start over from scratch again.
> 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 React from 1-2 years ago.
Does it? I've worked in React, at enterprise levels, for close to 3 years now. Except for the addition of hooks, there hasn't been a whole lot of churn. React today is still the react of yesteryear, but with extras.
Imo the biggest failure of the author was to jump headfirst into a stack they weren't familiar with it, and then blame it on the stack.
I know it's en vogue to hate npm/react/js "because the ecosystem", but at this point, picking the ecosystem and then blaming it is a self inflicted wound that I don't really have patience for.
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-weight framework can be a good thing. No one called it a bug. But like everything in life, there are trade-offs involved. And I'm not entirely convinced that it is a good tradeoff in the crazy JS ecosystem where everything is changing and breaking all the time, especially if you are building more complex things and don't have an army of web-devs to keep the house of cards from falling down.
> 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.
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.
There's so much cargo-cult mentality in react that it's difficult to perform DD and predict the technical landscape years into the future. So perhaps we're in agreement the author should have picked another technology.
Personally I think the author's original architecture was most likely satisfactory, but there should've been design guidelines to enforce a single coding style. You don't have to re architect your app because dan abramov tweeted something.
If there was no value added in adopting hooks then the architect shouldn't have wasted energy adopting it. And let's be real, there was no value added in adopting hooks lol.
> 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 it is a good tradeoff in the crazy JS ecosystem where everything is changing and breaking all the time, especially if you are building more complex things.
Right, and if that's your opinion (and a perfectly valid one!) then don't pick the JS ecosystem and cry when it bites you.
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 (Django), Elixir (Phoenix), etc? Even micro-frameworks like Flask, which don't include tons of batteries, are still much more dev-friendly than Node/Express/React/etc.
>frankly, let's stop pretending the JS ecosystem is not problematic. Can anyone in good faith argue for a Node project
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.
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 superset/transpiler. It makes working with Node/React/Express better, but it doesn't replace them.
With regard to Express, it's decent, but e.g. do we really need to torture newcomers by expecting them to know they'll need to also include/install and require body-parser? I mean, why would I be using a web framework, even a micro-one, if I'm expected to bring in a separate tool just for parsing requests?
Regarding the suggestion that I like Python more, I would gladly choose TypeScript over Python (the typing tools there are still immature) if there was less churn in the JS ecosystem. Deno is promising. :)
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 how they have introduced new features into React. Again - old code works with new React versions.
> do we really need to ... expect them to know
True, this is a weakness, but the documentation is pretty explicit on this front. It's not like there isn't a big community around the library to address this.
Anyhow, I respect your points here, and concede that writing server-side code in Node is probably not what you want to do; I reach for tools like Hasura in this case regardless. With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django template wizardry one can muster.
It would be great if developers stopped treating tools they like with this much sentiment. For starters, it would mean fewer flamewars.
They're just tools, criticizing them is not "hating" and your liking them is no endorsement (for anyone other than you, anyway).
> With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django template wizardry one can muster.
How can you "promise" this? How can anyone "promise" this? I'm not even sure I understood what you meant by this. Even more so in this case as the tools you mentioned are geared to different types of applications.
The only way I can parse this sentence is that you're claiming that react is indisputably better at [not sure what you meant to do since you said "website" and a website doesn't need a backend$, but you mentioned backend regardless] than any tool in [whatever other language/framework, clearly, even if you're using Python as example] and I'm gonna need a source on that one. It's a pretty strong claim, assuming I didn't misinterpret it.
$ Technically, a website doesn't need a frontend either; it's debatable whether a website even needs javascript, but certainly not react, which is a library for creating web applications.
What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement. There is no flamewar here, but criticizing something incorrectly because of personal bias and lack of knowledge is more or less "hating" in a nutshell
> How can you "promise" this?
Because I am a pro web dev who has made a ton of apps and understands the difference in power between HTML templates and JS components? There are objective standards of user experience and for anything non-trivial a web application is clearly going to be more interactive and deliver the data and workflows in a more user-friendly way. Reporting, workflows, interactivity, visualizations, all are much better when they're done interactively with JavaScript than delivered as some static asset to the browser.
>Because I am a pro web dev who has made a ton of apps and understands the difference in power between HTML templates and JS components
so what you're actually promising is you can make a better website with React than with Django for any website that needs advanced JavaScript interactivity - but then obviously the comparison would not be between Django and React but between React and some other JavaScript based frontend technology.
> What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement.
A) I have a very different interpretation of the other person's comments• and I don't see anything factually incorrect in them, b) I would call what the other person said criticizing even if I vehemently disagreed, if just to keep the discussion productive, and c) there was no specific "correction" of anything in the comment I replied to; you only expressed that you think react is stable.
> understands the difference in power between HTML templates and JS components
Those HTML templates don't exist in a vacuum and are invoked by whatever language is being used in the backend. The only "advantage" javascript gives is that it saves you the blink of reload; beyond that, the logic of a web application doesn't change in the slightest regardless of where the html is being rendered.
> There are objective standards of user experience and for anything non-trivial a web application is clearly going to be more interactive and deliver the data and workflows in a more user-friendly way
The GCP console is a gigantic mostly angular based single page application. The AWS console is mostly a jsp based server side application. You know what they have in common beyond being dashboards for managing cloud platforms? They're both unwieldy giant hodgepodges of work by a multitude of different teams.
There's no silver bullet.
You have a preference for single page applications. That doesn't mean a user is going to like an unusable SPA more than a well architected server application more just because the SPA saves page reloads.
> Reporting, workflows, interactivity, visualizations, all are much better when they're done interactively with JavaScript than delivered as some static asset to the browser.
I originally asked for a source of your claims, and I would really like to see your data for this.
Let me turn your original claim on its head: With proper backend tooling (be it Rails, or Django, or whatever else) and a low-javascript, progressive enhancement library like htmx, I can "promise" you I can make a better web application than with just javascript, no matter how much JSX hacking one can muster.
But I don't actually believe that, because it's better to use the right tool for the job. Sometimes an SPA framework is the right tool, and in that case I'll go for vue or svelte. After all, they're vastly superior to react ( ;) ).
• For starters, most of them were about the javascript ecosystem in general; for that matter, you've been focusing on react more than anyone else in this exchange.
FWIW, I am not against SPAs, either. I actually prefer using them in most cases if I can help it, because it pushes me toward building out an API that is not coupled tightly to my web front-end, and can be reused if I ever need to serve a mobile app, etc.
Also, you are correct that I was not initially dissing React specifically. The amount of churn in the Node ecosystem is a real issue, and I am always getting those vulnerability emails from GitHub for old, forgotten repos where a dependency I never even knew I had is problematic.
Deno recognizes this is a serious problem, with one of the bullet points at the top of the home page touting "a set of reviewed (audited) standard modules that are guaranteed to work with Deno: deno.land/std". Deno was started by Ryan Dahl, who also invented Node. I don't know if he's said this explicitly, but I would imagine he had his own Dr. Frankenstein moments with Node.
The other thing is that anyone who isn’t oblivious has seen the writing on the wall (React docs and changelogs) saying that class components are not the happy path of React development. This has been clear since late 2015.
The only people I could see not noticing or ignoring this are people new to React or people who are emotionally attached to classes.
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.
> can they come back and build new React projects without significant re-training?
Absolutely. For one, React introduced a few primary concepts: components, JSX, and the component lifecycle. Whether you wrote functional components, class components, or moved to the new hooks-based components, these lifecycles are behaving the same. The way you write the lifecycle hook might be slightly different in a hooks world but it still exists the same. JSX is almost entirely unchanged in my experience. Composability and other techniques to pass data or context thru to the children still work the same as ever. Accessing DOM nodes still works the same as previously but with a new method as well.
In general, "the old way works but there's a new way too" sums up a lot of the core features. The library has updated and refined itself, but maintained back-compat with almost all old ways of using it, and conceptually stayed true.
If you don't know why this was downvoted - React rose to popularity in 2014-2015, and so my code from 2016 working correctly implies that the library has remained compatible with code written almost at any point in its lifespan.
Also, shouldn't "enterprise level software" prioritize new and improved ways of working for maintainability in 30 years anyhow? React & TypeScript is going to be a much more readable form of maintaining UIs than old-school template hodge-podge, direct HTML generation, jQuery, or whatever you want to point at. To that end, I answer "my React/TS code is more likely to work in 30 years than a legacy system being forced into the modern web world"
I really wish I saw what everyone else sees in TypeScript because that language has not sold itself to me at all, even using it professionally for years now. Even using it's primary feature can be a pain because nobody documents their types as far as I've found. It's surprisingly common for me to write code that compiles but crashes at runtime. Other, better JS-targeting languages manage to allow me to retain type-level features at runtime while also outputting leaner, faster, and safer code. The only value prop I really see is the momentum, but it feels like a huge push for the right reasons and in the worst possible direction.
It's not that TypeScript hasn't helped at all, it just doesn't feel like it's this revolutionary thing that people treat it as. And I'm not even going to touch how visually noisy and distracting I find the C#-style type syntax to be.
Good at compile-time, breaks at runtime. It is because TypeScript doesn't want to diverge far from JavaScript. TypeScript compiles to JavaScript and if you give the wrong input you'll end up with runtime errors.
Usually this happens with casting. Casting an `any` variable as `string` doesn't do anything other than letting the compiler knows that it must be string. It doesn't transform the variable and throw error when it is not string. This is a bit like casting struct pointer in C.
This usually happens at IO: `fetch`, `localstorage`, `fs.readFileSync`, etc. It can't be solved purely with TypeScript. I used `io-ts` to mitigate this problem.
Other than data type, brutally tweaking your tsconfig (and webpack or rollup, if you use them) can also cause errors in module resolution, which is not a nice thing.
TypeScript is almost revolutionary. The thing I wish to exist is a superset of TypeScript that allows Rust-like macro. It is super handful, super beautiful.
> I really wish I saw what everyone else sees in TypeScript
> It's surprisingly common for me to wrrite code that compiles but crashes at runtime
Well, is it also common for you to allow `any` in your code?
TypeScript is strongest when it can type-check your entire code. If your API endpoints return data that doesn't match your type (or at any other external data load point), TypeScript clearly can't help with that. I'm actually quite sure that if you have this kind of behavior in TypeScript, your other JS-targeting languages would fail too; you have just mis-typed something.
> Other, better
Yes, you're not biased
> JS-targeting languages manage to allow me to retain type-level features at runtime
What does this mean? They compile to put a magic key `_type` on an object?
> while also outputting leaner, faster, and safer code
I highly dispute your claims. You're building JS still, it's not going to be magically better - this just means you write bad TS. Show me some numbers or some code to make this claim.
> it feels like a huge push for the right reasons and in the worst possible direction
Given that you started your complaint with "no one documents their types", I am not so inclined to listen to your opinion. Types are the documentation. Interface names, key names, types, full autocorrect interacting with any objects, generic type support, reasonably smart type solver / caster, great error messages; these are all things TypeScript offers for learning a thin extension of JS.
> I'm not even going to touch how visually noisy and distracting I find the C#-style type syntax to be
Why not? I would love to hear more ridiculous complaints which only make sense thru your personal lens and have no justification or empirical evidence behind them
> It's a feature, not a bug. Not understanding this is a red flag that you're going to run into problems.
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.
I'm not that familiar with React (although I have had the misfortune of working with Angular), but I've seen the horrific Spring "framework" defended that way: it doesn't actually include any functionality because it's designed to be open ended! What it turns out to be is the most useless thing that ever happened to programming: it's pure overhead, undocumented (surprising) behavior, unwanted defaults that you have to spend time working around without the benefit of actually simplifying anything. Not saying React is the same (like I said, haven't really spent much time looking at it), but it's adherents defend it the same way Spring's adherents defend it.
In React's case, it's meant to pretty much entirely focus on the process of (input data -> output DOM nodes), plus the minimal set of wrapper functionality needed to handle user input and general asynchronous data loading (class-based component state, context loading, and most recently hooks). It intentionally doesn't handle a lot of stuff like dependencies (that's a job for your bundler), the actual data fetching, the actual specifics of your UI, centralized global data management, etc.
> Does it? I've worked in React, at enterprise levels, for close to 3 years now. Except for the addition of hooks, there hasn't been a whole lot of churn. React today is still the react of yesteryear, but with extras.
I have been using it since you could only track state in class components, and I personally think it looks drastically different with the evolution of hooks. I interpret components differently than before. The patterns for doing most things has changed, such as the inherent deprecation of the higher order component and render props pattern. I'm not implying that it's bad there have been changes (some are absolutely warranted), but rather explaining how I do believe the library looks different than it did before hooks.
> Imo the biggest failure of the author was to jump headfirst into a stack they weren't familiar with it, and then blame it on the stack.
>I know it's en vogue to hate npm/react/js "because the ecosystem", but at this point, picking the ecosystem and then blaming it is a self inflicted wound that I don't really have patience for.
I work in corporate, you wouldn't believe the infantilism in frontend development, always doing everything but modeling the problem and iterating that model. People are also not good at picking up on cohesive properties of libraries. But this is life in the name of holy velocity.
> 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.
I think the large things in my admittedly limited experience were hooks and context API. Which in a sense isn't a massive change, but the problem is that just like the author of this article mentions, now there are more ways for things to be done, and moreover, because React is a small framework itself, all your 20+ dependency libs have probably moved on and implemented everything with hooks. So now you pretty much need to learn hooks, the context API and throw out your prior domain knowledge from 2018 because whether you like it or not, you gotta still adapt to hooks, because that is the new thing now and the libraries you rely on are now using the new API and approach.
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.
>I spent a yea rdoing a lot of intensive React + Electron + D3 + MobX in 2018
Right, and that code still runs and compiles exactly as it did then, correct?
The fact that other tools move on doesn't mean you have to. Actually, out of what you just said, D3, MobX, and React all have not removed any of the APIs you could've used back in 2018. Did people maybe rewrite some tools to support hooks, and in doing so find that hooks were a more concise and readable solution? Yeah, they did, so we moved to hooks.
> a year spent just writing and learning good software in Python gains me so much more transferable skills to anything I touch as a software engineer in the future
How so? This is a complete non-sequitur. If you consider data science / ML to be the entirety of software engineering, then maybe you have a point, but since you even put (for example) beside Python it just looks to me like you hate JS and will pretend it's not software engineering so you can avoid it. Any time you've spent tweaking build systems or updating libraries for no reason is on you, not on JS.
> I think the large things in my admittedly limited experience were hooks and context API.
Which, sure, is where a lot of the new goodies are going, but in enterprise land (where I recall working on apps that were .NET 2.0 and .NET 1.1 that were first written well after either was current and are still, AFAIK, being maintained, and on those platforms) writing apps with the still-fully-support class components and ignoring the newfangled options would be completely within the scope of normal approaches. Having new options doesn’t make something less stable, not supporting the old way of doing things is unstable.
> you gotta keep going frantically just to stay up to date with the newest libs and toys and APIs and current group think
AFAICT, there’s no active platform where that’s not true, if you want to stay up to date with the newest libs and toys and APIs and current group think.
In enterprise land, though, we typically (at least for any given product team, and often at a larger organizational level) tend to go to the opposite extreme: we plant our flag someplace that was out-of-fashion of the hipsters for years before we even started the project, and nothing that doesn’t actually break what we have built that happens after that really matters. Pushing things out of that rut often takes effort.
As a React dev for half a decade, I strongly disagree with many of your points.
> 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.
I’m sorry, but this comment is a total goalpost mover, and complete BS.
The goalpost moving: the initial article is talking about porting a desktop client based program with a reasonable amount of views to the web. Now Facebook scale and quality UI isn’t good enough to demonstrate that React is a strong front end tool.
I also don’t see how the UI is particularly likely to cause issues to an insurance or banking company.
The BS: “most software of significant cost and size is serving a industry, not the industry itself”. This sounds smart but it has virtually no relationship to the main drivers of complexity behind the UIs in discussion, which is number of developers and number of pages. You cannot reasonably tell me Facebook doesn’t show React scales for UI engineering.
"the initial article is talking about porting a desktop client based program with a reasonable amount of views to the web. Now Facebook scale and quality UI isn’t good enough to demonstrate that React is a strong front end tool"
Not the whole truth. It was a big job. "Enterprise level" has no clearly defined meaning, but I assume millions of dollars. A large team of C# programmers doin the system.
So it is worth doing sustainably. There is no evidence that react, which judging from the "I have N years experience of React..." N <= 5 is about five years old, can be a sustainable solution for anything. It might look good now, but can it be maintained in twelve years when all the script kiddies are off on the next Best Thing
Whichrelates to your rude and sweary comment about: "... is serving a industry, not the industry itself" it is not complexity but sustainability. Facebook is the software. Your bank is not its banking software. The bank needs to know that in a decade they will still be able to maintain the software. If they use React, or Angular or goodness knows what else the bountiful world of JS frameworks will throw up for us, they cannot guarantee that.
I can reasonably say that Facebook doesn’t show React scales for sustainability: It does not.
> "Enterprise level" has no clearly defined meaning, but I assume millions of dollars
Ok, so Facebook builds UIs, manages a valuation worth close to a trillion dollars, and uses React everywhere (even sometimes outside of the web!). That does NOT show React scales for sustainability? My fucking ass. That's a bullshit take.
> can it be maintained in twelve years when all the script kiddies
See, software engineers love to pretend UI engineering is like some half-discipline or doesn't matter, but it just makes you look braindead. Your whole take is "Facebook and its trillion dollars aren't showing React scales" and "UI engineering is for script kiddies". Fuck you.
Great reply to this mindset. The chance that anyone who makes this claim has actually evaluated enough (or any) JS projects to see why they churn is effectively zero.
We have version pinning for a reason. It lets churn exist without forcing the effects of it onto other developers. I don't care if a library I use gets updated every week or even every day, I'm not installing every new version when it's released, that's silly. Nobody does that in a real project, that's chaos.
Imagine having the arrogance to say "back in the day I looked at this language and I can firmly stay the whole thing is shit". Imagine that thing being the language powering the UIs of the entire modern web.
You have already shown me in other comments that you are highly biased and will say anything if it fits with your biases, but this is really an entirely new level of ignorant
Which is the biggest foot gun I've seen in my life.
There is a surprisingly high number of developer that still don't get it and will make those beautiful applications where, thanks to a naive usage of this, will create applications that rerender the entire application on every keystroke.
> React, since hooks, includes a full state management solution - Context, Provider, and hooks.
Sure, but that hasn't been around even 2 years. Prior to that, there was a different approach and philosophy to doing things. I remember when higher order components were all the rage till suddenly they weren't.
I'm not advocating for stagnation, but at the same time, everything in JS land feels experimental, even in established frameworks, and the entire community keeps marching along as things keep changing. Which if you are a full-time developer doing that, is fine I guess, but it is not the norm compared to pretty much any other software engineering field.
> Second, even if you want an actual state management library, both mobx and Redux are quite stable
I cannot say enough nice things about MobX (although I was using it back when it didn't use Proxies so you had to deal with a lot of cloning back to native JS objects which got a bit ugly at times), and I don't disagree with you on this point for state management, although I personally could not stand redux despite 90% of the community vehemently singing its praise.
> This is a comical take. Facebook is powered by React. Large, complex, enterprise, and fully powered by the cutting edge of JS frameworks.
I should have perhaps qualified that better. Yes, I know there are people writing complex apps, but I was viewing it from the POV of a non FAANG type place with tons of engineers to throw at a problem. If I was a single person or a very small team trying to develop something complex, I would place a much higher emphasis on a more stable development environment/language/framework.
> 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.
Let's take Pytorch as a comparison framework. It's had tons of releases, but at a fundamental level, the core API has stayed the same. I've ported 3 year old code to the latest version with pretty much negligible effort. And at its heart, it is because APIs are kept very stable and people aren't deciding each year that they need an entirely new way of doing ML or performing automatic gradient estimations, etc.
Similarly with Python... there have been a bunch of Python 3 releases in the past few years but they each add new things that are useful without making big changes that suddenly change how everyone would tackle building a new piece of software.
On the other hand, porting a 2+ year old React app to the latest version of React (along with bringing dependencies along) would be a very painful process. I know this, because we've done this at the company I work at.
There is also this implicit assumption in JS/React land that you are going to come marching along with all the latest changes. Heck, less than 2 years back, their documentation site wouldn't even let you view older versions of React documentation, so the moment they released a new version of React, the docs would only ever show you the new docs. What's funny, is that today they supposedly have links to their older docs...but every fucking link is broken :-/
And nobody probably even knows that, because there is a general expectation in the field that everyone just keeps staying up to date with the latest and greatest and deals with whatever pain points come along with that and no one has probably even tried to access older documentations or raise issues about it. Which is fine, like I've said many times before if you've made your peace with it and that is your full-time job, but it is not the expectation or norm in most other fields.
Finally, I should state for the record (because you stated otherwise in another reply to me), that I actually love javascript...well at least ES6+ JS. I greatly enjoy(ed) JS, JSX, developing in VsCode, and even building things with React, Mobx, etc. I'm not a software engineering snob who looks down on JS and the ecosystem. But I also have a more diverse viewpoint because I work at a small company and get to wear many hats and have been able to do lots of different things (ML Engineer, Front-end work, write and deploy pretty complex software, etc.). And while I have a lot of fun doing front-end stuff, It still feels like there is a lot of constant overhead to it, and that is pretty unique to this one field compared to most everything else.
> Prior to that, there was a different approach and philosophy
I don't really agree. Context and Provider have existed forever. Hooks really just expose the underlying setState calls with a different API and a more graceful backing engine which allows this more granular access. It's part of why they made hooks
> I remember when higher order components were all the rage till suddenly they weren't
I almost never used these, but what was their main point? You wrap something in a HOC to inject some variable, like a router or something? No kidding we moved on, no need for this to be so heavy. Again, you're kind of understanding why they made hooks, this type of functionality can be and is written more concisely with them
> everything in JS land feels experimental, and the entire community keeps marching along as things keep changing
UI engineering and the web as an application platform isi young compared to "pretty much any other software engineering field", don't you think? JavaScript was kind of a shit language 7 years ago too, so a lot of this churn is because first JS improved a lot and then still needed types so we played with a few type systems.
Now we have TypeScript making beautiful, readable, maintainable code, and battle-hardened yet concise libraries like React, because we were willing to say "hey this could be better, let's try a new way". Seems weird that everyone criticizes that so harshly, don't you think?
> I personally could not stand redux
I also don't understand its popularity. I avoided it from the start and opted for MobX
> large, enterprise app in React
> I would place a much higher emphasis on a more stable development environment/language/framework
I mean, no offense, but React is about the most stable UI framework there is. If you don't like JS and you're going to do this by generating HTML reports from some other language, I think whatever you build is going to feel behind the times.
> Let's take Pytorch as a comparison
> the core API has stayed the same
> I ported 3 year old code to the latest version with pretty much 0 effort
Right, how is this not comparable to React? I can run and build my 3 year old code against the newest version with no porting required. Porting from class-based to functional with hooks is also quite easy; I moved my entire component library (25+ components including graph + charts) in a few weeks, and it came out smaller and more performant.
> Similarly with Python
I actually don't think I would try and cite the Python 3 transition favorably if I were you; it was not smooth.
> On the other hand, porting a 2+ year old React app to the latest version of React would be a very painful process
!? It runs against the latest version of React!! Why do you need to port it?
Also, I'm imagining your app has significantly more complexity than your PyTorch app - otherwise this claim seems even more absurd.
> Finally, I should state that I actually love javascript
Yes, ES6+ JS is strong, with TypeScript it's actually a top language overall. I also work on a small team, and am responsible for UIs, APIs, database design, DevOps, and more. Each of these fields undergoes this massive churn as well; databases tried to go NoSQL on us, APIs are low-code now for CRUD and you're a sucker if you manually write your CRUD apps, DevOps has completely changed from rsyncing bundles to container orchestration deployments running on Kubernetes, ML and data science have reinvented themselves to use new features and more powerful toolsets.
UI development is a complex and young topic and so while you might feel it has churn, all software is constantly undergoing churn to match the community's desire for how expressive and powerful it should be. The fact that people constantly rag on UI toolkits being updated over time makes me think they fail to recognize UI as complex or young. I feel like you fell for it too, because each domain you listed yourself as working in has undergone similarly drastic changes in the last 5 years as React has.
> 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
1. 5 years ago no: React was already the #1 JS frontend framework at that point. In terms of mindshare if not project volume.
2. I think the key difference is that Angular was a nightmare to work with, especially on larger projects. Whereas React is fairly simple, and tends to be easily maintainable over time.
> React started off as a simple and straightforward library.
It still is. The implementation is kinda complex at this point, but the API is still super simple.
Regardless, you missed the point. Which was that, frameworks come and go. The DOM and other APIs implemented by the browser, on the other hand, are here to stay. Very few things built into the browser have been taken away (such as blink and frameset).
> The implementation is kinda complex at this point
Right. And that makes failures and perf issues hard to track down.
If you know how to program using APIs and components built into the browser, that is easier at this point.
> Regardless, you missed the point. Which was that, frameworks come and go.
Do they? Rails was released in 2005: it's still here. Ditto for Django. It's true that historically frontend frameworks haven't had the same longevity. But nothing in that space had gotten to the same level of momentum as React has. Except jQuery, and that's still here and maintained too.
In contrast, the web component APIs do not have momentum. I would not be entirely surprised if parts of them were removed in future due to lack of use.
> Right. And that makes failures and perf issues hard to track down.
> If you know how to program using APIs and components built into the browser, that is easier at this point.
I rather disagree on this point. I've only seen React slow in 2 circumstances:
1. Too many DOM elements for the browser to cope with. At this point you need to start looking into virtualisation solutions, which is easy to do with a library like react-window. And is exactly what you would do with raw DOM APIs.
2. Excessive re-renders. There is excellent documentation on how to avoid this (memoising transformation functions). And a very simple mental model for how it works (following the usual JavaScript === equality rules). Avoiding this in vanilla DOM code is much harder, because you have a choice between re-rendering everything any time anything updates, doing very tricky piecemeal updates which quickly becomes unmaintainable, or re-inventing a react-like diffing system.
To pile onto your point, webpack is clearly on its way out, it's all about snowpack now (afaik). I never got a chance to get into learning webpack, and I'm glad now. Throws hands up
Just recently I had to switch a project from snowpack to webpack because adding the features I needed to snowpack added up to too much additional work.
Like parcel snowpack works great when you can use it. Hoping it catches on because I really loved how fast it was.
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 flame.
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 this the ui and backend system needed to be developed. Design I proposed was a single "monolithic" service which did everything including UI and UI was supposed to be a old style mustache templates and some minor jquery. Instead they went with pub-sub systems, 4 different microservices, a react based UI, api which used json-schema, even to send data back to UI. When I left a team of 6-7 people was working full time on this and they were about 20% done.
If you join an early stage startup today, it will only be a matter of time until a developer comes in who builds a microservice for what would normally be a single function calling a third party api and then discovers that Kubernetes is necessary. Its almost impossible to stop this happening because business folk want microservices, or they might have heard microservices were going out of fashion but still want Kubernetes...which is only really necessary for microservices.
Devs like to have fun, learn new things, play with complicated things - that's all it is. It counteracts the dull features that most developers have to ship.
I have met enough devs that don't necessarily love to make everything Dockerized microservices on Kubernetes, just that if we don't learn this stuff we risk becoming unemployable.
Are you me? We had an (admittedly more complex) monolith application for customer contracts and billing. It wasn't ideal, and was getting long in the tooth (think Perl Catalyst and jQuery), so the powers that be wanted to build a new service. But instead of decomposing the monolith into a few more loosely integrated services, they went way overboard with 20+ microservices, every DB technology imagineable (Oracle RDBMS, Mongo, MariaDB), a full message bus via RabbitMQ, and some crazy AWS orchestration to manage it all.
What could've been an effort to split the existing service into manageable smaller services and rewrite components as needed turned into a multi-year ground-up effort. When I left they were no where near production ready, with significant technical debt and code rot from already years out of date libraries and practices.
Sounds like my current project. I was tasked to start working on a project and was told I could use "whatever [I] want." So me and the other frontend guy started working using Clojurescript with Reagent and Re-frame (highly recommend). Save for a few hiccups along the way the project was stable and fast.
It went swimmingly right up until QA was more or less told not to file any issues found, and then those issues were used as a reason we needed to use a TypeScript and Material-UI app he wrote over a weekend and said was "almost done." The bugs in question turned out to be minor visual bugs, and like I said, none of them were filed or even mentioned until this replacement got dropped in our lap. In fact, no problems of any kind were reported until this moment.
Instead it took another 6-8 months to get to feature parity with the app we'd already developed and now thrown away (or feature "parody" as my boss put it), it was full of bugs, development is slow and pretty directionless, my boss gets bored and contributes code that runs in the O(n^12) range (yes, really) before languishing in a draft PR for months and then getting dumped on us to actually implement for real, and it's been a year and a half with no end even remotely in sight.
I really want to find somewhere else but that doesn't seem like a realistic goal right now. Not to mention my enjoyment of programming died years ago and I haven't written code for fun in as long as I care to remember.
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.
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 we will be building a frankenstein React project which is built like a .NET application
- the success of the project is at risk
And the CTO would have been wise enough to agree and pull his people into line and give the blog post author the authority to demand things be done as he says they should be done.
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.
I've had clients where this would get you told (in execuspeak) that the least important part of a project is the engineering and the engineering team. Which is of course why their sales people would answer every question with, "Yep, it does that." Nevermind that some of the things getting promised were not actually possible.
I remember one in particular that would push incredibly tight deadlines for huge features, got frustrated at the pace and hired another dev team, and didn't change the way they set deadlines. This of course fixed nothing. Then the other team they hired pushed a huge change to the repo, almost every file in the codebase was touched. Nearly 70% of which was whitespace changes and the other 30% was unfinished code that did not compile. We later found evidence that they hadn't even run the code before pushing the changes. The client demanded that we merge it, were told it would break the build, got mad when we merged it and the build broke, then tried to use that (and a whole bunch of almost hilarious and similarly-effective arguments) against us in a lawsuit which they lost, and then lost the countersuit.
So yeah, that was a fun time for my liver, to say the least. Especially since the C-levels decided to focus the entire company's output on that lawsuit while the engineering team sat around mostly twiddling their thumbs.
If a CTO engages an external company to lead them into a project using new technologies for that team, then that CTO would be well advised to accept that their supplier has the right knowledge to advise them.
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.
One thing that I realized recently is that if you have a mantra of making "data-driven decisions", then you have raised the cost of making a decision. What you then need is a tool that minimizes the number of decisions you have to make. Gartner, Rails, Spring, each try to do some of that in their own ways.
That's where his 3 weeks of decisions about libraries reveals a real mismatch between React and the enterprise way of doing things. React requires a lot of decision making, and enterprises are bad at making decisions.
Ultimately, the fault is with the enterprise. Sometimes you don't need official data, you just need someone with good taste to make a decision (and if your developers cannot usually "disagree and commit", that's a people problem). Save the data for the big picture stuff.
Absolutely. Think about iOS or Android (native) development. Sure, the ecosystem is quite big, however you do not have the level of flexibility that the web has. You are limited not only in terms of languages, but also certain architectural decisions are bounded by the limits imposed by Framework (the Android or iOS SDK), so there are many decisions that _are already taken_, and for better or worse you have to live with it.
That is probably what I hate the most of front-end development compared with back-end or Mobile. There are too many options, and that certainly does not promote consistency within the project.
You could also make decisions not based on data but on your experience. That's how most arts and craftmanship works, and thus why software is often argued to be somewhere between engineering and craftmanship.
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 slightly more adventurous challenger.
I have built an absolute plethora of applications and I do not have any external dependencies beyond those two, TypeScript, D3, and the occasional helper library (date formatting, deep-equals, etc).
Speaking to some other points as well, the React core is not really minimal at all anymore, since the advent of hooks you can actually completely bypass external state management and just use hooks and your own context. I've done this on a couple smaller applications lately and the hooks `useState` and `useEffect` are actually insanely powerful.
Last but not least, React has insanely strong error messages and linting warnings. Things like non-unique key errors, debug symbols knowing the actual source of errors, stack traces enumerating thru the actual React tree so you can see your error, dependency array validation for useEffect, and more that I can't recall at the moment - it's the top library for UI for a lot of reasons and I think your opinion sounds a few years old.
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.
> Usually in combination with some babel plugin messing things up
To be honest with you, you can't really blame React in this situation - it is nonetheless immensely frustrating to be sure.
> Redux is quickly going out of fashion
Yes, when I say it's "king" I only mean in terms of popularity within the community. I personally never understood the point of Redux and have always greatly preferred MobX for exactly what you say - it is far too verbose.
I also don't really have a good read on how the future of these projects will go - I would have thought MobX would've won out long ago. Maybe now with MobX 6 moving away from decorators it can gain the steam it deserves. I think the key blocker has been / is that MobX is building a runtime graph, and people don't understand graphs (let alone dependency graphs) very well, so it feels like magic. It's really easy to use though.
With features like Suspense, I feel like React will continue to push for more concise ways to write your components, but I also wonder if even the one level of misdirection that Suspense shows will be enough to limit its adoption. So far, explicit and non-magic seems to be a strange community preference
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.
I agree. This story could have been written any time in the last couple of decades, but replace React and .NET with any two wildly divergent software development ecosystems/paradigms/communities. I could tell you stories about an insurance company where I worked and how Java on Solaris (or was it z/OS?) and VB on Windows 95 fought to the death in a cage match. The were many programmer casualties.
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 disappear. This is coming from a guy who is creating his own programming language for his next game though, and who makes his own game engines
I watched it. It was dumb. A textbook example of some major fallacies:
The first is mistaking your level of desire for something to happen with the actual probability of it happening. It's clear he doesn't just think web programming is going to collapse, he wants it to happen. And it's distorted his estimation of its likelihood. I'm sure in 2030 he'll be making videos confidently predicting the collapse of web programming by 2040.
The second is where an expert in one domain considers its complexity to be inherent and unavoidable, while assuming other domains, of which they are ignorant, are inherently simple. Then when they try to engage with those domains, they run into significant complexity and experience the uncomfortable and unfamiliar sensation of being an amateur again. Since the unfamiliar domain is, by their estimation, simple, they conclude that the complexity they've encountered is unnecessary — a result of people working in that domain being too stupid or inventing busywork.
The third is the mistaken belief that our means will improve, but that our desires will remain the same. So, right now we have certain requirements, and in order to meet them requires us to do a lot of complicated, cutting edge stuff. But soon all that complexity will get figured out, the cowpaths will get paved etc., and we'll happily just pushing a single button to do everything we need. The reality is, of course, that our requirements will just get more complicated as well. Human civilisation has been on this treadmill since time immemorial.
> an expert in one domain considers its complexity to be inherent and unavoidable, while assuming other domains, of which they are ignorant, are inherently simple
Like the data science guy I worked with who complained we were making authentication and access control complicated.
While I like your argument about requirements getting more complex in the future, if we are speaking of fallacies, the much of what you said is an ad hominem and mind reading.
The argument basically comes down to whether web development is or isn’t slower than it should be, and whether it will become dramatically faster to do in the future
He sounds like someone that hasn't done any web dev at large scale. 90% of the web devs at my place of work just fulfill business needs day in and day out. Around 10% actually spend any time messing with the tooling. Sure, when you don't know what you're doing and you're working on a smaller project, you can get bogged down with the tooling aspect. But in every job I've worked with a healthy engineering culture, the tooling side of web dev is invisible to most of the devs to the point where they wouldn't know how to make a config change if they wanted. They just build shit.
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.
Not to be overly dismissive, but I'm not all that worried about the opinions of a guy who works in a totally different branch of the discipline and also releases one product per decade.
> it would be faster for most teams to create their tech stacks utterly from scratch
I actually agree, but maybe not for the same reasons he gives. The problem with modern tech stacks is that, yes, they're insanely complex, and each of the dozen or so individual components has dozens if not hundreds of its own hidden expectations about what should be where and what it should look like. As long as you meet all of those expectations, everything works magically like it should, but as soon as you miss one, you'll be lucky if you even get an error message that you can google the solution for.
There are two efficient ways to solve this: 1) no dependencies, build everything from first principles that you already understand. Then, although there will be plenty of assumptions baked into the code, you'll know what they are and how to deal with them because you put them there. 2) take advantage of pre-built solutions, but actually read and understand the docs before you rely on them.
The second solution depends on two rarely present preconditions: one, the docs actually exist. Two, management understands that it takes more than twenty minutes to realistically absorb 500 pages of dense technical documentation.
What we end up doing as a workaround is using the off-the-shelf stuff without really understanding what it's doing (or are you telling me that you understand the 9000 files that are installed by NPM? I'm not exaggerating, BTW, go take a peek). We cross our fingers and hope that we got all the assumptions right, cut-and-paste solutions from stackoverflow, and let the horrifically inefficient solution take the place of actual engineering because the "timelines are aggressive".
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.
Things got more complex because the problems got more complex. Creating a stack from scratch is something that a contractor would suggest to a company, so then they will have full bookings for fixing those. I was at couple of companies who were React/Angular/.NET shy and their CTO wanted to show off building ultimate framework that will make company millions. Every developer had to spend weeks figuring out how to use it and then they always f up something. One gone bankrupt another is rebuilding everything with React...
It's funny, react reminds me a lot of J2EE (and other enterprise frameworks) in many ways. A very large and complex framework, with lots of moving parts and additional stuff that needs to be glued in to make it all work.
There is a reaction against this happening right now. You can see it in hotwire from 37signals, Alpine.js and my own response to it: https://htmx.org
I recently tried advocating for using htmx for our frontend, but had a hard time even articulating what it is. Calling it a framework seemed disingenuous because, well, HTML+HTTP is the "framework," htmx is just an extension on top. At the end of it all, we went with InertiaJS with a component library -- not a bad alternative in its own right -- but I was hoping to do away with the frontend/backend distinction entirely. I hope I get to use your library in production someday, tho! Nice work!
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 and useful for iteration. And lazy-loaded routings? Yes please.
And with the Angular CLI and TypeScript typings and using VSCode it's an absolute joy to build sites with.
Oof. I work on an angular app and the build is slow as molasses because it's big. And we of course don't want to move away from the official build tool because build time improvements are always "right around the corner".
You might consider NX if build times are an issue. It is monorepo based and includes computation caching[2] and incremental builds, but under the hood uses the angular build tools. We've found it pleasant to work with.
All the React routers I know of support lazy-loading well.
I'd argue far better than Angular handles it. React components tree shake extremely well out of the box and I've rarely had to worry about bundle size when lazy-loading in React. Whereas Angular's dependency injection framework and its "modules", in addition to being irritating busy work as soon as you realize you can't trust the CLI's scaffolding, do nothing but get in the way of proper tree-shaking and good webpack chunks/bundles.
Angular is opinionated and comes with batteries included. Not counting the AnguarJS mess, Angular has been extremely stable.
With a small and dynamic team that loves functional programming and reactive state management, React is great. But in larger enterprise projects with many experienced Java/.NET devs, Angular just seems to be the better choice to me.
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.
How is magically hydrating a DSL extension of HTML any better than using JSX? Arguing about "non-native browser functionality" doesn't make any sense to me, your Angular app doesn't work until it's com-trans-piled into the same HTML/CSS/JS output that JSX produces...
Oh I agree. It's all insane. Ready for native web components and/or web assembly to become mature and get rid of this JS framework, 5 layers of transpilation, nonsense.
But to address your point, you're locked into JSX a lot more than someone writing in native browser code that doesn't need transpilation and can be ported between other frameworks at the end of the day.
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 library; additionally, JSX is pretty semantically clear with what HTML elements your functions are binding to and what events they're paired to, so in either case you have to rewrite code for your new DSL. Going between Vue and Angular isn't going to be simple.
"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 reliably counted on to be around a decade more.
It will be surprising if React is around in 5 more years and hasn't been replaced by something else.
Is EmberJS still around? How much longer will webpack be around?
Stability in the browser ecosystem starts with stability in the browser.
I think instead of investing all this energy into browser frameworks we need to be devoting energy into making the browser do what we want it to do natively.
And as web assembly matures that's where I think this is headed.
> "JSX is supported by quite a lot of frameworks, so you aren't locked into React"
> Just not the browser natively....
Angular's *directive and [weird] (binding) [(choices)] will never be supported by the browser natively either. The fact that Angular uses an HTML file extension is a delusion (they really should have picked a different extension, it's such an ugly lie) that the templates will ever be more portable than they currently are. Sure, you generally have better raw copy/paste behavior of real HTML into Angular's templates than JSX, but if you think the mess that is the average Angular template will ever be portable to "native browser functionality", I may have a bridge to sell you.
I think it is a worse anti-pattern than JSX: JSX at least uses its own file extensions and doesn't pretend to be HTML. Angular uses the HTML file extension and in my experience confuses a lot of people into thinking the "Angular Template Language" is "just HTML" when it very definitely is not.
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.
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.
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 taking over and making all of this pointless. Native Typescript. Yes please.
But to address your point, you're locked into JSX a lot more than someone writing in native browser code that doesn't need transpilation and can be ported between other frameworks at the end of the day.
> But to address your point, you're locked into JSX a lot more than someone writing in native browser code that doesn't need transpilation and can be ported between other frameworks at the end of the day
Not really, because at the end of the day you still have to write the HTML and CSS and everything to render anything in a browser, the JSX really just gives you a new way to compose it.
Now if you're using other styling frameworks that provide their own components, you might not have access to that HTML but that's not a JSX problem that's a "you are too reliant on outside dependency" problem.
Also, transforming code into a runnable form has been a part of programming since we first invented compiled languages. Your comments about transpilation seem really bizarre with that in mind.
Compiling has. Transpiling is much less common and seems to me to be an anti pattern or a sign that something's not correct in what you're building on top of.
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.
Full flexibility means full responsibility. If I write sh_t, it will be sh_t and no one can stop me.(well, you have the full power of a turning complete language). Unfortunately not every team can afford it without trashing their code base eventually. (And yea, I don't even have the confidence that I won't. And even I do, what about teammates?). I always thinks having too much flexibility here is sometimes cons instead of pros.
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}
<MyComponent {...props}>
{children()}
</MyComponent>
function children() { return foos.map(b => <div>{b}</div>) }
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.
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.
Well said. It was frustrating how little he talked about the actual problems with the codebase, instead choosing to handwave and blame it all on React. The dig on the React team in particular was bizarre:
> React’s team enjoy experimenting with new ideas, but this is killing the ecosystem! They should be brave and take the blame for it!
Have to make a lot of assumptions with this sort of thing, but I can't imagine that attitude results in high quality engineering work.
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 language too. Then try to pick up React.
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.
Is this actually advantageous though over class components? The creator of React said he thought moving to functional components would make it harder for people to learn.
I've found that sometimes hooks can make things less flexible, more verbose, more error prone, and harder to reason about. Sometimes a class might have made things easier to understand.
I loved the fact that `useEffect` could modularize code that was otherwise split between `componentDidMount/Unmount/Update`...but couldn't a new class API also have solved this.
Maybe I just need to read the docs again to remind me. I'm all in for hooks, but it's rare that I think about what life could have been like if we kept class components.
The trouble that React has to deal with is that JavaScript lacks good built-in support for pure functions and immutable data. Hooks are an opinionated way to make React work more like FP, and there are still gotchas because of JS’s lack of enforcement.
“Advantageous” does not necessarily mean “easier to learn.” I’d say that for people coming from OOP, FP style is certainly unfamiliar and takes more getting used to. But for a front-end program that must always receive/send data to hand wave some other systems in order to do anything useful, it makes things much, much simpler. A whole class of problems disappears. The closer it gets to (state) => UI the easier it is to reason about and debug.
I still think that Reagent, the Clojurescript wrapper for React, is the best version of React available. All of the state management is handled by CLJS itself, and the language design prevents accidental mutation. You can still mutate things where appropriate, but it is always an intentional choice. A framework like re-frame takes this even further, with similar ideas as Redux but with better language support for and enforcement of the paradigm.
> Is this actually advantageous though over class components? The creator of React said he thought moving to functional components would make it harder for people to learn.
At the end of the day you just end up thinking of the chunks of JSX and how they map to parts of the DOM, and who cares if those chunks of JSX are wrapped into a function or a class...
> .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.
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.
Is there a frontend framework you can choose that suits .NET devs? Maybe this would have been a better choice if there was. Maybe Angular was better. Or Ember.
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.
If you're porting between two languages/frameworks with radically different approaches, preserving the original project's approach in the new code is going to give you something that's probably worse than the original!
Now when you hire someone new you're going to be looking for React experience but then having to re-train them to think in .NET, or looking for .NET experience but training them to write React... and any time you have dependency upgrades, you're gonna be fighting more impedance mismatches.
Most tech debt that slows down feature development has more to do with the code structure than with the language or framework, so if you're intent on preserving the structure and style I don't know that you should be doing a rewrite at all!
Well said. I went through the whole article and it just seems to me that instead of asking .NET devs to build a react app, you could have just hired react devs and none of the problems would've existed. Or have the entire team go through a proper react bootcamp. As a dev, I can say for sure, devs not learning new things and keeping up to date are the worst. The ones you need are the ones who try new things and then create solutions that are best fit for the problem with a rational mindset. Pretty much everything else will slow your development eventually, be it react or something else.
Bootcamps are just ways to extract money from the pockets of Enterprises with more money than sense. I worked on a project with some COBOL programmers who went to through a "Java in 21 Days" program. They were decent COBOL programmers, I actually learned some useful things about that language and the IBM environment. But Java programmers they were NOT. https://thedailywtf.com/articles/The_Brillant_Paula_Bean
It actually depends. Sure there's plenty of ones that are complete garbage, but well structured ones work well, especially in two situations: 1. For people who have 0 coding experience to get introduced to how to start coding and where to look to learn more 2. Experienced devs who need a good overview of a new technology that they can further explore more on their own. It's not a bandaid, do a bootcamp and you'll be gods kind of a solution.
Yeah, but Enterprises with more money than sense aren't going to pick the good bootcamps, they're going to go with whatever gets the highest rating in Gartner's Magic Quadrant, or whatever one is run by the guy who golfs with the CEO.
Maybe the team is a bunch of n00bs, so what? Wouldn't the perfect framework/language make it hard[er] to screw things up regardless of the lack of dev skill? For a big multi-year project it often strikes me that the best tools are those which are old, boring, and unlikely to change.
That being said, huge-multi-year development in _any_ js framework seems terrifying to me because of the churn in the general js/browser environment.
Also: I think the author doesn't cover this a lot, but it sounds like they REALLY saved their bacon by doing the boring due-diligence of carefully documenting the decision process behind all the choices they made. They probably would have had slowdowns and surprises and roadblocks no matter what, but someone's still got a job because they took time to get it in writing.
Does JS really churn more than other environments? I first saw React in production at work in 2015. That’s almost six years ago. Before React, sure, there was a lot of churn, but there has been a huge time period in which no one got fired for choosing React plus Webpack.
At that same job, our app team was switching to Swift for its new code, which no doubt has had considerable churn since then, since it was before ABI stability or SwiftUI or whatever (I’m not a Swift dev so just guessing from the outside on the specifics).
You're just making the author's point for them. A more opinionated framework that matched the team that was supposed to code with it would have worked better for them over the lifecycle of the project.
Most enterprise teams are poorly skilled with bad leadership. Modern frameworks and coding paradigms are a bad fit.
> A more opinionated framework that matched the team that was supposed to code with it would have worked better for them over the lifecycle of the project.
No it wouldn't, not for an enterprise application that is supposed to last a decade or more. Instead you want to use standards such as Web Components that will last essentially forever.
Now that's just silly. Longevity of the enterprise application is of no concern at all. The only things that matter is on-time and on-budget. If you can't deliver that, then you run into the problem the author of the article ran into, his bosses yelling at him and his career and job in jeopardy.
If the project develops issues after all the initial stakeholders have moved on, it's the new stakeholders' problem.
Not everything is a problem. If you design a language and only one human in the world it able to learn it. Then this is not a people problem but a language problem ! You can't control the skill of the team, this can't be the problem this is a fact.
At some point one has to see the trend of all these people hanging themselves with this one platform and maybe there's something to the platform, ecosystem, or community that is lending itself to the hangings.
> And I am not even considering the time that each developer spends on learning all those third-party libraries. I never saw two React projects with the same dependencies, project structure, and guidelines. This means the knowledge is not transferable from project to project, as can be the case in Angular or Vue.
For a developer just looking to make the thing their design team sent them as quickly as possible, this makes good sense to me. And I get that project/file structures can be wildly jarring to an uninitiated dev - I remember looking through a Java repo for the first time :shudders:
But! Isn’t there a necessary step of understanding why decisions were made the way they were? In my experience as a front-end eng, even if a previous project involves other-worldly dependencies or FS compared to the one I’m on now, if I understand the trade-offs of the approaches for the previous project, no amount of knowledge is untransferable.
> 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 isomorphic apps via Blazor. If immediate onboarding of .NET devs was a key requirement, .NET was the obvious answer.
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”.
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.
The best choice is always what the team has the most confidence with their skill set on delivering. Your framing is unhelpful. You can build amazing things with both React and .Net patterns. If you're on a deadline, you should probably stick with what you know. Every language and framework has different tradeoffs.
I was reacting, emotionally, to the blaming of the old guard.
I do think that Java Script frameworks would be great if they were stable. And for enterprise software - for any sensible definition - stability is a very important criterion.
But it is easier to write than it is to read so they keep reinventing the wheel, keep making new, not better, things.
I think the benefit of the new javascript frameworks, in particularly React + Typescript, enables complicated webapps. Facebook is probably the best example of enterprise scale.
The problem with the javascript ecosystem (other than javascript itself) is that browsers constantly change and webapps are expected to be increasingly sophisticated. The stacks can't really settle down until our expectations of what they should do stabilizes. I feel that's why we seen much less churn on the backend.
I mean, this feels like a classic example of not choosing the best technology for the situation. Picking a more opinionated (or more batteries included) framework likely would have streamlined a lot of the problems he described. That doesn't reflect badly on React - certainly there are teams that could have used it to implement a project of this size - but it reflects badly on the author.
> I will not encourage using it for enterprise applications.
Almost like large-scale projects have different requirements and the tools generally used on large scale projects (like .Net) have adapted to reflect those requirements.
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 millions of transactions a day. Just because an app is big doesn't make it an "enterprise" app.
architect was hired from outside to create a proposal for a team that had no one capable of operating in that role (and apparently the CTO as well)
"He already has a development partner in India, but they lack experience in building web applications." - this is a massive red flag
architect was sent away to do proposals without anyone talking to the development team to get any buy-in
architect got the background of the dev team from the CTO but neither architect or CTO talked to the development team (who would be implementing) prior to doing a proposal
"the technical lead ambushes me" - this is the first time the tech lead and the "architect" interacted. There's no "ambush" here; it's a failing on the CTO+architect's part to communicate to the team in advance, and perhaps at least involve the team lead
CTO is against angular but his outsourced team is familiar with .NET and Java; why is there even a need for an "outside architect" to make this choice when it's only between React and Angular?
"the CTO is backing his team, which is normal. He had known me for just two months, while he had been working with his team for many years." - Why is no one on the CTO's team, after many years, capable of investigating and making these decisions? Why did they need to go outside? If the plan was to continue using this outsourced team, why didn't anyone invest in their training to be self-sufficient vs a direction from on high? Why was there zero training plan?
"And that’s how we end up with three ways of doing things. There is no consistency anymore." Where is the CTO during all of this?
Adding to my comment: no mention of any sort of design system for a component based library (kind of key in either Angular or React or any other component-based UI framework), no mention of the CTO or the architect or the dev team establishing consistent standards and being responsible about their use...anyway, not every problem is "technical" in nature. Sounds like this project (and company) had a lot of issues going well beyond the tech.
what I find, with virtually every "new technology" that's come out in the past 20 years is that the "way of doing things" is not only completely undocumented, but also not agreed on by any two people. I can't remember the last time I found technical documentation that even bothered to describe what problem the technology was actually designed to solve in the first place - or was even written by somebody who seemed to understand why that would be important.
This had nothing to do with react, and everything to do with you rolling over and accepting what other people wanted to do differently irrespective of your project guidelines.
You can't expect an application to remain easy to develop when people do not adhere to your development protocols.
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, saga, etc.) which introduce their own quirks, and require their own tools. Soon, you're up to your eyeballs in boilerplate.
As for the (build-time) performance concerns, I think there's some work here. They have a _big app_. And if you're compiling a 220 page app in a single build, it's going to get slow. You'd have the same problem, though, with a native mobile app or a very large C++ app: at some point, you need folks focusing on the infrastructure bits part time. With a relatively small number of changes, they can probably make some big wins: adding build caching for local development, using an NPM proxy (to avoid downloading 600MB of deps over the public internet on every build), looking at alternative hot reload plugins, etc.
That's not to say React is without problems, but I think it's worth considering that _almost any_ technology of the scale of React is going to have drawbacks, especially if you don't have someone in-house who has really significant experience making it work well. Companies like Airbnb, Facebook, Uber, etc. all have whole teams ("JS Infra") dedicated to this stuff, in the same way there are teams like Ruby Infra, etc.
For most products, you didn't need anything besides React in the first place. It's really only useful when you have a single blob of state which is displayed/sliced/etc. in different ways across a large number of views. But for the most part, many apps are largely read-only (you can use `Context`s to push data down your render tree), where mutations happen close to where the data is loaded, meaning the benefits of redux are lost.
The big pain point of Redux (IMO) is that you do you data fetching separately from managing the data in your data store. It means that you need to add this glue layer between the data that comes back from your API and the redux store—you need to re-model everything. Every time you get new data, you need to go out of your way to remember to update everything that could be affected by that data.
GraphQL (I'm fond of Apollo) gets this more right. You can still use REST APIs with GQL (usually not by default, but it's possible). What this means is that you model your data in the way that the API expresses it. Your back-end folks aren't going to be lost when they read your code, because it matches the shape of the data they're already familiar with. The client-side cache means you don't need to manually fiddle with your store to invalidate stale data (I've yet to need to manually reach into the cache to perform updates).
That's not to say GQL is without its own issues. It is yet-another-thing, but it's one example of a solution which doesn't get quite as hairy when you've got 200+ pages in your app.
It all depends on the scope of the project, but if you use Redux as a way to keep a cache of backend data so you don't need to request everything every again in every component or pass everything down in props, then you could consider a system like graphql. One project I'm working on part time is switching from class based components + Redux to functional components + graphql and I must say I'm enjoying graphql a lot more than I was writing actions, sagas and reducers.
I don't have any recommendations for pure client side applications though, but for those you can probably get away with using contexts and hooks for quite a lot of the state management.
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).
Not the OP, but I'd suggest using what's built into React, i.e. keeping shared state in a parent component, until you hit one of the reasons the Redux docs enumerate for using it: https://redux.js.org/faq/general#when-should-i-use-redux
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".
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.
I the 1990s, when I started out as a working computer programmer it used to be said that 90% of software projects failed.
I have no idea what the figure is now, and now I have more experience, seen abject failure defined as tremendous success I would not be surprised if it si worse in fact and better in annual reports.
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 project is big, doesn't mean your new one has to be... split it up!
4. Redux... the root "technical problem"
My hot take is that the authors technical issues probably come from Redux and not React.
Using redux as the core of your application is like pouring glue on a lego set. In an ideal world this is great because everything is strong and well defined. In reality, it prevents flexibility and applies hard constraints to the entire system.
That one choice of using redux effects the decisions you make in every component. You lose flexibility to encapsulate features and experiments. You're forced to bend over backwards to do things in specific ways.
Redux is the JS equivalent of the Windows Registry.
> Redux is the JS equivalent of the Windows Registry.
Love it.
I find Dan Abramov a great guy, but it was he who brought us Redux and rose to such fame because of it, and its now considered a bad way of doing things (or maybe just a ridiculously verbose api) and caused a huge amount of pain for a lot of people (I am not blaming him tho!)
Now we have hooks as a collaborative effort involving the same guy, but they feel hacky in a way, and almost like they will not last either.
It really feels like this reinvention for the sake of reinvention. I can easily imagine the API I would like for managing my data layer, but its seems like we are trying to shoe-horn something into the React way when maybe it isn't the right fit and we need something else.
I don't think 1) is any issue. I worked on desktop apps as well as web apps, and overall I think it's mostly the same. You have some widgets, state, actions, etc - and need to connect all things together.
However I could totally imagine that a team which is familiar with advanced patterns for "connecting everything together" are unhappy with the bare minimum Redux approach. MVVM can be pleasant to work with, and isn't necessarily as much of a ceremony and chore as the redux stuff.
Angular 2 (or whatever version number it is now on) might indeed have made them happier.
well, I'm on the opposite side: I failed two code interviews (before the job I have now) because I did not used React. One comment I will never forget from the feedback I got back from one of the reviewers: JavaScript vanilla is HARD to read. Another one was that I used a "global" css file, instead of having CSS in the same file as the "component".
I’ve built successful large enterprise apps in React, and would recommend it.
Here’s how we avoided some of his pitfalls:
* Small team of talented developers who didn’t always agree on libraries and methodology, but worked through disagreements to reach a consensus
* Recognizing that libraries would change over a two year project, and being ready for major library migration and refactoring
* Writing our own state management tools when needed. Redux is a tiny library. On a two year project, why not create your own custom state management system from scratch, one which makes the .NET people comfortable and has the features that match your project’s needs? It boggles my mind that many devs consider state management libraries to be something sacred, like a compiler, which you would never consider reimplementing yourself on an enterprise project.
> why not create your own custom state management system from scratch
Normally "roll-your-own" is bad advice. But in enterprise apps I can see all you needing is an API client with normalized caching (Apollo or `react-query` for REST), and store as much of your page state in your query string, and the rest in React Context. I would reach for Recoil if React Context performance became an issue.
But rolling your own comes with so much personal risk if things go wrong - not good for politics.
> So I am not afraid of getting into a debate about why those are unusual patterns for React.
I have seen some developers follow patterns just because they are patterns. Once the community starts doing things one way that's it, even if it is a dumb way, the herd mentality causes the dumb way to become established. Redux is one of those dumb ways.
> Because 30% of the business logic was inside Redux-Saga, I marked it as a high risk.
Business logic should be written in POJO. Plain Old JavaScript Objects. Using a library such as Redux is a dumb way, but this is the community-embraced, herd-mentality way.
> I will not encourage using it for enterprise applications.
Use Web Components. Using the flavor-of-the-month JavaScript libs for a large application that must live years or decades is not justifiable.
> Business logic should be written in POJO. Plain Old JavaScript Objects. Using a library such as Redux is a dumb way, but this is the community-embraced, herd-mentality way.
Redux is really just a pattern for business logic using POJO - you have a function that takes an update and returns the new state. The library itself is about a hundred lines.
> Use Web Components. Using the flavor-of-the-month JavaScript libs for a large application that must live years or decades is not justifiable.
How is web components not just another flavor-of-the-month JavaScript library, and an unpopular one at that? Sure, it's part of the browser instead of something you load externally, but I'm not sure that changes things in any meaningful way. You're still tightly binding your code to something which may or may not remain popular.
I'm not really a React fan, but you could have encountered all of these problems regardless of what you'd chosen to use. Sounds like the writer had good intentions and worked hard to do the right things, but that there were fundamental misalignments beyond the technology. Could they have planned ahead for those conflicts? Maybe. But, as noted in one of the paragraphs, enterprise type projects have a way of taking on a life of their own even when all parties have the best of intensions - and in many projects, not all parties actually have the best intensions. Heck, I've seen projects get started and deliberately set up to fail as a counterbalance to some other project. Live and learn.
> “Why are file names dash-case when class names are PascalCase? It should reflect the class name, so from now on, we will name them SomePageComponent.tsx.”
That's actually a common practice. Files (modules, that is) are usually named after their principal export.
I'm surprised that you didn't pin and vendor your dependencies at the start of the project and declare that any additional dependencies must be compatible with them.
Enterprise applications are behemoths that without question will take longer to develop than the current webdev lifecycle and the most important thing for developers writing business logic is structure. Coding against a moving target is a recipe for failure.
The comments about node dependencies exploding and build times creeping up over time was painfully familiar. I now work at a large company that addresses this with strong library discipline and huge investment in build infrastructure, but when I worked on teams at small- and medium-sized companies we were always plagued by these kind of problems.
> Indeed, React is mostly backward-compatible, but the ecosystem around React is not. Developers and third-party libraries will always use the latest features and architecture patterns, while old experiments will be left behind to die. This should not be a problem for small and medium-sized projects because you can adapt much more easily. But for big multi-year projects, these experiments can be a deal-breaker.
I really wanted to use React for my current project and it would have sped up development. But I was afraid of this attitude of breaking things that pervades the ecosystem. I'm using HTML + Alpine.js. It's more work, but no breaking changes in libraries so far. I'm still not sure I made the right call. Only time will tell.
In my opinion you need to have a dedicated Tools engineer in teams above 10 people. Most developers are poorly prepared to debug build/perf issues. A lot of author issues could be reduced by using right tooling.
- eslint for style
- Webpack Externals/Module federation for build times
- Dependabot/renovate for automatic dependacies
- codemon for automated refactors
- WSL2 or vagrant VM + docker-compose for local dev
You need someone that like tinkering with this stuff instead of doing Jira points game. Give that person autonomy and your team would move faster.
Why not split the frontend and the backend apps into separate applications? That would help with the future proofing since if you wanted to switch to another javascript framework, you could do that.
It’s sad that Angular still has a bad reputation from AngularJS. Basically all the pain points the author mentions (deciding on router, DI, http client, working in multiple teams, reliable hot-reload, deciding between class or functional components, whether or not to use hooks) are all things in which angular shines. They could have saved a ton of money here by choosing Angular over react. In fact in comparison over the last 5 years, angular has been much more consistent whereas react has become a scattered mess.
That was a very interesting read and described a lot of interesting, very valid, and very realistic challenges that I could see myself running into in a similar situation. However I don't agree with the conclusion that React shouldn't be recommended for enterprise... instead I found myself thinking, gee, there just happen to be other mindsets, skillsets, management styles, and general ways of doing things, and they collided poorly here. Enjoyed reading this but a bit offput by the FUDdy punchline.
> Angular would have been a better choice in this case because of similar design patterns.
Well sure maybe superficially. There’s classes and then… that’s it. I don’t really see any other part of Angular that would help a (somewhat) experienced (pure) .NET developer in any way. There’s no batteries-included state management either.
Technology switches are hard. I don’t think the problem is with .NET specifically but with developers that stopped longing. Longing for new technologies, new algorithms, …
Angular has built in dependency injection, recommends to use services to encapsulate state. Built-in services use RxJs for propagating changes by default, and following that pattern gets you very far. Especially for an enterprise app.
I think RxJs evolved from "Reactive Extensions for .NET" which was quite popular even 10 years ago. So the core idea is probably well understood by many .NET devs.
RxJS is not a replacement for redux, in fact ngrx is a redux implementation based on RxJS and Angular. It brings everything, including effects with their own plugins and it is quite a pleasure to work with.
I'm aware, I'm saying that using (a few singleton) services for managing state plus RxJS to effectively propagate (state) changes into every other component/service provides a comfortable development workflow/mindset. (I find redux-like patterns unnecessarily complex.)
Yes that I completely true. However, not sure of you know @ngrx/entity but it solves 80% of all business logic I need in a clean way. An most of the time creating services I end up building exactly what the framework gives me
Unsatisfying read. It wasn't React's fault. PM was looking for blood. Dumping a bunch of devs who have little experience with the tech onto the project. Little notion of process and conventions for the app. Only reason I'm commenting is that the three questions posed by the CTO are entirely valid questions and I wished they'd been answered.
Some of the performance problems on Windows are related to always-on antivirus. Exclude your project directories from antivirus scan and you'll see the difference. JetBrains IDEs now even have an auto-suggestion and an option to do it directly from the IDE.
Is there a Rails for React? I use React+Redux+Typescript and it's nice but I always have trouble setting up a new project.
Rails is magic in that it's all ready. React+Redux+Typescript is great. I just don't want to make decisions here. I want to just make a web app. Like how Rails defaults to ActiveRecord and friends, is there something like that for Rails+React+Redux+Typescript?
I'm looking for:
* Few decisions for me to make
* It's relatively popular enough that there is a community around the whole thing
It's a huge productivity enhancer with Rails to be able to google "Rails do x" and someone has an answer to that. If I had to google "Ruby with X library and Y other library" I think I might commit suicide because the Rust experience is like that: "Use actix-web". Ah, and how do I use that with this other tokio based library. Oh you can't, because you need to make sure the runtimes are compatible.
Take a look at Next.js, which incorporates a general-purpose router, does all the Webpack stuff for you, has generally painless server side rendering support (but you can also build a purely client-side bundle), and has direct support for a long list of popular libraries.
It doesn't handle global state, but has tested examples for Redux[1] and various other libs that incorporate the server-side rendering and static site generation functionality that Next.js has.
Yep, next is great. It leaves you only with the following decisions to take:
How to do css, css-in-js etc
How to build the api, rest graphql or what
How to access your database
How to do background jobs
How to send emails
How to organize the project structure
How to do validations
How to do translations
How to do migrations
Then just use rails. Why are you looking for the same thing in a different language? Just for the language? Or because it is more fashionable than using ruby?
I find that writing React apps is easier for me than writing HAML apps. I have a system now where I can get both but I was wondering if that system is encoded as a framework. I tried the next.js suggestion from the other guy and it’s far short of rails so I think I’ll stick to my thing for now.
Would love see people go back to posting in their own blogs instead of Medium. I get paywalled or app walled. Where I have to either log in or use the native mobile app to read the article. Medium is not a good place to share information.
1200 dependencies?! Is this normal in web development? That sounds like a nightmare waiting to happen! I'm working with a rather large C++ project now, and it only has 40 dependencies, which I already consider pretty large.
I don't agree that React is not enterprise ready. The mistake OP made was reaching for Redux for some weird reason. Redux-saga, _thunks_? I guarantee this project used thunks of some kind because some blogger posted about it and it was popular and trendy.
Pick boring tech that's objectively simple and not an exercise in genius. mobx, today: apollo-client (if you have a graphql api).
I've never seen any other project stain a framework as much as Redux has done.
Also, he had a ton of organizational issues that have nothing to do with the tech.
> I've never seen any other project stain a framework as much as Redux has done.
Is there a good article that would summarize the backlash against Redux?
While I don't do front-end much anymore, Redux was such a productive tool for me when I was a contractor. I found it incredibly powerful and easy to work with, if cerebral for the uninitiated.
Meanwhile, I had the exact opposite experience with apollo-client and the apollo framework—very easy to get up and running, but a giant pita for doing anything complex.
Honestly, after using mobx, it's almost impossible to understand why Redux is popular. MobX is more concise, more performant, has a crazy amount of built-in optimizations, and lets you forget about tracing your crazy graph of relationships just to update some view.
Of course, mobx had "bad" (read: used decorators) syntax for a while, and only with MobX 6 did they clean it up, but boy oh boy is it clean now
Agree! Redux is never needed and was always a bad choice IMHO.
The goals of it seem so misaligned with developer productivity.
It was small, elegant library for the sake of being small. Ultimate flexibility that can do everything, but then required building heaps of stuff on top of it, and favoring this immutable one-way flow that just complicated things riding on the coat tails of flux.
> I've never seen any other project stain a framework as much as Redux has done.
The problem was not React it was .Net developers. Angular is worse in this regard because the .Net developers feel more confident and charge ahead writing terrible code that is only == to shite rather than === to good. Learn the fucking language first you ahhgsvsvsgsjdhwbdksbdvrievevdjajavsgwgdvshsvevejahahagagagagahgagagagagagagagjgjghgahhagagagahahhahaha
The problem is how broken all of it is trying to work around browsers native warts. As future versions of native JS becomes better and web assembly takes over, things will probably improve massively.
The article pictures conflicts from different programming cultures. There isn't any attempt of acculturation mentioned in the article. Acculturation is important to keep everyone in the same page on what's the added value of React. You don't need people from .NET to get culture conflict, frontend dev that haven't got any previous experience with React and the likes, those who operates with jquery and left frontend world, for example, will also introduce culture conflict.
In the near beginning, "Where is the dependency injection? What do you mean by ‘There is no need for one?'".
The React developers seem to also not aware what's the significance of dependency injection, therefore the culture acknowledgement goes both way. While the term came from heavy-OOP environment, dependency injection can take a different form.
In React's world, it can utilize context or types from common module. Dependency injection is crucial in flattening deep components surfaces, which in turn makes them testable. And it's not exclusively for the React part. Testable code (with actual tests at STRATEGIC PLACES) makes it easy to increment on, because validating if the added code takes less effort. (Although automated tests at NON STRATEGIC places can make it worse).
“Why is the development slowing down?”.
I can imagine the author's frustration when "They want to use the .NET guidelines and design patterns in React". I've been in and out some cultures, React, NodeJS, Java, C#, C++, Golang, Android, Game development, Game Engine, Ecommerce, Identity management, Crypto, LL/system programming, infra. I can say that without running around and having enough persistence to break and remake cultures while avoiding ineffective compromises, things will not work.
CTO losing his temper and blaming for what's decided 2 years prior seems like either things have gotten a bit out of control or the environment is a bit toxic. That is if the story is told accurately. Maybe CTO has been constantly reminding the author along the way but only the climax is told because it is peak emotional. Either way, observability and control over the project is lacking. Also the added values of React and other dependencies being included in the project as the main UI library is not communicated well.
There are a lot of "should we use [x] lib" going on. The easiest principle is if a module changes a lot, don't depend on any lib that locks it in.
"Redux-Forms, Formiq, or Final-Form?" This smells, just because without delving deep into the library, Redux-forms seems to tightly couple redux state with, well, forms, which is, in React environment, usually closer to the UI side rather than the core logic side, and you want UI and logic layers to be able to change a lot relative to each other even if they don't.
On Redux:
Redux itself was a weird long-running phenomenon. Its placement relative to other components is a big misunderstanding. It's supposed to be a state container that can be either local or global, but the default `connect` API stamps it as a god object permanently in the eyes of the ecosystem. Not to mention countless of medium articles that encourage the pattern.
Its "middlewares" such as thunk makes stories hard to write as a single top-to-bottom functions. In one project we identified the risk of misunderstanding as a problem early in the project, therefore redux is removed. We didn't even got to touch redux-saga. We had to find a replacement, which is unstated and custom typed event emitter.
This buys us code explicitness, loose-coupling, less processes on increments, more accurate types (redux doesn't play nice with typescript's type system), but we had to pay with writing a lot of types (we are using typescript). It teaches us the concept of message passing ala kafka/rabbitMQ, as well as the importance of immutability, which is the core of redux, without redux API bureaucracy.
On React hooks:
React hooks was a departure to a more (a bit forced) functional programming. Some concept introduced is good as it encourage us to write in automata-based programming style.
But it has bad API design too. For example `use*` can't be written inside `if`. So are custom hooks. We have to be very careful to not place any hooks inside `if`. Writing with hooks needs either: 1.) experienced hooks developers, 2.) linter. You can install/write the latter as long as you become the former, which is a paradox. Had it introduced hooks as below things would be a bit better.
```
const SomeComponent = makeComponent(
({ context, props }) => {
// context supplies useState and useEffect like APIs
return (
<ChildComp />
)
},
{ [stateName]: defaultValue } // the default state
)
```
The worse part of hooks introduction is that React's culture diverge, and so its users. A company can have people with and against hooks.
About the title, it should be "Using React the wrong way created roadblocks in our enterprise app".
I feel your pain. It was really too early for React until 2 years or so ago. Since hooks, things have calmed down a bit. I would be interested to hear from people who successfully navigated that past 5 years in JS world. I feel I would have been happier just being forced to use Ember or something until hooks came out. A ridiculous amount of time was spent on tooling, perf optimizations, and huge amounts of code is just going to go into the bin one day.
I have this feeling that 2010+ has been this massive story arc and one day we will end up very close to where we started, back to something similar to jquery and vanilla JS because the platform improved. Just like how a React platform feature like context hooks deprecated Redux.
For frontend, if Typescript is standardized and shipped with browsers...see ya later beefy compiler toolchains.
For backend, Deno.
That Typescript with its current popularity is not shipped in browsers within 10 years seems super unlikely.
The funny thing with TS is that to get good typing, you start to write everything similar to Java/.NET with dependency injection etc. I resisted it for such a long time, but when you realize you want things typed, classes and all those patterns become necessary - see Nest.js/TypeORM for an example. It just makes everything cleaner and is easier to standardize patterns.
The post seems to have a bit of a "holier than thou" when dealing with naive .NET developers. I think that .NET devs living outside of our JS bubble probably have a lot of interesting criticism to offer. The retort that pops in your mind is "you just don't understand...this is how its done", but if they critiqued any number of the features that have been deprecated in React - they would have been right and us wrong. And even the creator of React said that moving away from classes made it to difficult and would have preferred not to have done it. My point is that JS is a bubble and we shouldn't be so sure of ourselves.
Also the fact that Apollo is the top API library at the moment, and doing optimistic updates and working with the cache is insanely complicated when ultimately you just want something like ActiveRecord on the client like how we use to do it with Backbone models. Redux and friends is also extremely verbose and complicated for no gain. I miss the simple mental model of Backbone - yeh there were problems, but at the end of the day I just want to write `User.getPosts()` and `User.setPost()` and be done with it. 90% of the time I don't actually need GraphQL selective querying and such, its just got such a big momentum and community behind it that I use it. And REST with `react-query` and `swr` is still extremely complicated. Sorry for the rant.
So I wonder if anyone has taken the time to predict when all the tools we use today will eventually be deprecated.
I don't understand this sentiment at all... even approximately. I've been doing this for about 15 years now. I started in the days of "This website works best in IE5" (read, only works in ie5). I wrote Macromedia Flash Apps to make animations, because that was the only option. It was awesome! I spent hours or even days making rounded corners via chopping up images and table hacks, because rounded corners seemed really important. Just laying stuff out correctly on the page and stupid browser hacks was most of the job.
I personally went from spending probably 60% of my time fixing cross compatibility bugs to spending a few hours a year on it. We went from manual coding for cross browser support, to polyfills, to telling webpack to dynamically include polyfills to target the subset of browsers I care about with 2 lines of configuration. I can now determine the exact tradeoff between file size and audience reach. Yes, that came with some complexity. Yes, that tradeoff is 100% worth it. No, you do not have to use it.
This is how I feel about React. I've unintentionally built my own, shitty version of React at least half a dozen times over the last decade. The last time, maybe 4 or 5 years ago now, was an online file system browser which could contain tens or possibly hundreds of thousands of folders/files. The naive implementation wouldn't load. A less naive implementation took a few weeks to implement and seconds to load. The React rewrite took a day or two to write and loaded in milliseconds. It was less code, easier to understand, and a couple of orders of magnitude more performant!
Other languages don't have crazy build systems because they don't have to run the same code on multiple platforms made by multiple competing vendors on multiple operating systems for hardware ranging from a M1 to a refrigerator. If that's not you, not a problem, you can just write vanilla JS. If you don't have thousands of objects that you dynamically load that need to be turned into DOM Nodes, don't reach for React... If you just want a library that renders some DOM Nodes, thats fine too, use React and nothing else - you can even write react.createElement by hand and eschew JSX if so desired!
I would not choose to go back to the halcyon days of web dev where we didn't have dependencies and dependency management because we couldn't. At this point in my career, changing web tech has lead to a productivity increase of probably 10000%. There are some pain points, but we're working on it! Web tech, fuck yeah!
Just reading the initial scope of the requirements. This project was guaranteed to fail, no matter what tech stack was utilized.
There's no future proofing in Software Development. As soon as an application is deployed to prod, it's obsolete. It must be on constant maintenance/upgrade schedule. And, the replacement project must be scoped out quickly.
Also, the design system matters a lot. Have a small team working on the UI components to tailor and extend the design system. Dont allow the rest of the teams to extend the ui components with new libraries. Stick with the design system as much as you can. The rest of the teams should minimize the amount of CSS they have to write to components placement.
Usually the datagrid is the soul of any enterprise application. Choose it wisely and be sure it covers as much functionality as you can and also that it is customizable on an "easy" way. There is always a team with the need of a datagrid that sorts, groups, filters the data with dynamically adjustable cells and multi header items without pagination. Welcome to hell.
Use one pattern: hooks, central store, whatever you want. If at some point you have to change it you have to know which teams are using which one. Dont allow team members of the same team follow different patterns. Code reviews must take care of this.
Hope this small tips help one or two teams out there. I have worked on the migration of 5 big enterprise applications from angularjs to react or from legacy desktop application to react or from server pages to react.
I made a lot of mistakes that costed a lot of dollars. I have tried to learn from them. Also, dont take me very seriously, I am pretty sure I am about to discover another mistake I have made.