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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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
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.
> 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".
> 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 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.
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.
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;
};
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.
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.
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.
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.
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.
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'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.)
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
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.
> 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.
> 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
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.
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.
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.
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."
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.
This is funny. I was thinking that Bootstrap should be suffering the same fate as jquery. That is, it’s relevance should be decreasing as web technology catches on.
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).
If you actually try to do this yourself, you’ll learn why Bootstrap is popular. You’ll spend plenty of time making everything consistent across browsers, responsive, visually consistent, accessible (a legal requirement for most of us), etc. If you’re working on a big project with a dedicated team, that approach can give you quite a lot but there are a ton of projects which prefer to spend their time on the core product.
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.
I guess it's easier if you do it frequently. I hardly ever touch CSS and for me, cross-browser compatibility is certainly one of the harder things. Bootstrap makes that much easier.
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.
But you have to admit that this takes an inordinate amount of time. Some folks would prefer to have Bootstrap handle the CSS while focusing on the core product.
No, writing CSS is pretty fast and straight forward. I spend far more time wading through ever changing business requirements and adjusting the JavaScript UI to compensate for those changes.
100% agree with you. Especially now that almost all browsers are up to scratch, cross browser isn't a problem anymore. If some of these guys had to work with IE5/6 they would probably quit the industry.
Bootstrap provides an easily customizable (through SASS/LESS variables) base for a web project and the components are very useful. You can even pick/choose components now to keep it more barebones if you wish. It's also very easy to learn.
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.
Bootstrap is still super useful if you need something to look "pretty good", and want to build it fast. It's great for internal tools, protoypes, personal use, or even B2B software that just needs a functional design.
If you're building Facebook, yeah maybe it's not so useful.
Are there any good frameworks of just stylized components? In my experience building Bootstrap / Bulma without their not-grid grids and layout systems breaks all the component styles or makes them act really wonky. Like trying to grid-align or flex-basis a Bulma or Bootstrap btn can get all kinds of weird stuff going on.
Having to write all those components from scratch would be a real pain in the neck, and they'd look very basic. I don't use bootstrap, but I at least use something like bulma so I have a professional-looking starting point.
Have you seen all the CSS for simple stuff like a button and for other handy components? I don't want to write all that just to make a pretty button unless your job is doing only HTML/CSS.
Bootstrap sets a solid foundation for enterprise projects, where there are often many disparate projects, many developers, many deadlines, more concern with function vs. style/brand.
"because that is what they know and don’t bother picking up the new standards"
That's just an unnecessary comment and plain wrong.
Well, if you want to build something that has animations and feels like a native app (e.g. PWA), you will probably skip bootstrap (and take something like framework7 [1]). But if you just want to build a plain old server rendered website bootstrap is still very useful as a reliable default theme for your HTML documents.
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).
Indeed. Some years ago I was working on a project where I decided one day to rip Bootstrap out and reimplement everything that Bootstrap did with my own CSS. In the end I ended up pretty much just recreating Bootstrap, and after a few months it had become an unmaintainable mess.
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.
Neither was `document.querySelector` or `Element.prototype.closest` a few years back. It didn’t stop people from abandoning jquery in favor of the native APIs and just polyfilling the browers that were lacking the support.
Its only a matter of time before people realise their time is valuable and there is pushback against the frenzied cult of complexity driven by resume builders, framework builders and job seekers always looking for an opportunity to promote their latest projects and run everything else down.
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.
> 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.
Its not just the bandwidth spent its the extra complexity of the code base. Every framework you add is an extra thing that devs have to know and in the future there will be less and less people who know jquery.
This assumes that nobody will learn "the old stuff" and only focus on the new stuff. I don't think that's how it works, otherwise we wouldn't see PHP in the wild anymore. Or anything else that's more than five years old.
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.
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.
Well, the snippet you posted is a sensible immediate step before any dependency replacement.
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.
Yes...What were you expecting then to do? Usually you replace code if you're dropping a dependency. It's one less network request, saves bandwidth and removes obsolete and pretty much unmaintained code (at this point, the jQuery github is as good as dead, unlikely to see major releases any time soon).
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.
I don't agree, software needs to evolve as its dependencies does. In this case we have fetch, async/await, promises and loads more native features that jQuery hasn't adapted to (XHR is obsolete now for example).
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 and loads more native features that jQuery hasn't adapted to
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.
jQuery was nice in that everyone used it for a long time, it was required during browser inconsistencies and no transpiling. This made systems common for devs, and systems/skills were more transferrable without worry about browser testing hell.
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.
Is SelectorEngine sizzle directly? I'm not sure how practical replacing jQuery is, and not going to look that deep. But jQuery isn't nearly as big today since most browsers (even IE11) are pretty modern.
Darn, that's what you get from typing on mobile. Ment to use querySelectorAll originally. But apart from null handling (which can be solved using `|| []`), what else would be lacking? I used a similar version of this for a few projects a while back, with some additional stuff for query context and ID selector -> getElementById I think, but that's basically it...
This is great!
This will make bootstrap more attractive and competitive as a framework.
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)
It does. The fetch response object exposes a `ReadableStream` through the `body` property, which you can loop through with a `for await ... of` loop. On each iteration, simply update your progress.
Yep, that’s a cute hack. Now what would be the equivalent of that for file upload? There’s no such API for fetch() because there’s no writeable body stream for requests. QED
This is a hack that works only for downloads via streams. It won’t work e.g. for file uploads (unless you read the file into memory first, which is highly undesirable).
fetch is very bleh, so that's not a high bar. What I'd love to see is more Observable-based offerings in that space... RxJS has some rudimentary client, but seeing that pushed further would be great.
You should look at `for await ... of`[1]. You can get a streaming reader from a `fetch` response and loop if through an async iterator. If you prefer the functional syntax observables, I'm sure you can find a library that wraps async iterators as observables.
It's not to get a stream so much as it is to get automatic aborts in mergeMaps and such. Amazing for things like auto-complete from an API as you type.
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.
Too bad html without styling still looks terrible and differently terrible in every browser. My company uses bootstrap heavily and we’ve never used the grid. Bootstrap gives you a great basis on which to build an interface that has all the little details taken care of, and it’s very easy to skin. I’ve worked on projects where people made their own ui component kits to be cool, and they ended up having a lot of holes and incomplete parts. So much work could have been saved by skinning bootstrap.
Note: you can substitute any well done component framework for bootstrap in the above statement.
Well I just checked to see if I missed anything with it and I didn't. The utilities and components are the same as I remember them being.
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.
I think the reason is that many of the problems JQuery was designed to solve (DOM manipulation, cross-browser compatibility issues, AJAX, cool effects) have now been implemented as standards, either in Javascript or CSS and many developers consider the 55k minified download not worth it.
The general argument now is that 95%+ of jQuery is now native in browsers (with arguably the remaining 5% being odd overly backward compatible quirks worth ignoring), so adding a JS dependency for them is "silly" and/or a waste of bandwidth.
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.
I think jQuery is a good option if you're making "rich applications"; that is, normal HTML pages with some JavaScript for better UX. For many applications this is still a good approach.
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.
I believe Vue.js is much better option for this use case (just enhancing UX on an existing HTML page), and is similar in size while giving you much more flexibility.
I only looked at VueJS for about an hour, but it's my impression that Vue.js is much more of an application framework for SPAs than "rich HTML"? Quickly looking at the "getting started" guide doesn't give me the impression that it will work well if JavaScript is disabled?
What I want is just intercept some (but not all) form submissions and load the results via AJAX, and such.
You can just use DOM templates with Vue.js. Basically write your HTML the way you normally would and add the Vue.js attributes that tells Vue what to bind with. If JavaScript is disabled you just have plain HTML. It does scale up to doing a full SPA with single file components and compiled templates with Webpack.
jQuery is fine for spicing up a blog or something with really basic JavaScript functionality (e.g. a carousel, basic 'contact' form with validation/AJAX).
Anything more 'rich' gets confusing very, very quickly and with how accessible Vue/React/Angular are it doesn't make sense to use jQuery.
Not a total expert, but as a fan of JQuery I've read the arguments.
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.
I think you may be confusing Shadow DOM with Virtual DOM. Shadow DOM is more about encapsulation and isolation of independent DOMs, while Virtual DOM is about keeping an in memory representation of the DOM to allow for more efficient rendering. Shadow DOM is a browser API whereas Virtual DOM is implemented in frameworks.
You’re confusing the shadow DOM with the virtual DOM and if you benchmark it, the only way the virtual DOM is faster is if you’re doing a bunch of horribly inefficient interactions. I usually find the DOM to be faster by several orders of magnitude because ultimately the real DOM has to be updated so any overhead is going to be on top of the same work.
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.
Agreed. I've seen otherwise great developers overlooked by recruiters just because they haven't been practicing RDD.
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.
I think it's generally considered good when you can eliminate a dependency's reliance on another dependency to function. There's nothing inherently wrong with jQuery. If the functionality and size match your needs, there shouldn't be any problem.
My sense is that jQuery and early web front-end approaches reflect how designers think. They were created by designers who understood code for other designers who didn’t so that designers could play a role in the web. Sites wanted to be unique.
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.
Long-ish time ago I tried to modularize and modernize Bootstrap [0] to be easier to use with the (still) current way of development and needless to say it was hard, very hard. In the meantime challengers like Bulma, Semantic UI and Material and Material UI have risen to challenge, with the added benefit of being written at least partly from scratch (again).
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!
material-ui is hands-down the most fantastic UI library I have used (both in company and out). They provide a solid base set of features, balance convention over configuration well, docs are excellent, and the styling/themes are a nice thing to build on. I do wish the third-party themes would grow as large as bootstrap did though.
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.
And that's why it's called Bootstrap. If only more people understood why that matters. You're moving forward with the application while they're wasting time trying to reinvent a wheel, a wheel that has little to do with getting an MVP in front of your audience.
> 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?
We've had great success with the bootstrap-native fork (same css, different vanilla javascript). It's super lightweight, fast and the css is just as customizable (since it's unchanged from normal bootstrap). I look forward to getting something similar in the mainline :)
I build very simple websites, I'm using a tiny bootstrap subset that's sufficient for what I do. My css files average around 400-1100 bytes of unminified css.
cannot speak for GP, but often when I did use bootstrap, I'd have sass configured in webpack, and bring in the bits I wanted (prefixing my overrides). Usually copy/paste the variable.scss directly into my project, as well as the full list of modules, commenting out the ones I wasn't using.
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.
I use bootstrap, sometimes v3 sometimes v4 depending on the project. I don't use any of the layout aids, but I enjoy its default styling of HTML elements. Which is also why this PR doesn't concern me because I don't use the JS parts of Bootstrap.
I was looking at the milligram site and it looked oddly familiar. Seems http://getskeleton.com/ uses the same layout for their main page demoing the framework.
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.