4 ms·

Bad jQuery apps follow the pattern: When “.x” is clicked, show “.x .y”, add className “xyz” to “.z”, and fire off an XHR to “/api”. This defines what the devel

Bad jQuery apps follow the pattern: When “.x” is clicked, show “.x .y”, add className “xyz” to “.z”, and fire off an XHR to “/api”. This defines what the developer wants to happen, but is brittle and hard to test. Frameworks would typically break this into actions or methods that modify state and a UI that updates when the state changes, so that the parts can be effectively unit tested and the UI can be changed without touching the rest of the logic. This is possible to do with jQuery too, but the library doesn’t do anything to help you. This is one of the primary complaints levelled at React, too.

rhapsodic 8y ago
> Bad jQuery apps follow the pattern: When “.x” is clicked, show “.x .y”, add className “xyz” to “.z”, and fire off an XHR to “/api”. This defines what the developer wants to happen, Yes, it does. All in one place, in about 10 easy to understand, easy to debug lines of code. >but is brittle and hard to test. I don't see how it's brittle, or hard to test. You click the button, and verify that it does what it's supposed to. Having done it more times than I can possibly count, and ending up with robust code, shipped on time, I can tell you that it's not hard, if you know how to do it. > Frameworks would typically break this into actions or methods that modify state and a UI that updates when the state changes, Which, IMO, makes something simple to understand and dead simple to debug into something painfully, ridiculously complex. And people complain about "jQuery spaghetti code". >so that the parts can be effectively unit tested and the UI can be changed without touching the rest of the logic. You cannot effectively unit test UI code, if by effective, you mean that it can replace manual testing. It can't replace manual testing. Someone will have to click that button under all of the likely scenarios and verify that it works. I'm sure it's not to you, but to me, writing unit tests for UI code would be a massive waste of time. If someone thinks they can be more productive using JS frameworks, and I don't have any personal financial stake in their productivity, then they should use them. But I don't see web development using a few simple tools like jQuery as difficult or mysterious or time-consuming. Last year I interviewed a few recent boot camp grads and they all sent me a link to their copy of the same React-based project. When I asked them questions about how things worked, in generic terms, for example, "what do you think makes this picture slide down slightly and expand in size when I mouse over it", they had no clue. I guess it was just a React component they dropped in, following the steps in the tutorial. I'm not faulting those people -- they paid a lot of money and did exactly what they were told they needed to do to land a sweet high-paying programming job. But they're simply of no use to me. I need the one who looks at it and knows right away that it would take about 4 lines of CSS to accomplish, even if they had to consult a CSS reference to find out exactly which properties/values to use.
- davidjnelson 8y ago
  You can test conditional logic, state mutation, and any function without side effects. It takes very little time and definitely improves the codebase. Testing is very dependent on the culture of your team and company though.
  - rhapsodic 8y ago
    >You can test conditional logic, state mutation, and any function without side effects. It takes very little time and definitely improves the codebase. Testing is very dependent on the culture of your team and company though. For sure. We have a team of people dedicated to testing. Compared to developers, they're easier and cheaper to hire. Our developers, who are very brilliant and very expensive, mainly write code for production, and leave testing to the testers. They write code designed to run efficiently and be maintainable, not to be more amenable to unit-testing. This has proven to work extremely well for us. If you need unit testing to ship robust code in a short timeframe, it would be foolish for you to not write the unit tests. But our team culture is such that we don't do things that we don't need to do to be productive and successful, and unit testing is one of those things.
    - tracker1 8y ago
      functional code is VERY maintainable... If you built it to be thrown away, or replaced, that tends to make it more maintainable. Making something testable, even if you don't write tests, leads to better code.
      - rhapsodic 8y ago
        >Making something testable, even if you don't write tests, leads to better code. That's strictly your opinion, which I do not happen to share.
- tracker1 8y ago
  Scale that to a VERY large application. There are lots of applications where class names and even hierarchies get re-used by other teams working on another portion of an application. In practice, CSS blows up, other portions of the app stop working correctly. Yes, you CAN use discipline in order to create good applications with jquery and others. In the end, I'll take my single state tree (source of truth) and one-way rendering path, and find it much more sane, without weird state and interaction bugs that show up.
