91–100 of 143 posts
In a way, it's an end of an era. What jQuery did for the industry when it first came out was amazing. Normalizing differing browser APIs, making cumbersome APIs more palatable, providing powerfully expressive query selectors, enabling fairly trivial plugin development, and the nifty monadic chaining. Some of those issues have been addressed by browsers, making vanilla JS a little less unreasonable. For other bits, ra…
Can anyone explain when did jQuery start to fall back in the tech era? What were its failures? It is a bit sad to say goodbye to such an old friend.
Nikanj isn't wrong (and is funny), but I think the other (more justifiable) reason is that jQuery largely isn't necessary anymore: when it came out, there were an uncountable number of browser incompatibilities that needed painting over, and APIs for remote requests, DOM querying & manipulation and the like were very immature, so a library to make everything usable was extremely valuable. Now, those APIs are mature &…
(I couldn't confirm this by googling, so if anyone can confirm or deny that this is the case I'd love to know!)
Now they just need to replace coffeescript with es6/babel.
I'm not a fan of CoffeeScript but do they really need to lug the huge amount of dependencies babel brings along with it? Why not target ES5 with some ES2015 sprinkles in depending on compatibility and slowly work towards ES6?
The only way we can use them is through transpiling. This will be the case for at least another three or four years.
Earlier quoted context omitted.
I agree with you about jQuery getting quickly out of hand if you want to create something like a one page app and you should certainly use something like React or Angular. I do use it. But to do a quick Ajax post, read some data and display a message or show and hide something jQuery is awesome. To tie a quick event listener to a dropdown and do something or to find children of some element jQuery is still few lines…
I agree to an extent . I think in the example you mention, I would probably do it in vanilla JS. XHR is a negligible amount of code with vanilla javascript. It's also the same thing with event handlers but you do not need the overhead of the entire jQuery library. If you want animations, I would borrow a few CSS declarations from animate.css and add/remove classes or data attributes as needed. I think it really depen…
That was one of the pains the Fetch API cured for me. The syntax and overall concept is just so much nicer.
I was using Nanoajax library before that. It's great (and light, 620 bytes gzipped), but I moved almost completely to Fetch as soon as i started getting used to Promises more.
I guess libs like these and maybe even the Fetch in current browsers were somehow inspired by jQuery's $.ajax…
Earlier quoted context omitted.
> No, that's simply not true. Wow, really?! I stand corrected! I'm glad you took the time to bestow this illuminating perspective. Here I am thinking that 20k+ files for a Hello World App was a bit much but your response really cleared things up for me, thanks!
Can we please stick to the facts? Where exactly does it promote micro-modules? For example, React was repeatedly criticized for not splitting virtual dom implementation into a separate npm package. That's completely opposite side of the spectrum. > Here I am thinking that 20k+ files This are separate files and not necessary as many separate modules. Different things, really. That's ought to be solved with some kind o…
Start from any recommended starting React dev template and count the no of files, seperate tools, config files and runtime dependencies required to maintain an iterative dev workflow. The dependencies have gotten so out of hand Facebook's even developed their own package manager to manage it since npm has issues managing it properly.
> For example, React was repeatedly criticized for not splitting virtual-dom...
That's for production deployments, it doesn't represent the complexity and cognitive overhead required during development.
> I'm surprised node.js/npm doesn't have something like that implemented yet.
There's a number of bundlers available, it just requires integrating more tools and maintaining more config files.
Earlier quoted context omitted.
I agree to an extent . I think in the example you mention, I would probably do it in vanilla JS. XHR is a negligible amount of code with vanilla javascript. It's also the same thing with event handlers but you do not need the overhead of the entire jQuery library. If you want animations, I would borrow a few CSS declarations from animate.css and add/remove classes or data attributes as needed. I think it really depen…
> XHR is a negligible amount of code with vanilla javascript That was one of the pains the Fetch API cured for me. The syntax and overall concept is just so much nicer. I was using Nanoajax library before that. It's great (and light, 620 bytes gzipped), but I moved almost completely to Fetch as soon as i started getting used to Promises more. I guess libs like these and maybe even the Fetch in current browsers were s…
Earlier quoted context omitted.
I use plain JS. Can you give an example of a typical line of jQuery that you prefer over vanilla?
I have an example to which maybe you or someone else can suggest a better 'vanilla' solution. Would love to hear suggestions. With jQuery I'd often do $( ).on('click', , callback); crucially, because events bubble up, even a click on a child element of will register as a click on the target element. in plain js it doesn't seem to work that way. I'd do .addEventListener(), but I'd run into the problem that the event.t…
function delegate(el, evt, sel, handler) {
el.addEventListener(evt, function (event) {
let t = event.target
while (t && t !== this) {
if (t.matches(sel)) {
handler.call(t, event)
}
t = t.parentNode
}
})
}
You'll need a matches polyfill if supporting browsers that don't support el.matches
Earlier quoted context omitted.
See you've made an effort to go back to document.getElementBy... where I just wouldn't be able to go back to that after 10 years of such concise syntax that so closely matches CSS. But I'm a bit lazy and tend to find the easiest and quickest way to get to the result.
I find that the current state of things is that, indeed, jQuery is often still worth using, but only just , and especially if older browsers have to be supported. If download size is at all an issue, jQuery is the first thing to go. I have a tiny collection of helper functions that make 'plain js' almost as simple as jQuery in most cases. Almost. For example, at the very least I'll have a '$' helper function that mak…
I'm not a Ruby/Rails dev, but why the hell was it ever included? :o Isn't Ruby a backend language and Rails a backend framework? :o
There's some weird Rails specific things that I am not too sure make sense (like having the ability to use DELETE as a data method for a hyperlink) but make CRUD apps simple to follow in terms of the Rails way-of-thinking.
I'd have to check the source, but I think it was also used for AJAX forms. I think the safe answer is that Rails is great to create something quick but the built-in helpers aren't always very sane.