You might not need jQuery (2014)

"If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency"

That said, optimization techniques have gotten good enough that you might be able to just let a build tool do that for you. If you really still want to use jQuery.

On the web, user experience should really be a higher priority than developer experience.

For reference:

  // JSON
  const data = await (await fetch('/my-url')).json();

  // Post
  await fetch('/my-url', { method: 'POST', body: data });

  // Request
  try {
    const resp = await fetch('/my-url');
    // ...
  } catch (e) {
    // ...
  }

  // Fade In
  el.animate({ opacity: 1 }, 400);

  // Fade Out
  el.animate({ opacity: 0 }, 400);

  // Hide
  el.hidden = true;

  // Show
  el.hidden = false;

  // After
  target.after(el);

  // Append
  target.append(el);

  // Before
  target.before(el);

  // Each
  for (const el of document.querySelectorAll(selector)) {
    // ...
  }

  // Empty
  el.replaceChildren(); // or el.textContent = '', depending on which you find clearer

  // Filter
  [...document.querySelectorAll(selector)].filter(filterFn);

  // Get Height
  el.clientHeight;

  // Get Width
  el.clientWidth;

  // Matches
  el.matches('.my-class');

  // Remove
  el.remove();

  // Delegate
  document.addEventListener(eventName, e => {
    const match = e.target.closest(elementSelector);
    if (match) {
      handler.call(match, e);
    }
  });

  // Trigger Custom
  el.dispatchEvent(new CustomEvent('my-event', { detail: { some: 'data' } }));

  // Trigger Native
  el.dispatchEvent(new Event('change'));

  // Extend
  Object.assign({}, objA, objB);

  // Parse HTML
  (new DOMParser()).parseFromString(htmlString);

  // Type
  obj[Symbol.toStringTag];

"Every single example?" Are we reading the same page? I was fairly surprised to find that 75% of the alternatives are literally one-liners. There are a handful that swell up to 10-15 lines of code, but I would say it's a very small portion, far from "every single example."

But isn't the point here that you can wrap the 10-15 lines into your own function which you can then call with just a single line of code?

So you "might not need JQuery" because you can program it yourself following the examples given, and can choose which parts of it you need and want to package with your app.

"jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.

If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency."

If you're shipping a big application and need to use a large number of these utilities, by all means use jQuery. But if you're shipping a small library and only need one or two of these functions, you might want to forgo the dependency. Using jQuery in your library forces it as a dependency onto everyone who uses your library, potentially making them deal with version conflicts if your version of jQuery doesn't align with their version of jQuery (or the version that another dependency wants).

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1552313

That said, I was once a single page app skeptic but I now think React and Vue are great alternatives to HTML/templates that compile to HTML if you have a reasonably complex front end. Pre-React and Vue, in the Angular.js/Ember.js/Backbone era, SPAs were not in a stage of maturity that made it simple or optimal to use them as a primary front end. Today I'd say for a complex FE go ahead with React or Vue, if you have a very simple FE, definitely consider HTML/template-to-HTML as a serious option.

Hacks with :checked are well known, but you can do a ton of stuff with :focus-within, :invalid, :target, :hover, <details>/<summary>/[open], grids/flexbox/visibility, and the adjacent-sibling selector. <dialog> is almost there, although it still needs a JS activation hook.

It feels really good to have a complete application UI that works with JS disabled, and I can still progressively enhance it with JS for necessary perversions of HTML like ARIA etc.

(and no, I don't mean WebAssembly - bring back static websites!)

Look at svelte if you haven’t.

I strongly recommend reading through the newly rewritten official tutorials in the Redux docs, which have been specifically designed to show our recommended practices:

- "Redux Essentials" tutorial [0]: teaches "how to use Redux, the right way", by building a real-world app using Redux Toolkit - "Redux Fundamentals" tutorial [1]: teaches "how Redux works, from the bottom up", by showing how to write Redux code by hand and why standard usage patterns exist, and how Redux Toolkit simplifies those patterns

The older patterns shown in almost all other tutorials on the internet are still valid, but not how we recommend writing Redux code today.

You should also check out the Redux "Style Guide" docs page [2], which explains our recommended patterns and best practices, and why they exist. Following those will result in better and more maintainable Redux apps.

[0] https://redux.js.org/tutorials/essentials/part-1-overview-co...

[1] https://redux.js.org/tutorials/fundamentals/part-1-overview

[2] https://redux.js.org/style-guide/style-guide

- Got rid of redux because it's shit

- Got rid of Material UI because it's bulky and its API changes are painful, replaced it with tailwind

- Got rid of React Router because it's bulky and its API changes are also painful, replaced it with a simple hook

Because of bloated frameworks and slow convenience libraries the front end is a very low barrier of participation. The problem there is then that peoples’ entire careers and life worth are stacked around these fragile glass houses and the only thing they want is to avoid being exposed as a fraud.

Is writing a killer product without all the bullshit that impossible? No, clearly not, but that completely misses the point.

Sorry to pick on your post over the million and one other ones that pop every time jQuery gets mentioned in HN (same for the "look at my my blog website that just uses HTML/CSS" posts), but why is it silly? There's no halcyon period where it was simpler and easier, and the tools are in general much better than they were.

As someone who worked on large jQuery apps before React, I think most people would jump back into React or Vue in the first chance after seeing a non-trivial jQuery app. Not to mention there was a lot of "bloat" in those apps, too: Backbone, Bootstrap, Moment.js...

jQuery was amazing for small things, for landing pages, for some Bootstrap components here and there, and for sprinkling the page with progressive-enhanced features. And it still is probably the best choice.

But it was not a great fit for moderate-to-large apps. And it was a terrible fit for moderate-to-large apps that only consumed data from an API.

Not saying React and Redux are good, but I think at least the parts of React, Angular and Vue that replaced jQuery were definitely a step in the right direction.

I'm also not saying that "big apps" are the way to go. If I could I would go back to server-side rendered HTML and modern CSS, but it has become hard to find developers that are into it.

They're listing APIs that you used to need jQuery for that are now natively supported by the browser. This is for people still doing the jQuery style of development.

If we're really clever we can probably get it up to several megabytes, require three languages and have it run from an embedded C compiler written in Webassembly.

Of course, it will only work in Chrome but really who wants to waste time testing in browsers nobody even uses amirite?

https://en.m.wikipedia.org/wiki/Program_optimization#When_to...

If your code can execute 10x faster without jQuery then the optimization is not premature. If a developer takes twice as long to write any code the problem isn’t optimizations at all.