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.

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.

[0] https://twitter.com/paulg/status/1049723540902215681

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.

so the removal is not really a "remove jquery" thing - but more of "make sure the framework javascript doesnt screw up react".

For example, look at some of the earliest comments there - https://github.com/twbs/bootstrap/pull/23586

>If you are interested in Vanilla JS versions of tooltip, popover, and scrollspy, We have versions that we use in [Bootstrap-Vue v1.0.0.beta.7](https://github.com/bootstrap-vue/bootstrap-vue) (see in action at [docs](https://bootstrap-vue.js.org/))*

> Boostrap-Vue is quite interested in the jQuery free version of some of the plugins, as we might be able to direclty import some of these modues (or the classes), to replace some of our code.*

> Any chance this can be implemented as custom elements, this way everything would be nicely compatible with all component frameworks.

Incidentally one of the most interesting react apps that plays super nice with jQuery is the new WordPress editor. I have nothing but respect at how they made it work with the tons of bad js code out there.

React is great for rendering, but you can’t implement direct-manipulation on top of virtual DOM. Direct-manipulation means interactively resizing, drag & drop and so on. To implement this you need to know the position and size of real DOM elements. There is no "React way" to query the position and size of elements, so interactivity has to be implemented the old-school way, by interacting with real DOM. You can call native DOM methods to do this, but jQuery makes it easy. There are lots of shortcuts in jQuery. You can certainly do it without jQuery too, but unless reducing download size by around 85KB is very important to you, there is no reason you shouldn’t take advantage of the ease-of-use of jQuery.

Keep in mind that once you manipulate DOM directly (using jQuery or not) React can’t update those elements. For more on this look up "Integrating with Other Libraries" in React documentation.

I have helped build an interactive timeline web app where we explicitly placed elements on the page and moved them around based on user interactions. We did this with react and no jquery.

>React is great for rendering, but you can’t implement direct-manipulation on top of virtual DOM. Direct-manipulation means interactively resizing, drag & drop and so on.

There are react "drag and drop" libraries that have no dependency on jquery and don't break the react lifecycle for the elements. For example https://github.com/react-dnd/react-dnd

Maybe i'm not following what you are saying but I haven't encountered something that required me to use jquery and I've built some pretty ambitious interfaces.

And now they are dropping IE support, jQuery, which defeat the purpose of these framework in the first place, making it work across multiple browsers.

"a lot" is an important clarification there, though. If they copied 99% of jQuery over then yes, it's a total waste of time. But 5%? 10%? That's a meaningful reduction in download size.

> In other words, this entire effort seems of dubious benefit to me.

You made other points, but I wanted to focus on this one. Yes, there's a few remaining bits that don't have standards. But you can do so much with querySelector, classlist.toggle(), lastElementChild, scrollIntoView, insertAdjacentHTML - literally every JavaScript answer on SO is now "2016: all current browsers now support X".

Yeah, I'm sure they had to patch in a lot, but I'm also sure they didn't have to recreate everything.

Side benefit: also no weird $(thing)[0] when you need to use a DOM API, like HTML5 validity or whatever.

But looping over querySelectorAll() is painful. I'm not really a frontend dev, so perhaps I'm doing it wrong, but this is the "easier" way I found when I was writing an app a few weeks ago (in TypeScript):

  // Get Array of HTMLElements from querySelectorAll().
  let queryAll = (q: string): HTMLElement[] => {
    let nodes = document.querySelectorAll(q);

    let arr: HTMLElement[] = [];
    arr.length = nodes.length;

    for (let i = 0; i < nodes.length; i++) {
      if (!(nodes[i] instanceof HTMLElement)) {
        arr.length--;
        continue;
      }

      arr[i] = nodes[i] as HTMLElement;
    }

    return arr;
  };

Not any more:

    let elements = document.querySelectorAll('.some-class')
    elements.forEach(function(element){
      ...
    })

PS. The other two answers here are outdated.

Other people suggested Array.from(), but that won't work in IE, and the polyfill for it is a lot longer/more complex than the for loop I wrote.

Sure, the other two answers may be "outdated" but they're still extremely useful if you're looking to calling map/filter/etc against your queried elements.

    const elements = document.querySelectorAll('.some-class');
    const values = Array.prototype.map.call(elements, element => element.value);

    const elements = [...document.querySelectorAll('.some-class')];
    const values = elements.map(element => element.value);

    for (const element of document.querySelectorAll('.some-class')) {
      // ...
    }

  let queryAll = (q: string): HTMLElement[] => {
    let nodes = document.querySelectorAll(q);
    return Array.from(nodes).filter(node => (node instanceof HTMLElement)) as HTMLElement[];
  }

    return Array.from(document.querySelectorAll(q));

Older versions of IE have been dropped. And Edge is still their recommending browsing experience and the only one likely to receive enhancements (both will continue to receive security fixes).

Key Dates:

- Internet Explorer 9: EOL January 12, 2016

- Internet Explorer 10: EOL January 31, 2020

- Internet Explorer 11: EOL Unknown/Unannounced

IE11's EOL date is currently unknown. It would be at minimum 2025 based on Windows 10's current extended support date (but each Windows 10 feature release with IE11 pushes that date back).

Imagine TLS 1.4, or some other change that will occur that will completely break IE11.

Instead, Microsoft will ship Edge with Chromium (even on Windows 7) and say "use that instead" and will eventually remove IE altogether.

The PR specifically says "* Remove IE (but not Edge)" and to update docs containing IE references.

> IE itself is being "dropped" as well, so long term support commitment for new products does not make sense.

Also if you need to support IE you're probably not in the position of converting your application to BootStrap v5.

Microsoft is telling everyone to not use IE11. They are not adding features to IE11, or fixing (non-security) bugs. While it is the only browser shipped with LTSB, Microsoft's position is that no one should be using LTSB on general-purpose machines anyway. (Mind you, LTSB works and is wonderful, but Microsoft would prefer you don't know that.)

