Hacker News Reader

Comment by arp242 | Hacker News Reader

This PR is massive and represents a year and a half of work. If you look at the comments you see there are loads of browser-specific issues being fixed. IE support was dropped as they didn't feel making stuff compatible (jQuery did that for them before).

The API is also incompatible; in the words of one dev: "we broke everything".

As one of the commenters pointed out, a lot of stuff was copied from jQuery to make it work.

In other words, this entire effort seems of dubious benefit to me. Whereas before it was "jQuery for EVERYTHING", now it seems to be the reverse: "remove jQuery from EVERYTHING", which is equally silly. jQuery does a lot of useful stuff, and al things considered remains a pretty neat project. It shouldn't be used for everything, but spending loads of time in removing it just because it's no longer the kwel fr4m3wr0k of teh week just seems like a waste of effort.

View on HN

jQuery _did_ lots of useful stuff. It's unmaintained, has no interest/support (look at their github), doesn't adapt to modern features, is 'slow' compared to other frameworks that now use the Shadow Dom, and can be replaced with features that are native to JS - what's there not to like about that?

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.

But this isn't replaced with a new framework that uses the shadow DOM, it uses the same techniques as jQuery, except without jQuery.

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.

in the world of web performance and SEO 85kb is very significant. i wouldnt think twice to remove it if i had the opportunity. compared to modern frameworks, jquery is ~500% larger. you could definitely debate the usage and needs but thats a separate topic than efficiency.

Uh, at least in terms of react a bit of quick googling saw people who were putting effort into optimizing react's client side size getting it down to ~40 - 90 kB, so it seems pretty comparable. Some of these folks had a 1.2 MB script bundle they were sending to the client to begin with.

I'm not in the trenches with this stuff though so my numbers may be wrong but... the ~500% number seems pretty off.

https://gist.github.com/Restuta/cda69e50a853aa64912d react is 31kb vue is 20kb preact is 4kb. depends on the framework but 500% isnt far off

The standard download of Vue.js is 95k; React is 120k.

I have no idea where you got your "500%" from, but it seems wildly off-mark.

https://gist.github.com/Restuta/cda69e50a853aa64912d

react is 31kb vue is 20kb preact is 4kb

JQuery Minified and GZipped is also 30KB: https://mathiasbynens.be/demo/jquery-size

When doing comparisons, don't be disingenuous. Compare like numbers.

Plus Vue.js 2.6.6 is 91K, not the 63K of 2.0.3 in that comparison.

It's easy to "win" internet arguments like this rolls eyes.

whoops i assumed the 85k was already gzipped. fair enough

These massive compressed JS bundles make me think your numbers are off on the alleged golden age of modern frameworks:

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

Just because others do bad things doesn't make it OK for you to do bad things.

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.

Look, I’ve replaced plenty of jQuery with vanilla JS. I’m totally on board for lighter, leaner pages. My point was simply that there’s this tedious cycle where people crap on the older tools and say everything is better across the board with the current hotness without actually measuring anything. There are a lot of cool capabilities we can use now but they’re only going to be better at the things you actually measure & attempt to improve.

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.

The "cool new stack", in this case, is native, vanilla javascript that works everywhere without downloading anything and without a need to learn someone else's library.

Or, if you actually read the thread you’re replying to, “modern frameworks” where none of that is true.

I wouldn't say it's unmaintained. There have been more issues closed than opened in the last month. I would just say there isn't much interest in it anymore.

JQuery is still maintained. The last pull request was 2 weeks ago. Remember that this is a _mature_ project and as such doesn't need the plethora of pull requests everyday.

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.

> 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

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.

Not only are you recreating it, but your universe of users is smaller. Love it or hate it jQuery is being battle tested day in and day out by __a lot__ of sites and site visitors.

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.

> Personally if you are spending all that time and energy recreating the wheel just to say "you don't use JQuery "

