Thanks for your hint! It would be interesting to know which IE versions are affected.
Code on plainJS has no unit tests (so far) and it's objective is a) recommending useful and field tested vanilla JS plugins and b) provide useful code snippets for writing simple JavaScript driven sites without the help of jQuery.
The snippets are tested in all major browsers, but sure, at the current stage - there are rather likely some minor bugs here and there. Yet, I think it's pretty helpful to see the principle of how things are done without jQuery. So, even if there is a bug somewhere, the snippet still points into the right direction.
I think we're all aware jQuery is written plain JS and it's not an own language ... it's an abstraction layer. The question is: Is it still necessary - or is it becoming obsolete, because nativly in browsers implemented DOM has evolved to the point where an abstraction layer isn't making things easier any more.
So, why use an abstraction layer if the base layer itself offers quite the same comfort?
It's not just about performance. That can be important for complex projects, such as image editors, but it's not why I personally prefer plain JS over jQuery.
However, ask yourself: What's your advantage of using jQuery today? Modern JS is pretty cross browser safe and syntax is becoming simpler and simpler. Modern browsers, like Chrome or FF, have already DOM4 implemented. With that, a lot of jQuery-like methods were accepted: .prepend(), .closest() ... querySelectorAll() is essetially the same es $(...) in jQuery.
Personally, I was surprised how easy and effective it is to write vanilla JS. Which is why the idea of plainJS.com came up. And as a proof of concept, plainJS is naturally fully implemented in plain JS :D And it wasn't hard, and it works properly down to IE 8.
Answering in the name of Pixabay: We started Pixabay years ago and at the time, jQuery was kind of the holy grail in terms of cross browser safe JS development. However, times change and today we would use vanilla JS for the site. And the day will come when we finally take the time to rewrite the code.
Yet, I totally admit, there are use cases where jQuery is still extremely useful. E.g. online web page editors, such as Wix.com or HubPages.com ...
I actually love jQuery! Yet, plain JS has become pretty cross browser safe and once familiar with it, it isn't harder to develop most sites in vanilla JS.
Also, useful methods previously known only to jQuery get accepted as DOM methods. E.g. DOM4 includes methods like .closest(), .append(), or .prepend(), etc. This makes plain DOM manipulation similarly readable as jQuery. But it's not yet widely supported ...
> This makes plain JS code similarly readable as jQuery.
Please correct your sentence, "This makes plain DOM manipulation similarly readable as jQuery". Or are you suggesting that when one uses jQuery, which is a javascript library dealing with DOM manipulation, one isn't writing plain javascript code ? but using some third party language ? which is a false statement.
I'm going to need to see a complete site NOT using jQuery made by the people behind this before I can accept "However, times change and today we would use vanilla JS for the site.". You probably believe that statement 100% but it's an easy statement to make without the work to back it up.
> I actually love jQuery! Yet, plain JS has become pretty cross browser safe and once familiar with it, it isn't harder to develop most sites in vanilla JS.
I fundamentally disagree with this statement and I think it comes from someone who either hasn't done it or has done it on a tiny scale which doesn't really stress your JS chops.
> Also, useful methods previously known only to jQuery get accepted as DOM methods. E.g. DOM4 includes methods like .closest(), .append(), or .prepend(), etc. This makes plain DOM manipulation similarly readable as jQuery. But it's not yet widely supported ...
All the more reason to keep using jQuery in my opinion. jQuery will use the built-in methods if they exist and "polyfill" (yes I know that's not exactly the right usage of that word) the parts the browser doesn't all without bothering the developer.
The thing I keep coming back to is when people go down this PlainJS route here is what undoubtedly happens:
1) Oh yeah! Look how cool I am, I don't need no stinking jQuery!
2) Hmm, this doesn't work the same in both browsers. I'll just created this little helper functions to handle the differences.
3) Repeat #3 1 to Infinite number of times
*) Oh... Well my helper library has grown quite big and does pretty much what jQuery does (not all of it but most) all without being thoroughly tested nor being used by a MASSIVE chunk of the internet.
You almost always end up re-creating jQuery or parts of with the same slowdowns you worked so hard to avoid. All while making your codebase MUCH less readable and making it harder to bring new developers on the team up to speed with not only your PlainJS way but also your completely custom jQuery-clone. People can keep selling them "jQuery is so big and slow" story and I'll keep not buying it... I will GLADLY sacrifice a little speed here and there for the hundreds of hours of QA/Debugging/Bug-fixing I will save and I think most developers would agree. There is a reason that browsers implemented things jQuery does... BECAUSE IT MAKES SENSE, I'd rather be on the cutting edge of what CAN be done instead of waiting for browsers to implement it and users to upgrade. It's close to the same reason we use Babel JS to transpile our ES6 to ES5, I'm not going to wait for those new features when I can be using them today which results in not only speed ups in development time but also future-proofing our code to a degree. With jQuery if there is a faster or better way to do something all I need to do is upgrade jQuery to take advantage of it which cannot be said for your approach which would result in either not using the new stuff or writing your own wrapper to handle the differences between browsers (new functionality may ship fast in evergreen browsers but the first few implementations rarely match cross-browser implementations which is why we have jQuery.
jQuery is perfect for rather complex JS driven websites, e.g. web page builders. But most websites that make use of jQuery just don't need it.
As an example website we created without jQuery: plainJS.com :-P The site provides a neat interface with features like autocomplete search and syntax highlighting. And the whole page works nicely down to IE 8.
I was surprised how simple it is - and in the process we've also released some Vanilla JS plugins. Also, I was surprised how many modern Vanilla JS plugins there already are!
So where would be the point to use jQuery on plainJS.com? It neither makes development or maintenance easier, nor is it faster - but it add a third party dependency.
You have like 1.000.000 js libs from external sources, mostly from Social Networks and you think about maintance and third party dependencies?
Oh my god..
Dude, there are so many Tools around JavaScript at that time, that you should prolly stop integrating 1 million Social Sites and instead focus on JavaScript and testing.
Especially when you want your site to be faster.
Code on plainJS has no unit tests (so far) and it's objective is a) recommending useful and field tested vanilla JS plugins and b) provide useful code snippets for writing simple JavaScript driven sites without the help of jQuery.
The snippets are tested in all major browsers, but sure, at the current stage - there are rather likely some minor bugs here and there. Yet, I think it's pretty helpful to see the principle of how things are done without jQuery. So, even if there is a bug somewhere, the snippet still points into the right direction.