

PlainJS – The Vanilla JavaScript Repository - Nasmon
http://plainjs.com/

======
joshstrange
"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/](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...

~~~
Nasmon
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 ...

~~~
aikah
> 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.

~~~
Nasmon
Fixed it :-) Thanks.

------
aikah
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.

~~~
dlbucci
"There is no "document.createElement" in the Javascript spec." Uh...
[https://developer.mozilla.org/en-
US/docs/Web/API/Document/cr...](https://developer.mozilla.org/en-
US/docs/Web/API/Document/createElement)

~~~
matchu
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.

------
consptheory
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

~~~
BinaryIdiot
> 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.

~~~
Nasmon
> parents('.classname')

In DOM4, which is available in modern browsers: .closest('.classname')
possibly also .parent('.classname'), but haven't looked it up.

------
roneesh
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.

~~~
aikah
> They forgo learning plain JS in favor of jQuery

> 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.

~~~
MalcolmDiggs
> _Now you understand how stupid you sound._

> _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.

~~~
aikah
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.

~~~
roneesh
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.

------
BinaryIdiot
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.

------
hzhou321
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.

------
arenaninja
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

------
BinaryIdiot
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...](http://plainjs.com/javascript/manipulation/empty-an-elements-
content-34/)) it shows this code:

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](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.

~~~
Nasmon
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.

------
dreampulse
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..

~~~
Nasmon
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.

------
tmikaeld
PLEASE fix so that www.plainjs.com works.

