You're pointing out an IE problem, not a javascript problem that isn't present in other browsers.
And your point is? Pointing the blame at a different source doesn't mean the problem isn't present. If a client needs IE support, what do you do? Write the code three times? Detect IE and redirect the user to chrome-frame, then cry when you don't get paid? I don't care who caused the problem. Just that it wasn't me, I can't fix it, and I have a deadline to meet and constraints to follow. jQuery is a lifesaver.
You can basically sum up this entire rather ridiculous site with "Yes, you don't need jQuery, you can just use the built-in methods, but using jQuery is generally more pleasant, more consistent, and involves less typing". One particularly egregious example from the site: $('#foo').removeClass('bold'); vs. document.getElementById('foo').className = document.getElementById('foo').className.replace(/^bold$/, ''); The au…
.classlist() [1] is coming [2]. It'll allow you to do: document.getElementById('foo').classList.remove("bold"); Sure, it's still more verbose. But a lot of what jQuery does is slowly being obsoleted by better native javascript apis. [1] https://developer.mozilla.org/en-US/docs/Web/API/Element.cla... [2] http://caniuse.com/#feat=classlist
While I'm waiting for that, and still writing applications that have to support ancient versions of IE, I think I'll stick with Jquery. Can't wait for the future though
make building your site more complicated than compiling an entire Linux distribution from source http://browserify.org/ Browserify is not at all complicated. spend days choosing between a bunch of almost identical micro-libraries for every little thing you need to do Just search npm and pick the one that is being used the most. lock yourself into a proprietary framework that will be considered legacy code as soon as…
The problems that npm and browserify solve are at the level of builds and package management. You could use any number of trendy frameworks and tools on top of this. Right. But last week it was RequireJS, not Browserify. Today, as well as NPM, we have Bower and gem and pip and however many other package managers. Last week it was Angular, this week it’s React, and next week maybe it will be Web Components. Last week…
In a project right now that uses grunt, gulp, bower, npm, and angular (w. bootstrap). Just getting up and running to the point where we could actually code took too much brain. Going along nicely now though, at least until something needs styled, then there's all the bootstrap stuff and custom css from the main project bleeding into our plugin :)
I don't mind using a library for dom manipulation, or for xhr, or for missing ES5 function ... My problem with jquery is that it does all of it, in a very entangled way. This makes it very tempting to mix parts of your application that really shouldn't know about each other (like dom manipulation (UI) and XHR (IO)). I prefer to use a dedicated library for all of those things and to hide the fact that I am using a particular library to the rest of the application. I've seen standardising on one true huge library throughout an application gone wrong several times and it's very hard to refactor your way out of it.
The problems that npm and browserify solve are at the level of builds and package management. You could use any number of trendy frameworks and tools on top of this. Right. But last week it was RequireJS, not Browserify. Today, as well as NPM, we have Bower and gem and pip and however many other package managers. Last week it was Angular, this week it’s React, and next week maybe it will be Web Components. Last week…
We could have an actual discussion about the evolution of front-end tools if you could leave some of your hyperbolic rhetoric at the door. But last week it was RequireJS, not Browserify. I used RequireJS for a number of projects before being introduced to browserify and npm. I had reservations at first because I didn't want my front-end code to be reliant on a back-end environment even if the language was Javascript.…
Yes, why use a tried and tested tool that can be incorporated into your site and served efficiently with just a single extra line, when instead you could make building your site more complicated than compiling an entire Linux distribution from source, spend days choosing between a bunch of almost identical micro-libraries for every little thing you need to do, and lock yourself into a proprietary framework that will…
make building your site more complicated than compiling an entire Linux distribution from source http://browserify.org/ Browserify is not at all complicated. spend days choosing between a bunch of almost identical micro-libraries for every little thing you need to do Just search npm and pick the one that is being used the most. lock yourself into a proprietary framework that will be considered legacy code as soon as…
> Just search npm and pick the one that is being used the most.
This is basically the algorithm for picking jQuery