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

I loved jQuery, and still do (2019)

withblue.ink

Post reply on HN
Print view View original

121–130 of 189 posts

Re: I loved jQuery, and still do (2019)

#121

Post by acabal »

gmiller123456 wrote: post #116
acabal wrote: post #45

I still use jQuery even for new projects. Yes, these days it's possible to do everything jQuery does using native JS, but I find the native version to be much more verbose and its naming conventions to be far less clear. For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Meanwhile, natively getting a list of classes is `el.classList`,…

> but natively is the mouthful of `document.querySelectorAll('selector')` I'm curious as to whether there's a proper use case for querySelectorAll. I always use the getElementsByClassName, getElementById, and getElementsByTagName based on what I want. I find the more general querySelectorAll to be too likely to produce a bug when someone uses a CSS class name that equals a tag or ID. You can make it work, but I find…

The question should be the other way around: Why is there `getElementsByClassName` when you can do `querySelectorAll('.myClass')`? Why have `getElementById` when we have `querySelectorAll('#myId')`? Why have `getElementsByTagName` when we have `querySelectorAll('tagName')`?

Re: I loved jQuery, and still do (2019)

#122

Post by throwaway_egbs »

bstar77 wrote: post #110
throwaway_egbs wrote: post #108

Earlier quoted context omitted.

Right, I get that. What I don't get is why Node is a requirement for a JS compiler. Is that just to get the runtime? I'd always thought of Node as a server on top of a V8 runtime. (Thank you for your patience with this backend dev who finds your whole world very confusing.)

Node is required because that's what is used to compile the JS on the command line, it's a nodejs process. Once that's complete, any web server can serve the newly produced JS/CSS/HTML files. JS is interpreted by the browser, but we compile locally so that the code produced implements workarounds for missing language features. The code produced is typically minified so that the payload sent to the browser is much sma…

Yeah, I get all that too. I think my problem was that I sort of misunderstood what Node is. I've always thought of it as a web server, not a language runtime. So to me it seemed like using Node to run command-line tools was akin to doing

  python -m http.server my_cool_cli_thing
which is, of course, a bananas way to do things. But now that I've dug into it a little more I see that this is a misapprehension that I formed based on Node's original use case as an event-driven web server.

Thanks again.

Re: I loved jQuery, and still do (2019)

#123

Post by spiralx »

gmiller123456 wrote: post #116
acabal wrote: post #45

I still use jQuery even for new projects. Yes, these days it's possible to do everything jQuery does using native JS, but I find the native version to be much more verbose and its naming conventions to be far less clear. For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Meanwhile, natively getting a list of classes is `el.classList`,…

> but natively is the mouthful of `document.querySelectorAll('selector')` I'm curious as to whether there's a proper use case for querySelectorAll. I always use the getElementsByClassName, getElementById, and getElementsByTagName based on what I want. I find the more general querySelectorAll to be too likely to produce a bug when someone uses a CSS class name that equals a tag or ID. You can make it work, but I find…

Selecting descendants or sibling elements? Selecting based on tag and class? Selecting elements with a given attribute present or matching a particular value? Selecting elements with classes starting or ending with a given string? Selecting elements without children? Selecting elements that aren't any of the above.

Re: I loved jQuery, and still do (2019)

#124

Post by lordgroff »

bdcravens wrote: post #99
mortenjorck wrote: post #55

I finally learned some React a couple of months ago on the premise that as a designer, I needed a better understanding of the frameworks used by the developers I work with. I know React enforces some better practices that my spaghetti-jQuery of yore never followed, and that I was getting a crash course in those practices at the same time, but I was nonetheless surprised at just how slow I felt working in it! It gave…

Sounds like you're working on jQuery-sized apps, not React-sized. The problem is that many don't know the difference, and everything is React-sized, even apps that have no business being anything but server-rendered.

Yep... I mean, part of that is a problem of "SPA everything" cargo cult; basic web page? SPA everything! Content management? SPA everything!

I manage my wife's electronic store that's based on WordPress, and I see absolutely no reason for ever changing it. I've written a bunch of custom scripts, all in PHP back-end and jquery front-end, and... It just works. And it's fast. And complexity is totally manageable.

But, I've also written a few SPAs for her business deployed as PWAs, and I can't even begin to think about how it would look like if I was using jquery for these tasks. React (or Vue or whatever) is an escape hatch from going insane in such situations.

Re: I loved jQuery, and still do (2019)

#125

Post by spiralx »

acabal wrote: post #121
gmiller123456 wrote: post #116

Earlier quoted context omitted.

> but natively is the mouthful of `document.querySelectorAll('selector')` I'm curious as to whether there's a proper use case for querySelectorAll. I always use the getElementsByClassName, getElementById, and getElementsByTagName based on what I want. I find the more general querySelectorAll to be too likely to produce a bug when someone uses a CSS class name that equals a tag or ID. You can make it work, but I find…

