61 ms·

I think what GP was getting at is that there's a healthy amount of "if all you have is a hammer" mentality going on w/ React/Redux. The tragedy of commons here

by lhorie 7y ago

I think what GP was getting at is that there's a healthy amount of "if all you have is a hammer" mentality going on w/ React/Redux. The tragedy of commons here is that you _could_ conceivably just slap a class at the root of your React tree to implement dark mode, but if one is using something like styled-components, there's a good chance that the library will get in the way of the style cascading semantics that come for free w/ the browser. And ultimately, the end-user is the one paying the price for all the extra code needed to make a "complexity-friendly" implementation of dark mode work. Another observation that I've been finding interesting about "modern frontend development" is that despite all the arguments about how React makes DOM manipulation easier, people still prefer to defer to libraries to do any non-trivial amount of DOM manipulation rather than actually use pure React to do it. This is exactly the same modus operandi as when jQuery was "modern frontend development" ("it makes it easier to work w/ DOM", plus a ton of opaque jquery-* libs)

shadowgovt 7y ago
I don't see why using libraries for complicated interactions atop React is a bad thing.
- johnmaguire2013 7y ago
  I'm not sure it's a bad thing - but using a library for DOM manipulation on top of it diminishes the argument that React's advantage is to make DOM manipulation easy.
  - dragonsh 7y ago
    Having used react and modern web components to build webpages. I will agree with the first comment which says what is made so hard by react/redux can be easily done if the pages were rendered on server and delivered to client with progressive smaller bits of JavaScript for dynamic interaction. If state management is so critical to running a react app than I feel Elm/ClojureScript is a better choice than react to build web apps. But I doubt they will be as popular given network effect. Now everyone went on a bandwagon that react/angular/SPA/progressive apps is the only future and plain HTML/CSS/JS mix on server side with specific language templates is dead. I am sure we will again go full circle back as you can see now with SSR (server side rendering) is considered as a norm for performant react or angular apps. SSR combined with complexity of react/redux unnecessarily makes everything complicated (worse than even complex). Instead of doing HTML templates in nicer language on server side now people are forced with half baked solution on client side like JSX or angular templates etc. A developer not just need to learn intricacies of HTML/CSS/JS, but then API's of framework like react, combine it with state management framework, combine it with client side templates, combine it with build tools like gulp, webpack, combine it with NPM, Yarn, combine it with babel compiler, combine it with many testing frameworks. The whole eco-system is very complicated (not just complex). This is one of the reason for emergence of compiler based web application development language and frameworks like Svelte, Elm, ClojureScript, PureScripts. They will still be not popular because there is a network effect of jobs available. So inferior tools for user interface like react/angular will continue to thrive.
    - littlecranky67 7y ago
      > Now everyone went on a bandwagon that react/angular/SPA/progressive apps is the only future and plain HTML/CSS/JS mix on server side with specific language templates is dead Well it is not dead, but with the rise of Webapps (not Websites!) come use-cases you can only handle with SPAs. One major example is the new youtube feature, where the video playback is not interrupted when you click on a link somewhere (the video stays at the right bottom corner of the page and keeps plaing). No way to do this with SSR. Other examples include staying in fullscreen mode (think automatic playback of video playlists) - with SSR, every video change would trigger a page reload and thus require user interaction to go back to fullscreen. SPAs are not required for Websites, but for Webapps there are a lot of cases where SSR is not possible or would result in poor UX.
