5 ms·

This was one of the _problems_ React solves. Before with libraries like jQuery every potential action had to perform it's own UI modifications. As the project

by pests 10y ago

This was one of the _problems_ React solves. Before with libraries like jQuery every potential action had to perform it's own UI modifications. As the projects grows you have the same UI element being controlled from many different sections of code. States and state transitions not clearly defined. With React you set the state and the UI will always match, no matter how the current state was achieved. The purpose was to get rid of ad-hoc DOM manipulations. The Flux architecture just takes this a bit further by formally defining who holds onto the state/how it's accessed (stores) and the availible possible state changes (actions).

davelnewton 10y ago
Willy-nilly DOM and state modification wasn't a requirement with jQuery, it was just how a lot of people chose to (not) structure their applications.
- pests 10y ago
  It wasn't a requirement but it was encouraged. jQuery was all about selecting a node or node list and then applying manipulations to it.
  - davelnewton 10y ago
    To "encourage" means to openly advocate. Never ever have I seen active encouragement of poor programming discipline. You are correct in that's what jQuery was about, but it had no opinion on how to go about that task.
    - pests 10y ago
      It might not have a explicit opinion stated anywhere but in any library or framework, the API provided influences how those APIs are used. By having the central unit of work start with a query selector is one such influence which I feel implicitly encouraged DOM manipulations. Taking a look at the original jQuery website on web.archive, this is the introduction to the $() function: "The functionality of jQuery centers around one central function: $(). Everything in jQuery is based upon this, or uses this in some way. The most basic use of this function is to pass in an expression (usually consisting of CSS or XPath), which then finds all matching elements and remembers them for later use. For example:" And then goes to show a DOM selection followed by a chained mutation.
      - davelnewton 10y ago
        > [...] I feel implicitly encouraged DOM manipulations. That's jQuery's primary job. It isn't DOM manipulation that causes code/architectural issues. "All" (I'm simplifying) jQuery does is provide mechanisms to select and manipulate DOM. How to organize its usage is an exercise left to the reader, and most readers did it poorly. It's not jQuery's fault that people wrote shitty code with it. And, in fairness, when Prototype/jQuery/etc. came out, sites were simpler. When people started doing more, if they didn't take control of how they were using jQ/etc., it blew up and made them hate their lives. At the same time people were doing that, other people were using various organizing principles to tame their jQ/etc. soup, writing tests, and keeping a handle on the sprawl. You can write shitty code in React, too. It imposes a certain set of conventions that make it harder to want to. Layer on Redux/etc. and it's even harder to want to. Layer on other various conventions and frameworks and you want to even less. But it doesn't stop you--just like jQ didn't stop you from using self-discipline before people smarter than me evolved client-side frameworks to where we are now. While I wrote my share of jQ soup, I also worked on projects that were flexible, extensible, testable, and clean. The choice is always ours to make.
        pests 10y ago
        Take an average developer (or two) and sit them down in front of React and jQuery for the first time. My bet is anything based on React will be better built than that of jQuery. Of course you can architect those flexible, extensible, testable and clean projects. But straight out of the box you do not get that with jQuery. It requires planning and architecture engineering. Whereas every React project starts off with those principals. In other words, the ways people can use jQuery wrong is worse than the ways people can use React wrong.
        davelnewton 10y ago
        I both agree and disagree. If you code yourself into a corner with React it can be harder to understand and untangle: it's much easier to understand jQuery under the covers than React, especially if you're using other parts of the React ecosystem. None of this is related to what I said originally, which is that jQuery doesn't encourage shitty code. jQ's original purpose wasn't to organize developer activity, it was to simplify one tiny portion of it. > [Good code in jQ] requires planning and architecture engineering. Precisely what I said. (That said, if you don't do that with React, you'll still end up with a mess.)

by pests 10y ago

davelnewton 10y ago

Willy-nilly DOM and state modification wasn't a requirement with jQuery, it was just how a lot of people chose to (not) structure their applications.

pests 10y ago
It wasn't a requirement but it was encouraged. jQuery was all about selecting a node or node list and then applying manipulations to it.
- davelnewton 10y ago
  To "encourage" means to openly advocate. Never ever have I seen active encouragement of poor programming discipline. You are correct in that's what jQuery was about, but it had no opinion on how to go about that task.
  - pests 10y ago
    It might not have a explicit opinion stated anywhere but in any library or framework, the API provided influences how those APIs are used. By having the central unit of work start with a query selector is one such influence which I feel implicitly encouraged DOM manipulations. Taking a look at the original jQuery website on web.archive, this is the introduction to the $() function: "The functionality of jQuery centers around one central function: $(). Everything in jQuery is based upon this, or uses this in some way. The most basic use of this function is to pass in an expression (usually consisting of CSS or XPath), which then finds all matching elements and remembers them for later use. For example:" And then goes to show a DOM selection followed by a chained mutation.
    - davelnewton 10y ago
      > [...] I feel implicitly encouraged DOM manipulations. That's jQuery's primary job. It isn't DOM manipulation that causes code/architectural issues. "All" (I'm simplifying) jQuery does is provide mechanisms to select and manipulate DOM. How to organize its usage is an exercise left to the reader, and most readers did it poorly. It's not jQuery's fault that people wrote shitty code with it. And, in fairness, when Prototype/jQuery/etc. came out, sites were simpler. When people started doing more, if they didn't take control of how they were using jQ/etc., it blew up and made them hate their lives. At the same time people were doing that, other people were using various organizing principles to tame their jQ/etc. soup, writing tests, and keeping a handle on the sprawl. You can write shitty code in React, too. It imposes a certain set of conventions that make it harder to want to. Layer on Redux/etc. and it's even harder to want to. Layer on other various conventions and frameworks and you want to even less. But it doesn't stop you--just like jQ didn't stop you from using self-discipline before people smarter than me evolved client-side frameworks to where we are now. While I wrote my share of jQ soup, I also worked on projects that were flexible, extensible, testable, and clean. The choice is always ours to make.
      - pests 10y ago
        Take an average developer (or two) and sit them down in front of React and jQuery for the first time. My bet is anything based on React will be better built than that of jQuery. Of course you can architect those flexible, extensible, testable and clean projects. But straight out of the box you do not get that with jQuery. It requires planning and architecture engineering. Whereas every React project starts off with those principals. In other words, the ways people can use jQuery wrong is worse than the ways people can use React wrong.
        davelnewton 10y ago
        I both agree and disagree. If you code yourself into a corner with React it can be harder to understand and untangle: it's much easier to understand jQuery under the covers than React, especially if you're using other parts of the React ecosystem. None of this is related to what I said originally, which is that jQuery doesn't encourage shitty code. jQ's original purpose wasn't to organize developer activity, it was to simplify one tiny portion of it. > [Good code in jQ] requires planning and architecture engineering. Precisely what I said. (That said, if you don't do that with React, you'll still end up with a mess.)