Personally if you are spending all that time and energy recreating the wheel just to say "you don't use JQuery ", you're being an idiot and might as well just use JQuery. Seriously I wonder how much they actually spent in dollar hours on this pull request.
I prefer the term "Magpie Developer" https://blog.codinghorror.com/the-magpie-developer/
Personally, I'm currently working on projects that still use Bootstrap 3. It still works, just a jQuery still works.
Sure there's some baggage. There's always some trade off somewhere, isn't there. But if things working is a priority then jQuery isn't such a bad thing.
Heavy movie trailer voice Consider a world, where there is no problem that required jQuery.
I refer to React and such.
$('.tpm_sensors').forEach(function(sensor) { if (sensor.pressure < threshold) fixBeforeIDie(); });
vs:
var tpm_sensors = document.getElementsByClassName('tpm_sensors'); for (var i = 0, len = tpm_sensors.length; i < len; i++) { var sensor = tpm_sensors[i]; if (sensor.pressure < threshold) fixBeforeIDie(); }
And so it starts. jQuery uses .each, not .forEach. So you fix that. But stuff still doesn't work.
Right, because jQuery's .each passes the index as first parameter and the element as second (or this).
jQuery trips me every single time.
You cannot apply instant gratification to software library dev. If the work for a library was done and satisfied in 2015, then it’s fucking done. It’s tried and tested. It gets security patches. It’s maintained.
Recency and the last github commit is not a metric for stability or success.
Yes, I did check whether ls was still actively being developed, saw that it wasn't doing anything new, and switched to exa, which is a fantastic little project, with sane defaults, less cruft, and greater speed. You can always improve software, some people just get bored of doing so, and then declare it "done". But it isn't, and it's never going to be.
How many times can you update a URL parser or leftpad? Do you need to update them just to up your GitHub activity meter?
This might even be more possible for "simpler" softwares.
jQuery already uses many native features when supported, while also working around browser quirks and such. It's less of an issue than in the past, but it hasn't gone away completely; see all the comments/fixes for specific browsers.
> One less dependency, network request and more efficient code is always worth the effort.
Of course not. It's a return-of-investment calculation. The 85k of jQuery isn't all that large, especially considering that websites like Medium and NYC load 2MB of JS, and the overhead of jQuery compared to standard JavaScript is minor.
https://webpagetest.org/result/190213_XH_63c61dc3d45cb95ec8a...
https://www.webpagetest.org/result/190213_NX_ee1e7ae8fa74557...
It’s not hard to beat jQuery in many cases but they’re looking pretty svelte in comparison:
https://webpagetest.org/result/190213_93_e2da91a07e2b2bc0234...
The biggest complain I read about is javascript downloads being so big nowadays so piling on with jQuery--or anything else--just because frameworks and other libraries are so bloated doesn't make it OK.
If you don’t profile your app, that cool new stack is probably going to be bigger and slower because tools like webpack make it easy to manage tons of code and you won’t notice until you test it on mobile, slow WiFi, etc.
I'm not in the trenches with this stuff though so my numbers may be wrong but... the ~500% number seems pretty off.
I have no idea where you got your "500%" from, but it seems wildly off-mark.
react is 31kb vue is 20kb preact is 4kb
When doing comparisons, don't be disingenuous. Compare like numbers.
It's easy to "win" internet arguments like this rolls eyes.
Its primary purpose was smoothing over browser inconsistencies and it's cached by every major CDN already so using it is likely faster than trying to rebuild and maintain the individual parts separately.
I’ve never found this to be true any time I’ve measured, especially for mobile clients. Small caches with lots of versions and CDNs really cut into the theoretical benefits.
This is much better than serving that file from your origin server, and even if you use a CDN it's unlikely that it'll match the hit rates of the public CDNs. That can make a measurable improvement, and at worse is no slower than hosting it yourself.
My rule of thumb is that public CDNs aren’t a performance move in the HTTP/2 era (i.e. 2016 or later). They may still be convenient, however.
I don’t care what you or your industry today decides it ’needs’, you’re not getting a persistent webwide tracking ID.
Making that available for apps and websites would've eliminated 99% of cookies and user syncing pixels since the industry could use a short-term stable ID to track engagement and conversions.
Unfortunately the industry doesn't work like that, the name of the game is "collect everything and anything at any cost".
It is so bad that there is barely any difference between the behavior of "legal/legit" players (established advertisement businesses like Google) and scammers, Google for example bypassed 3rd party cookie restrictions on Safari, just like sophisticated scammers use any means to collection information on their targets for social engineering.
What this means is that not only there is no reason to believe that advertisers will be happy with a short-term stable ID akin to Apple's Advertising ID, they have time and time proven to go above and beyond to track users by any and every mean possible.
So what introducing something like Apple's Advertising ID to web will do is merely add yet another identifier to endless bucket of targeting methods already in use, sadly, it won't make advertisers stop abusing other things like cache so we can have nice things.
IDs are needed for 2 primary reasons: controlling ad frequency and attributing clicks and conversions to an ad impression.
Cookies worked for a long time but they were always considered loose short-term and anonymous identifiers. Apple had a opportunity to offer a better device-level option that had the same privacy but much better efficiency, and yet decided to break APIs and user experience instead, while also entrenching the big companies at the detriment of everyone else.
jQuery has many convenience features such as chaining, for example: item.addClass('selected').siblings().removeClass('selected'); and you don't have to check for nulls after each selection.
Many functions such as closest() and remove() have no equivalents in IE11, and other things such as replaceWith() and before() are not available even in Edge.
For simple sites it is easy enough to remove jQuery, but for more complex javascript applications, especially apps that have a lot of interactivity, removing jQuery will result in more code, or you will end up writing a lot of utility functions thereby creating your own little clone of jQuery.
This is misleading. Sure, that immediate code is cleaner in the left column. However, to do that, you have to have the entire JQuery library loaded as well. Sure, it's hidden, but the library looks like the code on the right column.
I'm not knocking JQuery, as I use it a lot.
But you didn't have to write that code or debug it.
That is, if you don't need to support IE (And I feel like we're finally in the phase where it slowly, but steadily dies off). Otherwise you can ponyfill it.
Except that 90% of sites that use BS5 will continue to use JQ for other things anyway so, in reality, you won't have less code, fewer requests, etc.
Personally I've felt for a while that JQ's day in the sun is over and that developers should really think about whether they need it or not. Maybe really getting rid of it starts with slightly risky moves like this. Like when Apple killed the floppy.
Switching from wired to wireless giving up performance capabilities (ex: over ear headphones vs ear buds) forcing one to recharge batteries etc is not even in the same ballpark as the loss of the floppy.
Yeah, but you're probably a nerd. I was working in a university computer lab at the time and people were always bringing in their (usually infected or damaged) floppies so they could print out an assignment or whatever. I was very happy about the decision but it freaked a lot of people out.
I built the framework so developers can take advantage of the benefits of modern frameworks (templating, data binding, state management, no explicit DOM manipulations, automated unit testing, loosely coupled modular components, etc) but without the typical drawbacks of modern frameworks. The framework has far fewer abstractions than React or Vue, requires no domain specific language (i.e., you write in plain HTML, CSS and JS), and does not require compiling/transpiling. The framework embraces the DOM instead of abstracting away from it and still refreshes/re-renders components in a highly performant manner via DocumentFragments.
We've used the framework fairly extensively at my work because it plays very nicely with our jQuery-heavy legacy code and allows for much easier re-factors.
The observer library has gained a fair bit of interest from other developers (~600 downloads per week via npm) and it'd be great if I could interest others in trying out the framework too. I'd love to hear feedback from anyone who takes the time to try it out. Other contributors would be fantastic.
The README is more like a reference manual. If you try to learn how the framework works just by reading the README, it'll probably just lead to confusion.
It's not cool anymore but there's little compelling reason to tear it out of existing projects other than a refactor. It still works.
It's always nice to have both feet securely on the ground as you shift your weight from one dependency to another.
I don't feel like writing document.querySelector() all the time and then checking if it really got anything. Aliasing it to $ will break jq upon which some libraries still depend.
One less dependency, network request and more efficient code is always worth the effort.
Oh, and since the new code is vanilla and written in ES6 (it was already but transpiled) you can use modules/tree shaking, even better for performance.