7 ms·

PlainJS – The Vanilla JavaScript Repository

55 points by Nasmon 11y ago

BinaryIdiot 11y ago
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.
roneesh 11y ago
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 11y ago
  > 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 11y ago
    > 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 11y ago
      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.
      - deleted 11y ago
        [deleted]
      - roneesh 11y ago
        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.
hzhou321 11y ago
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.
BinaryIdiot 11y ago
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-content-34/ http://plainjs.com/javascript/manipulation/empty-an-elements...) 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 11y ago
  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.
aikah 11y ago
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 11y ago
  "There is no "document.createElement" in the Javascript spec." Uh... https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement https://developer.mozilla.org/en-US/docs/Web/API/Document/cr...
  - BinaryIdiot 11y ago
    Your link actually shows it's not part of the EMCAScript specification :) No worries just a common misconception; the DOM API is part of HTML and DOM specifications.
  - matchu 11y ago
    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.
  - aikah 11y ago
    Yeah well , this IS the ecmascript AKA javascript spec : https://es5.github.io/ https://es5.github.io/ 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... well, I hope you learned something today because your link isn't the javascript spec.
- woah 11y ago
  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".
deleted 11y ago
[deleted]
arenaninja 11y ago
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
consptheory 11y ago
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 11y ago
  > 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.
joshstrange 11y ago
"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...
- cozuya 11y ago
  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?
grimmdude 11y ago
A big drawback I see by not using jQuery is the lack of access to many third party libraries/plugins that depend on it. Using jQuery opens all of that up which is pretty huge.
dreampulse 11y ago
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 11y ago
  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 11y ago
PLEASE fix so that www.plainjs.com works.

55 points by Nasmon 11y ago

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.

roneesh 11y ago

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 11y ago
> 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 11y ago
  > 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 11y ago
    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.
    - deleted 11y ago
      [deleted]
    - roneesh 11y ago
      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.

hzhou321 11y ago

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.

BinaryIdiot 11y ago

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-content-34/ http://plainjs.com/javascript/manipulation/empty-an-elements...) 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 11y ago
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.

aikah 11y ago

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 11y ago
"There is no "document.createElement" in the Javascript spec." Uh... https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement https://developer.mozilla.org/en-US/docs/Web/API/Document/cr...
- BinaryIdiot 11y ago
  Your link actually shows it's not part of the EMCAScript specification :) No worries just a common misconception; the DOM API is part of HTML and DOM specifications.
- matchu 11y ago
  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.
- aikah 11y ago
  Yeah well , this IS the ecmascript AKA javascript spec : https://es5.github.io/ https://es5.github.io/ 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... well, I hope you learned something today because your link isn't the javascript spec.
woah 11y ago
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".

deleted 11y ago

[deleted]

arenaninja 11y ago

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

consptheory 11y ago

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 11y ago
> 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.

joshstrange 11y ago

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

cozuya 11y ago
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?

grimmdude 11y ago

A big drawback I see by not using jQuery is the lack of access to many third party libraries/plugins that depend on it. Using jQuery opens all of that up which is pretty huge.

dreampulse 11y ago

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 11y ago
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 11y ago

PLEASE fix so that www.plainjs.com works.