(I would issue one caution: the kebab-case `float` becomes the camel-case `cssFloat` because `float` was a reserved word this is a little like how for becomes htmlFor and class className.) Camel-casing the property name: I can do that myself readily enough remember this lets you deal in direct property access, so we’re talking things like `styles.backgroundColor` rather than what would otherwise be `.css('backgroundColor')`, where using the kebab-case is nicer.They’re often not exactly equivalent, but I don’t think that all of your points are reasonable. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow. Aside from the eliminating the extra 69KB footprint from adding jQuery 3.1.1 slim min, I don't see any reason to rush to rip jQuery out of the Nimbly core. Nimbly components are not required to use jQuery - only the framework core uses it. It uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. I'm the maintainer of and - the latter of which is an SPA component framework whose core requires jQuery. There are some things that jQuery does very well - even in today's world where modern web dev is dominated by SPA components. It seems like a lot of people are doing it just because it's the trending thing to do. I don't particularly understand the rush to rip jQuery out of everything. Also, their `extend` does a shallow merge, not a deep merge. Their `replaceWith` doesn't provide the functionality that jQuery offers - it doesn't take into account event handlers bound to DOM elements. I glanced through the list and noticed a couple problems myself too.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |