It’s been awhile since I did any frontend work. Is there something that has taken jQuery’s place?

  • @[email protected]
    link
    fedilink
    English
    1023 months ago

    JavaScript itself provides the functionality jQuery became popular for. So no. Check the standard lib first before considering helper libs.

  • Max-P
    link
    fedilink
    513 months ago

    It depends what you want to do and the amount of polyfills/backwards compatibility you need.

    Nowadays most projects use one of the big frameworks like React/Vue/Svelte and others which take a vastly different approach to maintaining the DOM and for the most part you never manipulate nodes yourself, therefore you don’t need jQuery and it’s not used much anymore. JSX is weird at first but it’s actually quite nice. Some of those libraries like SolidJS have impressively low overhead.

    And for those that like to stick to just minimal JS, the browser APIs have matured a lot so a lot of jQuery isn’t really necessary anymore either. We have querySelectorAll and things like Array.prototype.forEach and Array.prototype.map and arrow functions that cut down a lot on what shortcuts jQuery would offer. Visual effects are usually done with CSS animations and just switching up classes. Everything AJAX is easier and cleaner with the new fetch() function and accessories. Vanilla JavaScript is for the most part quite usable and easy these days. You can even create custom HTML elements from JavaScript to make your life easier!

    But if you’re looking at the jQuery API specifically, you can still use jQuery today. It’s still maintained and functional. I think modern versions are pretty small too since it no longer needs half of it to be Internet Explorer hacks and other obsolete browsers that were holding web development back.

      • @[email protected]
        link
        fedilink
        3
        edit-2
        3 months ago

        Custom template language and custom DOM attributes are way weirder than just using language-native constructs (ternary operator, map/filter, variables, functions, etc.) directly like you can in JSX.

            • @[email protected]
              link
              fedilink
              7
              edit-2
              3 months ago

              template syntax is a piece of cake, takes literally 2 hours to learn everything you need and you can easily see what’s where and how the html will look when it’s rendered or not.

              and the list rendering? you are literally pointing out the best features of vue.

              • @[email protected]
                link
                fedilink
                0
                edit-2
                3 months ago

                But why bother with creating a new language, and duplicating all the features your language already has, in a weird way?

                If I want a list of UI items based on an array of some data, I can just do items.map(item => 〈Item key={item.id} item={item} /〉), using the normal map function that’s already part of the language.

                Or I can use a function, e.g. items.map(item => renderItem(item, otherData)) etc.

                JSX itself is a very thin layer that translates to normal function calls.

                • @spartanatreyu
                  link
                  43 months ago

                  But why bother with creating a new language

                  I can just do items.map(item => 〈Item key={item.id} item={item} /〉)

                  I don’t think this is a very good example. You’ve just said not to use a new language, then used JSX, a new language.

                • @[email protected]
                  link
                  fedilink
                  2
                  edit-2
                  3 months ago

                  but how do you know what renderItem does? where will the items end up?

                  we are visual creatures.

                  if I see a <ul><li></li></ul> I know it’s doing a list item for every object in given list.

                  it’s literally just html with a few added stuff, v-if to determine whether it’s rendered, v-for for iteration, dynamic class bindings and event listener bindings.

                  templating has also been around for a while for a reason it’s solid tech, thymeleaf and jsf/primefaces being prime examples.

        • @spartanatreyu
          link
          2
          edit-2
          3 months ago

          DOM attributes are built for browsers and frameworks to take advantage of.

          The style of some of those frameworks to stick symbols in there is downright weird. But that only goes against those particular frameworks. It doesn’t impact how good DOM attributes actually are.

        • @spartanatreyu
          link
          1
          edit-2
          3 months ago

          Svelte uses labels, so Svelte itself is weird compared to everything. Except in a way to assembly and 50s goto-control-flow styled code.

          • @[email protected]
            link
            fedilink
            13 months ago

            You mean these? Does it use them internally, because I haven’t really seen them in any Svelte code.

            If so, what does it matter what the compiler does in order to make your code work, so long as it’s legal? It’s perfectly valid JS, that’s all that counts.

            I wouldn’t say Svelte is weird as much as it’s different. That’s the whole point after all. Instead of adding a bunch of library bloat and keeping an entire copy of the DOM to constantly compare to and derive changes from, it compiles your components down to native JS that manipulates the DOM directly, like you would by hand. Except of course the compiler uses different ways to achieve that than you would, but that’s because it doesn’t have to care about readability, as long as it creates valid and efficient code.

      • DroneRights [it/its]
        link
        fedilink
        English
        -13 months ago

        Vue sucks. A pretty graphic of a CGI robot convincing untrained programmers to merge their web files and produce unreadable garbage as the output file.

      • kellyaster
        link
        fedilink
        23 months ago

        Same here, tbh I haven’t thought about jquery in a while and kinda came in here to see if it’s dead or not. Yeah frameworks have largely eliminated the “need” for jquery libraries for most projects. It’s weird to think about, didn’t take too long to happen.

      • @spartanatreyu
        link
        13 months ago

        What do you mean about animations?

        Every use-case I can think about is already well supported by vanilla css/js without libraries or frameworks. (not including really out-there use-cases like game engines or image editors)

        Can you give an example?

        • @[email protected]
          link
          fedilink
          English
          1
          edit-2
          3 months ago

          jQuery Effects are usually easier to work with than CSS alternatives, single predictable line with events vs multiple lines that you can’t hook thing into easily. Note that I’m not defending jQuery nowadays I even void it and always prefer vanilla, but there are things on that library that are objectify easier to do.

          • @spartanatreyu
            link
            43 months ago

            I think you’re forgetting about the Animation API.

            Example: making something flash once to get a user’s attention

            element.animate( {opacity: [1, 0, 1]}, { duration: 500 } );
            

            Use CSS animations everywhere you can, but if you need to be able to hook into an animation (to dynamically change the speed, cancel something, sync animations together, etc…) you should be using the Animation API.

            There’s never a need for jQuery.

  • 𝒍𝒆𝒎𝒂𝒏𝒏
    link
    fedilink
    233 months ago

    A lot of jQuery’s features are now available in native JS - would also suggest just using native JS anyway because jQuery won’t throw any errors into the console if a selector matches no elements etc.

    The only additional library I’ve needed recently for (personal work) is Axios for requests - easier than working with the Fetch API in some cases

    • Nerd02
      link
      fedilink
      English
      83 months ago

      Axios for requests - easier than working with the Fetch API in some cases

      May I ask what cases? I used to use Axios on Node, before they implemented the fetch API over there but I haven’t touched it since. And defintiely never used it on the client. Could you make an example of some case where it’d be easier to work with Axios than with fetch?

      • 𝒍𝒆𝒎𝒂𝒏𝒏
        link
        fedilink
        73 months ago

        For me it’s the ability to set up a shared instance with the base request URL, and set headers for things like the user’s token, allowing all requests made with that shared Axios instance to be sent to the right path with the token without needing to define them for each individual request.

        To be honest though something similar can be done with spread syntax in the Fetch API’s options parameter

  • @[email protected]
    link
    fedilink
    English
    18
    edit-2
    3 months ago

    No, because the current practices have shifted from writing html+css+js in the classic style to using JavaScript frontend frameworks like vue, react, angular, svelte… Which offer a lot of features that would jQyery give you but also removed the need for some of them.
    The paradigm has shifted and I don’t think jQuery is used anymore (atleast not for new projects).

    • @[email protected]
      link
      fedilink
      143 months ago

      To explain this a bit further, the main difference between older jQuery-based projects and newer (React|Vue|Angular|Svelte)-based projects is imperative vs. declarative programming.

      It used to be that you give commands (e.g. “when the user clicks this button, change that label content and add CSS classes to these elements”). Very quick to add something small, but also hard to grow and maintain well. It’s easy to forget a command in some code paths.

      Nowadays you declare state, and define how your UI is derived from that. This means you don’t give commands to change things, instead you change data and your UI is updated automatically. This makes it much easier to understand a component, and allows for maintainable growth.

  • @[email protected]
    link
    fedilink
    173 months ago

    Jquery is a swear word in professional front end contexts, the replacement is transpilation and dropping ie support.

    Personally I used jquery up until react and babel got hot, now I never touch the dom directly with jquery and no longer have a need for the polyfill features as I rely on babel preset-env to support the browsers we have selected (especially for things like promises/async await/es6+ features)

    • @spartanatreyu
      link
      13 months ago

      What do you still need babel for?

      The only features that come to mind for anyone who needs to reach out to babel today would be those working on the tc39 proposals themselves.

  • @[email protected]
    link
    fedilink
    113 months ago

    IIRC most stuff can be done with vanilla JS in any modern browser.
    Although, I’ve been doing little front-end work, and mostly for personal projects, nothing fancy nor production ready, so someone might have another opinion about using jQuery.

    • @CodeBlooded
      link
      63 months ago

      Not sure why downvoted. HTMX does seem to be becoming popular. I prefer the simplicity of it.

      • Rikudou_Sage
        link
        fedilink
        323 months ago

        Because it’s only gaining traction, while the commenter made it sound like everyone was using it instead of jQuery. Which is simply not true, everyone is using Vue, React, Angular, Svelte and so on.

    • @asyncrosaurus
      link
      33 months ago

      Htmx for server requests and AplineJS for client interactions