"There's no real gain from jQuery, although syntax is typically slightly shorter." and with that comment the author completely misses the point of all wrappers/libraries all while stating something that is just completely untrue: "There's no real gain from jQuery". It's like saying "There's no real gain from jQuery, it just saves you a ton of time and energy but besides that it sucks".
This is a terrible idea. I've said it before and I'll say it again unless you only have to worry about support the newest Chrome/FF and even then the jQuery syntax is MUCH nicer than plain JS.
It's simply not worth a developers time to account for all the different ways to accomplish the same end-task in all browsers. I know that when I use jQuery I can count on it working the same in every browser without having to test it extensively. The same cannot be said for plain JS. I know this is getting better but if you need to support a few versions back of IE (8/9) then not using jQuery is like shooting yourself in the foot. I am fully in support of using less jQuery and being smart about caching selectors and the like but not using jQuery is very bad advice unless you are suggesting a full framework in it's place which does all the things jQuery does.
Let's take a quick minute and look at the company behind this site: http://pixabay.com/ They are a picture hosting (possibly selling? IDK) site. I'm sure FOR THEM they can get away with just plain JS but for people actually building web apps or building multiple client sites it's not nearly as easy. So not only do I think their site would be fairly simple to create without jQuery if we take a little look at the source we see THEY ARE USING jQUERY! Just think about that, the company behind a website urging you not to use jQuery is using jQuery on their own site...
Lastly using libraries that don't use jQuery will (9 times out of 10) set you up for failure unless the developer behind the library did extensive tests in every browser. I personally am more a fan of things working everywhere then trying to shave off the time that jQuery might add. If you want to convince me on how bad jQuery is you are going to need to show some benchmarks to prove your point. I, for one, do not accept that across the board jQuery is slow and using native JS will make my app "load and react blazingly fast". With or without jQuery you can write shitty code, it's not jQuery's fault it's the developers...
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.
While I agree with you that the author completely missed the point I have to disagree with this assertion:
" I've said it before and I'll say it again unless you only have to worry about support the newest Chrome/FF[...]It's simply not worth a developers time to account for all the different ways to accomplish the same end-task in all browsers.[...]Lastly using libraries that don't use jQuery will (9 times out of 10) set you up for failure unless the developer behind the library did extensive tests in every browser. "
What you purport was true 4 years ago. Yes IE 9 and 10 are kinda crappy but essentially every browser in the past 4 years supports at least the same way of manipulating the DOM. Yeah there are weird quirks when you use non standard stuff like innerHTML with IE but if you're sticking to the HTML / DOM spec then unless you're targeting an older browser there is a good chance you're fine. You should be using feature detection for graceful degradation regardless if you're using jQuery or not.
Yeah jQuery providers a better API and yeah if you want to support older browsers then it's a good idea. But saying not using jQuery is only targeting the "newest" browsers is just disingenuous.
but but but "you might not need jquery", all you need is a million extensively tested hand coded if typeof !== undefined and try catches to support enterprise clients. Why would you not want to do that?
Obviously PlainJS author isn't going to do the debugging for you when a client calls you at 2am to ask you why some widget is broken on an old version of webkit on his android.
Because that's why serious front-end developers use jQuery. Because the jQuery team actually tests the code against a wide range of browsers. All these libs hacked in an afternoon are lucky if they have at least some tests...
And again, the DOM=/=Javascript. Jquery is as vanilla JS as all these libs. But some people still can't tell the difference. An API isn't the language. There is no "document.createElement" in the Javascript spec.
Plain JS is better suited for developers who are writing large apps. jQuery is a nightmare to maintain in large applications and popular SPA apps have foregone jQuery (except Backbone.js). jQuery has its place in small websites that don't do much but when you need to code logic into things, jQuery is just not suitable.
The problem with the DOM is the DOM itself and how it is written. React decided to abstract it completely, AngularJS decided to bundle its own version of jQuery with it and try to restrict DOM manipulations within directives. But both still do DOM manipulation under the hood, whether it is with jQuery or framework X it doesn't matter, provided the DOM abstraction works on a wide range of browsers and is extensively tested.
But what is wrong is saying jQuery isn't plain JS or "Vanilla JS". Which is stupid since jQuery IS a DOM abstraction and any javascript library written in javascript is plain or vanilla js. It can only mean that the person who says that doesn't know the difference between the DOM and Javascript.
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?
If you're using jquery to make apps instead of an app framework like react or angular, you are guaranteed to be writing spaghetti. If you're using it to enhance pages sent from the server, it's hard to call that "serious".
> If you're using jquery to make apps instead of an app framework like react or angular, you are guaranteed to be writing spaghetti.
This is just flat out wrong. Frameworks provide a layer (or multiple layers) of abstraction to make code organization and maintenance easier. How that translates into "guaranteed to be writing spaghetti" I have no idea; those frameworks can't force you into their coding structure and you can still write absolutely horrible spaghetti in them (I've seen some really bad angular that should have been simply set on fire and re-written).
In fact you can write horrible spaghetti using basically any language or framework. It comes down to discipline and experience, in my opinion, when you want to write clean and easy-to-maintain code.
> If you're using jquery to make apps instead of an app framework like react or angular, you are guaranteed to be writing spaghetti.
I definitely do not need react or angularjs. Trust me I don't.
Because I know and respect SOLID principles and I don't need a framework to enforce them.
If you can't tell what should be in the view from where your business logic should be OR you need a framework to enforce these principles then you're going to write spaghetti code no matter what, jQuery or not, react,angularjs or not.
And by the way Angular 1.x works quite well with jQuery, Angular 1.x even includes a light version of jQuery.
Yes, document.createElement exists and is documented. But check the links at the bottom of the page: the function comes from the DOM and HTML5 specs, not from the Javascript spec.
I seriously don't know what these "puritan"/back-to-the-roots people are trying to achieve here.
First, when they mention raw/plain/vanilla js, they 99% of the time mean DOM and not js.
So, there you go, case closed, next please.
But for the sake of argument, let's explore both sides of the debate. Yeah, learning and mastering js and DOM is very important and if you rely only on jQuery or any other library or layer of abstraction to get by with web development, that would definitely hurt your potential and chances of getting ahead within any organization or specifically my team but let's put this point aside for a moment here and discuss an equally if not more important one.
The main criticism leveled against using libraries to manipulate the DOM is that they add another layer of abstraction and subsequent maintenance overhead and also the perceived or alleged performance degradation in terms of time required to complete the necessary operations.
Without downplaying these "legitimate" concerns, I have not seen not even once one of these critics faking being impartial in their assessment of DOM libraries by listing their unquestionable advantages they bring to the table like next-generation selectors like :has(), :contains(), :gt()...etc and not having to write a lot of boring and suffocating boilerplate garbage just to apply some style info to a set/list of DOM elements just to prove to those reactionary folks that I'm a capable dev.
Sorry guys, if jQuery or lo-dash is already used and bundled with the project, I'd use it in a blink of eye, if it is not included, I just wait and see if I'm writing a lot of boilerplate garbage just to get the basic functiosn I expect and take for granted when manipulating the DOM, I'm bringing to the mix to your chagrin.
parents('.classname') >>>>> parentElement.parentElement.parentElement.parentElement Ad nauseam
> The main criticism leveled against using libraries to manipulate the DOM is that it adds another layer of abstraction and subsequent maintenance overhead and also the perceived or alleged performance degradation in terms of time required to complete the operations.
I partially disagree with your assertion; layers of abstraction are not always bad and let's face it the DOM API, while simple, isn't as nice to write as jQuery due to its verboseness. But the main criticism I've seen is the size and speed, not abstraction and speed. If you're working on a project that doesn't require supporting older browsers then you don't really need much of what jQuery includes except maybe its simplified API. Calling native query methods in the browser is always faster if they're fully supported.
I certainly wouldn't recommend dropping jQuery for only performance reasons though. jQuery is awesome; it makes the DOM API less stupid and it helps a lot with older browsers. But I also don't think it's bad at all to completely drop the use of jQuery if you don't have old browser requirements.
> parents('.classname') >>>>> parentElement.parentElement.parentElement.parentElement Ad nauseam
While this looks terrible I would argue your code shouldn't need to do this in native DOM or jQuery. Ever. This looks like something you might do in an emergency / patch but any html structure and / or front-end framework you're using that requires this has a serious issue. In my opinion.
This is a really well done site, and it's a perfect resource for someone learning JavaScript.
Most new devs get it wrong when choosing what to learn. They forgo learning plain JS in favor of jQuery, then they forgo jQuery to learn a front-end framework. It should be the other way around. Do absolutely all you can with plain JS first, then use jQuery as needed (and make sure your copy of jQuery only has what you need), and then only for complex interactions, use a front-end framework, but most interactions on a website aren't complex enough to merit one.
For any site that is mostly content with some interaction, well written pure JS should be the solution you try first.
> Most new devs get it wrong when choosing what to learn.
Hear me:
"most new java devs get it wrong when choosing what to learn,
they forgo learning plain Java in favor of Spring MVC."
Now you understand how stupid you sound. Spring MVC is a actually plain Java just like jQuery is actually plain Javascript. jQuery is a library that abstract the DOM , not Javascript. jQuery IS a DOM abstraction, not Javascript abstraction ,it is not a third party language that compiles to javascript.
Your point would make sense however if you said:"They forgo learning the DOM in favor of jQuery". Unfortunalty you are part of the problem. Either you are not a developer thus don't know what you are talking about OR you can't tell an api from the language itself. Either way your comment is plain stupid and doesn't help. What you should tell beginners is "learn the difference between the DOM and Javascript". But you're not saying that, you're blaming a library for whatever reason.
I'm not attacking him, I'm attacking ignorance which leads to people writing what he wrote then perpetuating this false dichotomy between "vanilla javascript" and jQuery. jQuery IS "vanilla javascript" despite being a DOM abstraction. Am I being pedantic? No i'm not. This is a fundamental mistake A LOT of frontend developers do. Javascript IS not the DOM.
Clearly, you feel really passionately about this topic, which makes your choice of words all the more unfortunate. If you had made your points kindly, rather than saying "Now you understand how stupid you sound.", I would have loved to engage with you, however now I think I'll take a pass.
Comments like yours not only degrade the HN community, but the coding community in general. I'm not going to engage or dissect your comments any further, rather I'm just going to ask that for the sake of this community and our profession, you hold yourself to a higher standard next time you comment.
Not a half bad idea but most of this is already covered in awesome resources like the MDN. This would have been perfect 5 years ago but I'm not necessarily convinced of its usefulness today. The MDN has examples and explains the why and how; this just has examples.
One nit pick from my browsing on the site
>> Alternatively, use DOM methods for creating content nodes and append them to the new element. This approach requires more code, and is in general slower or equally fast as working with innerHTML
So I would suggest using best practices and simply omitting the innerHTML bit versus laying out all of the possible options. Yeah there are cases where it's faster but that's not always the case and using things like createTextNode() will actually escape html for you so you don't have to worry about sanitizing input into innerHTML calls. Naturally there is innerText but I'm not sure all browsers support that.
Jquery is/was a practical solution, never a right solution.
For example, most people recognize the merit of Jquery as it solves the inconsistency of browser support. The right solution is of course the inconsistency itself, but practically, we patch it with band-aids.
Interesting. I fired up IE8 expecting to find bugs, and to my surprise, even though the page looks different (some colored text is not colored, backgrounds are a different shade, etc.), it works perfectly. I was recently bit by trying to use `document.getElementsByClassName` which didn't work in IE 8, which makes it easy for me to just slap jQuery onto a new project because as long as people use IE8 and pay for things, you're expected to support it
Is there a suite of unit tests to verify all of the code listed and that it works in all browsers or is the content opened sourced anywhere? For example if you look at "Empty an elements content" (http://plainjs.com/javascript/manipulation/empty-an-elements...) it shows this code:
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 know the guys behind this project.
And as far as I know PlainJS is all about performance.
I've seen a lot of projects including megabytes of libraries. So a litte bit of purism is maybe not a bad Idea.
But I think this is just a starting point. In my opinion they need to provide test for there lib..
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.
This is a terrible idea. I've said it before and I'll say it again unless you only have to worry about support the newest Chrome/FF and even then the jQuery syntax is MUCH nicer than plain JS.
It's simply not worth a developers time to account for all the different ways to accomplish the same end-task in all browsers. I know that when I use jQuery I can count on it working the same in every browser without having to test it extensively. The same cannot be said for plain JS. I know this is getting better but if you need to support a few versions back of IE (8/9) then not using jQuery is like shooting yourself in the foot. I am fully in support of using less jQuery and being smart about caching selectors and the like but not using jQuery is very bad advice unless you are suggesting a full framework in it's place which does all the things jQuery does.
Let's take a quick minute and look at the company behind this site: http://pixabay.com/ They are a picture hosting (possibly selling? IDK) site. I'm sure FOR THEM they can get away with just plain JS but for people actually building web apps or building multiple client sites it's not nearly as easy. So not only do I think their site would be fairly simple to create without jQuery if we take a little look at the source we see THEY ARE USING jQUERY! Just think about that, the company behind a website urging you not to use jQuery is using jQuery on their own site...
Lastly using libraries that don't use jQuery will (9 times out of 10) set you up for failure unless the developer behind the library did extensive tests in every browser. I personally am more a fan of things working everywhere then trying to shave off the time that jQuery might add. If you want to convince me on how bad jQuery is you are going to need to show some benchmarks to prove your point. I, for one, do not accept that across the board jQuery is slow and using native JS will make my app "load and react blazingly fast". With or without jQuery you can write shitty code, it's not jQuery's fault it's the developers...