On a purely technical level, this is really cool. But I can't help but wonder: if this level of complexity is the answer, maybe we're asking the wrong question.
back
6 comments
I am huge React fan, but when I see how complicated are some of the modern React codebases in some "leading" companies I have a strong feeling that we will soon need to go back to drawing board and hit some kind of reset button. As I said, I love React ecosystem, but there is something fundamentally wrong with most front-end developers today. They build bigger and bigger SPAs because they are confident that React ecosystem makes it maintainable, well good luck maintaing React/Redux/Graphql/hooks/bazillion-libs after 5 years. Abstraction is good, but it has its limits.
Sometimes frontend developers overengineer their solutions, yes.
Sometimes you need a more complicated solution for a complicated set of requirements.
Do you need GraphQL? Nope!
Do you need GraphQL for an application that needs to fetch a lot of highly relational data with nested objects? No, but it sure would be more optimal to just ask for what you need in one request in the shape you expect, instead of either:
a) Multiple REST API calls that you need to combine and coordinate in the frontend
b) A specialized REST API call that gives you all the data you need in the shape you want, but it isn't very RESTful
c) A REST API call with a bunch of `with[]` params (a la Laravel) that indicate what nested objects you'd like, but not their exact shape
So, which is more maintainable then?
—
The other wild misconception I see time and time again is this:
Of the five things you mentioned "React/Redux/Graphql/hooks/bazillion-libs", only the first one is React, and the second-to-last (Hooks) of which it is optional.
The rest are dependencies you opt for, hopefully after weighing pros and cons. You don't need to use Redux, GraphQL, react-table, whatever other dependency in your React web application.
Please separate out React from React-based codebases from code architecture. They're not one in the same.
I just don't buy this idea that there is some kind of separation between React library and React as a platform. I'm building SPAs since 2008, been to too many front-end meetups, have friends in so many different companies its hard to count. NOBODY is using React as a library. Banks, shops, news sites, you name it, everyone is using React+Redux+Typescript+bazilion-libs. Graphql is not a standard yet but it is already very popular, basically every new hired Dev adds new libs or switches to something else. It's a mess.
The thing is, I don't disagree that a large (if not majority) number of developers reach for dependencies by default, instead of carefully considering patterns first.
I don't think bundling React the view library, Redux the state management library, Typescript the Javascript superset, GraphQL the API query language, Webpack the bundler as one "React the platform" is helpful.
I'd like to see the developers that automatically merge all of these technologies together by default because everyone else does it (or worse, because X Big Tech Co does it) to start questioning and exploring other options. I'm not sure how to get there, and maybe my comment above is my contribution towards convincing readers to reconsider their understanding of the React ecosystem.
You're right though, it is a mess. I think the mess comes from people and how they code, not so much this specific library nor the language.
These new frameworks and things like "create-react-app" have made it easier and easier for junior developers to make immensely complicated apps with immensely complicated tool chains. I think that has a lot to do with how things have gotten to the point described in your comment and many of the others. As you start reading tutorials about Vue or React they tend to quickly stray into other dependencies, and webpack or whatever. The web has gotten more complex. The only way to navigate it wisely is to become wise through experience. There are no shortcuts but we've definitely made it easier for new developers to stumble into a mess.
Most of the time, the complexity comes from the app and its requirements rather than having anything to do with React. Could another framework do a better job of handling and helping you manage that complexity? Maybe, depending on the specific use cases. But my guess is the majority of those apps would be complex regardless of framework.
Clients are never as simple as people seem to think. Look at how complex the iOS/Android stacks are, and they aren't even crossplatform like web is.
Correct me if I'm wrong but I think the reason for all the ceremony you're seeing is that React is trying to implement algebraic effects in JavaScript, which doesn't support them and neither do most other languages.
In an ideal world, the HTML rendering infrastructure would have been built atop a lower level representation that was also accessible to JavaScript and allowed for the construction of one's own rendering loop and pixel by pixel manipulation. This doesn't exist, but you can kind of imagine what it would look like if you imagine a world were the HTML rendering architecture was just a library that ran atop webGL.
But that isn't the world that is exposed to web developers, so a lot of complexity is necessary to take a declarative rendering language and trick it into giving developers the kind of control they need to address issues like the naive solution for altering the declarative tree and triggering a repaint not necessarily cohering with what users consider "good looking."
Are there any similar UI libraries that are actually less complex? I’m pretty sure the DOM engines in browsers, which people might think of as “simple,” are incomprehensibly complex. I’m sure that the Android and iOS UI libraries are significantly more complex than React.
I don't think Android and iOS UIs are necessarily more complex than React. And yes, I've shipped code in all three, for... way too many years, at this point.
React's trying to add functionality & developer workflow on top of an existing UI system (document rendering system...) that wasn't meant for application UI, has barely been modified to accommodate it since using it for that became normal, and isn't doing React many favors, and for bonus LULZ it's doing that in a single-threaded scripting language that somehow manages to have both too many and too few features to capably support React's vision, with the result that they're constantly fighting & replacing all the technology they're working with.
This puts it at a significant disadvantage versus any half-decent native UI toolkit, when it comes to complexity.
Yes, it's ridiculously easy on Android Studio. You can drag and drop interfaces lol. What would take 10 seconds in Android Studio takes 5 hours of CSS and 2 weeks of testing/debugging on the web. What is impossible or requires esoteric hacks on the web (concurrency) is done on mobile the exact same way it has been done for decades in software engineering (multithreading, CSP, ...) with entire books and college classes about how to do it.
Yes, anyone building apps on websites is doing the wrong thing.
Android is dead simple to develop GUIs on. Because it was designed for that. .NET is dead simple to develop Windows apps on. XCode/Swift is dead simple to develop Apple apps on.
Websites should go back to being advertisements for the the native apps. Here is a billion dollar company doing just that:
I guarantee you that the next Facebook, whatever it is, will not have a web client.