4 ms·
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.
by anderspitman 7y ago
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.
- hombre_fatal 7y agoClients 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.
- deleted 7y ago[deleted]
- huy-nguyen 7y agoCorrect 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.
- draw_down 7y ago"Too complex, but I can't come up with anything better"
- Grzegrzolka 7y agoI 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.
- nickdandakis 7y agoSometimes 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.
- Grzegrzolka 7y agoI 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.
- nickdandakis 7y agoThe 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.
- RussianCow 7y agoMost 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.
- baddox 7y agoAre 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.
- shantly 7y agoI 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.
- zelly 7y agoYes, 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.
- shadowgovt 7y agoIn 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."
- zelly 7y agoYes, 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: https://cash.app/ https://cash.app/ I guarantee you that the next Facebook, whatever it is, will not have a web client.