51–60 of 72 posts
There isn't a single test for this project. How can its claims of jQuery-alike-ness be supported? Tests, or it doesn't exist.
Better yet, the author should just implement the jQuery test suite, and give a rundown of what passes and what fails.
Earlier quoted context omitted.
JQuery themselves have two versions, one with less browser support which is apparently smaller/faster. So it's weird to say that it's not-JQuery-like. Though JQuery still recommends the bigger library for most users (unless you're embedding in a mobile app or stuff like that).
jQuery 1.x is recommended over 2.x due to lack of IE8 support in the latter. If you don't have IE8 traffic on your site, you can safely go with 2.x (which isn't that much smaller to begin with).
> So, here’s the TL;DR for version 3.0 of the jQuery API:
> * If you need support for the widest variety of browsers including IE8, Opera 12, Safari 5, and the like, use the jQuery-Compat 3.0.0 package. We recommend this version for most web sites, since it provides the best compatibility for all website visitors.
> * If your web site is built only for evergreen leading-edge browsers, or is an HTML-based app contained in a webview (for example PhoneGap or Cordova) where you know which browser engines are in use, go for the jQuery 3.0.0 package.
from http://blog.jquery.com/2014/10/29/jquery-3-0-the-next-genera...
I personally currently need to support IE9 which I wouldn't class as an "evergreen leading-edge browser". I was hoping for a more in depth compatibility chart that named specific versions.
Or, you know, use the Javascript DOM APIs? They're really not at all that bad. var d = document.createElement("div"); d.className = "new"; d.innerHTML = " Hi Sprint "; Skimming through the code I'm not sure the authors really grok Javascript anyway, which might explain why they need a (pretty thin) custom API for the standard APIs. toArray should be simply this: function toArray(o) { return Array.prototype.slice.call…
But yeah cherry-picking may not be the most constructive thing however you do have good points. The DOM API is kinda funky (I wish it did some things like chaining) but it's very simple. Half the times I write a very thin wrapper around it JUST to provide some chaining.
Earlier quoted context omitted.
> the API still sucks If you want syntactic sugar, a better alternative to a client-side library (which has overhead) is to use something like TypeScript (or one of the other compile-to-JavaScript options).
they solve different problems though... syntactic sugar from TypeScript et al solve problems with Javascript the language jQuery solve problems with the various builtin APIs like DOM etc that are part of either Javascript or the web browser host
In response to your comment, polyfills are more future-proof solutions to browser compatibility, which is the only remaining problem that I see jQuery as solving well.
Earlier quoted context omitted.
Do you have any examples? In my opinion the DOM API only sucked pre-IE9 because of all the inconsistencies and incompatibilities. I have dropped jQuery completely except for when I need some of its plugins because I end up having to access the internal DOM objects too often and using $el.get(0) all over the place is ugly and a PITA.
$('.something').toggleClass('collapsed') .click(somethingClicked); This simple and readable statement will turn into a lot of lines with DOM API.
Or, you know, use the Javascript DOM APIs? They're really not at all that bad. var d = document.createElement("div"); d.className = "new"; d.innerHTML = " Hi Sprint "; Skimming through the code I'm not sure the authors really grok Javascript anyway, which might explain why they need a (pretty thin) custom API for the standard APIs. toArray should be simply this: function toArray(o) { return Array.prototype.slice.call…
To save you some work: http://youmightnotneedjquery.com/
Earlier quoted context omitted.
[deleted]
> This does get a little uglier if the intent is that you have multiple '.something' elements, though. That part of the DOM API will always be pretty gross compared to jQuery, I think. Well yeah hence my remark. Working on a single node in a single modern browser, the snippet will turn into var node = document.querySelector('.something'); node.classList.toggle('collapsed') node.addEventListener('click', somethingClic…
Why would things so south? The DOM API, while not very elegant, is very simple and straight forward. So you need some loops because jQuery hides that for you, so what? Why does using the DOM API make you think things go south fast?
Or, you know, use the Javascript DOM APIs? They're really not at all that bad. var d = document.createElement("div"); d.className = "new"; d.innerHTML = " Hi Sprint "; Skimming through the code I'm not sure the authors really grok Javascript anyway, which might explain why they need a (pretty thin) custom API for the standard APIs. toArray should be simply this: function toArray(o) { return Array.prototype.slice.call…
Modifying your example:
var d = document.querySelectorAll('div');
d = Array.prototype.slice.call(d);
d.forEach(function(el){ el.classList.add('new') });
$('div').addClass('new');Earlier quoted context omitted.
> This does get a little uglier if the intent is that you have multiple '.something' elements, though. That part of the DOM API will always be pretty gross compared to jQuery, I think. Well yeah hence my remark. Working on a single node in a single modern browser, the snippet will turn into var node = document.querySelector('.something'); node.classList.toggle('collapsed') node.addEventListener('click', somethingClic…
> And that's a best-case scenario, then you start traversing the DOM tree, adding elements, using events delegation and changing attributes and things go south fast. Why would things so south? The DOM API, while not very elegant, is very simple and straight forward. So you need some loops because jQuery hides that for you, so what? Why does using the DOM API make you think things go south fast ?
It's not just "not very elegant", it's highly inconvenient and horrendously verbose, and generally fails to take advantage of or correctly integrate with the host language as it's originally expressed in a restrictive and alien IDL.
> is very simple and straight forward
I completely disagree on both count, the API is neither simple nor straightforward, many tasks remain convoluted even with HTML5's additions of a number of long-awaited APIs (e.g.: repeatedly adding children at the start of a possibly child-less element) and the userland code is made unnecessarily complex not by a simple API but by an insufficient one (e.g. enjoy handrolling element-relative events delegation Element#matches is a pointless waste of API space).
And then there's the truly idiotic stuff added on top, such as the live nodelists which serve no other purpose than making implementations slower, more complex and event less integrable with the host language. Thank god the WhatWG managed to keep that garbage out of the new APIs they introduced.
> So you need some loops because jQuery hides that for you, so what?
So that means overly complex user code for no good reason but the base API being garbage. And jQuery does not "hide loops", that's just a side-effect of jQuery working at a higher conceptual level of manipulating nodesets.