7 ms·
Yea, let's bury jQuery again and make more "helpers.js" [1] export function extend(src) { var obj, args = arguments for (let i = 1; i <
by batat 9y ago
Yea, let's bury jQuery again and make more "helpers.js" [1]
export function extend(src) {
var obj, args = arguments
for (let i = 1; i < args.length; ++i) {
if (obj = args[i]) {
for (let key in obj) {
// check if this property of the source object could be overridden
if (isWritable(src, key))
src[key] = obj[key]
}
}
}
}
or just add super-unique stuff to our classes [2]
DragSelect.prototype.removeClass = function( element, classname ) {
var cn = element.className;
var rxp = new RegExp( classname + \'\\b\', \'g\' );
cn = cn.replace( rxp, \'\' );
element.className = cn;
return element;
};
DragSelect.prototype.hasClass = function( element, classname ) {
var cn = element.className;
if( cn.indexOf( classname ) > -1 ) { return true; }
else { return false; }
};
or write tons of boilerplate code like
if (typeof element === 'string') {
owner.element = document.querySelector(element);
} else {
owner.element = ((typeof element.length !== 'undefined') && element.length > 0) ? element[0] : element;
}
(mmm, it's so vanilla)
[1] https://github.com/oncode/handorgel/blob/master/src/helpers.js#L56 https://github.com/oncode/handorgel/blob/master/src/helpers....
[2] https://github.com/ThibaultJanBeyer/DragSelect/blob/master/src/DragSelect.js#L768 https://github.com/ThibaultJanBeyer/DragSelect/blob/master/s...
- Touche 9y agoRather than using a library with a bunch of utility functions that you may or may not need, using individual utility functions indeed does seem like a better idea. For example, I don't support browsers without classList, so I don't need your regexp stuff. Maybe you do, but my code shouldn't be larger because of that.
- jonursenbach 9y agoProblem now is that you get to write, test and maintain all this instead of using something that has a whole community backing it.
- hw 9y agoMost of these utility functions are fairly straightforward and will rarely require any changes or maintenance. Testing should therefore be straightforward as well. Having the whole community back something doesn't mean it's bug-free, and sometimes it makes it harder when their release cycle isn't as frequent as you'd like it to be. Having said that, it's all about tradeoffs. Whether your project needs something as big as <insert JS framework or lib here> or if you can live with just needing a few utility functions, you make those choices, doesn't mean one is better than the other as it all depends on context and situation. jQuery has become the defacto must-use library for javascript now which IMO is unfortunate, as a lot of sites and apps include it when they barely use most of what jQuery offers. I'm guessing most use jQuery for only a few things - Ajax, DOM querying, and events. I hope that sometime in the future jQuery would be more modular.
- Touche 9y agoIf you search for classList on npm you get a half dozen results. I disagree with your assessment here.
- aurbano 9y agoDead code elimination (i.e. UglifyJS) should do away with most unused code from a library - so with a proper build system this shouldn't be a big concern...
- madeofpalk 9y agoI don't think you'll find UglifyJS's dead code elimination to do the type of tree shaking that'll remove jQuery's unused functions.
- kitsunesoba 9y agoWhat if one wants to keep things simple with a minimal/nonexistent build system? I haven’t done serious web work in ages but if I did I’m quite sure I’d find all of today’s “required” build tools quite frustrating.
- jonknee 9y agoAnd yet by "keeping it simple" you have to re-write and maintain a bunch of utility functions that are solved problems.
- megous 9y agoIf it's for some gain, then why not. It's a trade off decision.
- rhizome 9y agoIf they're solved problems, what difference does it make what form and package they arrive in?
- Touche 9y agoYou say that as those jQuery is the only place you can get a addClass function without writing it yourself. It isn't.
- jonknee 9y ago
- madeofpalk 9y agoremoveClass and hasClass are interesting choices considering browsers ship with these APIs
- jlukic 9y agoThese utility functions and shims are "per" component. This means that functions like extend will be repeated many times in different idiosyncratic code across app. Imagine your app uses, modals, dropdowns, multiselects, search autocompletes, sliders, rich text areas etc. Instead of having one cached utility library upfront you have many hidden utility libraries scattered around each component, which makes it difficult to say clearly that jQuery is always larger. The other issue is maintainability. When you're working with third party components, hot-fixing an OS library can be fairly daunting if you need to also learn their own internal class structure, selector helpers, dom manip functions. Doing this in jQuery, it's fairly easy to fork the codebase and plop in a .clone() or .append() to fix a stale issue.
- twhb 9y agoYour JS knowledge appears to be severely outdated. Instead of the first you can now write: Object.assign(target, object1, objectN); The second: element.classList.add(className); element.classList.contains(className); And the third has been fixed at a community level, as we've learned the value of API strictness, obviating such checks. I don't think anybody was against jQuery back when the alternative was helper functions, I certainly wasn't. But that's five years ago at this point. Modern JavaScript looks nothing like the code you posted, it's actually been built up into a pretty good language.
- sosuke 9y agoPerhaps the examples are just a reflection of having to support Internet Explorer?
- csomar 9y agoYou are ignoring browsers support. One of the main reasons I suggest using jQuery is browser support. Another solution is to use a transpiler like Bable.
- ctrl-j 9y ago> Another solution is to use a transpiler like Bable. At this point in front-end development something like Babel is a must. If you aren't using Babel/Flow/Typescript in your workflow, you are putting yourself at disadvantage for no good reason. For better or worse, transpiling is a fact of life.
- platz 9y agoIf you're not using a framework that requires you to transpile, jQuery basically takes care of the most common bits.
- loganfsmyth 9y agoBabel on its own only addresses syntactic functionality and wouldn't cover this, but it is indeed extremely easily to polyfill `classList`.
- jswizzy 9y agoThe real problem is JQuery isn't modular and it is tightly coupled with your code.
- manigandham 9y agoIf you're using a build system like webpack you can use Babel/minify to get rid of unused code or pick and choose your modules directly from the npm package.
- nightski 9y agoI've thought a lot about this and honestly I'm curious if this would even be an advantage. Currently I can pull in jQuery from a CDN and it is likely used by many other sites. If I have a custom version of jQuery, now it is guaranteed to need to be loaded. Is it truly a win?
- zamalek 9y agoI don't think that burying jQuery is the best idea, too. It is a very well-designed library. What we really need is a library of functions to make the native APIs less awful and verbose - which exists: Zepto.js. Ultimately mutating the DOM directly is just an awful job - it's solving problems that are ancillary to the problem that you are trying to solve (making great UIs). React and Vue feel like sensible abstractions, although there's still a far better but undiscovered solution to this problem.
- dheera 9y agoVanilla JS is more about being agnostic to the framework and framework version the developer is using. Not everyone uses jQuery, and if you library depends on it, you now require several tens more kilobytes of bloat to be loaded just for your thing to function.