Bootstrap no longer depends on jQuery and we’ve dropped support for Internet Explorer.
On a related note, I feel like I'm officially becoming an old fogy because I learned web development with jQuery but never did enough to experience the pains it brings that newer frameworks do away with, and as such I still feel drawn to using jQuery, especially when I want to throw together a smaller websites.
Do the maths - if the file size isn't a problem then go for it. Life's too short to be the victim of fashion.
Given appropriate element names and classes, jQuery and CSS selectors can provide a straightforward and readable way to express application behaviours, and it's a well-proven and stable project at this point.
* veteran of the original browser wars
Things have really gotten much better in the vanilla world. Although some things remain more verbose or cumbersome than jQuery alternatives, you really don't need a whole layer of abstraction to handle the simple tasks jQuery was designed for any more.
Unless, of course, you care about IE...
"I did my last small project with vanilla js and the ugliness of the native APIs reminded my how lovely jQuery is" or am I seeing wonky here
With that said, I do use the modern vanilla js api from time to time. It's gotten better. There are still some things that aren't great, but it's fine. I use it a lot when working in puppeteer actually.
But back to jQUery. If I need to add some interactivity to a site and I know some jQuery plugins. I just use that. I did it for an entire MVP just recently. I know if it takes off all that frontend work I did will be replaced. Great, jQuery (but mostly just plain old school web dev) got me there without the need for an over-engineered tooling ecosystem. I've watched people struggle with slick new shit on MVPs before. I'm already iterating on my product and testing new hypothesis.
If you are more comfortable with the newer stuff then you should use that. If you are more comfortable with jQuery you should use that. If the product you are developing specifically needs or doesn't need one, then go with what the product needs.
Edit: Also this about BootStrap. I love it, also makes my life easy for MVPs and backends. Keep going strong bootstrap!
Even if I'm aware of the latter, I refuse to use it when former is available just for the sake of being "PureJS trendy".
However, the number of websites where a full-blown library like React is the right tech stack is probably less than 5%. For everyone else you would want to use vanilla JS, though if you are already familiar with jQuery I don't think there is anything wrong with using it.
The funny thing is I spent years using jQuery and have also used Vue.js, but I'm just so tired have having to deal with importing libraries, setting up build systems, etc. that 9 times out of 10 I will just use vanilla HTML/CSS/JS and call it a day. It is just so much simpler. YMMV
For a normal/small website, there is no need for a framework like that which adds unneeded complexity.
The developer ergonomics, and the mental models which it prescribes - which are why I’d argue it’s actually a framework and not just a library, but that’s semantics - are really well thought out and can make you very productive.
If I want to build a static site with minimal fuss I might still use something like HTML, Sass and vanilla JS with Parcel. For pretty much everything else React has become a default.
Throwing together an API in .NET Core and a website consuming that API in React takes less than 5 minutes to get going.
Think making use of html `canvas`. Though there are nice libraries that abstract the ugliness like react-canvas, it would lead to less reusable code than the jQuery equivalent, imo.
There's one use case that might remain: the jquery plugins ecosystem. You can find many replacements on npm, but they're a bit less beginner-friendly.
I'd use React on every project if I could run it like a Rails front-end instead of needing to write distinct server and client side applications.
> This page explains what the reactive pattern is and what Observables and observers are (and how observers subscribe to Observables). Other pages show how you use the variety of Observable operators to link Observables together and change their behaviors.
I'm not familiar with React so I'm not sure how all these concepts are implemented in React.
I don't think it makes sense to use React and friends unless you are building Single Page Applications.
I'd be hesitant to refer to jQuery as a framework, as I don't think it fills the same void as what we commonly think of as a "javascript framework" does; it was more a utility for querying and mutating the DOM. It doesn't provide answers for questions like "how do I handle state?" or "how do I convert state into DOM?", although it does give you some tools to answer those questions yourself.
But also, since Bootstrap, a lot of competition in that space has popped up, and there's less of a need to buy in to everything that Bootstrap comes with, or any particular frontend library for that matter.
These days, I don't know if I would use Bootstrap again unless there were parts I wanted to harvest from it.
With that said, there's a lot to like in Bootstrap 5 to quickly throw together a site.
Where I work, we sell into large companies, where IE may be a default browser without the ability to install an alternative. Therefore, we support IE11 (only version of IE still officially supported). Financially, it would be irresponsible not to, as it could kill 6 or 7 figure contracts if the CEO tries to use our software and it doesn't load or just shows them a "upgrade your browser" page.
But even then, we do make allowances for IE. It is slower. In fact, some of the speed issues come from adding polyfills for things we deemed necessary for efficient development. It may not have exactly the same layout (for instance, we use an accordion to reduce the number of elements on a screen for IE on one page, but a list of carousels in browsers that are capable of handling the extra complexity).
We actually attempted to use CSS Grid, and it mostly worked. We've since stripped most of that out except some of the base page structures - just too many edge cases. And flex actually works fairly well as long as you stay away from some of the well-defined known issues.
Anyways, to the main point - has to be a site by site decision based on your site's visitor base, their browsers, and whether it makes the financial sense to spend the time supporting IE compared to the return you may get.
So, yes similar story. IE11 needs to _work_, though maybe not as well. Though, I generally avoid polyfills (even jQuery) and try to just write code works natively in IE11.
I have a feeling IE11 will be around a while.
My current employer has dropped IE11 for new projects, but we keep it around for already extant products and pages, unless we do a full redesign and rethink. IE11 is such a small percentage these days that the cost/benefit ratio isn’t good.
(I only prototype stuff as a designer, so I am just throwing caution to the wind and doing whatever the Big 3 rendering engines support, because the idea of giving up grid makes me sad, now that I understand how it works. [sort of understand how it works])
Which is to say, a lot of your potential customers already probably have a dozen tools they depend on that don't work in IE already anyways.
IE is still a thing in the enterprise and a lot of enterprise web apps are built on bootstrap. I totally understand their motivations but until IE is dead I wish they'd kept support. Based on the planned EOL this leads me to believe that they don't expect BS 5 to pick up steam in corporate environments until later next year.