5 ms·

So what was the struggle with vanilla js? I'm just curious :) One of the first things I learned in web development was jquery but right now I never use it. Ev

• skizm 7y ago
  Not really a struggle, but why would you want to type ten lines when two will do?
  • JaTochNietDan 7y ago
    This is exactly it summarised. It's more frustration at the extra verbosity I had to put in to do something I'd become so accustomed to doing in a line or two.
  • RodericDay 7y ago
    what examples do you have in mind?
  • akmittal 7y ago
    Isn't that different reduced a lot with ES6+? By adding jQuery load time increase by almost a second or two
    • dmitriid 7y ago
      > Isn't that different reduced a lot with ES6+? ES6+ does not replace browser APIs. There's no ES6+ way around this: const el = document.createElement(...) el.setAttribute(...) el.classList.toggle(...) const parent = document.getElementById(...) parent.appendChild(el) You either do that in one line of jQuery, or end up writing your own wrappers if you need to do this more than once.
      • 52-6F-62 7y ago
        I personally prefer what you just outlined over jQuery. It's more explicit—that will almost always win with me.
        • dmitriid 7y ago
          That was simplified code to create just one element and add it to the DOM. Once you write it not once, but twice, or five times, you will either switch to a lib/framework, or to jQuery, or will write your own wrapper not that different from jQuery.
          • 52-6F-62 7y ago
            Not for something so simple. It's trivial to abstract small, oft-repeated actions like that to their own function. As I do, regularly. And then I can give it a readable name, like `createElement` or `insertElement` with an interface like: insertElement(type: string, text?: string. attributes?: object, parent?: string): void; I prefer writing something like that with some minor case-handling over pulling in a library every time I meet a repeatable fragment. If I know I'm going to run into a large host of needs, then it's a different story. But most of the time I find jQuery overkill and somewhat opaque.
            • dmitriid 7y ago
              I wonder why you found necessary to repeat what I said but in different words? :)
              • 52-6F-62 7y ago
                But I expressly wouldn't include a 30-100k library just to wrap a couple of repeated functions. I happily write them myself. It's a few seconds of work, really.
          • raydev 7y ago
            The reusable functions you need from jQuery likely don't justify jQuery's size. It's better to write or copy/paste wrappers for everything you need.
  • austincheney 7y ago
    There are a lot of answers to that question, but they all summarize down to: you are the developer not the user. * Perhaps those 10 lines execute faster * Perhaps those 10 lines are exactly 10 lines, where jQuery is 2 lines plus a 65k library * Perhaps those 10 lines work equally in multiple environments (node, deno, electron, browser) where jQuery does not. * Perhaps those 10 lines sit behind a custom abstraction that actually looks like a single method * Perhaps those 10 lines do something jQuery does not * Perhaps those 10 lines scale and extend in ways jQuery does not * Perhaps those 10 lines have a desired side effect
    • losvedir 7y ago
      > * Perhaps those 10 lines work equally in multiple environments (node, deno, electron, browser) where jQuery does not. Heh, and here we come full circle. I remember back when the whole point of jQuery was to handle the different underlying JS implementations for you.
      • austincheney 7y ago
        Yeah, that always passed me off. I had little trouble writing cross browser code, but to be helpful jQuery would add code especially for IE that always got in the way when debugging cross browser compatibility problems.
    • skizm 7y ago
      I'm the user of the language, and JS is a bad user experience.
      • austincheney 7y ago
        So you are the primary end user of everything you write in JavaScript? I think you are deliberately being hyperbolic to justify ignoring micro improvements to end user concerns for a self-serving convenience.
        • skizm 7y ago
• sametmax 7y ago
  The fetch API is nowhere as convenient as the jQuery one. It requires craft to get addEventListener() on par with on(). jQuery comes with many implicits loops that save you time. fadeIn() is easier to handle than the equivalent css. jQuery supports edge if you target it (things like prepend(), parent() work on it). Error handling is just better. E.G: jQuery().val() will not raise an error if there is no match while document.getElementById().value will. And probably a hundred of other little details that won't come out of my head but that will grind my gear if I start working on code. Chaining is awesome to manipulate DOM. The imperative API is very verbose. So. Many. Plugins. I'm more of a VueJS guy now, but if I have only a quick page to setup, the 30ko of jquery are better than anything I can produce to wrap my repetitive code.
  • lampe3 7y ago
    Interesting all of these points for me are kind of a non-issue. The fetch API is more powerful than the Jquery one. Since forEach is implemented in es6 I just use that. I see the point that you need it sometimes but still I would prefer some other lighter solutions.