Back in 2007, if you wanted to add some simple visual effects to your CRUD app, then jQuery was like a gift from God. But nowadays, given the complex systems that people are building, jQuery has less to offer. It never had an opinion about managing state, so it leaves the core question of building a large app to other frameworks, and those frameworks have various built-in ways of updating the DOM, so the ease-of-use offered by jQuery is no longer such a noticeable advantage.
This Week in Rails: jQuery no longer part of Rails, and more
131–140 of 143 posts
Re: This Week in Rails: jQuery no longer part of Rails, and more
#132Pour 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…
I only used jQuery through Ember, never directly. It seemed to me, that the problem of jQuery wasn't how it was designed, but how it was used. I mean, if you simply use it to "directly" do your thing, without any framework/modularity pattern, you gonna have a bad time. But you could simply assume jQuery was the "browser API" and build your application framework on top of it, like Ember and others did. I mean, even th…
It's never been faced by the problems that backbone, angular, react, etc. where they rapidly die as soon as something else comes along, because it's a well built utility library, not a framework that had to include nasty hacks to work.
But, technically, there are no problems with it. If it were included by default in browsers, everyone would still be using it over vanilla javascript as even the new vanilla javascript has really poorly designed and wordy APIs.
Re: This Week in Rails: jQuery no longer part of Rails, and more
#133Pour 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.
Nowdays that true of vanilla JS. (Didn't use to be.)
addEventListener, documentQuerySelector, XMLHttpRequest...yes not everything is a one character function name ($), but it's all quite usuable if you value barebones-no-dependency simplicity.
Re: This Week in Rails: jQuery no longer part of Rails, and more
#134Earlier quoted context omitted.
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.
> Why do I use it? It fucking works Nowdays that true of vanilla JS. (Didn't use to be.) addEventListener, documentQuerySelector, XMLHttpRequest...yes not everything is a one character function name ($), but it's all quite usuable if you value barebones-no-dependency simplicity.
I guess it depends on what you're working on, but for us it's expressly not an option to say "we only support the latest version of [insert browser]". Some users aren't even technical enough to differentiate between a browser and the internet
Re: This Week in Rails: jQuery no longer part of Rails, and more
#135Earlier quoted context omitted.
I apologize in advance and mean no disrespect, but I think this analogy is terrible. PHP was browser-agnostic. PHP was a flawed tool that existed alongside other tools, and survived based on various merits and despite various drawbacks. jQuery was a life preserver. Javascript is wholly browser dependent, and at the time of its inception, browser compatibility was a jungle full of king kongs and velociraptors. Before…
I'd like to point a possible flaw in your counter-argument: jQuery wasn't the only choice and it wasn't the first. PrototypeJS, which came before it, did an arguably better job since it didn't have many of jQuery's design flaws, like hijacking 'this' or silent selector errors. The PHP analogy is therefore spot on IMHO: both it and jQuery (and I'd like to throw MySQL in there while we're at it) were tools that achieve…
If you're referring to those legions of people who "don't know javascript, but know jQuery," without jQuery they simply would have been lousy javascript developers instead of lousy javascript developers, that doesn't change anything.
Re: This Week in Rails: jQuery no longer part of Rails, and more
#136Earlier quoted context omitted.
> Why do I use it? It fucking works Nowdays that true of vanilla JS. (Didn't use to be.) addEventListener, documentQuerySelector, XMLHttpRequest...yes not everything is a one character function name ($), but it's all quite usuable if you value barebones-no-dependency simplicity.
I beg to differ... There's still weird Safari/Android bugs from old devices that are out in the wild. Even Windows 8 + IE11 has warts and might be used by application users. I guess it depends on what you're working on, but for us it's expressly not an option to say "we only support the latest version of [insert browser]". Some users aren't even technical enough to differentiate between a browser and the internet
Re: This Week in Rails: jQuery no longer part of Rails, and more
#137Earlier quoted context omitted.
I'm not a fan of CoffeeScript but do they really need to lug the huge amount of dependencies babel brings along with it? Why not target ES5 with some ES2015 sprinkles in depending on compatibility and slowly work towards ES6?
I'm not sure how you slowly 'work towards' ES6. Unless you decide to only support bleeding edge browsers, you cannot use ES6 or ES7 features in production applications. The only way we can use them is through transpiling. This will be the case for at least another three or four years.
Not really.
First it depends on your target audience. How new are their web browsers? Where are you developing your web applications? Some projects I've worked on have web applications that run in only a single environment so those are easy. Others I've had highly technical websites that the vast, vast majority went to using newer web browsers.
Second, pick and choose your ES2015 features. Honestly you don't need ES2015 at all but if you want to use it then some items, like let and const, are supported all over the place but others, like fat arrows, not as much.
> The only way we can use them is through transpiling. This will be the case for at least another three or four years.
Again all depends on your target audience. Maybe? Then again I've never been the biggest fan of transpiling one language into another just to access a couple of minor feature additions. It's a huge amount of dependencies, build time, etc all to support a few minor things.
Re: This Week in Rails: jQuery no longer part of Rails, and more
#138Earlier quoted context omitted.
I apologize in advance and mean no disrespect, but I think this analogy is terrible. PHP was browser-agnostic. PHP was a flawed tool that existed alongside other tools, and survived based on various merits and despite various drawbacks. jQuery was a life preserver. Javascript is wholly browser dependent, and at the time of its inception, browser compatibility was a jungle full of king kongs and velociraptors. Before…
I'd like to point a possible flaw in your counter-argument: jQuery wasn't the only choice and it wasn't the first. PrototypeJS, which came before it, did an arguably better job since it didn't have many of jQuery's design flaws, like hijacking 'this' or silent selector errors. The PHP analogy is therefore spot on IMHO: both it and jQuery (and I'd like to throw MySQL in there while we're at it) were tools that achieve…
Their moronic choice of directly extending the DOM was a more fundamental and far-reaching flaw than any of the - definitly numerous - problems and bad choices jquery has and had in the past, and it's one of the reasons it's has all but vanished for years now.
Re: This Week in Rails: jQuery no longer part of Rails, and more
#139Earlier quoted context omitted.
> 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.target would point at the exact element that was clicked on instead of the parent element that I wanted to register clicks on. 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…
Yeah, but that would then either be 'document' or the 'root' of my widget/component, no? Not the 'item' which is somewhere in between the root and the target. $().on() is very convenient in that way.
.querySelector()
.addEventListener('click', function(event){
// event.currentTarget refers to
// no matter which of its
// children were clicked
});
Admittedly, this doesn't work as well for multiple target elements. I use a forEach polyfill which could loop through them, but that could create a lot of event listeners when possibly you'd only need one higher up. Depends how many there are, I suppose.Re: This Week in Rails: jQuery no longer part of Rails, and more
#140Earlier quoted context omitted.
Yeah, but that would then either be 'document' or the 'root' of my widget/component, no? Not the 'item' which is somewhere in between the root and the target. $().on() is very convenient in that way.
I see, I missed the " " part of the call. Well, why not just attach the event listener to that, then? `querySelector` / `querySelectorAll` can be called on any old element, not just document. .querySelector( ) .addEventListener('click', function(event){ // event.currentTarget refers to // no matter which of its // children were clicked }); Admittedly, this doesn't work as well for multiple target elements. I use a fo…
This is why one of the early lessons you learn as a jQuery user is to use $().on() instead of something like $().click();
Plus, while I don't suppose it's a real performance issue much of the time, adding an event listener to each of, say, a few hundred items in a list is probably rather inefficient compared to adding it to the root element of the list.