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

81–90 of 143 posts

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

#81

Post by magic_quotes »

mythz wrote: post #75
pavlov wrote: post #73

Earlier quoted context omitted.

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

> React's also culpable to npm's "micro module" madness

I love comments like this. Ever heard of "modularity shaming"? Now it's React's fault apparently.

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

#82

Post by mythz »

magic_quotes wrote: post #81
mythz wrote: post #75

Earlier quoted context omitted.

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

> React's also culpable to npm's "micro module" madness I love comments like this. Ever heard of "modularity shaming"? Now it's React's fault apparently.

It's not just React's fault, but they're also following the trend.

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

#83

Post by magic_quotes »

mythz wrote: post #82
magic_quotes wrote: post #81

Earlier quoted context omitted.

> React's also culpable to npm's "micro module" madness I love comments like this. Ever heard of "modularity shaming"? Now it's React's fault apparently.

It's not just React's fault, but they're also following the trend.

No, that's simply not true.

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

#84

Post by mercer »

5350-uiop-1130 wrote: post #29

i still personally find vanilla js quite cumbersome for dom manipulation but that's partly because i've grown used to the jquery way.

Yeah, it's a bit more verbose, although some of that can be alleviated with a helper function or two, well enough that it's worth it for me in many cases.

But I still regularly find myself just using jQuery for convenience, as there's still a bunch of gotchas with plain js.

For example, I rather liked the event.path property to deal with event bubbling, only to discover that safari (mobile, at least) doesn't support it. Adding a helper function for that was trivial, but it's still one extra thing to do, and it makes it just a bit harder for other devs to get going. I ran into a number of these minor issues.

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

#85

Post by paublyrne »

michaldudek wrote: post #76

I'm not a Ruby/Rails dev, but why the hell was it ever included? :o Isn't Ruby a backend language and Rails a backend framework? :o

It's a full stack framework. You can include JavaScript for your views, probably most commonly used to show, hide, and insert and remove elements from the DOM.

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

#86

Post by mythz »

magic_quotes wrote: post #83
mythz wrote: post #82

Earlier quoted context omitted.

It's not just React's fault, but they're also following the trend.

No, that's simply not true.

> No, that's simply not true.

Wow, really?! I stand corrected! I'm glad you took the time to bestow this illuminating perspective.

Here I am thinking that 20k+ files for a Hello World App was a bit much but your response really cleared things up for me, thanks!

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

#87

Post by mercer »

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…

> In someways we've digressed significantly and made it ridiculously more complicated to build a modern web app in contrast to what jQuery gives you out-of-the-box with a simple script include.

That's true, but I find that things are complicated because either 1) the complexity is higher because we're dealing with a proper app, in which case jQuery wouldn't be much simpler (you'd probably use Backbone.js at the very least, and that gets messy quick), or 2) people use a lot of 'state of the art' stuff that they don't really need.

In regards to 2: if what you need to do can be done with a script tag and jQuery, you probably wouldn't need anything beyond 'plain' React and it would still be a benefit. And if you go for something like Preact, the download size is smaller than jQuery, so you could even consider using both at the same time; preact for dom updates, and jQuery for everything else.

More and more I find myself opting for (p)react even for simple things like a slideshow widget or a tabbed element. I find it nicer than jQuery and if you avoid using all the 'cool stuff' (redux, etc.) it's simpler too.

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

#88

Post by mercer »

somecallitblues wrote: post #74
rajangdavis wrote: post #71

Earlier quoted context omitted.

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.

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 makes document.querySelector(All) simpler/quicker to use, and I use a helper function for events to make it a bit more like $().on().

But considering the fact that I have quite a few projects where the client will upload some huge image for the home slideshow or where there's no time or incentive to do any lazy loading of images, jQuery is often still the pragmatic solution. Especially when other devs need to deal with the project at a later stage.

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

#89

Post by magic_quotes »

mythz wrote: post #86
magic_quotes wrote: post #83

Earlier quoted context omitted.

No, that's simply not true.

> No, that's simply not true. Wow, really?! I stand corrected! I'm glad you took the time to bestow this illuminating perspective. Here I am thinking that 20k+ files for a Hello World App was a bit much but your response really cleared things up for me, thanks!

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 of jar-like packaging format. I'm surprised node.js/npm doesn't have something like that implemented yet.

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

#90

Post by mercer »

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?

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.target would point at the exact element that was clicked on instead of the parent element that I wanted to register clicks on.

Given the structure ".item .inner .title", I can't just check if event.target.classList contains 'item', because it might only contain 'title' or 'inner'.

event.path to the rescue! I can simply check if any of the parent nodes do contain the 'item' class. Except event.path doesn't work in safari mobile, so it needs a polyfill. Plus on every event handler I have to go up event.path to check.

Obviously it's not that hard to write a helper function that basically emulates .on(), but I can't help but feel that I'm maybe missing some simpler, plain solution. Any suggestions?

Post reply on HN