4 ms·
This is the first time I’ve seen jQuery defined as “...plain, vanilla jQuery”!
by _eht 7y ago
This is the first time I’ve seen jQuery defined as “...plain, vanilla jQuery”!
- tagspace 7y agohaha. Fair point.
- npsomaratna 7y agoI find this refreshing. jQuery works very well for simple and direct stuff. No need to over-complicate things!
- nkozyra 7y agoNo need to over complicate things by adding an unnecessary library? I'm sympathetic to jQuery users and I think it's a phenomenal artifact in the history of the early web but unless you need to accommodate IE9 I don't know why you'd want to use it for a widget like this.
- rajangdavis 7y agoIt's using some animation sugar from jQuery (source is in this blogpost: https://app.trevor.io/public/blog/demo https://app.trevor.io/public/blog/demo). It might be possible to port most stuff over to ES6 and use CSS animations; however, the code is concise and readable.
- nkozyra 7y agoI'm not arguing against jQuery in the abstract, but you can write concise readable vanilla js/css with animations. I've used jQuery recently because I had to target older browsers, but if you don't it's almost always cleaner and lighter weight to use modern J's.
- rajangdavis 7y agoHonestly, my first thought was to port the code to ES6/CSS3 because I also share the belief that the code can be as concise if not moreso; however, I still think what the author did was a good solution. I think the tradeoff is if you want to delegate everything (animations and DOM manipulation) to one language using a single library or split things up into two languages with no libraries. I prefer splitting things between JS and CSS, but I'm impressed with how clever, concise, and expressive using jQuery can be.
- tagspace 7y agoYeah, true. Maybe we'll try and port this to CSS animations at some point.
- lucideer 7y agoHave we really come so far that using jQuery is interpreted as not overcomplicating things?? jQuery is the extra complexity people are raising issue with here. It's not needed (and definitely shouldn't be described as "plain, vanilla". There's nothing vanilla about an extra unnecessary dependency).
- npsomaratna 7y agoI think we have, for better or worse. When I think of frontend JS these days, what comes to mind is Angular, React, Vue, Svelte, etc. jQuery feels (and is) simple in comparison. All the more surprising - I've been building frontend UIs from the late 90s, starting with plain JS, to prototype, to jQuery and onwards. I'm kinda amazed over how my perception of 'what is normal/acceptable in JS' has slowly but steadily changed over time.
- lucideer 7y agoI'm a big fan of a lot of new frameworks, but one of the reasons I prefer React* to Angular is its simple feel. The React library is usable "with" idiomatic plain javascript, rather than instead of (sure chained jQuery api calls are technically JS, but they're more akin to another language/convention within. Angular html directives are a whole nuther thing). The React library itself is small (~7kb to jQuery's ~30kb), and simple. So conceptually simple in fact that it lends itself to reimplementations like preact. The added weight of the somewhat over engineered react-dom renderer needed for browser rendering is regrettable, but still the modular approach is elegant in its simplicity and there's no reason you couldn't swap out the renderer. What I'm getting at here is: I much prefer using plain vanilla JS as I did when I started in the early 00s, but even when it does makes sense to jump on the library bandwagon, it's possible to take a critical approach and avoid unnecessary extra complexity. jQuery has never been that. At any point. * Important to clarify I'm referring to the React library, not React's ecosystem
- stepbeek 7y agoI thought that idiomatic react involved using JS render functions to turn JSX + Data into HTML; and using css-in-js to handle styles? I'm somewhat wary of React because I feel like it pushes developers to work with non-standard tools rather than the HTML + CSS + JS that browsers handle just fine. I agree wholeheartedly on the ecosystem. I think global state stores will have a reckoning in the next 10 years where we collectively realize that maintaining a large amount of client-side state is not required for 90% of sites.