Live data from Hacker News

This Week in Rails: jQuery no longer part of Rails, and more

weblog.rubyonrails.org

131–140 of 143 posts

Re: This Week in Rails: jQuery no longer part of Rails, and more

#131
I loved jQuery when it first appeared, but it is from another era, for sure. The rise of the Single Page Application was one big strike against jQuery. Frameworks such as Angular 1.0 emerged which relied on jQuery, and the software built with those frameworks revealed the dangers of mutable state, especially when combined with something async like Ajax. Anyone who has worked on a large Javascript project is eventually burned by mutable state. Then other frameworks such as React and Om Next emerged, which advocated for immutable data. The team behind Angular realized their mistakes and tried to fix them, so Angular 2.0 was a radical re-write of Angular 1.0, and yet despite that, more and more developers continued to flock to something like React. The immutable frameworks offer the idea that all state should be held in a single immutable atom, and the views should merely be straight reflections of the state that is held in that atom. One could still potentially use jQuery in the background to handle the actual update of the DOM elements, but there are many other ways of updating DOM elements, and many of those other methods are more efficient than jQuery, so jQuery's importance has declined.

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.

Re: This Week in Rails: jQuery no longer part of Rails, and more

#132
post #77
post #28

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…

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…

There was never a 'problem' with jQuery apart from that it's quite a heavy file, especially for mobile, and some people want to stop having to download it.

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

#133
post #28

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.

> 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.

Re: This Week in Rails: jQuery no longer part of Rails, and more

#134

Earlier 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 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

#135

Earlier 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…

I overlooked the fact that PrototypeJS was first (in fact, I was one of the unfortunates who backed that horse), but I still disagree. I don't think the jQuery lowered any kind of quality bar, it made absurd and redundant work irrelevant.

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

#136

Earlier 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

What bugs do Safari/Android/IE 11 have that jQuery fixes?

Re: This Week in Rails: jQuery no longer part of Rails, and more

#137

Earlier 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.

> 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.

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

#138

Earlier 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…

You bring up prototype of all things as an argument for having less design flaws than jquery...sorry, I really don't want to sound snarky, but that made me chuckle.

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

#139
post #122

Earlier 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.

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 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

#140
post #122

Earlier 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…

The problem with attaching the listener to the 'actual' target is that it goes wrong when your markup is dynamic and so the target element is not (always) there the moment you create the listener.

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.

Post reply on HN