7 ms·

But why? With mainstream websites pumping out literal megabytes of JavaScript, why spend time rewriting an entire library (with less features) to save 50KB?

simonw 2y ago
Some of us still try to ship websites that use less than 50KB of JavaScript total.
happytoexplain 2y ago
Maybe if we embraced small dependencies rather than saying "why bother?", then dependencies would become smaller?
- szundi 2y ago
  This
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.
  - 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.
- 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.
oliwarner 2y ago
Mainstream websites are advertising-delivery trash. Don't use them as a benchmark for what we should be doing.
karaterobot 2y ago
This argument confuses me. It seems equivalent to saying "with mainstream fast food restaurants selling meals with 1600 calories, why are you making yourself a green salad for lunch?", or saying "with the national debt approaching $35 trillion dollars, why are you shopping around for the best rate on a mortgage?". One answer for all three cases is: I'm not the thing that's big, I'm a different thing that's smaller. Another answer is: if being too large is the problem, then being smaller sounds like a solution. But I guess you're really asking why the developer would spend time on rewriting a library. Is that really surprising? Most of programming is rewriting something that's been made before, either because you have to for your job, or because you need it to do something slightly different, or have different performance characteristics, or just want to learn how it's done.
EasyMark 2y ago
Embedded system? Or “I don’t need all that stuff for my comic book collection manager” or “minimalism has it’s own rewards”?
knowitnone 2y ago
oh, ok. Let make things larger then.
NotAnOtter 2y ago
Why rewrite an entire code base away from JQuery.. and not to native implementations? The era of jQuery and it's clones are over. People need to move on. If you're ever at the architecture level of your code base and think "What package should I use for DOM manipulation?", you're doing something wrong.
- skydhash 2y ago
  jQuery's API is nice. And it's abstraction reflects common sense more than technical implementations. It's another abstraction layer, all right, and not required, but it's so convenient.
- hu3 2y ago
  for htmx, jQuery is amazing My current client has a web application written in a lightweight strongly typed php framework, htmx and sprinkled jquery. Devs move very quickly, the website is blazing fast, and it makes around 140k mrr. It's not small. About 350 database tables and 200 crud pages. Business logic is well unit tested. You don't need to make jQuery the center of DOM manipulation if your application swaps dom with htmx with all the safety and comfort of a cozy backend. It feels magical. And the node_modules folder is smol. Icing on the cake. I look forward to jQuery 4 and 5. You don't see this kind of architecture in CVs because these people are too busy making money to bother.
  - hit8run 2y ago
    Sounds interesting from a tech perspective. What PHP framework is it and at what abstraction level you handle forms?
    - hu3 2y ago
      Thanks. It's a small custom framework built from libraries, some custom, some third party. - File based HTTP router running on top of https://frankenphp.dev/ https://frankenphp.dev/ - ORM/SQL with: https://github.com/cycle/orm https://github.com/cycle/orm but this is preference. Anything works. From SQL builders to ORMs. I'll try to explain their form handling: Forms almost always POST to their own GET URL. If you GET /user/save you'll get back HTML and `<script>` to build the form. If you POST /user/save you're expected to pass the entire form data PLUS an "operation" parameter which is used by the backend to decide what should be done and returned. For example if user clicks [add new user] button, the "operation" parameter has value of "btnSubmit.click". Why pass operation parameter? Because business forms can have more than just a [submit] button. For example, there might be a datagrid filter value being changed (operation: "txtFilter.change"), or perhaps a dropdown search to select a city name from a large list (operation: "textCitySearch.change"), it can be a postal code to address lookup (operation: "txtPostalCode.change"), etc. On the backend, the pseudocode looks somewhat like this but it's cleaner/safer because of encapsulation, validation, error handling, data sanitization, model binding and csrf/xss protection: function user_save($operation) { $form = new Form('/user/save'); $form->add($textName = new component(...)); $form->add($textCitySearch = new component(...)); $form->add($btnSubmit = new component(...)); if (method == "GET") return $form->getHtml(); try { if ($operation == "btnSubmit.click") { $newUser = UserService.createNewUser($_POST); return '<script>' . makeJavaScriptSuccessDialog('New user created!') . '</script>'; } if ($operation == "textCitySearch.change") { $foundCities = UserService.searchCities($_POST); return '<script>' . $textCitySearch->getJsToReplaceResultsWith($foundCities) . '</script>'; } } catch ($exception){ // Services above throw ValidationException() for incorrect input, $form takes that and generates friendly HTML for users in a centralized way if ($exception is ValidationException) { return '<script>' . $form->getValidationErrorJs($exception) . '</script>'; } // code below is actually done by a middleware elsewhere that catches unhandled exceptions, // but i put it here for brevity in this example. logSystemException($exception); return '<script>' . makeJavaScriptErrorDialog('Ops, something went wrong with us. We will fix it!') . '</script>'; } So the HTML generation and form processing for user creation is handled by a single HTTP endpoint and the code is very straight-forward. The locality of behaviour is off the charts and I don't need 10 template fragments for each form because everything is component based.

