3 ms·
There is more to it than "wanting to learn". You can peruse Can I Use https://caniuse.com/#search=fetch https://caniuse.com/#search=fetch to evaluate if the AP
by goto11 7y ago
There is more to it than "wanting to learn".
You can peruse Can I Use https://caniuse.com/#search=fetch https://caniuse.com/#search=fetch to evaluate if the API is widely enough supported to be viable. Then you have to figure out which bugs and incompatibilities exist across browsers.
If you look at http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ you will notice that the native approach is at best similar to jQuery, but in many cases more cumbersome and verbose.
30kb is completely insignificant.
Using jQuery is just easier and less risk.
- davidweatherall 7y agoA fetch polyfill can be added to a project for ~500 bytes[1] vs jQuery which is ~30kB [2] - or if you were to import just the ajax element from jQuery it would be 13kB [3] And by correctly using polyfills only on browsers that don't support native fetch, the majority of your users (chrome/safari/firefox) won't have any extra dependencies by using fetch, whereas jQuery will need to be loaded on every browser that hits your site. [1] https://bundlephobia.com/result?p=unfetch@4.1.0 https://bundlephobia.com/result?p=unfetch@4.1.0 [2] https://bundlephobia.com/result?p=jquery@3.4.1 https://bundlephobia.com/result?p=jquery@3.4.1 [3] https://www.telerik.com/blogs/jquery-using-only-what-you-need https://www.telerik.com/blogs/jquery-using-only-what-you-nee...
- goto11 7y agoJust for comparison, the "favicon" for Hacker News is 7.66 KB. Does the size of jQuery really matter for a typical web site? If you have just a typical size logo, it will dwarf the size of jQuery, never mind if you have some illustrations or photos.
- davidweatherall 7y agoI agree there are often more important performance issues on sites, especially with images, but that doesn't mean we should completely ignore javascript bundle sizes. In modern sites if javascript doesn't load sites then become non functional, e.g. navs don't work, some SPAs won't work at all. Whereas an image or favicon taking a long time to load shouldn't stop the user from being able to functionally view most of the site.
- charrondev 7y agoSee https://v8.dev/blog/cost-of-javascript-2019 https://v8.dev/blog/cost-of-javascript-2019 JavaScript has, in a addition to download time, parse and execution time. These are non-negligible on lower end devices. 30k of JS has a far greater impact on the speed of your page than 30k of images.
- goto11 7y agoSo what is the parse and execution time for jQuery on a low-end device? Genuine question, I have no idea.
- onion2k 7y agoYou should optimize images as well as removing unnecessary JS libraries. The point is to not send data the user doesn't need. It doesn't matter if you're using 50MB of images, fonts, video, etc in a page... Adding an extra 30kb you don't need is not good for the user. So don't. (Also don't stick 50MB of assets in a page please.)
- goto11 7y agoSince the jQuery API is more concise than the standard API, you probably save bytes anyway. And if you use a CDN, jQuery will likely already be cached, so it will perform a lot better than writing your own code to present a similar abstraction layer.
- Turing_Machine 7y ago> 30kb is completely insignificant. Also, if you're serving jQuery from one of the major CDNs (as many, perhaps most, sites do), the probability that it's already in the browser's cache is pretty close to 1, in which case the "30kb overhead" is utterly irrelevant. > There is more to it than "wanting to learn". Indeed. What about people who just think the new official APIs suck? Strange as it may seem, there are people who would rather type "$" than "document.querySelector", especially when they're going to be doing it hundreds of times. With respect to "bloat", "$" is one character. "document.querySelector" is 22.