The thing is that when Bootstrap first launched everyone was using jQuery, so it was a de facto standard, everyone already had it, so requiring it as a dependency was not an issue at all, now we are moving towards different web technologies and practically nobody is using jQuery, and having to load it just a dependency to Bootstrap is not good, considering that it will slow down the loading of the page and consume traffic for mobile users.

You can just use the CSS and ignore the JavaScript parts, or write your own JS to build the CSS, which is what I did (twice, at the different jobs).

I never liked the Bootstrap JavaScript for a host of reasons. Unfortunately this incompatible rewrite fixes exactly nothing of that.

Well, yeah, no: https://trends.builtwith.com/javascript/jQuery

Reminds me of "replace ALL tables with divs" in the mid 2000s. I actually saw developers spending inordinate amounts of time using divs and css to display tabular data across browsers (which back then meant the one you used: Firefox, and the one everyone else used: IE6).

I'm not sure what causes this black and white thinking. I guess it's laziness. It's easy to spot the word jquery and say "bad". It's more difficult to consider each case independently.

Magpie developer-ing.

But, really just mediocrity.

In Bootstrap, it really does very few things. It was an error to begin with to bring the whole jQuery just to do few floating menus.

I won't be on the boat leaving for that destination.

But, yeah, other than that, it's a stupid idea.

Refactoring and static analysis tools are incredibly limited or nonexistent for plain CSS or SCSS (when talking about the barriers between HTML and the stylesheet).

We do all of our new views and stylesheets using React, TypeScript, and Typestyle. As a result we can expose much controlled methods of theming and have a compiler enforced link between variables, selectors, and their usages. We can refactor easily. We can catch simple typos at compile time instead of runtime, and validate them more easily in CI.

That sounds interesting. Can you describe that in more detail?

2) anyone claiming not to have a single `style=""` attribute (which is almost as specific and 1000x less maintainable) in their code is lying

Every CSS-in-JS library I've tried makes everything way too cumbersome with no real upside. I especially hate how they all spread my style declarations all over the place.

It allows you to write your CSS inside the backtick js strings (template literals?) and then inserts/removes the relevant CSS as components are loaded/unloaded.

Personally I've gone in an entirely different direction (server-side everything, and simply diffing the HTML on the client when necessary), but if I were to build a proper front-end app, I'd probably go for styled-components.

The main downside is that the stuff needed to parse the css-in-js-string is yet another thing that increases payload size, but for an app it's not too bad.

Your argument is like saying Chevy never should have abandoned the carburetor because the effort was not worth the efficiency gain of first generation fuel injectors.