Live data from Hacker News

jQuery 3.6.0

blog.jquery.com

261–270 of 292 posts

Re: jQuery 3.6.0

#261

I'm a happy jQuery/Bootstrap user @ https://forwardemail.net . The site scores ~100% on Lighthouse and PageSpeed Insights and is ranked #1. Open-startup @ https://forwardemail.net/open-startup ! Completely open-source too @ https://github.com/forwardemail

Do you use automatic translation? At least the German version feels a bit odd.

Yeah, Google Translate via the npm package "mandarin" I made @ https://www.npmjs.com/package/mandarin. I planned to hire curators to go through the JSON files and clean it up - though I'm incredibly surprised that open source contributors have come forward (sometimes for their first time doing a PR) to submit fixes to locales. I give them free service for several years for their help.

Re: jQuery 3.6.0

#262

I'm a happy jQuery/Bootstrap user @ https://forwardemail.net . The site scores ~100% on Lighthouse and PageSpeed Insights and is ranked #1. Open-startup @ https://forwardemail.net/open-startup ! Completely open-source too @ https://github.com/forwardemail

Offtopic but thanks for launching this. A happy customer.

Very glad to have you Tycho.

Re: jQuery 3.6.0

#263

I'm a happy jQuery/Bootstrap user @ https://forwardemail.net . The site scores ~100% on Lighthouse and PageSpeed Insights and is ranked #1. Open-startup @ https://forwardemail.net/open-startup ! Completely open-source too @ https://github.com/forwardemail

Super cool. I really like that you can also reply using this service to each individual inbox. Like a universal inbox but not married to any specific client/app. Maybe suggest making that a little more easier to learn on your marketing homepage. For your current users, are you seeing them use this more like the demo gym owner video or for other use cases? Thanks

So many cases. Some are using this on hundreds of sub-domains. I hope to launch SMTP and regex support soon. Then... it has final form, power level over 9000.

Re: jQuery 3.6.0

#264
post #124
post #60

Earlier quoted context omitted.

Technically that breaks, you want: document.querySelectorAll('.my-class-selector').forEach(el => el.classList.add('active')) Personally I use the native APIs because they aren't that hard to use (most of them, anyways) and I tend to be OCD about bundle sizes, but to each their own, I suppose.

Yeah, oh so many years ago I realized that I use just a small subset of jQuery, and just rewrote those bits, to avoid having to inject whole of jQuery into all pages that I browse (I had some global https?://* userscripts, so I was basically injecting jQuery into every single page and frame). https://megous.com/dl/tmp/basic.js 1.3kB compressed. Much better. :) And I avoided having to rewrite my extensions with platfo…

You should totally open-source that, put it on NPM, and write an article or so about it.

Re: jQuery 3.6.0

#265

Earlier quoted context omitted.

> and that's the lean alternative to React. Ahem https://preactjs.com/

oh look, another one. lol

> another one

Preact [0] came before Vue [1].

[0] https://github.com/preactjs/preact/commits/master?after=605b... [1] https://github.com/vuejs/vue/commits/dev?after=5255841aaff44...

Re: jQuery 3.6.0

#266
post #24
post #14

Earlier quoted context omitted.

Please elaborate about toString() ?

If called on a Function it returns the source of the function, which allows for all sorts of meta programming.

Yep. We used to use this for some hacks back before AST libraries were a thing, mainly because Function.prototype.toString() preserves comments.

function foo() { /* a comment! / }

console.log(foo.toString()); //-> "function foo() { / a comment! */ }"

Re: jQuery 3.6.0

#267

Earlier quoted context omitted.

>Do people still use jQuery? Oh yes. Everyday. Still love it. >…Javascript document api via document.querySelector, and document.querySelectorAll The jQuery API is still (and probably aways will be) far superior to the native DOM (terser, composable, more expressive, etc). >…smaller footprint libraries like lodash jQuery is ≈30k gziped and most likely already cached from CDN. >…has fallen out of favor of more compreh…

"The jQuery API is still (and probably aways will be) far superior to the native DOM" The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations. It only operates on individual DOM nodes. Any looping should be done using your JS loop of choice (forEach, for loop, which, etc). Th…

> The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations.

so... like jQuery?

Re: jQuery 3.6.0

#268
post #6

Do people still use jQuery? I thought the biggest advantage of this library back in the day was css selector access of DOM nodes (back when we only had getElementById, getElementsByClassName, and getElementsByTagName). This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll. Also there are browser compatibility issues that jQuery solved but a lot of these are so…

Still use it. Still love it. Just last month I decided to toss a quite arbitrary `=>` in my javascript (I still write `function (args) { code }`), and shipped it. Immediately got a _TON_ of user complaints. Turns out, we sent a link in a newsletter, and most folks were reading those in Outlook, and that evidently just opens links internally, and that is still IE11. We don't ordinarily support IE11, but given that thi…

jQuery is "bad" when complexity increases.

jQuery's strength is the CSS selector based approach, where CSS, HTML and JS all "speak the same language", but it also its greatest weakness, your JS code gets too tightly coupled with the structure of the HTML, which makes it harder to refactor.

Good code management can solve this, like using a class or class like construct (e.g. jQuery plugin) to create independent components. But jQuery misses a lot of features to be a truly component based solution. jQuery UI widget is somewhat closer but still missing features like other component based solution has, e.g. no built in template library.

One of the most common things in JS is to attach listeners to HTML elements, however the most common way when doing so in jQuery is that you have a bunch of selectors and then some listener code, but that type of statements is not self explanatory, you have no function name to describe what it is doing or any other context. You see all these registrations of event listeners scattered across the project. What do they do? Are they in use? Hard to tell because searching your source code for a CSS selector is very difficult. That is why jQuery based projects usually have tons of leftover code from the last refactor, no one dares to touch it.

Many component based libraries out there lets you register a method name on the HTML element directly. Much better. If you can't find the method/function name referenced in your code, you can delete it.

It is true that you can add event listeners inline on your HTML element, but that is not how jQeury is usually written, because it is selector based.

Re: jQuery 3.6.0

#269

I think a lot of the comments in this thread that are critical of SPAs are thinking about them wrong. SPAs aren't (shouldn't be) a replacement for websites. They are a fantastic option for replacing native apps (PWAs). Moving from walled garden native apps to the open web is good for everyone except the app stores.

Probably because many websites today are written as SPAs. Many of these modern frameworks are also pushed as to be used for websites.

Re: jQuery 3.6.0

#270

Earlier quoted context omitted.

>Do people still use jQuery? Oh yes. Everyday. Still love it. >…Javascript document api via document.querySelector, and document.querySelectorAll The jQuery API is still (and probably aways will be) far superior to the native DOM (terser, composable, more expressive, etc). >…smaller footprint libraries like lodash jQuery is ≈30k gziped and most likely already cached from CDN. >…has fallen out of favor of more compreh…

> jQuery is ≈30k gziped and most likely already cached from CDN. This part isn't so true in reality anymore, due to revised browser caching systems[1]. Doesn't mean you shouldn't use jQuery, just that part of the benefits of a centralized CDN are no longer a factor and it's a lot more sensible to self-host. 1: https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...

There's still a huge benefit to using CDNs, despite caching being dead - they are almost certainly faster then whatever is hosting your site. If your site is relatively light and has a lot of traffic (especially international), pulling libs from a CDN could significantly increase the amount of requests you can process on the same server hardware and regardless of that, decrease the load latency for your users.
Post reply on HN