Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

weblog.rubyonrails.org

Post reply on HN
Print view View original

71–80 of 143 posts

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

#71

Post by rajangdavis »

somecallitblues wrote: post #69
rajangdavis wrote: post #65

Earlier quoted context omitted.

I think it just depends on what type of web application/site you are making. For a simple site, it's probably not that big of a deal to hook in jQuery and write some basic scripts. In my limited experience, if you are writing a Single Page Application, it gets really hard to rationalize changes when everything is hooked in through the DOM. It also gets pretty expensive with mobile browsers as DOM elements carry a hug…

I agree with you about jQuery getting quickly out of hand if you want to create something like a one page app and you should certainly use something like React or Angular. I do use it. But to do a quick Ajax post, read some data and display a message or show and hide something jQuery is awesome. To tie a quick event listener to a dropdown and do something or to find children of some element jQuery is still few lines…

I agree to an extent. I think in the example you mention, I would probably do it in vanilla JS. XHR is a negligible amount of code with vanilla javascript. It's also the same thing with event handlers but you do not need the overhead of the entire jQuery library. If you want animations, I would borrow a few CSS declarations from animate.css and add/remove classes or data attributes as needed.

I think it really depends on how you structure your HTML as well; having tortured myself into learning Angular has really helped with understanding how to think about data structures as opposed to strict DOM elements and this has carried over to how I write javascript nowadays.

One thing that I will mention is that I have worked really hard to not use jQuery over the last year, so my preferences may not be shared by you. I guess it depends on what is quicker and easier to maintain for you.

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

#72

Post by dom0 »

wfleming wrote: post #22
aamederen wrote: post #7

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.

Nikanj isn't wrong (and is funny), but I think the other (more justifiable) reason is that jQuery largely isn't necessary anymore: when it came out, there were an uncountable number of browser incompatibilities that needed painting over, and APIs for remote requests, DOM querying & manipulation and the like were very immature, so a library to make everything usable was extremely valuable. Now, those APIs are mature &…

Exactly. For my little JS needs I just use vanilla JS (even though the APIs are poor and the language is worse), since it will very likely work across all browsers I care about (recent FF/Chrome/Edge).

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

#73

Post by pavlov »

mythz wrote: 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…

It's not just Angular. I really do like React, but the ecosystem complexity is staggering there as well.

Facebook's "create-react-app" tool does a great job of packaging all the pieces... But the cost is apparent when looking at the size of an empty create-react-app boilerplate app:

> 85,174,715 bytes (148.8 MB on disk) for 23,387 items

This is on Mac, so the wasteful HFS+ file system means that an empty web frontend project takes up 150 MB of disk space. Each project I make with create-react-app will have this same overhead. That's fairly incredible.

People think C++ is complex, but a full C++14 compiler and dozens of libraries will fit in less space than a web boilerplate.

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

#74

Post by somecallitblues »

rajangdavis wrote: post #71
somecallitblues wrote: post #69

Earlier quoted context omitted.

I agree with you about jQuery getting quickly out of hand if you want to create something like a one page app and you should certainly use something like React or Angular. I do use it. But to do a quick Ajax post, read some data and display a message or show and hide something jQuery is awesome. To tie a quick event listener to a dropdown and do something or to find children of some element jQuery is still few lines…

I agree to an extent . I think in the example you mention, I would probably do it in vanilla JS. XHR is a negligible amount of code with vanilla javascript. It's also the same thing with event handlers but you do not need the overhead of the entire jQuery library. If you want animations, I would borrow a few CSS declarations from animate.css and add/remove classes or data attributes as needed. I think it really depen…

See you've made an effort to go back to document.getElementBy... where I just wouldn't be able to go back to that after 10 years of such concise syntax that so closely matches CSS. But I'm a bit lazy and tend to find the easiest and quickest way to get to the result.

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

#75

Post by mythz »

pavlov wrote: post #73
mythz wrote: 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…

