5 ms·

I agree with the author that jQuery was essential for the time. Abstracting away browser compatibility issues in the era of IE6 was a wonderful thing, for sure

I agree with the author that jQuery was essential for the time. Abstracting away browser compatibility issues in the era of IE6 was a wonderful thing, for sure. The problem is jQuery has no business being used today unless you have to maintain legacy code. Even then I would deprecate jQuery wherever possible. Using jQuery for a "quick and dirty" application today is just terrible and it sends the message to green devs that jQuery code slinging is a skill worth having. If you like quick and dirty, just make sure you have a working Node.js environment and generate a simple project that supports Webpack or Parcel. You will get all the advantages of Babel and Polyfills (if you need them) with little to no effort. jQuery has no value except for maintaining legacy code. jQuery was useful back in the day (and John Resig had the best solution), but I don't love it anymore. In fact, I have serious judgements of the devs that use it that should know better. Edit: I should note that jQuery is bad because it has no state management and you cannot easily track side-effects. I would much rather see someone use something like Svelte and construct the functionality with modern best practices while keeping a very small footprint.

bluedevil2k 5y ago
> If you like quick and dirty, just make sure you have a working Node.js environment and generate a simple project that supports Webpack or Parcel There’s nothing quick or easy about these steps. Linking to a jQuery CDN and getting working code immediately is easy.
- bstar77 5y ago
  I respectfully disagree. If you take 15 min to understand the basics it becomes trivially easy and the productivity you gain going forward is massive.
  - sc68cal 5y ago
    It's not going to take 15 minutes to understand WebPack and Parcel. Let's be a little more realistic. Sometimes you don't have the luxury of time and tools that you already know are going to get used, instead of new tools you don't.
    - bstar77 5y ago
      https://parceljs.org/getting_started.html https://parceljs.org/getting_started.html If you have a use case as simple as the author is advocating, this only take about 15 minutes to grok. If it takes longer then you probably don't have enough front-end experience to productively contribute to this conversation. That is a little harsh, but the FUD in the JS world is incredible, mainly by people that have very little experience and understanding.
  - kayodelycaon 5y ago
    I've been dealing with Webpacker for almost a year and it's been a nightmare every time I've tried to use it. And yes, I did sit down and try to figure out what the hell was going on.
    - bstar77 5y ago
      Parcel is literally zero configuration, maybe that would have been a better solution for your usecase. You need to understand some Webpack basics for it to be functionally useful, but all the criticisms of Webpack could easily be levied against jQuery and some.
    - brainbag 5y ago
      Vite is the way to go now, IMO. It just works and is extremely fast.
  - mickaelkerjean 5y ago
    I respectfully disagree if you have some other things to do in your free time than maintaining dependencies, trying to figure out why your project won't compile at all in 6 months of time while reporting 100 security issues, what will be the next change in webpack to will require to update both your config and some plugins, why does npm now cry for you to use a "--legacy-peer-deps" flags to nicely handle dependencies you didn't know you had while being happy you can't compile your frontend project on a small raspberry pi. It's not because you can use all those tools than you should
    - bstar77 5y ago
      You are literally criticising Webpack for its best features. Identifying outdated libraries and potentially dangerous vulnerabilities is a huge plus for Webpack. Do you think just because you include a CDN lib in the global space vulnerabilities just magically go away? You also don't need to include packages that are poorly engineered and maintained. For what you do decide to use, you are getting visibility into the warts that you may have blissfully ignored in the past. The issues you are describing are not really problems anymore unless you let your app get woefully out of date. The web and browsers are a moving target, so it's critical that you minimize running legacy code wherever possible. Npm/Yarn and Webpack is a huge step in making that manageable. jQuery has been on autopilot for years because it has limited usefulness. We've collectively moved on except for a few holdouts.
      - gunapologist99 5y ago
        You are literally criticizing jQuery for its best features. Not having outdated libraries and potentially dangerous vulnerabilities is a huge plus for jQuery. Do you think just because you use a build tool for modules from all over the npm-verse that vulnerabilities just magically go away?
        bstar77 5y ago
        jQuery has had its share of dangerous vulnerabilities. https://snyk.io/vuln/npm:jquery https://snyk.io/vuln/npm:jquery
throwaway_egbs 5y ago
> a working Node.js environment Sincere no-snark question from someone who's been out of the frontend game for a while: Why do I need Node in order to do "quick and dirty" frontend development? (FTR I'm with you that jQuery is silly these days. Today's built-in web APIs do pretty much everything jQuery ever did.)
- dragonwriter 5y ago
  > Why on earth do I need Node in order to do "simple" frontend development Because using current JS standards while moving the vast majority of the “make it work across a moving-target set of browsers” concerns to build toolchain configuration settings is a simplification from either explicitly managing all the compatibility issues and/or restricting to least-common-denominator JS features. Yes, build toolchains are themselves a source of complexity, but in net they can be a simplification.
- bstar77 5y ago
  Basically what Dragonwriter said. Without getting into the weeds of where webdev was and where it is now, we have made some massive progress. One of the huge improvements was moving to JS compilers (Babel/Typescript/Flow) that normalized features so all browsers going back to IE11 could be reliably supported with the latest language standards. When you just sling jQuery on a page and try to use spread syntax or async/await, shit's gonna break.
  - throwaway_egbs 5y ago
    Right, I get that. What I don't get is why Node is a requirement for a JS compiler. Is that just to get the runtime? I'd always thought of Node as a server on top of a V8 runtime. (Thank you for your patience with this backend dev who finds your whole world very confusing.)
    - bstar77 5y ago
      Node is required because that's what is used to compile the JS on the command line, it's a nodejs process. Once that's complete, any web server can serve the newly produced JS/CSS/HTML files. JS is interpreted by the browser, but we compile locally so that the code produced implements workarounds for missing language features. The code produced is typically minified so that the payload sent to the browser is much smaller than it would otherwise be. Node is analogous to Python, Ruby and PHP... they all can run webservices, power desktop apps and compile/build projects.
