8 ms·
Not really an answer to your question, but this might be useful: http://youmightnotneedjquery.com http://youmightnotneedjquery.com
by JepZ 9y ago
Not really an answer to your question, but this might be useful: http://youmightnotneedjquery.com http://youmightnotneedjquery.com
- sametmax 9y agoYeah. Except you need to do Ajax and fetch doesn't cut it. So new lib. And manipulate the dom with something better then the browser API or you loose your mind. So new lib. Then normalize browser events. Oh wait, you can do that manually. But you are writing a new lib. Eventually the code will grow to be the size of jQuery anyway. Only not as well tested, documented and cached.
- shakna 9y ago> Yeah. Except you need to do Ajax and fetch doesn't cut it. So new lib. Why doesn't fetch and its polyfill cut it?
- sametmax 9y agoPolyfill. So new lib. And even then. You need to encode params manually. And of course no middleware, so for special decoding or repeating headers, you end up writting a wrapper.
- megous 9y agoProgramming is mostly creating functions and interfaces to decompose problems into reusable parts where reuse makes sense. Nothing wrong with creating a simple function for making XMLHttpRequests or for fetch API. Most of the time there's no need for the level of generality of jQuery interfaces. Just by making a function you're not creating a library. Sometimes I find DOM API verbose too. Nevertheless the fix does not need to be a interface like jQuery to completely hide DOM API under another interface. It may be enough to extend the HTMLElement prototype a bit or write a function to "compress" the code a bit and make it more readable.
- forgottenpass 9y agoJust by making a function you're not creating a library. Have you seen what passes for a library on npm?
- megous 9y agoGood point. :D
- sametmax 9y ago> it may be enough to extend the HTMLElement prototype a bit You lost me here. Anybody extending standard objects cannot be taken seriously.
- megous 9y agoDo you realize JavaScript is a prototype based programming language? It is a major and very useful feature of the language. There's no reason not to use it. There are some things to be careful about with interop if you need it, but that's it.
- jamiepenney 9y agoWe've already learned from our past mistakes changing the prototype of the standard library - the Ruby community learned the same thing with monkey patching their standard lib too. The maintenance overhead far outweighs any immediate benefits.
- megous 9y agoWhat maintenance overhead? Current and future costs are reduced by making code simpler and cleaner in the first place by using prototypes efficiently. Also, to be clear, I'm suggesting adding new methods to DOM object prototypes, not changing behavior of existing methods.
- 9y ago
- inimino 9y agoNo, a polyfill is not a library. It's a dozen lines, not a thousand.
- dragonwriter 9y ago> No, a polyfill is not a library Yes, it is. > It's a dozen lines, not a thousand A polyfill can be any size, but there's no size minimum to be a library.
- AstralStorm 9y agoSome people are mistaking a book (actually a module) for a library.
- inimino 9y agoOverly-literal response. A polyfill is a short snippet to implement a missing feature. Notably almost all recent additions to JS and DOM have been designed to be polyfillable where possible. Generally that means under a thousand lines, by the way. A library in this context means a set of functionality built on top of the platform, like jQuery, with its own API, etc. "Use a library" and "use a polyfill" are not the same advice. A polyfill is not a library.
- deleted 9y ago[deleted]
- shakna 9y ago> Polyfill. So new lib. So, you don't like the polyfill, created to the specification. Fine, but depending who you target, you might not need it. Plenty of modern browsers have good support. > And even then. You need to encode params manually. Or use the Request constructor. > And of course no middleware, so for special decoding or repeating headers, you end up writing a wrapper. Request constructor will let you handle the headers quite nicely.
- pharrlax 9y agoAlso, vast majority of users will have a cached copy of jQuery from Google CDN already. Now bundling it with the rest of your JS, that's indeed a mistake.
- deleted 9y ago[deleted]
- nilved 9y agoCDNs are a lie. The privacy implications outweigh the performance benefits since there are many, many, many CDNs and many, many versions of jQuery. It's rare for users to benefit from caching.
- pmlnr 9y agoI believe this is true, but the world will only be convinced if there are metrics for this. Are you aware of anything that verifies it?
- Can_Not 9y agoAlso, the performance benefits from free CDNs that you have no service level agreements are unsubstantiated at best, but you'll notice very quickly how much your site is broken when your CDN is over capacity.
- nilved 9y ago> Yeah. Except you need to do Ajax and fetch doesn't cut it. So new lib. Ah, so this is how front-end got the way it is.
- deleted 9y ago[deleted]
- maze-le 9y agoYou can implement an minimal ajax interface in js (no jquery) in less than 30 LOC. But I grasp what you mean, it not just that. There are other concerns and requirements and you do not want to reinvent the wheel everytime...
- moron4hire 9y agoI am so sick and tired of this argument. Having done it several times, no, you do not end up with something as big as jQuery, not by a long shot.
- Udik 9y agoAs big as jQuery? Gzipped it's 27k, a ridiculously small size.
- zmodem 9y agoRidiculously small? That could take 10 s to download on a 2G network.
- moron4hire 9y agoNetwork bandwidth usage is also not the only metric of size we care about. After it's ungzipped, it needs to be parsed by the JS engine, and more code = slower execution.
- sametmax 9y agoSure, if all you do is some onclick() and a few appendChild(). Plus for the time you spend chasing compat issues, writting wrappers, choosing small libs and packing it all together, you could have done your site. For less than 40ko. People are not blinking at including react ecosysteme, which is huge. But attack jQuery ? Seriously ?
- adtac 9y ago>Eventually the code will grow to be the size of jQuery anyway. Um what? jQuery is huge. You won't possibly use everything in it.
- emodendroket 9y agoWell, define "huge." It's like 28KB that your user may already have cached if you use a CDN. https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size
- adtac 9y agoI meant huge in terms of functionality. It supports so many things that you can't possibly need everything.
- emodendroket 9y agoOh. Well that's true, but I think the point is more like you end up implementing some significant subset of that, except with homespun code that isn't tested as well.
- sametmax 9y agoEvent + Ajax + DOM is most of jQuery. And is most what your webapp is. Now I'm more of a fan of Vue.JS + axios myself. But if I have to go minimal, 40ko of jQuery is nothing and save so much trouble. All the "you don't need jquery" thing is done by people doing prototypes that are not tested on most browser or assess in term or ressource vs reward, which is a lot of the projects in the JS community.
- madeofpalk 9y ago> Except you need to do Ajax and fetch doesn't cut it curious as to why you think this? fetch is pretty convenient to use. We created our own wrappers around it, but that basically just consists of ajax = (url) => fetch(url).then(res => res.json())
- sametmax 9y agoExactly, you had to write a wrapper. And the next project will do so. And if you want to save time, and improve reliability, you'll test it, and write doc for the 3rd. And the new team member. Or you can use the few ko of jQuery.
- deleted 9y ago[deleted]
- juandazapata 9y agoGood luck supporting old android browsers, IE and dealing with the inconsistencies between browsers. It only takes one look at the jQuery source code to understand why it's not a good idea to "roll your own jQuery".
- Fifer82 9y agoSimply don't target old browsers. If people don't use JS, or don't have a modern browser, feel free to go elsewhere. I don't target edge cases as I don't get paid to.
- juandazapata 9y agoI really envy the industry where you work on. In my industry you can't just ignore half a billion of outdated Android phones and Government seats.
- Fifer82 9y agoI presume you get paid for this specifically?