4 ms·

>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?
      - eropple 8y ago
        So I'm gonna be honest: I don't have much time or patience for "but webpack is complex" complaints. Webpack is complex, sure. It has many moving parts. It is not complicated, and that means its complexity is more or less "remember a few nouns". Each of the parts those nouns encapsulate is simple and obvious with straightforward inputs and outputs. The interactions may not always be so straightforward--but, in practice, they are. I am comfortable asserting that you shouldn't be surprised by anything webpack or gulp or whatever does. If you are, you haven't internalized what you're working on to a sufficient degree. Because it is just. not. that. big. a. deal. "Just get things done" when the way you're doing so is less clear, less testable, and less reliable is not, to me, the hallmark of a developer I would trust with anything I cared about.
      - hajile 8y ago
        I've heard about webpack and build tools a ton and I don't understand the issue. If your project is simple, webpack setup is copy/paste (v3) or no config at all (v4). If your project is doing complex stuff, webpack is more in-depth, but a breeze compared to the make files and XML config of other languages. More importantly, webpack has a very clear tutorial and extensive documentation. You have to go incredibly far off the normal path to run into something that isn't covered. Off topic, but augmenting webpack dev server express instance made dev work many times easier on my current project.
- 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.

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?
    - eropple 8y ago
      So I'm gonna be honest: I don't have much time or patience for "but webpack is complex" complaints. Webpack is complex, sure. It has many moving parts. It is not complicated, and that means its complexity is more or less "remember a few nouns". Each of the parts those nouns encapsulate is simple and obvious with straightforward inputs and outputs. The interactions may not always be so straightforward--but, in practice, they are. I am comfortable asserting that you shouldn't be surprised by anything webpack or gulp or whatever does. If you are, you haven't internalized what you're working on to a sufficient degree. Because it is just. not. that. big. a. deal. "Just get things done" when the way you're doing so is less clear, less testable, and less reliable is not, to me, the hallmark of a developer I would trust with anything I cared about.
    - hajile 8y ago
      I've heard about webpack and build tools a ton and I don't understand the issue. If your project is simple, webpack setup is copy/paste (v3) or no config at all (v4). If your project is doing complex stuff, webpack is more in-depth, but a breeze compared to the make files and XML config of other languages. More importantly, webpack has a very clear tutorial and extensive documentation. You have to go incredibly far off the normal path to run into something that isn't covered. Off topic, but augmenting webpack dev server express instance made dev work many times easier on my current project.
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.