6 ms·

> jQuery is great for small snippets of code, but encourages a quick and dirty style that collapses for larger applications. I keep hearing (well, reading on H

> jQuery is great for small snippets of code, but encourages a quick and dirty style that collapses for larger applications. I keep hearing (well, reading on HN) criticisms of this sort about jQuery and they are absolutely not supported by the years of experience I have using jQuery for front-ends that have in many cases been quite complex. I use it because it greatly simplifies DOM manipulation and event handling. (e.g., no need to remove event handlers for a subtree removed by the .remove() method.)

underwater 8y ago
In my experience the app tends to evolve around jQuery selectors and event handlers, rather than having a well defined structure. This is not a fault of jQuery, as it never intended to solve those problems. Like you said, it is purely meant to solve the DOM issue.
- rhapsodic 8y ago
  >In my experience the app tends to evolve around jQuery selectors and event handlers, rather than having a well defined structure What does that even mean?
  - DaiPlusPlus 8y ago
    CSS selectors are highly dependent on the structure of your HTML. If you refactor your HTML then you’ll be required to rewrite many of your CSS selectors. None of that is surprising at all, but jQuery makes it hard to abstract the use of CSS selectors away from the rest of your UI code. Compare with Angular2+ where the logical separation of Components and the HTML of the template is rigidly enforced making refactoring and “scaling” considerably easier. jQuery is library that provides DOM shorthand - it isn’t a true application framework.
    - rhapsodic 8y ago
      >If you refactor your HTML then you’ll be required to rewrite many of your CSS selectors. I haven't found that to be a major issue. And I don't think the term "refactor" is the best choice here. jQuery is library that provides DOM shorthand - it isn’t a true application framework. Of course not. I don't want a third-party application framework. I discovered years ago that they're not worth the extra effort or the technical debt one incurs with them. (At least not to me. I'm not telling anyone what they should think or that they should design their applications like I do.) My approach for me and the developers on my team is to develop a deep level of understanding of HTML, CSS and JS. Once you have that, the prospect of doing things for yourself that frameworks would otherwise provide does not seem all that daunting. To me, frameworks like React, Angular, etc. don't reduce complexity, they increase it. And I hasten to note that I realize that many bright, capable people hold a different view , and I'm not saying they're wrong.
      - eropple 8y ago
        Something like React isn't even an application framework, though, it's a view library of compositional functions feeding into a tree diff. How does functional, side-effect-free code increase complexity? What makes your side-effecting code more testable and verifiable than unambiguous in/out functional transforms?
        digitalzombie 8y ago
        Personally for me it's a trade off and it does increase complexity. With jQuery and such you just include a script and back then there were no package management system, glup/grunt, webpack, yeoman/brunch, etc.. Also the client side rendering make SEO hard. jQuery just get stuff done but at the same time the organization of your code is up to you and you do sacrifice some reusability but in general the trade off is complexity. VueJS as much as I love learning this framework, it is complex with webpack, cli, browser plugin, and etc...
        jexah 8y ago
        You realise there are SSR setups for React, and even better, isomorphic setups like Next.js?
    - tracker1 8y ago
      Now evolve that to say React, where your components aren't separated by a DSL from your component code. ;-) Not to dig on Angular too much, I think it's fine, but I'd much rather use Vue if I was going for small, or React if I'm going for larger interactions/components/applications. Angular does have a lot in the box, but when it takes 4 guys to lift that box, there's a lot less value than 4 smaller boxes.
  - underwater 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, 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.
  - darepublic 8y ago
    Having worked with large codebase written in jQuery here are some of my thoughts, There were a ton of times where the complexity of the situation made it so hard to know how to debug something. I mean you had to keep track in your head in a given piece of code what the UI state was, what classes or event handlers were toggled on or off, what the value of various variables were etc. In order to keep my sanity I would have to create functions that basically do what React or other frameworks give you out of the box so it would be easy to reason about everything. There was so much code like this: var $snippet = $(<div></div>).append(...).addClass().on('click', handler => { if (alienState) { $snippet.off('click') } else { $snippet.on('click', handler2) } }) $(".parentClass > ").remove() /clear any dom framents in there //before a fresh injection! fingers crossed!*/ $(".parentClass").append($snippet)... etc etc I'm sure there is a way to do disciplined excellent jquery code. I'm always quick to say its the coder(s) that make a piece of software code good or bad. But if you were to make a well made jquery application you would need to implement some kind of design pattern, and exercise some kind of conventions and discipline that you could really get for free with a framework.
    - gkya 8y ago
      That sounds like an issue caused by an indecent debugger to me. I havent had to debug JS, but indeed the browser debuggers can use some sophistication and customisability, IMHO.
      - hajile 8y ago
        JS debuggers are generally very good. The level of interactiveness of JS also puts them ahead of most non-lisp languages. Debugging async code isn't like debugging other code. Once you cross that async barrier, all stack traces disappear (I understand Google's doing some work on making that better). In this particular case, debugging is harder because the UI is also holding all the data, so in order to reset to known good data, you have to reset the page itself. One of the biggest benefits to moving to React (or similar) is that you start keeping all that data in a central place.
quxbar 8y ago
The fact that you're keeping track of your actual DOM and event handling at all? That's what I got sick of. Going from jQuery to React was a huge breath of fresh air.
- rhapsodic 8y ago
  > The fact that you're keeping track of your actual DOM and event handling at all? That's what I got sick of. Not me. I call it "writing software."

underwater 8y ago

In my experience the app tends to evolve around jQuery selectors and event handlers, rather than having a well defined structure. This is not a fault of jQuery, as it never intended to solve those problems. Like you said, it is purely meant to solve the DOM issue.

rhapsodic 8y ago
>In my experience the app tends to evolve around jQuery selectors and event handlers, rather than having a well defined structure What does that even mean?
- DaiPlusPlus 8y ago
  CSS selectors are highly dependent on the structure of your HTML. If you refactor your HTML then you’ll be required to rewrite many of your CSS selectors. None of that is surprising at all, but jQuery makes it hard to abstract the use of CSS selectors away from the rest of your UI code. Compare with Angular2+ where the logical separation of Components and the HTML of the template is rigidly enforced making refactoring and “scaling” considerably easier. jQuery is library that provides DOM shorthand - it isn’t a true application framework.
  - rhapsodic 8y ago
    >If you refactor your HTML then you’ll be required to rewrite many of your CSS selectors. I haven't found that to be a major issue. And I don't think the term "refactor" is the best choice here. jQuery is library that provides DOM shorthand - it isn’t a true application framework. Of course not. I don't want a third-party application framework. I discovered years ago that they're not worth the extra effort or the technical debt one incurs with them. (At least not to me. I'm not telling anyone what they should think or that they should design their applications like I do.) My approach for me and the developers on my team is to develop a deep level of understanding of HTML, CSS and JS. Once you have that, the prospect of doing things for yourself that frameworks would otherwise provide does not seem all that daunting. To me, frameworks like React, Angular, etc. don't reduce complexity, they increase it. And I hasten to note that I realize that many bright, capable people hold a different view , and I'm not saying they're wrong.
    - eropple 8y ago
      Something like React isn't even an application framework, though, it's a view library of compositional functions feeding into a tree diff. How does functional, side-effect-free code increase complexity? What makes your side-effecting code more testable and verifiable than unambiguous in/out functional transforms?
      - digitalzombie 8y ago
        Personally for me it's a trade off and it does increase complexity. With jQuery and such you just include a script and back then there were no package management system, glup/grunt, webpack, yeoman/brunch, etc.. Also the client side rendering make SEO hard. jQuery just get stuff done but at the same time the organization of your code is up to you and you do sacrifice some reusability but in general the trade off is complexity. VueJS as much as I love learning this framework, it is complex with webpack, cli, browser plugin, and etc...
        jexah 8y ago
        You realise there are SSR setups for React, and even better, isomorphic setups like Next.js?
  - tracker1 8y ago
    Now evolve that to say React, where your components aren't separated by a DSL from your component code. ;-) Not to dig on Angular too much, I think it's fine, but I'd much rather use Vue if I was going for small, or React if I'm going for larger interactions/components/applications. Angular does have a lot in the box, but when it takes 4 guys to lift that box, there's a lot less value than 4 smaller boxes.
- underwater 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, 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.
- darepublic 8y ago
  Having worked with large codebase written in jQuery here are some of my thoughts, There were a ton of times where the complexity of the situation made it so hard to know how to debug something. I mean you had to keep track in your head in a given piece of code what the UI state was, what classes or event handlers were toggled on or off, what the value of various variables were etc. In order to keep my sanity I would have to create functions that basically do what React or other frameworks give you out of the box so it would be easy to reason about everything. There was so much code like this: var $snippet = $(<div></div>).append(...).addClass().on('click', handler => { if (alienState) { $snippet.off('click') } else { $snippet.on('click', handler2) } }) $(".parentClass > ").remove() /clear any dom framents in there //before a fresh injection! fingers crossed!*/ $(".parentClass").append($snippet)... etc etc I'm sure there is a way to do disciplined excellent jquery code. I'm always quick to say its the coder(s) that make a piece of software code good or bad. But if you were to make a well made jquery application you would need to implement some kind of design pattern, and exercise some kind of conventions and discipline that you could really get for free with a framework.
  - gkya 8y ago
    That sounds like an issue caused by an indecent debugger to me. I havent had to debug JS, but indeed the browser debuggers can use some sophistication and customisability, IMHO.
    - hajile 8y ago
      JS debuggers are generally very good. The level of interactiveness of JS also puts them ahead of most non-lisp languages. Debugging async code isn't like debugging other code. Once you cross that async barrier, all stack traces disappear (I understand Google's doing some work on making that better). In this particular case, debugging is harder because the UI is also holding all the data, so in order to reset to known good data, you have to reset the page itself. One of the biggest benefits to moving to React (or similar) is that you start keeping all that data in a central place.

quxbar 8y ago

The fact that you're keeping track of your actual DOM and event handling at all? That's what I got sick of. Going from jQuery to React was a huge breath of fresh air.

rhapsodic 8y ago
> The fact that you're keeping track of your actual DOM and event handling at all? That's what I got sick of. Not me. I call it "writing software."