Heavy movie trailer voice Consider a world, where there is no problem that required jQuery.

I refer to React and such.

Jquery will fallback to native functions where available and it's feature complete. It doesn't need to have constant commits to still be immensely useful.

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.

> it's cached by every major CDN already

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.

I wish I could find it, but I read an article a while ago that showed how CDN-cached stuff usually, well, isn't. At the very least it's not something to rely on when making decisions about payload size.

It's cached at the CDN nodes, which means quick delivery to the device.

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.

Have you benchmarked that? Each host you add has its own overhead thanks to DNS, TLS, etc. and every time I’ve done the tests, that cancels out the benefits entirely for a site which itself uses a CDN. I’ve also tended to see numbers for public CDNs which suggest that things aren’t cached as often as you’d like - maybe if it’s a popular project which hasn’t updated in years but otherwise version spread undercuts hit rates dramatically.

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.

Safari shards their cache by first party domain, so you don't get that caching benefit there.

Didn't know that. Looks like Safari is continuing it's devolution into becoming the next IE.

Advertisers have abused every single factor possible for tracking, including ETAGs and many other aspects of cache. Don't blame Safari for protecting it's users from disingenuous and dodgy tracking.

A single stable identifier would've solved the whole situation and Apple already had it with Advertising ID. Exposing that to the browser would've been enough so Safari could've been ahead of the curve.

"Solved the whole situation"? From what perpective? Completely killing privacy is not a solution, quite the opposite.

Advertising ID is Apple's own standard and already in use. It's what mobile apps use but it's the most privacy conscious method since it has no personal details and can be reset at anytime.

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.

> since it has no personal details

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.

That's exactly how the industry works. I've spent more than a decade in it. We're talking about IDs, not tracking other information.

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.

Yeah, all you need to do is include a persistent identifier shared across all sites in the world! In fact, this solution is so great you don’t even need cookies anymore and you never get logged out if you accidentally delete them!

Is this sarcasm? The Advertising ID system is from Apple and in use in all apps, and it can be reset at anytime. It increases privacy, security, and efficiency.

Yeah, it’s efficient alright. Therefore the advertising ID is only accessible to apps that have declared their interest and these have to meet specific requirements. Not just any random website.

I don’t care what you or your industry today decides it ’needs’, you’re not getting a persistent webwide tracking ID.

It's a privacy thing. I expect we'll see Firefox and Chrome sharding cache as well.

jQuery may be outdated from a JS point of view, but nothing beats its syntax. Nothing is as simple and straightforward.

Indeed it's polymorphic overloads ( over 10 on the $() method! ) were commendated in The book 'modular JavaScript' i'm reading right now. Whilst it would be questionable offering quite that many options nowadays on a library method it certainly helped devs get productive quickly and helped it become a such a success

Most of its syntax is now part of JS/DOM natively now. I think that's because of how intuitive it was.

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.

I've been jQuery-less for quite a while now, but honestly I still miss it sometimes. [...document.querySelectorAll()], event binding, and quite a lot of other jQuery stuff is still a bit more verbose, even in the hippest browser environments.

That said, I'm still waiting for a js framework to come around that uses the shadow dom that isn't terrible in some way. Like something with the light-weight unopinionated-ness of jquery, but modern features. I don't want to use whatever paradigm some framework enforces, just let me use the new features, with whatever paradigm I feel like making myself.

Polymer or the more light-weight LitElement.