todd_t 5y ago
Quick and dirty should be a combination of Alpine and/or htmx.

bluedevil2k 5y ago

> If you like quick and dirty, just make sure you have a working Node.js environment and generate a simple project that supports Webpack or Parcel There’s nothing quick or easy about these steps. Linking to a jQuery CDN and getting working code immediately is easy.

bstar77 5y ago
I respectfully disagree. If you take 15 min to understand the basics it becomes trivially easy and the productivity you gain going forward is massive.
- sc68cal 5y ago
  It's not going to take 15 minutes to understand WebPack and Parcel. Let's be a little more realistic. Sometimes you don't have the luxury of time and tools that you already know are going to get used, instead of new tools you don't.
  - bstar77 5y ago
    https://parceljs.org/getting_started.html https://parceljs.org/getting_started.html If you have a use case as simple as the author is advocating, this only take about 15 minutes to grok. If it takes longer then you probably don't have enough front-end experience to productively contribute to this conversation. That is a little harsh, but the FUD in the JS world is incredible, mainly by people that have very little experience and understanding.
- kayodelycaon 5y ago
  I've been dealing with Webpacker for almost a year and it's been a nightmare every time I've tried to use it. And yes, I did sit down and try to figure out what the hell was going on.
  - bstar77 5y ago
    Parcel is literally zero configuration, maybe that would have been a better solution for your usecase. You need to understand some Webpack basics for it to be functionally useful, but all the criticisms of Webpack could easily be levied against jQuery and some.
  - brainbag 5y ago
    Vite is the way to go now, IMO. It just works and is extremely fast.
- mickaelkerjean 5y ago
  I respectfully disagree if you have some other things to do in your free time than maintaining dependencies, trying to figure out why your project won't compile at all in 6 months of time while reporting 100 security issues, what will be the next change in webpack to will require to update both your config and some plugins, why does npm now cry for you to use a "--legacy-peer-deps" flags to nicely handle dependencies you didn't know you had while being happy you can't compile your frontend project on a small raspberry pi. It's not because you can use all those tools than you should
  - bstar77 5y ago
    You are literally criticising Webpack for its best features. Identifying outdated libraries and potentially dangerous vulnerabilities is a huge plus for Webpack. Do you think just because you include a CDN lib in the global space vulnerabilities just magically go away? You also don't need to include packages that are poorly engineered and maintained. For what you do decide to use, you are getting visibility into the warts that you may have blissfully ignored in the past. The issues you are describing are not really problems anymore unless you let your app get woefully out of date. The web and browsers are a moving target, so it's critical that you minimize running legacy code wherever possible. Npm/Yarn and Webpack is a huge step in making that manageable. jQuery has been on autopilot for years because it has limited usefulness. We've collectively moved on except for a few holdouts.
    - gunapologist99 5y ago
      You are literally criticizing jQuery for its best features. Not having outdated libraries and potentially dangerous vulnerabilities is a huge plus for jQuery. Do you think just because you use a build tool for modules from all over the npm-verse that vulnerabilities just magically go away?
      - bstar77 5y ago
        jQuery has had its share of dangerous vulnerabilities. https://snyk.io/vuln/npm:jquery https://snyk.io/vuln/npm:jquery

throwaway_egbs 5y ago

> a working Node.js environment Sincere no-snark question from someone who's been out of the frontend game for a while: Why do I need Node in order to do "quick and dirty" frontend development? (FTR I'm with you that jQuery is silly these days. Today's built-in web APIs do pretty much everything jQuery ever did.)

dragonwriter 5y ago
> Why on earth do I need Node in order to do "simple" frontend development Because using current JS standards while moving the vast majority of the “make it work across a moving-target set of browsers” concerns to build toolchain configuration settings is a simplification from either explicitly managing all the compatibility issues and/or restricting to least-common-denominator JS features. Yes, build toolchains are themselves a source of complexity, but in net they can be a simplification.
bstar77 5y ago
Basically what Dragonwriter said. Without getting into the weeds of where webdev was and where it is now, we have made some massive progress. One of the huge improvements was moving to JS compilers (Babel/Typescript/Flow) that normalized features so all browsers going back to IE11 could be reliably supported with the latest language standards. When you just sling jQuery on a page and try to use spread syntax or async/await, shit's gonna break.
- throwaway_egbs 5y ago
  Right, I get that. What I don't get is why Node is a requirement for a JS compiler. Is that just to get the runtime? I'd always thought of Node as a server on top of a V8 runtime. (Thank you for your patience with this backend dev who finds your whole world very confusing.)
  - bstar77 5y ago
    Node is required because that's what is used to compile the JS on the command line, it's a nodejs process. Once that's complete, any web server can serve the newly produced JS/CSS/HTML files. JS is interpreted by the browser, but we compile locally so that the code produced implements workarounds for missing language features. The code produced is typically minified so that the payload sent to the browser is much smaller than it would otherwise be. Node is analogous to Python, Ruby and PHP... they all can run webservices, power desktop apps and compile/build projects.

todd_t 5y ago

Quick and dirty should be a combination of Alpine and/or htmx.