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.
jQuery 3.6.0
261–270 of 292 posts
Re: jQuery 3.6.0
#262I'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.
Re: jQuery 3.6.0
#263I'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
Re: jQuery 3.6.0
#264Earlier 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…
Re: jQuery 3.6.0
#265Earlier quoted context omitted.
> and that's the lean alternative to React. Ahem https://preactjs.com/
oh look, another one. lol
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
#266Earlier 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.
function foo() { /* a comment! / }
console.log(foo.toString()); //-> "function foo() { / a comment! */ }"
Re: jQuery 3.6.0
#267Earlier 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…
so... like jQuery?
Re: jQuery 3.6.0
#268Do 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'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
#269I 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.
Re: jQuery 3.6.0
#270Earlier 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...