Comment on Which side are you? Javascript or Typescript

• SnowdenHeroOfOurTime@unilem.org ⁨1⁩ ⁨year⁩ ago

  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

  source

  • fidodo@lemm.ee ⁨1⁩ ⁨year⁩ ago

    Even if you do, you can still use most modern js features with transpilation.

    source
  • severien@lemmy.world ⁨1⁩ ⁨year⁩ ago

    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.

    source

    • SnowdenHeroOfOurTime@unilem.org ⁨1⁩ ⁨year⁩ ago

      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.

      source

      • severien@lemmy.world ⁨1⁩ ⁨year⁩ ago

        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.

        source

        • -> View More Comments
    • fidodo@lemm.ee ⁨1⁩ ⁨year⁩ ago

      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.

      source

      • severien@lemmy.world ⁨1⁩ ⁨year⁩ 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.

        source