westoncb 7y ago
> people still prefer to defer to libraries to do any non-trivial amount of DOM manipulation rather than actually use pure React to do it. Could you give an example of a commonly-used library that serves this purpose?
- lhorie 7y ago
  Add a word after "react-" and there's a good chance it's one. React-bootstrap (vs bootstrap), react-dnd (vs something like dragula), etc.
  - acemarke 7y ago
    I'm not sure what point you're trying to make here. Both of those examples are _specifically_ about using React to do the actual DOM manipulation. React-Bootstrap is a set of React components that know how to generate the correct HTML structure and classnames to get the matching Bootstrap styles. As part of that, I believe some of the jQuery-centric logic in Bootstrap has been implemented in just React. For drag and drop especially, you're having to approach the problem from a different mental model. You can't just `$(".my-list").sortable()`. React wants you to describe your UI based on _state_ rather than doing raw DOM manipulation, so libraries like react-dnd and react-beautiful-dnd do the work to tie together drag events with the underlying logic to drive React re-rendering. But in both these cases, you're not "using other libraries to do DOM manipulation". React's doing the work. These libraries are just helping tell React what the DOM should be.
    - lhorie 7y ago
      This is why I was reluctant to give examples (because as soon I did, someone was bound to say something along the lines of "well these leverage react in a very react specific way so of course it makes sense they're react things") The thing is that we could s/react/jquery/ and end up with a more-or-less believable argument for why "jquery is needed for complex apps": You can't just `draggable=true`. jQuery wants you to describe your UI in terms of a plugin's options object rather than doing raw DOM manipulation; libraries like jquery-ui do the work to tie together drag events with underlying logic (e.g. snap) to drive jQuery re-rendering. You're not "using other libraries to do DOM manipulation"; jQuery's doing the work. Etc. Of course a library on top of react/jquery/whatever will generally be written in a way that is idiomatic for code written on top of its respective base framework. For library writers like you and me, it might even make sense to argue that React rendering model is nicer for writing libraries on top of than jQuery. But that's a developer-oriented mindset, which, as the_gastropod had alluded to, it's very often at odds w/ a user-oriented mindset. The "old beard" approach slices through all the abstraction layers and simply points out: huh, you don't need context and css-in-js and themes to do dark mode, plain CSS fits the bill. And when one resets assumptions enough times and start noticing more often than not that "complex" projects turn out to be glorified CRUD apps, one might indeed start to wonder if the abstractions are really as fitting for the task at hand as they should be.
dragonwriter 7y ago
> The tragedy of commons here is that you _could_ conceivably just slap a class at the root of your React tree to implement dark mode, but if one is using something like styled-components, there's a good chance that the library will get in the way of the style cascading semantics that come for free w/ the browser. A decent dark mode is going to take a lot than a class at the root in any case (a class at the root makes a good toggle, sure, but you have to do all the styling if particular elements that that toggle applies.) If you have handrolled CSS for your light theme and want to add a dark theme toggle, hand rolling CSS for it and toggling with a class at the root is pretty idiomatic React. If you've chosen a styling/theming library to solve other problems, or incidentally to doing so as might have happened if you chose Material-UI, then, sure, a class at the root might not work well, and/or you might have a much easier solution (not easier than the class at root but easier than the rest of the work of implementing a dark theme) for adding a toggleable dark theme. Like in Material-UI, where you just tell the theming solution you’d like the computed dark version of a theme.

by lhorie 7y ago

shadowgovt 7y ago

I don't see why using libraries for complicated interactions atop React is a bad thing.

johnmaguire2013 7y ago
I'm not sure it's a bad thing - but using a library for DOM manipulation on top of it diminishes the argument that React's advantage is to make DOM manipulation easy.
- dragonsh 7y ago
  Having used react and modern web components to build webpages. I will agree with the first comment which says what is made so hard by react/redux can be easily done if the pages were rendered on server and delivered to client with progressive smaller bits of JavaScript for dynamic interaction. If state management is so critical to running a react app than I feel Elm/ClojureScript is a better choice than react to build web apps. But I doubt they will be as popular given network effect. Now everyone went on a bandwagon that react/angular/SPA/progressive apps is the only future and plain HTML/CSS/JS mix on server side with specific language templates is dead. I am sure we will again go full circle back as you can see now with SSR (server side rendering) is considered as a norm for performant react or angular apps. SSR combined with complexity of react/redux unnecessarily makes everything complicated (worse than even complex). Instead of doing HTML templates in nicer language on server side now people are forced with half baked solution on client side like JSX or angular templates etc. A developer not just need to learn intricacies of HTML/CSS/JS, but then API's of framework like react, combine it with state management framework, combine it with client side templates, combine it with build tools like gulp, webpack, combine it with NPM, Yarn, combine it with babel compiler, combine it with many testing frameworks. The whole eco-system is very complicated (not just complex). This is one of the reason for emergence of compiler based web application development language and frameworks like Svelte, Elm, ClojureScript, PureScripts. They will still be not popular because there is a network effect of jobs available. So inferior tools for user interface like react/angular will continue to thrive.
  - littlecranky67 7y ago
    > Now everyone went on a bandwagon that react/angular/SPA/progressive apps is the only future and plain HTML/CSS/JS mix on server side with specific language templates is dead Well it is not dead, but with the rise of Webapps (not Websites!) come use-cases you can only handle with SPAs. One major example is the new youtube feature, where the video playback is not interrupted when you click on a link somewhere (the video stays at the right bottom corner of the page and keeps plaing). No way to do this with SSR. Other examples include staying in fullscreen mode (think automatic playback of video playlists) - with SSR, every video change would trigger a page reload and thus require user interaction to go back to fullscreen. SPAs are not required for Websites, but for Webapps there are a lot of cases where SSR is not possible or would result in poor UX.

