111–120 of 143 posts
Earlier quoted context omitted.
I find that the current state of things is that, indeed, jQuery is often still worth using, but only just , and especially if older browsers have to be supported. If download size is at all an issue, jQuery is the first thing to go. I have a tiny collection of helper functions that make 'plain js' almost as simple as jQuery in most cases. Almost. For example, at the very least I'll have a '$' helper function that mak…
I can't help but think the obsession with download size of script files in the JavaScript community is a bizarre premature optimization. I'm saving 400 kb by dropping useful library XYZ . Meanwhile, the page is loading 47 different snippets of non-async advertising and tracking code, social media buttons, non-optimized full-size PNG images, auto-playing videos, and more useless resources that dwarf any amount of Java…
Besides, 400k of (blocking) JavaScript can be the difference between the site loading quickly on mobile and the user giving up.
Earlier quoted context omitted.
I use plain JS. Can you give an example of a typical line of jQuery that you prefer over vanilla?
I have an example to which maybe you or someone else can suggest a better 'vanilla' solution. Would love to hear suggestions. With jQuery I'd often do $( ).on('click', , callback); crucially, because events bubble up, even a click on a child element of will register as a click on the target element. in plain js it doesn't seem to work that way. I'd do .addEventListener(), but I'd run into the problem that the event.t…
Unless I misunderstand, I think you might be looking for "event.currentTarget". event.target is the element that was clicked on, event.currentTarget is the element that has the event listener attached.
I somehow still seem to need jQuery. Mainly because I need to use a UI component, and out there one already exists, which does exactly what I need. So jQuery gets in as a dependency. Maybe because I have used it for more than 8 years now, I seem to know the jQuery based components well. Especially times when one needs things like https://fullcalendar.io/ and Kendo UI jQuery becomes a required dependency. To those, ho…
The back-end administrative panel of those sites is more complex. It uses Bootstrap, so there's some incentive to include jQuery there, though I don't always use features that require it. But this is an area I struggle with as well - there are so many external components, like date and time pickers, drag & drop image uploads, etc, that aren't easily replaced with vanilla JS components that have feature parity. Curious to see what others have to say about this as well.
Pour one out for jQuery! jQuery was a major productivity boost when first released but it didn't scale well and encouraged creation of tightly coupled glue code. It's decline being the result of evergreen browsers maintaining good parity where "vanilla JS" is now a feasible option and from it no longer being needed in the premier JS SPA frameworks which scales better and allows for the creation of better componentize…
If I move on from jQuery, it won't be to Angular. I tried React, but I also found it too much boilerplate. I'm trying VueJS next.
Can anyone explain when did jQuery start to fall back in the tech era? What were its failures? It is a bit sad to say goodbye to such an old friend.
Pour one out for jQuery! jQuery was a major productivity boost when first released but it didn't scale well and encouraged creation of tightly coupled glue code. It's decline being the result of evergreen browsers maintaining good parity where "vanilla JS" is now a feasible option and from it no longer being needed in the premier JS SPA frameworks which scales better and allows for the creation of better componentize…
Yeah I get flak when I still use jQuery in new projects. Why do I use it? It fucking works, with no need to depend on npm, the application is a lot snappier than using Angular. If I move on from jQuery, it won't be to Angular. I tried React, but I also found it too much boilerplate. I'm trying VueJS next.
Earlier quoted context omitted.
jQuery to me was always meant as a DOM manipulation library. It didn't fall behind per se, it's just that browsers became good enough and standard enough that you no longer needed this type of tool. I think it would have been a huge mistake for jQUery to have attempted to become a Backbone, Angular or React, because it really was never meant for building web apps (of course you could still use jQuery in Backbone and…
> it would have been a huge mistake for jQUery to have attempted to become a Backbone, Angular or React What would you call jQuery UI?
Pour one out for jQuery! jQuery was a major productivity boost when first released but it didn't scale well and encouraged creation of tightly coupled glue code. It's decline being the result of evergreen browsers maintaining good parity where "vanilla JS" is now a feasible option and from it no longer being needed in the premier JS SPA frameworks which scales better and allows for the creation of better componentize…
Earlier quoted context omitted.
Can we please stick to the facts? Where exactly does it promote micro-modules? For example, React was repeatedly criticized for not splitting virtual dom implementation into a separate npm package. That's completely opposite side of the spectrum. > Here I am thinking that 20k+ files This are separate files and not necessary as many separate modules. Different things, really. That's ought to be solved with some kind o…
I've already made this clear, a blank Hello World App requires 20k+ files and 100's runtime dependencies. It literally takes minutes to download everything which I've had often fail. npm installs of SPA templates are one of the few things that can cause my MBP CPU to burn and HDD to thrash for long periods of time where I'd expect it to consume a non-trivial amount of energy. The fact there's so many deps mandates ad…
That's a legitimate complaint but I don't think it has anything to do with micro-modules. You can easily have thousands of files per one npm package just as well. Now, if you actually mean commonjs-modules as opposed to npm packages, then you have a point. We really need to avoid unpacking all this files on disk separately.
> Your point about their being only 2 dependencies
Not my point. In fact, React has exactly zero runtime dependencies and as many development dependencies as you like.
> recommended state of the art React SPA development.
I only have the issue with the recommended part. All that React does is just trying to cooperate cleanly with the most popular js development stack out there. That unfortunately means npm mess (for now).