7 ms·

Not relevant to this package in particular, but this line of reasoning baffles me every time I see HN comments about JQuery. So many posters argue against the u

by w4 2y ago

Not relevant to this package in particular, but this line of reasoning baffles me every time I see HN comments about JQuery. So many posters argue against the use of JQuery because of its package size and bandwidth constraints, while simultaneously advocating for SPA frameworks that use orders of magnitude more bandwidth. Absolutely ridiculous cargo cult reasoning.

happytoexplain 2y ago
A. You're assuming they are largely the same people by extrapolating from your observations. It's impossible to actually know. B. Your two examples provide different things. This is like saying it's OK to include any old multi-megabyte dependency if a site loads a couple mb worth of images. There's no reason to stop considering the size of the small parts just because you decided you need some large parts. Things add up - that will never stop being a useful thing to remember, in any context.
nashashmi 2y ago
Two different types of people. One wants to create lightweight applications. The other wants lightweight development. Lightweight development for lightweight applications is a bit of an oxymoron at this time.
- not_a_bot_4sho 2y ago
  > Lightweight development for lightweight applications is a bit of an oxymoron at this time. Apt description
- hecanjog 2y ago
  IMHO the way to achieve this is to pay the upfront cost of building out a small framework for your application, which has lightweight abstractions for common patterns. With some design, a small internal API can be as nice to work with as the kitchen sink abstractions. (Much nicer, too, when it comes to maintenance and debugging.)
  - KronisLV 2y ago
    > IMHO the way to achieve this is to pay the upfront cost of building out a small framework for your application And then 5 years down the line it has grown into a worse version of the popular alternatives, the original developers are gone and the ones who currently maintain the mess have to pay the price. In corporate or professional contexts, you probably just should pick whatever is popular. Though that anecdote about risk management should also have this link alongside it: https://www.robinsloan.com/notes/home-cooked-app/ https://www.robinsloan.com/notes/home-cooked-app/ When you’re working on something others won’t have to maintain years down the line, thankfully your hands aren’t tied then and you can have a bit more fun. For everything else? Svelte, HTMX, jQuery, Vue, React, Angular or whatever else makes sense. That said, sometimes I wonder what a world would look like, where the browser would have the most popular options pre-packaged in a way where you wouldn’t need to download hundreds of KB in each site you visit, but you’d get the packages with browser updates. It’d probably save petabytes of data. Except seems like we went in the opposite direction, with even CDNs being less efficient in some ways: https://httptoolkit.com/blog/public-cdn-risks/ https://httptoolkit.com/blog/public-cdn-risks/
    - skydhash 2y ago
      The thing is that while your application is working well, the library authors would have moved on and it's up to you to upgrade your application and fix breaking changes. At least with an in-house framework, it's always morphing into something that the company needs. Not saying that there aren't nicer framework, but it's always someone agenda that has aligned with yours at the time of selection.
      - KronisLV 2y ago
        > The thing is that while your application is working well, the library authors would have moved on and it's up to you to upgrade your application and fix breaking changes. AngularJS is actually a pretty good argument to support your point, I had to migrate an app off of it (we picked Vue as the successor) and it was quite the pain, because a lot of the code was already a bit messy and the concepts don't carry over all that nicely, especially if you want something quite close to the old implementation, functionality wise. On the other hand, jQuery just seems to be trucking along throughout the years. There are cases like Vue 2 to Vue 3 migrations which can also have growing pains, but I think that the likes of Vue, React and Angular are generally unlikely to be abandoned, even with growing pains along the way. In that regard, your job as a developer is probably to pick whatever might have the least amount of surprises, the most longevity and the lowest chance of you having to maintain it yourself and instead being able to coast off of the work of others (and maybe contributing, if you have the time), with the project having hundreds if not thousands of contributors, which will often be better than what a few people within any given org could achieve. Sometimes that might even be reaching for something like SSR instead of making SPAs, depending on what you can get away with. One can probably talk about Boring Technology or Lindy effect here.
leptons 2y ago
We're using jQuery on our sites which score 100% on all Google Lighthouse pagespeed tests. A smaller version of jQuery really wouldn't matter to us, our pages are already extremely fast to load and score amazingly well on any page speed/SEO test. About the only place I could see a benefit from this library is maybe in embedded, where space really is an issue. I've created a few IoT devices with web interfaces that are built-into the tiny ROM of the device. A 6KB library is nice, but I'm using Preact with everything gzipped in one single .html file and my very complex web app hosted in the IoT device is about 50KB total size gzipped - including code, content, SVG images and everything, so jQuery or a JQ substitute isn't going to be a better solution for me, but maybe it fits for someone that doesn't know how to set up the tooling for a react/preact app.
- Rapzid 2y ago
  To add, I really try to minimize external deps but if first-load speed were absolutely critical loading from jQuery CDN would increase odds of it already being cached.. Meh for most places I've worked though.
  - leptons 2y ago
    We don't make any external HTTP requests for any library code. jQuery is embedded into the page HTML file, along with all other required library code necessary for the page to start functioning, in one bundle. Nothing that runs below the fold is executed until the page is scrolled. All scripts are deferred, except the required libraries, one of which is jQuery and is loaded in-line in a <script> block in the page <head>. There's a ton of tricks we use to get to a perfect Google Lighthouse score - we also score perfect 100% on mobile too. This isn't a complex web application but we do a lot of cool front-end stuff.
    - Rapzid 2y ago
      That's great and fair. Some places are NUTS about first page load speed(and I mean first time someone has ever visited the site) though and it really could matter across all deps depending on a ton of other factors.. Serving super common libs, like jQuery, from the lost likely CDN location could maximize the likelihood it's already cached. I have never personally worked anywhere this mattered.