The question should be the other way around: Why is there `getElementsByClassName` when you can do `querySelectorAll('.myClass')`? Why have `getElementById` when we have `querySelectorAll('#myId')`? Why have `getElementsByTagName` when we have `querySelectorAll('tagName')`?

Apart from the historical reasons both `getElementsByClassName` and especially `getElementById` are optimised - the latter being a simple lookup - which I'm not sure `querySelectorAll` is able to take advantage of.

Re: I loved jQuery, and still do (2019)

#126

Post by ducharmdev »

AnIdiotOnTheNet wrote: post #80
dageshi wrote: post #29

Earlier quoted context omitted.

Does 30kb of js really matter on modern phones and modern mobile internet?

This kind of thinking is why software continues to get slower and slower despite incredible advances in hardware.

Bingo. 30kb doesn't seem like much, but its easy to think it doesn't matter when viewing one dependency in isolation. But if you say "it's just x kb" to all dependencies, then you have a problem when they're all aggregated.

This is why I appreciate Svelte's take: with a compiler-heavy approach, you can have a great dev experience without saddling your users with extra dependencies.

Re: I loved jQuery, and still do (2019)

#128

Post by mjgoeke »

throwaway_egbs wrote: post #108
bstar77 wrote: post #105

Earlier quoted context omitted.

Basically what Dragonwriter said. Without getting into the weeds of where webdev was and where it is now, we have made some massive progress. One of the huge improvements was moving to JS compilers (Babel/Typescript/Flow) that normalized features so all browsers going back to IE11 could be reliably supported with the latest language standards. When you just sling jQuery on a page and try to use spread syntax or async…

Right, I get that. What I don't get is why Node is a requirement for a JS compiler. Is that just to get the runtime? I'd always thought of Node as a server on top of a V8 runtime. (Thank you for your patience with this backend dev who finds your whole world very confusing.)

I had a similar jarring experience moving from C# dev to web apps. I knew I wanted to use building blocks available via npm. I went to download npm, and found the way you get npm is via installing node.js

Node js and the the package manager are inextricably tied together. Node js provides a local js runtime environment for the e.g. dev time packages to execute. It's also the api for interacting with the filesystem. Somewhere down there, yes, Node js is a web server, but it's kind of 'the' javascript execution environment for building local packages ("plugins"?) against.

The whole ecosystem is built up on javascript. If you're running grunt or gulp or webpack, it's all javascript. When you install packages globally they're put in a global folder. There are exceptions (I'm looking at you Cypress) that have native assemblies instead of js, but by and large there it's js, and it's stored locally. There are some pretty simple conventions (e.g. the 'node_modules' folder and the hidden '.bin' folder inside that) When running npm it feels like passing a one-liner javascript command into node's javascript repl/environment. The .bin commands are ambiently available.

It makes a lot of sense how it's grown organically... why there haven't been efforts to separate the constituent parts... I don't know. At some point maintaining the 'working thing' with complexity is easier than following a more rigorous, provable set of tools. I think it's a culture thing. Probably the same reason most of the problems are fixed by deleting node_modules and re running `npm i`

Re: I loved jQuery, and still do (2019)

#129

Post by Legion »

rchaud wrote: post #61

Every time anything about jQuery is posted, someone will inevitably post the "You might not need jQuery" site. [0] I look at that site and laugh. Is this supposed to be making the case ~against~ jQuery? Maybe the audience for that site are seasoned developers for whom the vanilla JS syntax is easily understood. Everybody else is going to look at those code snippets and think jQ is the way to go. For people that have…

> Is this supposed to be making the case ~against~ jQuery?

It's supposed to be making a case against jQuery if you're pulling in the whole library just to do this one thing.

I've always read the site as "here's how to do it in native JS, yes it's uglier, but if you only need this, you can skip pulling in another dependency."

Re: I loved jQuery, and still do (2019)

#130

Post by iso1631 »

rchaud wrote: post #61

Every time anything about jQuery is posted, someone will inevitably post the "You might not need jQuery" site. [0] I look at that site and laugh. Is this supposed to be making the case ~against~ jQuery? Maybe the audience for that site are seasoned developers for whom the vanilla JS syntax is easily understood. Everybody else is going to look at those code snippets and think jQ is the way to go. For people that have…

I assume that's a pro-jquery site

I write random bits of scripts for internal use, I'm happy enough to drop the min.js in with my index.js, index.css and index.php files, especially if it means I can continue to use

  getJSON('/my/url', function(data) {
  
  });
Rather than

  var request = new XMLHttpRequest();
  request.open('GET', '/my/url', true);
  
  request.onload = function() {
  if (this.status >= 200 && this.status
The 90KB of jquery is nothing compared with the amount of crap modern javascript frameworks put in on other sites.

I've just looked at one page I wrote which has a little jquery in it. The outputted data is 673kb, which takes nearly half a second to generate and load. The jquery file being static is down in 0.01s.

This isn't a problem

Post reply on HN