davidjnelson 8y ago
Exactly. I’ve seen 10,000 line single jquery files handed off to other teams who were asked to merge them into their 4,000 loc customized quasi consumer of the 10,000 loc file. This was at a well respected and iconic tech company with very smart engineers. Even good people and teams can suck at architecture. I’ve taken those codebases and refactored them to be testable so I know it’s possible. But why not just use something sane like react to begin with, considering it’s 2018 now. At that point, backbone was only a year old.

rhapsodic 8y ago

> Bad jQuery apps follow the pattern: When “.x” is clicked, show “.x .y”, add className “xyz” to “.z”, and fire off an XHR to “/api”. This defines what the developer wants to happen, Yes, it does. All in one place, in about 10 easy to understand, easy to debug lines of code. >but is brittle and hard to test. I don't see how it's brittle, or hard to test. You click the button, and verify that it does what it's supposed to. Having done it more times than I can possibly count, and ending up with robust code, shipped on time, I can tell you that it's not hard, if you know how to do it. > Frameworks would typically break this into actions or methods that modify state and a UI that updates when the state changes, Which, IMO, makes something simple to understand and dead simple to debug into something painfully, ridiculously complex. And people complain about "jQuery spaghetti code". >so that the parts can be effectively unit tested and the UI can be changed without touching the rest of the logic. You cannot effectively unit test UI code, if by effective, you mean that it can replace manual testing. It can't replace manual testing. Someone will have to click that button under all of the likely scenarios and verify that it works. I'm sure it's not to you, but to me, writing unit tests for UI code would be a massive waste of time. If someone thinks they can be more productive using JS frameworks, and I don't have any personal financial stake in their productivity, then they should use them. But I don't see web development using a few simple tools like jQuery as difficult or mysterious or time-consuming. Last year I interviewed a few recent boot camp grads and they all sent me a link to their copy of the same React-based project. When I asked them questions about how things worked, in generic terms, for example, "what do you think makes this picture slide down slightly and expand in size when I mouse over it", they had no clue. I guess it was just a React component they dropped in, following the steps in the tutorial. I'm not faulting those people -- they paid a lot of money and did exactly what they were told they needed to do to land a sweet high-paying programming job. But they're simply of no use to me. I need the one who looks at it and knows right away that it would take about 4 lines of CSS to accomplish, even if they had to consult a CSS reference to find out exactly which properties/values to use.

davidjnelson 8y ago
You can test conditional logic, state mutation, and any function without side effects. It takes very little time and definitely improves the codebase. Testing is very dependent on the culture of your team and company though.
- rhapsodic 8y ago
  >You can test conditional logic, state mutation, and any function without side effects. It takes very little time and definitely improves the codebase. Testing is very dependent on the culture of your team and company though. For sure. We have a team of people dedicated to testing. Compared to developers, they're easier and cheaper to hire. Our developers, who are very brilliant and very expensive, mainly write code for production, and leave testing to the testers. They write code designed to run efficiently and be maintainable, not to be more amenable to unit-testing. This has proven to work extremely well for us. If you need unit testing to ship robust code in a short timeframe, it would be foolish for you to not write the unit tests. But our team culture is such that we don't do things that we don't need to do to be productive and successful, and unit testing is one of those things.
  - tracker1 8y ago
    functional code is VERY maintainable... If you built it to be thrown away, or replaced, that tends to make it more maintainable. Making something testable, even if you don't write tests, leads to better code.
    - rhapsodic 8y ago
      >Making something testable, even if you don't write tests, leads to better code. That's strictly your opinion, which I do not happen to share.
tracker1 8y ago
Scale that to a VERY large application. There are lots of applications where class names and even hierarchies get re-used by other teams working on another portion of an application. In practice, CSS blows up, other portions of the app stop working correctly. Yes, you CAN use discipline in order to create good applications with jquery and others. In the end, I'll take my single state tree (source of truth) and one-way rendering path, and find it much more sane, without weird state and interaction bugs that show up.

davidjnelson 8y ago

Exactly. I’ve seen 10,000 line single jquery files handed off to other teams who were asked to merge them into their 4,000 loc customized quasi consumer of the 10,000 loc file. This was at a well respected and iconic tech company with very smart engineers. Even good people and teams can suck at architecture. I’ve taken those codebases and refactored them to be testable so I know it’s possible. But why not just use something sane like react to begin with, considering it’s 2018 now. At that point, backbone was only a year old.