@sam0x17 If you have the time, take a look at this JS framework I put together ( https://github.com/elliotnb/nimbly ) and it's observer library dependency ( https://github.com/elliotnb/observable-slim ).

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.

This sounds super nice. Checking it out!

@sam0x17 Awesome! The best way to get started is to take a look the basic set of sample components: https://github.com/ElliotNB/nimbly/tree/master/sample

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.

GitHub is a terrible metric. You probably use tools like grep and ls many times a day... you do not check if ls is up to modern standards and has a constant stream of issues and fixes. You don’t do it for grep, or git...you depend on git.

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.

FWIW, git is actively being developed. I see both pull requests and traffic on the git mailing list pretty much every day.

There's no such thing as "done" software. Your view is incompatible with reality, I'm afraid.

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.

Paul Graham said he "finished" writing Hacker News 12 years ago. [0]

This might even be more possible for "simpler" softwares.

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

HN and Arc are still being updated, though, just not by Paul Graham.

So you are like Barney from How I Met Your Mother? “What’s my other other number one rule Ted? New is always better!”

How many times can you update a URL parser or leftpad? Do you need to update them just to up your GitHub activity meter?

Is whatever benefit you see worth the hassle when sharing scripts or setting up servers?

If you mean for exa specifically, then yes. It’s mostly compatible with ls. Never caused problems in years now.

Less dependencies is a wonderful thing but... why not take an approach where alternative tools (like the shadow DOM) are preferred for new features and refactorings, just slowly deprecate it out of existence.

It's always nice to have both feet securely on the ground as you shift your weight from one dependency to another.

> One less dependency, network request and more efficient code is always worth the effort.

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.

How was Apple killing the floppy a slightly risky move? Granted, we have hindsight now, but when they released the first machine without a floppy I had already said good riddance to lame 1.5MB slower than christmas devices. The only thing I miss about floppies are the sounds they made. The heads cycling back and forth and the Mac eject sounds were so distinct. I also do not miss the ADB connections, nor do I miss SCSI. I also do not miss System 7,8,9. Some of the decisions Apple has "forced" upon us have not all been bad. Although, all of those decisions were made when they were a computer company. The forced decisions after have sucked. I'm looking directly at you TouchBar, butterfly keyboard, MacPro Trashcan, AMD GPU only, and loss of MagSafe.

Just curious, what's your opinion on their decision to remove the headphone jack?

That's one of the post Apple Computer decisions that bugs me. I'm a relic and like my headphones with wires attached. My wired cans have this unique feature of not needing to be recharged.

Now you know how everyone else felt when Apple killed the floppy.

I don't follow your logic. When the floppy was killed, there were better replacements available. There were devices just as portable, larger capacity, and faster access. It just plugged into a different port, and came in a different form factor.

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.

You had to buy another device. You couldn't use your collection of data and programs stored on those floppies. Many questioned, "What's wrong with floppies?". And the collection of same questions being mentioned in this thread about earphones.

That’s what people would’ve felt about floppys. I can say I don’t really care about the removal of headphone jack. But I’m not assuming most people feel that way.

> when they released the first machine without a floppy I had already said good riddance to lame 1.5MB slower than christmas devices.

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.

jQuery still does a lot of useful stuff. The best advertisement for jQuery, ironically, is this site: http://youmightnotneedjquery.com/ Look at how simple things are in the left column, and how much more code is needed in the right column.

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.

I agree. I still use it from time to time when initially hacking together a project. It makes my development process faster and easier. I never have problems with it. The primary concern between start and launch is getting to done, not shaving 20kb or 30kb off (if it was 300kb or 500kb that would be a different matter). As I get to roughly 85%-90% done, or sometimes post launch, I'll then allocate time where it makes sense to removing jQuery and pursuing further optimizations. Eliminating jQuery is toward the bottom of the list of reasonable concerns when it comes to making a new product successful. I have more than two decades of experience with JavaScript, and there are numerous things that are simplified to a point of fast, no concern development triviality with jQuery. If it's useful to your development process, use it.

> Look at how simple things are in the left column, and how much more code is needed in the right column.

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.

>>However, to do that, you have to have the entire JQuery library loaded as well.

But you didn't have to write that code or debug it.

Nowadays you'd use fetch anyway which would reduce that code to not much more than the jQuery samples.

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.

I still use jQuery, it still works quite well. IMO it still has a better API for a lot of stuff.

> can be replaced with features that are native to JS - what's there not to like about that?

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 big reason here is actually React. Whether you like it or not, the developer momentum behind React/Vue is massive. And jquery works in weird ways with React/Vue. You can still make it work, but people are choosing to go with other frameworks.

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.

What does jQuery do to play poorly with React that this reimplementation doesn't?

I have used jQuery in a React app without issues. It is no worse than making direct DOM calls.

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.

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

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.

React lifecycle - the virtual dom breaks down when you are manipulating the dom directly. It can still be done, but it's a bit weird.

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.

This sounds like a valid goal as such, but I don't quite follow how this refactor will really make things better? As I understand it, it will still use the same fundamental techniques (modifying the DOM directly), just without using the jQuery API?

220 Comments, I still don't see any one with good enough rational reason for removing jQuery. If you are reimplementing more than a few jQuery stuff to make it work then it shouldn't have been removed in the first place. At least not now.

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.

> As one of the commenters pointed out, a lot of stuff was copied from jQuery to make it work.

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

> As one of the commenters pointed out, a lot of stuff was copied from jQuery to make it work.

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

> 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;
  };

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