It's not just Angular. I really do like React, but the ecosystem complexity is staggering there as well. Facebook's "create-react-app" tool does a great job of packaging all the pieces... But the cost is apparent when looking at the size of an empty create-react-app boilerplate app: > 85,174,715 bytes (148.8 MB on disk) for 23,387 items This is on Mac, so the wasteful HFS+ file system means that an empty web frontend…

Yep React's also culpable to npm's "micro module" madness, where often the scope of a npm package is wrapping a single function! Which explains why blank SPA templates requires 1000's of files.

But I've got my choice SPA stack down to a solution I'm happy with, where a blank App is down to:

   - TypeScript (using Type Definitions in npm package or @types)
   - JSPM (package/dep management, module loader + bundler)
   - Gulp (automate all tasks in reusable scripts)
   - React
JSPM `bundle` feature also lets you combine all React's deps into a single .js file which speeds up iterative dev workflow by combining the 100's of runtime dep requests down to 1 .js file.

Also using jspm@beta means I don't have to configure a separate tool like Webpack as JSPM reuses your dependencies where its 'build' feature rolls up your app into a single stand-alone, minified .js file to give you an optimal packaged app for deployment.

Using the TypeScript integration in VS.NET means I don't have to run any external processes or watchers as TypeScript automatically re-compiles every modified .ts file on save where it's ready by the time I reload the page.

Unfortunately it looks like npm has passed the point of no return and every developer is stuck building on this complexity. Honestly if it wasn't for the potential of React Native I'd strongly consider moving to Vue.js (https://vuejs.org/v2/guide/) since it's still a modern well supported SPA fx, but lets you reference a single script include. Ideally React would offer a simplified solution where it also maintains a parallel "react-dev" npm package with no deps, but it's unlikely since it goes against npm's micro module madness trend - but it's something I'm keen on exploring if I ever get the free time.

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

#77

Post by k__ »

mythz wrote: 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 the Sencha devs did their own abstraction layer and built their frameworks on top of it.

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

#78

Post by reitanqild »

dang wrote: post #48
reitanqild wrote: post #47

Earlier quoted context omitted.

I don't think you really got it jayajay: You are talking down a tool that saved thousands of engineering hours and helped level the playing field between the browsers. And then it seems you try to lie your way out of it. (The first comment looks nothing like a joke.) Recommendation: own your mistake, be more careful next time. Oh, and skip unnecessary profanities.

> And then it seems you try to lie your way out of it. Please be charitable and give others the benefit of the doubt when commenting here.

Ok, sorry about that. Will try to be even more so in the future.

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

#79

Post by adamlett »

TekMol wrote: post #66
somecallitblues wrote: post #59

I will personally continue to use jQuery for many years to come. It's a lot of power in few concise lines of code and it really makes sense. And it comes at the cost of a single request. For the small amount of JS my sites use its perfect. I don't know why everyone in thread is saying goodbye to jQuery. Are that many people coding in vanilla JS?

I use plain JS. Can you give an example of a typical line of jQuery that you prefer over vanilla?

JQuery still smoothes over browser inconsistencies. For instance, I was recently bit by this:

https://connect.microsoft.com/IE/feedback/details/878564/ele...

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

#80

Post by mythz »

k__ wrote: post #77
mythz wrote: 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…

jQuery still boils down to mutating DOM state, forcing you to become a bookkeeper where you have to carefully ensure your App's state and rendered DOM are in constant sync and you also have to deal with interim state transitions where it's easy to run into bugs for state transitions you've never tested or thought about, which gets complicated quickly.

React's Virtual DOM means you only have to care about the representation of a given state and React takes care of transparently and optimally handling all the DOM mutations required to sync the DOM with your App's state. React also has great componentization making it natural and easy to encapsulate reusable logic. The benefits really stand out in medium to large code-bases where it scales much better than jQuery. It's still ok for Apps maintaining little state, but there's a large class of Apps I'd never consider creating in jQuery which I've found trivial to develop with in React.

Post reply on HN