PlainJS – The Vanilla JavaScript Repository
plainjs.com
plainjs.com
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...
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 ...
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 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.
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.
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.
" 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.
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.
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.
So, why use an abstraction layer if the base layer itself offers quite the same comfort?
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.
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.
No worries just a common misconception; the DOM API is part of HTML and DOM specifications.
you pointed to a mozilla wiki which has a entry under "web" directory
>"There is no "document.createElement" in the Javascript spec." Uh... https://developer.mozilla.org/en-US/docs/Web/API/Document/cr...
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
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.
In DOM4, which is available in modern browsers: .closest('.classname') possibly also .parent('.classname'), but haven't looked it up.
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."
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.
> Either you are not a developer thus don't know what you are talking about
> Either way your comment is plain stupid and doesn't help.
C'mon man. I'm sure you could have made your point, in a helpful way, without attacking him. No need to go there.
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.
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.
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.
var el = document.querySelector('div');
el.innerHTML = '';
Which is fine for a div but won't work in IE for a select (https://support.microsoft.com/en-us/kb/276228?wa=wsignin1.0).
Granted that's a weird bug but I'd expect any issues with examples could be logged, updated and tested against a browser suite to ensure correctness.
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.
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.