westoncb 7y ago

> people still prefer to defer to libraries to do any non-trivial amount of DOM manipulation rather than actually use pure React to do it. Could you give an example of a commonly-used library that serves this purpose?

lhorie 7y ago
Add a word after "react-" and there's a good chance it's one. React-bootstrap (vs bootstrap), react-dnd (vs something like dragula), etc.
- acemarke 7y ago
  I'm not sure what point you're trying to make here. Both of those examples are _specifically_ about using React to do the actual DOM manipulation. React-Bootstrap is a set of React components that know how to generate the correct HTML structure and classnames to get the matching Bootstrap styles. As part of that, I believe some of the jQuery-centric logic in Bootstrap has been implemented in just React. For drag and drop especially, you're having to approach the problem from a different mental model. You can't just `$(".my-list").sortable()`. React wants you to describe your UI based on _state_ rather than doing raw DOM manipulation, so libraries like react-dnd and react-beautiful-dnd do the work to tie together drag events with the underlying logic to drive React re-rendering. But in both these cases, you're not "using other libraries to do DOM manipulation". React's doing the work. These libraries are just helping tell React what the DOM should be.
  - lhorie 7y ago
    This is why I was reluctant to give examples (because as soon I did, someone was bound to say something along the lines of "well these leverage react in a very react specific way so of course it makes sense they're react things") The thing is that we could s/react/jquery/ and end up with a more-or-less believable argument for why "jquery is needed for complex apps": You can't just `draggable=true`. jQuery wants you to describe your UI in terms of a plugin's options object rather than doing raw DOM manipulation; libraries like jquery-ui do the work to tie together drag events with underlying logic (e.g. snap) to drive jQuery re-rendering. You're not "using other libraries to do DOM manipulation"; jQuery's doing the work. Etc. Of course a library on top of react/jquery/whatever will generally be written in a way that is idiomatic for code written on top of its respective base framework. For library writers like you and me, it might even make sense to argue that React rendering model is nicer for writing libraries on top of than jQuery. But that's a developer-oriented mindset, which, as the_gastropod had alluded to, it's very often at odds w/ a user-oriented mindset. The "old beard" approach slices through all the abstraction layers and simply points out: huh, you don't need context and css-in-js and themes to do dark mode, plain CSS fits the bill. And when one resets assumptions enough times and start noticing more often than not that "complex" projects turn out to be glorified CRUD apps, one might indeed start to wonder if the abstractions are really as fitting for the task at hand as they should be.

dragonwriter 7y ago

> The tragedy of commons here is that you _could_ conceivably just slap a class at the root of your React tree to implement dark mode, but if one is using something like styled-components, there's a good chance that the library will get in the way of the style cascading semantics that come for free w/ the browser. A decent dark mode is going to take a lot than a class at the root in any case (a class at the root makes a good toggle, sure, but you have to do all the styling if particular elements that that toggle applies.) If you have handrolled CSS for your light theme and want to add a dark theme toggle, hand rolling CSS for it and toggling with a class at the root is pretty idiomatic React. If you've chosen a styling/theming library to solve other problems, or incidentally to doing so as might have happened if you chose Material-UI, then, sure, a class at the root might not work well, and/or you might have a much easier solution (not easier than the class at root but easier than the rest of the work of implementing a dark theme) for adding a toggleable dark theme. Like in Material-UI, where you just tell the theming solution you’d like the computed dark version of a theme.