546
Which side are you? Javascript or Typescript (i.postimg.cc)
submitted 3 years ago by to c/programmer_humor@programming.dev
224 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 3 years ago (1 child)

Where'd you get your time machine, that you obviously would've needed to set to 2008 to find anyone actual recommending jQuery?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago (1 child)

    It's still the best API for imperative access to DOM.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 3 years ago (2 children)

    Do you need to support 15 year old browsers? Practically all the jQuery features I used (which was a lot) are now available in standard js

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 3 years ago (2 children)

    Yes, the features are there. Just the API is still horrible.

    As an example, make a hidden element visible (extremely common imperative operation).

    jQuery:

    $("#element").show();

    Native JavaScript:

    document.getElementById("element").style.display = '';

    I hope you'd agree that the native JS is certainly not an example of good API.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 3 years ago (1 child)

    Why would you not want to be using a rendering library? Your code is basically storing your application state in the dom which will turn into a horrible mess as soon as you reach any actual level of complexity. I know first hand. I'm traumatized from having to maintain large jquery code bases in the 00s. No serious professional writes code like this anymore.

    Also, your vanilla code isn't modern. It should look more like this:

    document.querySelector("#element").classList.toggle("hidden")

    I could see not wanting to use a rendering library if you're building a simple site on top of basic static HTML, but that's not a serious discussion for industry professionals, and even still, jQuery is such a heavy dependency for saving some characters. If you find yourself using it so much you need the extra convenience then your site is already complicated enough that you should be using a rendering library with state management instead.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago*

    Why would you not want to be using a rendering library?

    Because it's just not very useful in some contexts. I've seen web extensions which mostly query the current page, and it doesn't render much or even anything.

    Not all pages are SPAs either. Many apps are the old request-response with some dynamic behavior sprinkled on top. jQuery covers that well.

    This model is also quite compatible with the rising HTMX where the state/rendering is driven from backend and you just insert few dynamic pieces with JS.

    document.querySelector("#element").classList.toggle("hidden")

    There's no difference between document.querySelector("#element") and document.getElementById("element"), they're both same level clunky.

    Also, what you wrote is not functionally identical. $el.show() is idempotent, the el.toggle("hidden") is not (as the name suggests, it toggles a class). It also needs an extra boilerplate class.

    I could see not wanting to use a rendering library if you’re building a simple site on top of basic static HTML, but that’s not a serious discussion for industry professionals

    There are plenty of non-professionals doing web stuff and I think it's great!

    jQuery is such a heavy dependency for saving some characters

    jQuery is 24 KiBs (minified, gzipped), that's a good price for the egonomics it provides. If you're constrained, there are API-compatible alternatives like cash which go down to 6KiBs.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 3 years ago (1 child)

    That's actually a great example of the shortcomings of jQuery. There are multiple ways to hide an element yet they standardized on one that often wouldn't work.

    Also you're using an ancient method getElementById... I think visuals should still be controlled with css. So what is the right way to do that in modern js? document.querySelector('.some-name').classList.add('hidden') with that class defined in the css, with whatever makes sense, including maybe a css transition.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago* (1 child)

    There are multiple ways to hide an element yet they standardized on one that often wouldn’t work.

    It's the most common one. And it's not like you can't hide the element with some other mechanism with jQuery.

    Also you’re using an ancient method getElementById…

    And? What's the difference from document.querySelector() when querying for ID?

    So what is the right way to do that in modern js?

    What is the right way is context dependent. I don't see how having extra .hidden { display: none; } boilerplate is somehow modern or superior.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 3 years ago* (1 child)

    What's the difference

    Your code reads like it's from 1992 mainly, which makes sense I guess, given that you still find jQuery better than modern vanilla js. jQuery was created as a way to account for browser support challenges but is now obsolete. Anyhow, if I read "getElementById" in recent js code I would assume something was weird about that code. It's old hat and there is rarely a reason to use it.

    What is the right way is context dependent

    Precisely my point. Which is why I think it's opinionated in a bad way to arbitrarily pick one of them as the defacto. I often had trouble with jQuery's .hide() method because while it felt natural to use it, it often conflicted with what actually needed to happen for good UX.

    What you're missing is that the hidden class can contain anything you want. Animations or whatever else. In other words, the idea that there is a "right" or "most common" way to hide an element is flawed at its core.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] -1 points 3 years ago* (1 child)

    Your code reads like it’s from 1992 mainly

    Lol. You write a lot of text to mask the fact there's no good reason why getElementById should be bad. It's the same groupthink as with the jQuery, you're told it's bad, so you just follow the crowd.

    jQuery was created as a way to account for browser support challenges

    That was one of the reasons. The other was that DOM API was and still is crap. There were many such libraries to abstract away browser differences back in late 00s (Dojo, script.aculo.us, Prototype.js, MooTools), and the main reason jQuery "won" was that it provided the nicest API.

    Which is why I think it’s opinionated in a bad way to arbitrarily pick one of them as the defacto.

    You're missing the fact that jQuery does not prevent you from hiding the element in other ways. It's just optimizing for the most common case, which is one of the principles of good API.

    What you’re missing is that the hidden class can contain anything you want. Animations or whatever else.

    Sure, and when I just want to ... hide it, without any animations? Then this hidden class is boilerplate only.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago (1 child)

    I mean you're coming across like more of an old man than I am and that's saying a lot more than you know. For the first 2 years people shit talked jQuery I didn't agree with them. And then I got the opportunity to work without it and it seriously took like 3 days to completely change my mind. And all my pages were I believe about 100KB lighter.

    jQuery is trash. And that doesn't mean it wasn't a great tool for its time. It's truly obsolete now though. If you hate the native JavaScript stuff so much.. I dunno maybe go work with Java or something?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] -1 points 3 years ago (1 child)

    Just fluff, no real arguments, ok.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago* (1 child)

    I sure am glad I don't work with a moron like you who would ship a fuckton of JavaScript to users because they're too much of a pussy/old fuck to use modern practices

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] -1 points 3 years ago* (1 child)

    Lol, so angry :-D jQuery hating must be a real passion for ya.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago (1 child)

    we know that being a pain in the ass is your passion -- your coworkers definitely have noticed

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago*

    So far they didn't complain. My manager is all praise too ;-) It's kinda weird that I'm supposed to be the asshole for not being hateful of a technology. But you the hater are the nice guy?

    The things is, I don't diss on technologies without arguments. I've grown to recognize that they are tools, not a subject of passion, at least in a professional context.

  • permalink
  • fedilink
  • source
  • parent