simonw 2y ago

Some of us still try to ship websites that use less than 50KB of JavaScript total.

happytoexplain 2y ago

Maybe if we embraced small dependencies rather than saying "why bother?", then dependencies would become smaller?

szundi 2y ago
This

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.
- 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.
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.

oliwarner 2y ago

Mainstream websites are advertising-delivery trash. Don't use them as a benchmark for what we should be doing.

karaterobot 2y ago

This argument confuses me. It seems equivalent to saying "with mainstream fast food restaurants selling meals with 1600 calories, why are you making yourself a green salad for lunch?", or saying "with the national debt approaching $35 trillion dollars, why are you shopping around for the best rate on a mortgage?". One answer for all three cases is: I'm not the thing that's big, I'm a different thing that's smaller. Another answer is: if being too large is the problem, then being smaller sounds like a solution. But I guess you're really asking why the developer would spend time on rewriting a library. Is that really surprising? Most of programming is rewriting something that's been made before, either because you have to for your job, or because you need it to do something slightly different, or have different performance characteristics, or just want to learn how it's done.

EasyMark 2y ago

Embedded system? Or “I don’t need all that stuff for my comic book collection manager” or “minimalism has it’s own rewards”?

knowitnone 2y ago

oh, ok. Let make things larger then.

NotAnOtter 2y ago

Why rewrite an entire code base away from JQuery.. and not to native implementations? The era of jQuery and it's clones are over. People need to move on. If you're ever at the architecture level of your code base and think "What package should I use for DOM manipulation?", you're doing something wrong.

skydhash 2y ago
jQuery's API is nice. And it's abstraction reflects common sense more than technical implementations. It's another abstraction layer, all right, and not required, but it's so convenient.
hu3 2y ago
for htmx, jQuery is amazing My current client has a web application written in a lightweight strongly typed php framework, htmx and sprinkled jquery. Devs move very quickly, the website is blazing fast, and it makes around 140k mrr. It's not small. About 350 database tables and 200 crud pages. Business logic is well unit tested. You don't need to make jQuery the center of DOM manipulation if your application swaps dom with htmx with all the safety and comfort of a cozy backend. It feels magical. And the node_modules folder is smol. Icing on the cake. I look forward to jQuery 4 and 5. You don't see this kind of architecture in CVs because these people are too busy making money to bother.
- hit8run 2y ago
  Sounds interesting from a tech perspective. What PHP framework is it and at what abstraction level you handle forms?
  - hu3 2y ago
    Thanks. It's a small custom framework built from libraries, some custom, some third party. - File based HTTP router running on top of https://frankenphp.dev/ https://frankenphp.dev/ - ORM/SQL with: https://github.com/cycle/orm https://github.com/cycle/orm but this is preference. Anything works. From SQL builders to ORMs. I'll try to explain their form handling: Forms almost always POST to their own GET URL. If you GET /user/save you'll get back HTML and `<script>` to build the form. If you POST /user/save you're expected to pass the entire form data PLUS an "operation" parameter which is used by the backend to decide what should be done and returned. For example if user clicks [add new user] button, the "operation" parameter has value of "btnSubmit.click". Why pass operation parameter? Because business forms can have more than just a [submit] button. For example, there might be a datagrid filter value being changed (operation: "txtFilter.change"), or perhaps a dropdown search to select a city name from a large list (operation: "textCitySearch.change"), it can be a postal code to address lookup (operation: "txtPostalCode.change"), etc. On the backend, the pseudocode looks somewhat like this but it's cleaner/safer because of encapsulation, validation, error handling, data sanitization, model binding and csrf/xss protection: function user_save($operation) { $form = new Form('/user/save'); $form->add($textName = new component(...)); $form->add($textCitySearch = new component(...)); $form->add($btnSubmit = new component(...)); if (method == "GET") return $form->getHtml(); try { if ($operation == "btnSubmit.click") { $newUser = UserService.createNewUser($_POST); return '<script>' . makeJavaScriptSuccessDialog('New user created!') . '</script>'; } if ($operation == "textCitySearch.change") { $foundCities = UserService.searchCities($_POST); return '<script>' . $textCitySearch->getJsToReplaceResultsWith($foundCities) . '</script>'; } } catch ($exception){ // Services above throw ValidationException() for incorrect input, $form takes that and generates friendly HTML for users in a centralized way if ($exception is ValidationException) { return '<script>' . $form->getValidationErrorJs($exception) . '</script>'; } // code below is actually done by a middleware elsewhere that catches unhandled exceptions, // but i put it here for brevity in this example. logSystemException($exception); return '<script>' . makeJavaScriptErrorDialog('Ops, something went wrong with us. We will fix it!') . '</script>'; } So the HTML generation and form processing for user creation is handled by a single HTTP endpoint and the code is very straight-forward. The locality of behaviour is off the charts and I don't need 10 template fragments for each form because everything is component based.