5 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 dev

> 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.
- rhapsodic 8y ago
  >Scale that to a VERY large application. I have. Without problems. >In practice, CSS blows up, other portions of the app stop working correctly. Perhaps in your practice, tracker1. But not in mine. That's what everyone seems to be missing here. This is all a bunch of hand waving to me, because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me. If you need all of this stuff to ship robust, maintainable code, then you would be foolish not to use it. But I would be foolish to use some complex framework that I do not need to ship robust, maintainable code. I think the facade is starting to crack with many of these JS frameworks. More and more people are writing articles like the OP and saying that this particular emperor has no clothes.
  - tracker1 8y ago
    > because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. Frameworks and modern tools help to take care in these situations. The application above was around 2007-2008 IIRC... different parts made by different teams, cobbled together. Layers of backend cruft as well. I did help start a new project, that had much more consistent/clean structure. But when you have too many hands in a pie, and no automated testing in place, you wind up with that eventually. I've been developing web based applications since 1996. I've lived through the eras without the browsers and abilities we have today... the growth of the DOM and the JS language from a few interfaces for forms, to being able to do so very much. You don't have to use anything to ship your code... but you have to do something to get a few dozen devs working on something cohesive.

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.

rhapsodic 8y ago
>Scale that to a VERY large application. I have. Without problems. >In practice, CSS blows up, other portions of the app stop working correctly. Perhaps in your practice, tracker1. But not in mine. That's what everyone seems to be missing here. This is all a bunch of hand waving to me, because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me. If you need all of this stuff to ship robust, maintainable code, then you would be foolish not to use it. But I would be foolish to use some complex framework that I do not need to ship robust, maintainable code. I think the facade is starting to crack with many of these JS frameworks. More and more people are writing articles like the OP and saying that this particular emperor has no clothes.
- tracker1 8y ago
  > because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. Frameworks and modern tools help to take care in these situations. The application above was around 2007-2008 IIRC... different parts made by different teams, cobbled together. Layers of backend cruft as well. I did help start a new project, that had much more consistent/clean structure. But when you have too many hands in a pie, and no automated testing in place, you wind up with that eventually. I've been developing web based applications since 1996. I've lived through the eras without the browsers and abilities we have today... the growth of the DOM and the JS language from a few interfaces for forms, to being able to do so very much. You don't have to use anything to ship your code... but you have to do something to get a few dozen devs working on something cohesive.