Bootstrap 5 will remove jQuery as a dependency
github.com
github.com
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
I don’t care what you or your industry today decides it ’needs’, you’re not getting a persistent webwide tracking ID.
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 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.
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.
This might even be more possible for "simpler" softwares.
How many times can you update a URL parser or leftpad? Do you need to update them just to up your GitHub activity meter?
It's always nice to have both feet securely on the ground as you shift your weight from one dependency to another.
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.
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.
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.
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.
> 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;
}; return Array.from(document.querySelectorAll(q)); let queryAll = (q: string): HTMLElement[] => {
let nodes = document.querySelectorAll(q);
return Array.from(nodes).filter(node => (node instanceof HTMLElement)) as HTMLElement[];
}
Not any more:
let elements = document.querySelectorAll('.some-class')
elements.forEach(function(element){
...
})
PS. The other two answers here are outdated.
for (const element of document.querySelectorAll('.some-class')) {
// ...
}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);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.
"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.
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
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.
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.
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.
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.
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.
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.
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.
I see no reason for using a third party layout system now that CSS has `display: flex;` and `display: grid;`. As for modals and menus, HTML has `<dialog>` and `<details>`. And for reusable components, we have custom elements, that you can either implement your self (not that hard) or pull from a library (using javascript modules).
Really the only reason I see anyone using CSS frameworks like bootstrap is for quick prototyping or because that is what they know and don’t bother picking up the new standards (which is ironically where jquery was a few years ago).
All the utility classes are useful too.
Why waste time creating all those components manually?
Also as you say it's still great for prototyping and internal applications that don't need bespoke styles.
It’s just nice clean flexible sass to start from.
I prefer a 24 col grid as well which takes about 4 lines of sass.
If you're building Facebook, yeah maybe it's not so useful.
My reason for using bootstrap is that it looks better than any UI I design from scratch.
If your application has many basic views, you'll be wasting time writing out CSS grid properties for a basic responsive layout.
I mean, at some point you'll recognize you're reinventing the wheel and just pull in a CSS grid from a framework.
This applies to basically any components that has been battle tested in Bootstrap.
I'm not saying that everyone should use Bootstrap, or even CSS frameworks in general, but this idea that we should avoid them because don't 100% require them is madness. The simple reality is that they save a hell of a lot of time that can then be invested in things that'll have a more material improvement for the end user.
The layout support in Bootstrap is nice, but the baseline design language is more important
"because that is what they know and don’t bother picking up the new standards"
That's just an unnecessary comment and plain wrong.
That’s a legitimate decision responding to their environment – you might disagree because you have different goals and resource levels but it’s wortb understanding why not everyone makes the same call.
I do frequently. There are many things in life that are hard and cross-browser CSS is not among them.
In the past I have found things like Bootstrap and jQuery to be more of a frustration than a benefit by introducing cross-browser differences in their attempt to help. At the same time they don't fix the cross browser differences that really impact layout, such as differences in font rendering.
And jquery support often isn't necessary at the moment. It's required for some functionality, but many simpler web pages will work with a slim version of the CSS without any JS. Makes it very light-weight and still easy to set up.
Nevertheless, recently I tried spectre.css [2] and liked it a lot better than bootstrap as it doesn't feel so heavy (don't know how it performs in terms of browser compatibility).
jQuery remains as useful as ever and the constant sniping here is a dead giveaway of a faddish mindset of not just making one's own choice but trying to force it on others.
Fortunately for those who do not have hours and weeks of time navigating NPM dependency wildlands, jQuery represents a quick and efficient escape. If Vue or React offer better efficiency or simpler use, users will migrate swiftly but given the current state of affairs that seems unlikely, so they can coexist serving different use cases.
The idea that React or Vue can or should replace jQuery is more wishful than real given 90% of jQuery use cases are for websites and ajax calls that would not benefit from the massive overhead of a shadow dom and NPM workflow.
90% of what people used jquery for now is built in to browsers by default. Every dependency removed from your website is a win.
Sorry that this rant is hitting you, it's nothing personal, but this is somewhat a distraction.
Deliver the slim version from your own host and with an existing HTTP connection and it's just 70 KB without compressed transfer. That's very little, even on mobile.
People are regularly missing to optimize images and will easily transfer 100s of KB in image overhead on their sites, but they cry out for jQuery?
Or throw in a bunch of analytics stuff which gets you set back a significant amount of time and connections...
Really: Using jQuery is one of the smallest problems of modern web development.
On the other hand, people are integrating libraries for ANYTHING in their projects and don't care about that either.
Call me old-fashioned, but PHP + MySQL with HTML, CSS and a handful of jQuery has still brought me everywhere in terms of tech stack. Maybe I'm just doing shitty jobs, I don't know, but it works and the client is happy, so it doesn't look like a problem for me.
... by copying over/rebuilding big chunks of it.
- $(element).closest(`.${ClassName.ALERT}`)[0]
+ SelectorEngine.closest(element, `.${ClassName.ALERT}`)
- $.Event(Event.CLOSE)
+ EventHandler.trigger(element, Event.CLOSE)
- $(element).one( ... )
+ EventHandler.one( ... )
- $(this).data(DATA_KEY)
+ Data.getData(this, DATA_KEY)
DOM APIs are just as pain in all of parts of a dev's body as they were 10, 15, and 25 years ago. Even if you "replace" jQuery, you end up just reimplementing easily a half of it just because it's so brilliant in it's ease of use and convenience.
Seems to be a sensible approach to me. It's like using native code rather than electron, even if you add more lines, I'm pretty sure the performance gains would be worth while.
Given that most stuff these days is packed together with Webpack or at least concat'd together, you don't really save much, plus jQuery in gzip'd form is clocking in at <30 kB anyway (https://mathiasbynens.be/demo/jquery-size).
> and pretty much unmaintained code (at this point, the jQuery github is as good as dead, unlikely to see major releases any time soon)
So what? Software can very well be "done", there is no need to always evolve and evolve. As long as there is no security issue left unsolved, though.
In addition, if you're rebuilding half of it on your own anyway, chances are high you'll miss some weird corner case that jQuery solved years, or decades, ago.
Why include a dependency that the browser provides for free? jQuery was good before ES6/next came along, these days it's extra cruft.
And if what you're saying is true about weird corner cases, people will fix that up in PR's anyway, that's not a reason to stop innovating and just say "meh, jQuery is good enough".
Thank god most software doesn't work your way, we'd probably be stuck in the stone ages still.
Promises work great in Jquery. I've had much success chaining combinations of AJAX and interface events together using Jquery deferred promises.
Jquery is stable and reliable. Use it or don't use it.
A lot of devs tend to think the whole world has an updated web browser like they do. Forgetting that millions of hand-me-down older devices that can't be updated (eg an iPad 3) will NOT load a page properly with ES6 javascript.
Example: the Steam website... this site is now useless to browse on an "old" device like an iPad 3 which Apple considers "vintage" so doesn't give updates. So do we throw the iPad in the trash? We're talking an iPad 3 with retina screen and pretty good performance, but no updates to OS or web browser. In the real world, people are not throwing their iPad3's and older devices in the trash, they're keeping them around house, giving to kids or selling them on ebay, which means people are buying them on ebay and still using them for years and years.
You replace direct usage with indirection (adapter) that still calls jQuery, ensure everything still works, then swap out the indirection's implementation (e.g. with native DOM functions), and ensure everything still works.
The pattern specifically just decouples the callsite from implementation.
`const selectorEngine = selector => Array.from(document.querySelector(selector));`
:)
Now every framework will use a different internal jQuery like custom system, when these pile up high enough another jQuery like library will appear that everyone will use if browsers start fragmenting again. Though with WebAssembly and other technologies maybe less of that will be restrictive enough to need common browser baseline libraries.
jQuery was very required during IE/Firefox/Chrome changes and made a baseplane of support that didn't need to be tested in every browser by every project, devs could just focus on building their webapp. It is a bit similar to a game studio making a custom engine or using a common one like Unity or Unreal, there are pros and cons of both, but the pro is the devs can focus on building a game and not having to worry as much about the engine.
Now that browsers and transpilers exist, that is less of an issue but also leads to many more versions of the same thing, for better or worse.
I just hope that most projects aren't bogged down in extra work and testing recreating jQuery for the thousandths time. That is one problem I see with javascript ecosystem today is that lots more work goes into the tech rather than your app/game/project/product. While it is simplifying in some areas, sometimes it can actually add complexity to your tech stack that is unnecessary and wastes cycles that should be on your product.
JQuery was one of the most important frameworks in Javascript history. It has enabled us to built real webapps. However since then differences between browsers shrunk significantly and we learned how to build maintainable and scalable apps in a more declarative fashion (hello React, Angular and friends)
Good riddance.
[1]:https://tejasq.github.io/basically-streams/examples/fetch/
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://github.com/axios/axios
Much nicer to use than fetch IMHO
JavaScript itself has subsumed most of jQuery and replacements like lodash would not have existed without it.
Browsers will catch up badly.
Bootstrap is going the way of table layouts. Table layouts were great too but times change. Right now we have CSS Grid and it works in all browsers. I am sure they will bring this goodness to Bootstrap 5 but there is no need for the new layout engine that works great in all useful browsers to have a framework wrapper.
Similarly with the jQuery, it was once useful in a table layout kind of way but nowadays you might as well just write ES6 javascript rather than learn how to do things the special jQuery way. Frameworks are dead in a similar way to how the internal combustion engine is.
Using the intrinsic properties of the browser is where it is at in the same way that electric is where it is at in the automotive world. The fact that everyone is stuck with their excuses for frameworks (and ICE engines) does not change matters. Hence I read this news with all the enthusiasm of a Tesla owner reading about Peugeot developing a more efficient diesel engine.
Which is irrelevant, as Bootstrap is much more than a grid system.
Not to mention it's not meant for the types to mess with their own custom grid layout anyway.
I was the biggest fan of Bootstrap ever about five or more years ago, a total evangelist. But it seems to be just another flavour of div soup really. I have moved on.
Even things like cool scrollspy things aren't worth the bloat or the learning requirement. I also prefer to learn real things rather than fake framework things. Now the tools are needed in modern browsers you might as well do it properly and learn something useful rather than follow some convenient hacks. It is quicker.
Note: you can substitute any well done component framework for bootstrap in the above statement.
Globally support seems to be at around 85%-87% [1], all browsers is misleading.
JQuery modifies the DOM at runtime, this means lots of node traversals and redrawings on the fly, which make it nearly impossible for the Javascript engine to optimize anything.
More modern frameworks in general use the concept of a Shadow DOM: they keep their own representation of the DOM internally and only send the full frame to the engine for rendering. It seems to be extremely more efficient and flexible.
That’s not saying don’t use a virtual DOM but pick it knowing that you’re taking on a moderate degree of inefficiency in exchange for a better coding experience, consistent structure, etc.
Obviously, if jQuery is still your jam in 2019, that's your decision and no one is going to force you to stop using it. The approach Bootstrap is taking is interestingly backwards compatible in that the updated plugins will still register their previous jQuery APIs, even if their actual implementations will now be "vanilla" JS directly against the modern browser APIs.
If you're making an SPA, then jQuery is a bad choice for many reasons. jQuery is just a DOM wrapper, and doesn't give you any application structure, which tends to lead to pretty messy applications.
What I want is just intercept some (but not all) form submissions and load the results via AJAX, and such.
Here's a simple form example:
Anything more 'rich' gets confusing very, very quickly and with how accessible Vue/React/Angular are it doesn't make sense to use jQuery.
Thankfully there are still places that will see past that. Still, the idea of "keeping up" does need to factor in, and the experience could serve as a wake up call to where the industry is headed.
New frameworks reflect how developers think. Sites want to work more than they want to look unique. In many cases, uniqueness is viewed as driving up training or onboarding cost.
At least nobody mentioned Classic ASP.
I still think that Bootstrap has it's uses, but incremental updates at this point seem to be harder than rebooting the whole thing writing everything from scratch, maybe even using things like CSS Grid and friends in the background. All the best to the current maintainers in their pretty hard task!
I love bootstrap. I know it's not as cool these days, but it still lets me put together a passable (albeit generic) UI quickly, to present whatever it is I'm actually trying to do to the user in a way they will recognise.
I don't want to spend my time building all of that myself, of learning a UI framework, I want to spend it building functionality, and then using Bootstrap (which I know like the back of my hand at this point) to present the functionality.
> I noticed how almost every kind of military strategy, from air force dogfights to large scale naval maneuvers, is based on the idea of Fire and Motion. It took me another fifteen years to realize that the principle of Fire and Motion is how you get things done in life. You have to move forward a little bit, every day. It doesn’t matter if your code is lame and buggy and nobody wants it. If you are moving forward, writing code and fixing bugs constantly, time is on your side. Watch out when your competition fires at you. Do they just want to force you to keep busy reacting to their volleys, so you can’t move forward?
Still as relevant as ever.
If yes, what version?
If not, why not? Which alternative do you use?
Alternatively using Material through vuetify in other projects too.
All of the modules are tiny and easy (even for me) to understand.
https://themeforest.net/item/kleo-pro-community-focused-mult...
Looking around the theme marketplace, it looks like most WordPress themes are still on Bootstrap 3 too. They haven't even upgraded to 3.4 which contains security fixes.
If I need something quick/dirty, I'll pull in jquery and bootstrap via cdnjs and roll with it.
Like the $.getJSON jQuery code seems much compact compare to IE8+ to IE10+.
I'm quite happy with my newest site (https://ziglang.org/), which has a dependency on... nothing! With cache off, 54.36 KB / 50.08 KB transferred. Cache on: 54.36 KB / 0 B transferred. No JavaScript.
jQuery is mature and API are solid compared to other frameworks, where you cannot build projects again after just 1 week
Then there's always: https://github.com/thednp/bootstrap.native/
(which I've not used), but appears to remove jQuery as a dependency
I hope they wont do the same mistake again.
If you want faster releases then feel free to submit PRs :)
Bootstrap is a _framework_, not just a layout system.
Also, BS uses Flexbox at the moment, I doubt they'll go to grid any time soon.
[1]: https://html.spec.whatwg.org/multipage/interactive-elements....
(Personally, I'd rather they just build it in Lazarus, but people have forgotten about building desktop apps.)
(Which btw is mentally a lot easier than the odd CSS grid syntax)