This won't filter SVG elements, and unfortunately Array.from isn't available in IE (and perhaps some other browsers that are still in use).

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

Will do the same. Note that `Array.from()` is a relatively new method, that you will need to polyfill if you wish to support internet explorer, but `Array.prototype.slice.call()` serves the same purpose and can be used in older browsers.

> But looping over querySelectorAll() is painful.

Not any more:

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

https://developer.mozilla.org/en-US/docs/Web/API/NodeList/fo...

PS. The other two answers here are outdated.

Or if you prefer:

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

> PS. The other two answers here are outdated.

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.

For that you can write:

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

or more idiomatically (and perhaps a little slower):

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

They asked about looping, not mapping or filtering.

I should have explained the use case better: I need to store an indexed array of elements for cache/querying later on; so forEach() isn't a good fit here.

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.

[...document.querySelectorAll(el)]

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

You seem to be misinformed. IE11 hasn't been dropped, is supported, and is still the only browser shipping with some versions of Windows as of right now.

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

IE will go EOL for the majority of users well before 2025, simply because they're not adding features and the web _will_ break (and is already breaking) as a result.

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.

Windows 7 will be unsupported next year.

Yes. MS still intends to ship their new browser on Windows 7 since it'll be like any other browser you can install...

Minor nitpick but TLS support is separate from IE and is handled by the OS.

And enterprise users will block the update and continue demanding that all of their vendors support IE11 and I will continue smashing my head on the desk finding 10 year old bugs.

Worse still: they’ll force your site into the bizarro world of ersatz IE9 or even IE8 “compatibility” through the auspices of “enterprise mode”. There’s nothing like the unique experience of trying to resolve a problem in your modern app, reported by a user who thinks they’re running IE11, but is actually running a never-was IE8 — because the last known developer of some indecipherable ActiveX-festooned internal budgeting app passed away 12 years ago.

I'm not sure security patches to ensure a program is not dangerous to use is quite the same thing as "supported". I mean, yes, it technically is in a sense of the word, but it's not meaningful.

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

> You seem to be misinformed.

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

You misread the post I was responding to. They remarked that because IE itself was "dropped" that new products, including Bootstrap 5 need not support it.

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

I did read that as "Support for IE is being dropped from Bootstrap", not the way you interpreted it.

The OP was def saying IE itself is being dropped. Unless we are talking about a different comment.

IE 11 is not a browser. It is a compatibility solution.

Which makes jQuery a compatibility solution for a compatibility solution.

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

Well, IE has not been receiving feature updates for over a year. It only receives security patches, and these days only critical ones. It is a dead browser; do not use it unless your job forces you to.