by w4 2y ago

happytoexplain 2y ago

A. You're assuming they are largely the same people by extrapolating from your observations. It's impossible to actually know. B. Your two examples provide different things. This is like saying it's OK to include any old multi-megabyte dependency if a site loads a couple mb worth of images. There's no reason to stop considering the size of the small parts just because you decided you need some large parts. Things add up - that will never stop being a useful thing to remember, in any context.

nashashmi 2y ago

Two different types of people. One wants to create lightweight applications. The other wants lightweight development. Lightweight development for lightweight applications is a bit of an oxymoron at this time.

not_a_bot_4sho 2y ago
> Lightweight development for lightweight applications is a bit of an oxymoron at this time. Apt description
hecanjog 2y ago
IMHO the way to achieve this is to pay the upfront cost of building out a small framework for your application, which has lightweight abstractions for common patterns. With some design, a small internal API can be as nice to work with as the kitchen sink abstractions. (Much nicer, too, when it comes to maintenance and debugging.)
- KronisLV 2y ago
  > IMHO the way to achieve this is to pay the upfront cost of building out a small framework for your application And then 5 years down the line it has grown into a worse version of the popular alternatives, the original developers are gone and the ones who currently maintain the mess have to pay the price. In corporate or professional contexts, you probably just should pick whatever is popular. Though that anecdote about risk management should also have this link alongside it: https://www.robinsloan.com/notes/home-cooked-app/ https://www.robinsloan.com/notes/home-cooked-app/ When you’re working on something others won’t have to maintain years down the line, thankfully your hands aren’t tied then and you can have a bit more fun. For everything else? Svelte, HTMX, jQuery, Vue, React, Angular or whatever else makes sense. That said, sometimes I wonder what a world would look like, where the browser would have the most popular options pre-packaged in a way where you wouldn’t need to download hundreds of KB in each site you visit, but you’d get the packages with browser updates. It’d probably save petabytes of data. Except seems like we went in the opposite direction, with even CDNs being less efficient in some ways: https://httptoolkit.com/blog/public-cdn-risks/ https://httptoolkit.com/blog/public-cdn-risks/
  - skydhash 2y ago
    The thing is that while your application is working well, the library authors would have moved on and it's up to you to upgrade your application and fix breaking changes. At least with an in-house framework, it's always morphing into something that the company needs. Not saying that there aren't nicer framework, but it's always someone agenda that has aligned with yours at the time of selection.
    - KronisLV 2y ago
      > The thing is that while your application is working well, the library authors would have moved on and it's up to you to upgrade your application and fix breaking changes. AngularJS is actually a pretty good argument to support your point, I had to migrate an app off of it (we picked Vue as the successor) and it was quite the pain, because a lot of the code was already a bit messy and the concepts don't carry over all that nicely, especially if you want something quite close to the old implementation, functionality wise. On the other hand, jQuery just seems to be trucking along throughout the years. There are cases like Vue 2 to Vue 3 migrations which can also have growing pains, but I think that the likes of Vue, React and Angular are generally unlikely to be abandoned, even with growing pains along the way. In that regard, your job as a developer is probably to pick whatever might have the least amount of surprises, the most longevity and the lowest chance of you having to maintain it yourself and instead being able to coast off of the work of others (and maybe contributing, if you have the time), with the project having hundreds if not thousands of contributors, which will often be better than what a few people within any given org could achieve. Sometimes that might even be reaching for something like SSR instead of making SPAs, depending on what you can get away with. One can probably talk about Boring Technology or Lindy effect here.

leptons 2y ago

We're using jQuery on our sites which score 100% on all Google Lighthouse pagespeed tests. A smaller version of jQuery really wouldn't matter to us, our pages are already extremely fast to load and score amazingly well on any page speed/SEO test. About the only place I could see a benefit from this library is maybe in embedded, where space really is an issue. I've created a few IoT devices with web interfaces that are built-into the tiny ROM of the device. A 6KB library is nice, but I'm using Preact with everything gzipped in one single .html file and my very complex web app hosted in the IoT device is about 50KB total size gzipped - including code, content, SVG images and everything, so jQuery or a JQ substitute isn't going to be a better solution for me, but maybe it fits for someone that doesn't know how to set up the tooling for a react/preact app.

Rapzid 2y ago
To add, I really try to minimize external deps but if first-load speed were absolutely critical loading from jQuery CDN would increase odds of it already being cached.. Meh for most places I've worked though.
- leptons 2y ago
  We don't make any external HTTP requests for any library code. jQuery is embedded into the page HTML file, along with all other required library code necessary for the page to start functioning, in one bundle. Nothing that runs below the fold is executed until the page is scrolled. All scripts are deferred, except the required libraries, one of which is jQuery and is loaded in-line in a <script> block in the page <head>. There's a ton of tricks we use to get to a perfect Google Lighthouse score - we also score perfect 100% on mobile too. This isn't a complex web application but we do a lot of cool front-end stuff.
  - Rapzid 2y ago
    That's great and fair. Some places are NUTS about first page load speed(and I mean first time someone has ever visited the site) though and it really could matter across all deps depending on a ton of other factors.. Serving super common libs, like jQuery, from the lost likely CDN location could maximize the likelihood it's already cached. I have never personally worked anywhere this mattered.