A thing I always didn't like of Bootstrap is that it requires you to load a full version of jQuery just to use it. Maybe I don't need the whole jQuery, because I use another framework, or because I have a very simple site that doesn't require any JavaScript at all.

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.

Well, technically, it uses jQuery’s “slim” build which omits some features such as AJAX, but yes. You do have to pull in all of jQuery’s slim build to run it

> A thing I always didn't like of Bootstrap is that it requires you to load a full version of jQuery just to use it.

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.

> practically nobody is using jQuery

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

There are some nice benefits possible. I don't know if bootstrap actually gets rid of this already, but if you want to enable CSP headers on your website, you have to allow eval for jQuery. Enabling a stricter policy would be great.

I tend to agree.

> Whereas before it was "jQuery for EVERYTHING", now it seems to be the reverse: "remove jQuery from EVERYTHING",

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.

Herd thinking.

Magpie developer-ing.

But, really just mediocrity.

> Whereas before it was "jQuery for EVERYTHING", now it seems to be the reverse: "remove jQuery from EVERYTHING", which is equally silly. jQuery does a lot of useful stuff

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.

A lot of things jQuery did can now be done with vanilla javascript so including a non-standard (in a way) code for things that already work in "standard" javascript is what doesn't make sense anymore.

Legacy bootstrap did ship with considerably fat set of dependencies - jQuery, popper, etc. Compare that to Bulma or something more modern, it ships without these dependencies. When the world is moving towards css-in-js and other aggressive ways of trimming unwanted code, removing dependencies is a good move by Bootstrap

Only part of the world is moving to css-in-js.

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

Completely agree - I find the current trend (and that's what I see it as) of css-in-js to be most disagreeable. CSS works fine without JS, or even better with SASS/LESS.

I both love it and hate it. I love it because a lot of the supporters, on the inside, hate it too. They've spent the last decade saying, ya gotta keep 'em separated. Now they have to say no, it is fine to mix 'em. And it's killing them to say it, but they need jobs, so they follow the herd.

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

CSS in JS isn't CSS. It's just SS. It ignores the best part of the language; the cascade.

Or the worst from my point of view. CSS rots more than any other code in a front end codebase and the methods for static analysis are incredibly limited.

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.

> have a compiler enforced link between variables, selectors, and their usages.

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

1) it doesnt ignore it

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

I will swear on my life that I haven't used a style attribute in the last five years. Since I started using BEM for namespacing I have had a very easy time keeping my CSS clean and maintainable. I won't deny others their opinions, though.

BEM is a decent convention for old-school, global document styling, in the absence of scope. But it's also manual, error-prone, and verbose, making it a poor substitute for actual namespacing provided by components. I sympathize with your resistance to css-in-js; I've been doing webdev since 1998 and only really embraced it in the last couple years. I'm reminded of quotes like "The difficulty lies not so much in new ideas, but in escaping the old."

Fair enough. I felt the same way about JSX when it came out so maybe I need to give it another look. :)

I think BEM was the point where I decided to give up and accept CSS in my JS.

The cascade was great for HTML in the absence of scope, which is to say in the age of documents. It's a reasonable approach to dealing with all the problems inherent in managing global state. But globals suck. In the age of components it makes little sense to cling to the cascade as if it were more than a means to an end.

Is CSS Modules considered to be "CSS-in-JS"? It does require JavaScript to import the class names, but the stylesheet itself is static. I personally find it to be a great solution to the scoping problem, and combined with Sass it's very flexible. Even theming is a cinch with a single shared Sass file with theming variables, or CSS custom properties.

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.

I can't answer your question, but after a lot of experimenting and reading I ended up with styled-components as my preferred solution if I were to go the SPA way.

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.

Jquery is dead (RIP). Moving away from it is a necessary act to keep a project alive, even if they copied 50% of it into Bootstrap (I’m guessing the real number is much lower) to do so. Over time the remnants will decay away as well.

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.

Reply on news.ycombinator.com