14 ms·

PlainJS – Vanilla JavaScript Repository

210 points by shakes 9y ago

AndyKelley 9y ago
If you don't have VanillaJS you can get it here: http://vanilla-js.com http://vanilla-js.com
- projectramo 9y ago
  I looked at the page and I think the documentation is a little lacking. I only understand what VanillaJS is supposed to do by implication, by looking at the PlainJS sight and then extrapolating that this must be competition.
  - EGreg 9y ago
    I found the documentation link on VanillaJS on the bottom of the page. It seems VanillaJS is a project of Mozilla, or adopted by them. Very nice for a browser maker to spend time documenting a library so thoroughly. I would say the docs are almost better than jQuery's docs. On the other hand, I like jQuery more for the support community :)
    - beager 9y ago
      VanillaJS has a huge support community, it's even taught in universities.
      - EGreg 9y ago
        Also I suggest they refactor the next version of VanillaJS to be less verbose. Perhaps they can get some inspiration from jQuery.
        beager 9y ago
        Or maybe from CoffeeScript?
- beager 9y ago
  My problem with VanillaJS is that browser companies ship browsers with VanillaJS support already. This is a clear case of picking winners, regardless of VanillaJS's excellent benchmarks. Why should all these browsers ship with Vanilla? Why not Vue? Why not MooTools? Why not Moo.fx?
  - tentaTherapist 9y ago
    Like you said, VanillaJS isn't inherently faster than any of these frameworks, but the cost to the user (and the increased API surface) isn't worth that tiny improvement in code clarity.
    - beager 9y ago
      I did not say that. VanillaJS is pretty much faster than all of those other frameworks. Can you point me to a library that has better benchmarks than VanillaJS?
      - tentaTherapist 9y ago
        Uh, inherently faster as in, there's nothing about the API design that makes it easier to optimize.
  - dualogy 9y ago
    Not sure Vue falls in the same category, Vanilla lists "features" such as: "DOM (Traversal / Selectors), Prototype-based Object System, AJAX, Animations, Event System, Regular Expressions, Functions as first-class objects, Closures, Math Library, Array Library, String Library". Not "component-markup-to-JS transpilation" or SPA v-dom render loop
    - beager 9y ago
      Maybe there should be a Vue+MooTools library called VueTools.
- shortstuffsushi 9y ago
  Huh, I have enjoyed this site in the past, but I forgot about the code comparisons including script tags for non-Vanilla and not for Vanilla. That seems a bit misleading. I get the extra script tag for jQuery, but the <script> { content } </script> would still be necessary for vanilla..
austincheney 9y ago
Or... just learn the DOM api. It is only about 2 hours of practice and study: http://prettydiff.com/guide/unrelated_dom.xhtml http://prettydiff.com/guide/unrelated_dom.xhtml
- allover 9y ago
  jQuery is more than the DOM api.
projectramo 9y ago
It is late in the day to try to replace jQuery. Does PlainJS have components? Does it have bootstrap like functionality (i.e. columns)?
- didgeoridoo 9y ago
  https://en.m.wikipedia.org/wiki/Poe's_law https://en.m.wikipedia.org/wiki/Poe's_law
- spankalee 9y ago
  Web Components
- freshyill 9y ago
  It sounds like you didn't click through. This is not a framework. This is a repository of vanilla JS scripts that take the place of a lot of things that would have had a jQuery dependency in the past.
- Touche 9y ago
  Ironically jQuery doesn't have the things you ask for here, but plain JS indeed does (custom elements for components, CSS grid for columns).
- reificator 9y ago
  Yes, in fact it does. Components are created by `class MyEl extends HTMLElement`, and columns are included in the CSS module under the `grid` declaration.
atonse 9y ago
This is such a great idea. I have been a web developer for 18 years, and kicking the jQuery habit has been one of the toughest. Frameworks also still rely on them. I'm a full time ember developer and last I checked they're trying pretty hard to drop the jQuery limitation (REALLY sorry to Ember devs if my info is outdated on this), but the ecosystem of ember/non-ember addons surrounding it will prolong things even longer I'm sure.
jordache 9y ago
who still uses jquery? to create usability mockups?
- chickenfries 9y ago
  This is like asking "who still uses wordpress." Outside of the HN bubble, everyone still uses jQuery.
  - dmitriid 9y ago
    Even inside HN bubble people regularly drop into jQuery from inside their Reacts and Vues and Polymers. Just because it's super convenient
    - jordache 9y ago
      to do what with jQuery? It's not a good practice to mix them.
      - dmitriid 9y ago
        It isn't, that's true. Sometimes you need to integrate with some third-party things thoug. Ranging from ad networks to well established UI components like Select2 or DynaTables.
- jncraton 9y ago
  I'm not sure if this is a serious question or not, but about 75% of the top sites on the Internet use jQuery: https://trends.builtwith.com/javascript/jQuery https://trends.builtwith.com/javascript/jQuery Perhaps new projects shouldn't be using jQuery, but it's possible that some devs who just churn out code without watching the industry aren't aware of this. Increasing that awareness appears to be the point of this plainJS landing page.
  - rhapsodic 9y ago
    >Perhaps new projects shouldn't be using jQuery, but it's possible that some devs who just churn out code without watching the industry aren't aware of this. Or maybe those devs are watching the industry but don't care for the direction it's urging them to take, e.g. locking themselves into complex frameworks like React for simple crud pages that have the basically the same DOM each and every time they're loaded.
gizmodo59 9y ago
jQuery has helped me tremendously in the past and continues to do so. Not everyone has to design a website like google.com and not everyone needs to take into consideration every byte that is loaded in a web page. A library that gives you a single way to do things that many browsers support in a less verbose form is just amazing tbh. At the end of the day when you need to just get things done jQuery still shines. Does it produce spaghetti code? No, you are doing it. Does it become an enabler in spaghetti code? Yes. But not all the use cases are the same.
EGreg 9y ago
Can someone make a lite version of jQuery? Angular did that. I think Zepto was that for a while. Isn't jQuery's lite version already there, which drops Android support etc. Why not serve that to correct browsers?
- 52-6F-62 9y ago
  Why not try rolling your own? * http://projects.jga.me/jquery-builder/ http://projects.jga.me/jquery-builder/ * https://www.ericponto.com/blog/2014/10/05/es6-dom-library/ https://www.ericponto.com/blog/2014/10/05/es6-dom-library/
  - rhizome 9y ago
    How do I get jQ without <IE9 support?
    - 52-6F-62 9y ago
      Can't help you there specifically. However, depending on what you need from jQuery, you might consider writing your own DOM library so you can have some control over the size. If you have a look at some of the comments above, you'll see that many jQuery advantages are met with equivalent features in vanilla JS, just slightly more verbose. It isn't difficult to write a wrapper for some of the major jQuery features. That second link is a terse example of this.
batat 9y ago
Yea, let's bury jQuery again and make more "helpers.js" [1] export function extend(src) { var obj, args = arguments for (let i = 1; i < args.length; ++i) { if (obj = args[i]) { for (let key in obj) { // check if this property of the source object could be overridden if (isWritable(src, key)) src[key] = obj[key] } } } } or just add super-unique stuff to our classes [2] DragSelect.prototype.removeClass = function( element, classname ) { var cn = element.className; var rxp = new RegExp( classname + \'\\b\', \'g\' ); cn = cn.replace( rxp, \'\' ); element.className = cn; return element; }; DragSelect.prototype.hasClass = function( element, classname ) { var cn = element.className; if( cn.indexOf( classname ) > -1 ) { return true; } else { return false; } }; or write tons of boilerplate code like if (typeof element === 'string') { owner.element = document.querySelector(element); } else { owner.element = ((typeof element.length !== 'undefined') && element.length > 0) ? element[0] : element; } (mmm, it's so vanilla) [1] https://github.com/oncode/handorgel/blob/master/src/helpers.js#L56 https://github.com/oncode/handorgel/blob/master/src/helpers.... [2] https://github.com/ThibaultJanBeyer/DragSelect/blob/master/src/DragSelect.js#L768 https://github.com/ThibaultJanBeyer/DragSelect/blob/master/s...
- Touche 9y ago
  Rather than using a library with a bunch of utility functions that you may or may not need, using individual utility functions indeed does seem like a better idea. For example, I don't support browsers without classList, so I don't need your regexp stuff. Maybe you do, but my code shouldn't be larger because of that.
  - jonursenbach 9y ago
    Problem now is that you get to write, test and maintain all this instead of using something that has a whole community backing it.
    - hw 9y ago
      Most of these utility functions are fairly straightforward and will rarely require any changes or maintenance. Testing should therefore be straightforward as well. Having the whole community back something doesn't mean it's bug-free, and sometimes it makes it harder when their release cycle isn't as frequent as you'd like it to be. Having said that, it's all about tradeoffs. Whether your project needs something as big as <insert JS framework or lib here> or if you can live with just needing a few utility functions, you make those choices, doesn't mean one is better than the other as it all depends on context and situation. jQuery has become the defacto must-use library for javascript now which IMO is unfortunate, as a lot of sites and apps include it when they barely use most of what jQuery offers. I'm guessing most use jQuery for only a few things - Ajax, DOM querying, and events. I hope that sometime in the future jQuery would be more modular.
g00gler 9y ago
jQuery is really useful when it comes to DOM manipulation, obviously. Without using any framework you'll find yourself iterating over NodeLists all over the place. ie, it's much cleaner to write $('p').css('color', 'blue'); Than document.querySelectorAll('p').forEach(el => el.style.color = 'blue'); Also, Microsoft kinda screwed us by keeping IE 11 around until 2025.
- tenryuu 9y ago
  Code cleanliness matters more so in a compiled language. Having an interpreted language means, regardless of how long it takes you to write, everything has to be downloaded/processed on every single execution of the file. Putting more effort into my code to remove unnecessary libraries allows the end user to load pages faster, and that's what I think matters most, because I hate having to wait, sometimes even twenty seconds for some simple pages to pass a loading screen
- megous 9y ago
  You can create a trivial helper function such as: let $ = s => document.querySelectorAll(s); And then use: for (let p of $('p')) p.style.color = 'blue'; And if you start doing anything more complex per iteration: $('p') .css('color', 'blue') .addClass('bla') .filter(function() { $(this).parent().is('article'); }) .removeClass('qwe'); The code becomes much less magical and clearer (it's almost self explanatory): for (let p of $('p')) { p.style.color = 'blue'; p.classList.add('ble'); if (p.parentNode.matches('article')) p.classList.remove('qwe'); } Also much more debuggable in a debugger, and faster, as you're iterating only once and are not calling many needless functions.
  - g00gler 9y ago
    Very true, nice codes :). Would be nice if we could write that without transpiling.
91bananas 9y ago
I still think jQuery/UI, libs maintained by a group that has a vision, organization, etc. Is a better solution than pulling in a ton of shitty half hearted components, functions, what have you from a bunch of random developers and repos scattered across the internet. Bootstrap works because it is built by a team, solves a specific problem and solves it well. jQuery is the same thing. I grant that the things linked from this site are useful and novel, but I don't want to build a project sourcing things from 16 different developers when I could just bring in one library that does all of them, and might weigh a little more over the net.
- emodendroket 9y ago
  That's my problem with microlibraries in general. How rigorous is your vetting process when you're starting to pull in code like left-pad, really?
  - Spivak 9y ago
    leftPad is a very simple example but the goal of these micro libraries is to keep every project from having a utils.js which contain slightly different variations of the same code.
    - emodendroket 9y ago
      But a "macrolibrary" would seem to serve that goal equally well and also help solve the problem where many of your libraries overlap because none of them do quite what you need.
- hw 9y ago
  Bootstrap at least provides a way to pull in only components that you need. I would argue for a more modular jQuery. There are some projects that don't require all that jQuery provides, and sometimes you want to min-max performance and size of JS that gets downloaded. Keep in mind that jQuery is maintained and contributed to by more than 16 developers so you are technically sourcing things from multiple developers, just so happens they are in a single library. Again, it really depends on what you're doing with your project and what you need for your project. Most developers include jQuery by default because it's just the most common and most used library, and PlainJS offers an alternative which I think is great.
talindras 9y ago
This is just a fork of http://vanilla-js.com/ http://vanilla-js.com/
alistproducer2 9y ago
I went to the site and I'm a little unclear of what its purpose is. Is it supposed to be a way to learn vanilla JS?
disconnected 9y ago
This is cute and all, but JQuery is slightly more than just a framework for accessing the DOM. My JS is a bit rusty, but I remember that in JQuery I could do: $("some selector").do_things() And "do_things" would be done on all matching elements. For example: $("li").addClass("foo") Would add the class "foo" to all "li". I could further refine the selector above to select only the "li"s I wanted of course. With the "plain js" solution, you have to "querySelectorAll" and then iterate over each element. Another example is "ajax" requests. In JQuery you have the general purpose "ajax" method, with simple "success" and "failure" callbacks, and configuration done via a standard JS object filled with all the necessary parameters (and this object could be reused for the most part, since most of the parameters don't change). You can also chain ajax requests together with deferred objects. Simple, straightforward and useful. With their proposed solution here, you have to faff around with the XMLHttpRequest object every single time you want to make a POST or a GET. Ugh. And if you need to chain a bunch of those together? Uuuuugh. Yeah, you can put all of these things inside helper functions to hide the ugliness, but if you are going through all that trouble, you are essentially rewriting JQuery (or similar libraries), badly. If it is a one off thing, I guess you don't need JQuery, but if you are rewriting most of these methods, you are crazy. Use a library, and trim it down to remove the stuff you don't need (JQuery allows this, IIRC). A final aside. One oft overlooked advantage of JQuery is that the "$()" method can be applied to anything, not just the DOM. You can create a JQuery object that encapsulates, say, an array. Then you can iterate with "each", you can "filter", etc. Also, you can easily trigger events on your objects with "trigger" that other interested parties can listen to them by setting up event listener with "on". Useful to give your classes some Qt style signal/slot semantics.
- madeofpalk 9y ago
  > You can create a JQuery object that encapsulates, say, an array. Then you can iterate with "each", you can "filter", etc. each and filter are native functions on Array.
  - megous 9y ago
    'each' is not. forEach is.
tomcam 9y ago
Most cool! A couple notes. Anyone maintaining a public-facing codebase should note that "All functions work properly in IE 9 and above - most of them are compatible with IE 8." jQuery has compatibility going back much, much further. Users in third world countries with older computers are better served by jQuery. jQuery has an enormous test suite, tons of documentation with examples, and unparalleled third-party support.
deleted 9y ago
[deleted]
woah 9y ago
With this article and these comments, I feel like I've been transported back in time 3-4 years.
beager 9y ago
I think it's a pretty amusing observation about the JS dev community to see some of the responses to this here. Some people are here for Irony Club, some people have no clue there's an Irony Club meeting, and some people are opening up their jQuery wounds and bleeding all over the room. One thing I'll say about jQuery vs doing POJS (Plain-ol' JavaScript, pronounced Poise, heh) is that jQuery comes from a world where browsers sucked and build processes for JS were virtually non-existent. The market share of sucky browsers is much smaller now, and we have sophisticated build systems for JS. All of the benefits of jQuery (normalization, removing boilerplate, etc) can be had with vanilla plugins that you can put in your project and forget about. The lingering damage of jQuery is that we have a bunch of jQuery devs in the world now who simply cannot write JavaScript. We've got to move past that.
- allover 9y ago
  > We've got to move past that. No, we've got to move past lazy generalizations. You've boiled down multiple issues to 'people only know jQuery'. Meanwhile the rest of this thread is dealing with more interesting and accurate specifics.
  - beager 9y ago
    I have not boiled down multiple issues to that, I'm indicating that the problem with jQuery in long-term adoption is that patterns meant to help devs avoid the untenable realm of JS yesterday keep them sheltered from good JS practice today. For that reason, we should move past jquery.
    - goatlover 9y ago
      "We" should do whatever makes sense for the project at hand, be that vanilla, jquery, react, etc. There's a ton of different websites out there. jQuery might be a requirement of the codebase, or already loaded, or heavily used, etc. Or the developer might find it fastest to just drop jquery in for a simple site.
throw2016 9y ago
There is an unfortunate trend of people running down jQuery indiscriminately. Given millions of people used jQuery for years without issue it's difficult to believe those who benefited are going to run it down publicly because they found something better. The only people who would do this are those marketing something else. This is by far the worst part of tech forums, this kind of insidious marketing that seeks to 'force obsolence' on software and entire groups of people happily using it because some are promoting their own thing.
MentallyRetired 9y ago
DHTML, the framework!
fiatjaf 9y ago
See also https://svelte.technology/ https://svelte.technology/, the magical disappearing UI framework.
manigandham 9y ago
jQuery usually falls back to native methods if the browser supports it. Also build systems can easily remove unused code (webpack + babel-minify does great with ES6 on the whole bundle), and you can even pick and choose the exact components you need from the jQuery npm package.
emodendroket 9y ago
I mean when does it stop being "vanilla"? jQuery is written in "vanilla JS" too.
- Spivak 9y ago
  Completely counter to the author I would say everything is vanilla until you start compiling and pollyfilling. Once you start writing in idealized languages like TypeScript, CoffeeScript, or ES6 you're no longer writing vanilla JS.
  - emodendroket 9y ago
    I could see that, or else maybe it's not "vanilla" if you start using something like angularjs which expects to mediate basically the entire lifecycle of your application. But I think in general the concept is ill defined.
tareqak 9y ago
Are there any kinds of dead code elimination tools for JavaScript? If <link> tags can take additional attributes / query string parameters, the CDN be smart enough to only send down the required code.
olavgg 9y ago
At my company we prefer using vanilla Javascript over all these (exhausting) frameworks! Especially many of the new features in Ecmascript 6 makes things much simpler. No more overusing bind(), template literals for building HTML and so on. Recently I've missed the way you create DOM elements like you do with React.DOM so I created a simple proxy function like this: let bai = {}; bai.DOM = function(){ return new Proxy({}, { get: function(target, name){ return function(args, body) { let newEle = document.createElement(name); if(args){ let keys = Object.keys(args); for (let i = 0; i < keys.length; i++) { newEle.setAttribute(keys[i], args[keys[i]]); } } if(body){ if(typeof body === 'string'){ newEle.textContent = body; } else { newEle.appendChild(body); } } return newEle; } } }) }(); With this you can create new DOM elements as following, document.body.appendChild( bai.DOM.div( {"id": "message"}, bai.DOM.p(null, "hello world") ) );
mike-cardwell 9y ago
It took me less than 10 seconds to find an XSS on this website. Literally, the first place anybody would look worked.
cuu508 9y ago
I've found http://microjs.com/ http://microjs.com/ useful quite a few times.
ausjke 9y ago
the issue is that I need bootstrap which requires jquery
javascriptChris 9y ago
I agree jQuery isn't really needed but at the same time it's simpler for people who may not understand JavaScript fully of willing to look at boring web API docs to replicate some of the functionality.
stevebmark 9y ago
Can you imagine any other language / ecosystem where you're encouraged NOT to use any libraries of any kind? The web is a weird place.
sAbakumoff 9y ago
jQuery is here to stay. It will outlive react angular vue and whatever shiny framework you have been using.
tomxor 9y ago
As someone who's written a lot of DOM code, i've tried dropping jquery (and do) but selectively. You cannot drop it completely without great pain. It's true that the DOM interface has stabilised and is now mostly consistent cross browser, however the API is massively unwieldy in places, from excessively long method names to irritating asymmetric potholes. TLDR; Jquery is not needed for cross browser now, it's needed to make using the DOM API not so ridiculously verbose and long winded. You need to use jQuery today because: you want your DOM code to be 1/5th the size, more legible, more debug-able. I still use native methods where possible where there is little difference, especially when performance is a concern.
temporallobe 9y ago
I'm so tired of this argument. There's no reason to drop jQuery for any of the reasons stated. Especially with modern JavaScript engines, the performance hit is negligible. Also, jQuery is especially optimized for complex DOM manipulation which Vanilla JS cannot do on its own. Sorry, but querySelectorAll is not the same as jQuery's powerful selector engine, and you can't chain thngs the same way either. Sure, it's less relevant now than it once was and for minor projects you could probably get away with a no-library approach, but who are we kidding here? Most modern web apps and sites are extremely library and framework heavy. It's complete bullshit to say otherwise. The only exception is of course for design-centric, static content web sites which tend to heavily lean on CSS for display logic. This article is just full of amateur and meaningless advice.
futurefriendly 9y ago
Read this thread but replace every mention of jQuery with "table layouts", the parallels are striking. jQuery has been a good friend for many years. It saved us from the drudgery of cross-browser support and gave us an enjoyable API for browser development. Technology moves on, today's browser APIs and tooling are light years ahead of what we had 11 years. You might not need jQuery, and that's ok!

210 points by shakes 9y ago

AndyKelley 9y ago

If you don't have VanillaJS you can get it here: http://vanilla-js.com http://vanilla-js.com

projectramo 9y ago
I looked at the page and I think the documentation is a little lacking. I only understand what VanillaJS is supposed to do by implication, by looking at the PlainJS sight and then extrapolating that this must be competition.
- EGreg 9y ago
  I found the documentation link on VanillaJS on the bottom of the page. It seems VanillaJS is a project of Mozilla, or adopted by them. Very nice for a browser maker to spend time documenting a library so thoroughly. I would say the docs are almost better than jQuery's docs. On the other hand, I like jQuery more for the support community :)
  - beager 9y ago
    VanillaJS has a huge support community, it's even taught in universities.
    - EGreg 9y ago
      Also I suggest they refactor the next version of VanillaJS to be less verbose. Perhaps they can get some inspiration from jQuery.
      - beager 9y ago
        Or maybe from CoffeeScript?
beager 9y ago
My problem with VanillaJS is that browser companies ship browsers with VanillaJS support already. This is a clear case of picking winners, regardless of VanillaJS's excellent benchmarks. Why should all these browsers ship with Vanilla? Why not Vue? Why not MooTools? Why not Moo.fx?
- tentaTherapist 9y ago
  Like you said, VanillaJS isn't inherently faster than any of these frameworks, but the cost to the user (and the increased API surface) isn't worth that tiny improvement in code clarity.
  - beager 9y ago
    I did not say that. VanillaJS is pretty much faster than all of those other frameworks. Can you point me to a library that has better benchmarks than VanillaJS?
    - tentaTherapist 9y ago
      Uh, inherently faster as in, there's nothing about the API design that makes it easier to optimize.
- dualogy 9y ago
  Not sure Vue falls in the same category, Vanilla lists "features" such as: "DOM (Traversal / Selectors), Prototype-based Object System, AJAX, Animations, Event System, Regular Expressions, Functions as first-class objects, Closures, Math Library, Array Library, String Library". Not "component-markup-to-JS transpilation" or SPA v-dom render loop
  - beager 9y ago
    Maybe there should be a Vue+MooTools library called VueTools.
shortstuffsushi 9y ago
Huh, I have enjoyed this site in the past, but I forgot about the code comparisons including script tags for non-Vanilla and not for Vanilla. That seems a bit misleading. I get the extra script tag for jQuery, but the <script> { content } </script> would still be necessary for vanilla..

austincheney 9y ago

Or... just learn the DOM api. It is only about 2 hours of practice and study: http://prettydiff.com/guide/unrelated_dom.xhtml http://prettydiff.com/guide/unrelated_dom.xhtml

allover 9y ago
jQuery is more than the DOM api.

projectramo 9y ago

It is late in the day to try to replace jQuery. Does PlainJS have components? Does it have bootstrap like functionality (i.e. columns)?

didgeoridoo 9y ago
https://en.m.wikipedia.org/wiki/Poe's_law https://en.m.wikipedia.org/wiki/Poe's_law
spankalee 9y ago
Web Components
freshyill 9y ago
It sounds like you didn't click through. This is not a framework. This is a repository of vanilla JS scripts that take the place of a lot of things that would have had a jQuery dependency in the past.
Touche 9y ago
Ironically jQuery doesn't have the things you ask for here, but plain JS indeed does (custom elements for components, CSS grid for columns).
reificator 9y ago
Yes, in fact it does. Components are created by `class MyEl extends HTMLElement`, and columns are included in the CSS module under the `grid` declaration.

atonse 9y ago

This is such a great idea. I have been a web developer for 18 years, and kicking the jQuery habit has been one of the toughest. Frameworks also still rely on them. I'm a full time ember developer and last I checked they're trying pretty hard to drop the jQuery limitation (REALLY sorry to Ember devs if my info is outdated on this), but the ecosystem of ember/non-ember addons surrounding it will prolong things even longer I'm sure.

jordache 9y ago

who still uses jquery? to create usability mockups?

chickenfries 9y ago
This is like asking "who still uses wordpress." Outside of the HN bubble, everyone still uses jQuery.
- dmitriid 9y ago
  Even inside HN bubble people regularly drop into jQuery from inside their Reacts and Vues and Polymers. Just because it's super convenient
  - jordache 9y ago
    to do what with jQuery? It's not a good practice to mix them.
    - dmitriid 9y ago
      It isn't, that's true. Sometimes you need to integrate with some third-party things thoug. Ranging from ad networks to well established UI components like Select2 or DynaTables.
jncraton 9y ago
I'm not sure if this is a serious question or not, but about 75% of the top sites on the Internet use jQuery: https://trends.builtwith.com/javascript/jQuery https://trends.builtwith.com/javascript/jQuery Perhaps new projects shouldn't be using jQuery, but it's possible that some devs who just churn out code without watching the industry aren't aware of this. Increasing that awareness appears to be the point of this plainJS landing page.
- rhapsodic 9y ago
  >Perhaps new projects shouldn't be using jQuery, but it's possible that some devs who just churn out code without watching the industry aren't aware of this. Or maybe those devs are watching the industry but don't care for the direction it's urging them to take, e.g. locking themselves into complex frameworks like React for simple crud pages that have the basically the same DOM each and every time they're loaded.

gizmodo59 9y ago

jQuery has helped me tremendously in the past and continues to do so. Not everyone has to design a website like google.com and not everyone needs to take into consideration every byte that is loaded in a web page. A library that gives you a single way to do things that many browsers support in a less verbose form is just amazing tbh. At the end of the day when you need to just get things done jQuery still shines. Does it produce spaghetti code? No, you are doing it. Does it become an enabler in spaghetti code? Yes. But not all the use cases are the same.

EGreg 9y ago

Can someone make a lite version of jQuery? Angular did that. I think Zepto was that for a while. Isn't jQuery's lite version already there, which drops Android support etc. Why not serve that to correct browsers?

52-6F-62 9y ago
Why not try rolling your own? * http://projects.jga.me/jquery-builder/ http://projects.jga.me/jquery-builder/ * https://www.ericponto.com/blog/2014/10/05/es6-dom-library/ https://www.ericponto.com/blog/2014/10/05/es6-dom-library/
- rhizome 9y ago
  How do I get jQ without <IE9 support?
  - 52-6F-62 9y ago
    Can't help you there specifically. However, depending on what you need from jQuery, you might consider writing your own DOM library so you can have some control over the size. If you have a look at some of the comments above, you'll see that many jQuery advantages are met with equivalent features in vanilla JS, just slightly more verbose. It isn't difficult to write a wrapper for some of the major jQuery features. That second link is a terse example of this.

batat 9y ago

Yea, let's bury jQuery again and make more "helpers.js" [1] export function extend(src) { var obj, args = arguments for (let i = 1; i < args.length; ++i) { if (obj = args[i]) { for (let key in obj) { // check if this property of the source object could be overridden if (isWritable(src, key)) src[key] = obj[key] } } } } or just add super-unique stuff to our classes [2] DragSelect.prototype.removeClass = function( element, classname ) { var cn = element.className; var rxp = new RegExp( classname + \'\\b\', \'g\' ); cn = cn.replace( rxp, \'\' ); element.className = cn; return element; }; DragSelect.prototype.hasClass = function( element, classname ) { var cn = element.className; if( cn.indexOf( classname ) > -1 ) { return true; } else { return false; } }; or write tons of boilerplate code like if (typeof element === 'string') { owner.element = document.querySelector(element); } else { owner.element = ((typeof element.length !== 'undefined') && element.length > 0) ? element[0] : element; } (mmm, it's so vanilla) [1] https://github.com/oncode/handorgel/blob/master/src/helpers.js#L56 https://github.com/oncode/handorgel/blob/master/src/helpers.... [2] https://github.com/ThibaultJanBeyer/DragSelect/blob/master/src/DragSelect.js#L768 https://github.com/ThibaultJanBeyer/DragSelect/blob/master/s...

Touche 9y ago
Rather than using a library with a bunch of utility functions that you may or may not need, using individual utility functions indeed does seem like a better idea. For example, I don't support browsers without classList, so I don't need your regexp stuff. Maybe you do, but my code shouldn't be larger because of that.
- jonursenbach 9y ago
  Problem now is that you get to write, test and maintain all this instead of using something that has a whole community backing it.
  - hw 9y ago
    Most of these utility functions are fairly straightforward and will rarely require any changes or maintenance. Testing should therefore be straightforward as well. Having the whole community back something doesn't mean it's bug-free, and sometimes it makes it harder when their release cycle isn't as frequent as you'd like it to be. Having said that, it's all about tradeoffs. Whether your project needs something as big as <insert JS framework or lib here> or if you can live with just needing a few utility functions, you make those choices, doesn't mean one is better than the other as it all depends on context and situation. jQuery has become the defacto must-use library for javascript now which IMO is unfortunate, as a lot of sites and apps include it when they barely use most of what jQuery offers. I'm guessing most use jQuery for only a few things - Ajax, DOM querying, and events. I hope that sometime in the future jQuery would be more modular.

g00gler 9y ago

jQuery is really useful when it comes to DOM manipulation, obviously. Without using any framework you'll find yourself iterating over NodeLists all over the place. ie, it's much cleaner to write $('p').css('color', 'blue'); Than document.querySelectorAll('p').forEach(el => el.style.color = 'blue'); Also, Microsoft kinda screwed us by keeping IE 11 around until 2025.

tenryuu 9y ago
Code cleanliness matters more so in a compiled language. Having an interpreted language means, regardless of how long it takes you to write, everything has to be downloaded/processed on every single execution of the file. Putting more effort into my code to remove unnecessary libraries allows the end user to load pages faster, and that's what I think matters most, because I hate having to wait, sometimes even twenty seconds for some simple pages to pass a loading screen
megous 9y ago
You can create a trivial helper function such as: let $ = s => document.querySelectorAll(s); And then use: for (let p of $('p')) p.style.color = 'blue'; And if you start doing anything more complex per iteration: $('p') .css('color', 'blue') .addClass('bla') .filter(function() { $(this).parent().is('article'); }) .removeClass('qwe'); The code becomes much less magical and clearer (it's almost self explanatory): for (let p of $('p')) { p.style.color = 'blue'; p.classList.add('ble'); if (p.parentNode.matches('article')) p.classList.remove('qwe'); } Also much more debuggable in a debugger, and faster, as you're iterating only once and are not calling many needless functions.
- g00gler 9y ago
  Very true, nice codes :). Would be nice if we could write that without transpiling.

91bananas 9y ago

I still think jQuery/UI, libs maintained by a group that has a vision, organization, etc. Is a better solution than pulling in a ton of shitty half hearted components, functions, what have you from a bunch of random developers and repos scattered across the internet. Bootstrap works because it is built by a team, solves a specific problem and solves it well. jQuery is the same thing. I grant that the things linked from this site are useful and novel, but I don't want to build a project sourcing things from 16 different developers when I could just bring in one library that does all of them, and might weigh a little more over the net.

emodendroket 9y ago
That's my problem with microlibraries in general. How rigorous is your vetting process when you're starting to pull in code like left-pad, really?
- Spivak 9y ago
  leftPad is a very simple example but the goal of these micro libraries is to keep every project from having a utils.js which contain slightly different variations of the same code.
  - emodendroket 9y ago
    But a "macrolibrary" would seem to serve that goal equally well and also help solve the problem where many of your libraries overlap because none of them do quite what you need.
hw 9y ago
Bootstrap at least provides a way to pull in only components that you need. I would argue for a more modular jQuery. There are some projects that don't require all that jQuery provides, and sometimes you want to min-max performance and size of JS that gets downloaded. Keep in mind that jQuery is maintained and contributed to by more than 16 developers so you are technically sourcing things from multiple developers, just so happens they are in a single library. Again, it really depends on what you're doing with your project and what you need for your project. Most developers include jQuery by default because it's just the most common and most used library, and PlainJS offers an alternative which I think is great.

talindras 9y ago

This is just a fork of http://vanilla-js.com/ http://vanilla-js.com/

alistproducer2 9y ago

I went to the site and I'm a little unclear of what its purpose is. Is it supposed to be a way to learn vanilla JS?

disconnected 9y ago

This is cute and all, but JQuery is slightly more than just a framework for accessing the DOM. My JS is a bit rusty, but I remember that in JQuery I could do: $("some selector").do_things() And "do_things" would be done on all matching elements. For example: $("li").addClass("foo") Would add the class "foo" to all "li". I could further refine the selector above to select only the "li"s I wanted of course. With the "plain js" solution, you have to "querySelectorAll" and then iterate over each element. Another example is "ajax" requests. In JQuery you have the general purpose "ajax" method, with simple "success" and "failure" callbacks, and configuration done via a standard JS object filled with all the necessary parameters (and this object could be reused for the most part, since most of the parameters don't change). You can also chain ajax requests together with deferred objects. Simple, straightforward and useful. With their proposed solution here, you have to faff around with the XMLHttpRequest object every single time you want to make a POST or a GET. Ugh. And if you need to chain a bunch of those together? Uuuuugh. Yeah, you can put all of these things inside helper functions to hide the ugliness, but if you are going through all that trouble, you are essentially rewriting JQuery (or similar libraries), badly. If it is a one off thing, I guess you don't need JQuery, but if you are rewriting most of these methods, you are crazy. Use a library, and trim it down to remove the stuff you don't need (JQuery allows this, IIRC). A final aside. One oft overlooked advantage of JQuery is that the "$()" method can be applied to anything, not just the DOM. You can create a JQuery object that encapsulates, say, an array. Then you can iterate with "each", you can "filter", etc. Also, you can easily trigger events on your objects with "trigger" that other interested parties can listen to them by setting up event listener with "on". Useful to give your classes some Qt style signal/slot semantics.

madeofpalk 9y ago
> You can create a JQuery object that encapsulates, say, an array. Then you can iterate with "each", you can "filter", etc. each and filter are native functions on Array.
- megous 9y ago
  'each' is not. forEach is.

tomcam 9y ago

Most cool! A couple notes. Anyone maintaining a public-facing codebase should note that "All functions work properly in IE 9 and above - most of them are compatible with IE 8." jQuery has compatibility going back much, much further. Users in third world countries with older computers are better served by jQuery. jQuery has an enormous test suite, tons of documentation with examples, and unparalleled third-party support.

deleted 9y ago

[deleted]

woah 9y ago

With this article and these comments, I feel like I've been transported back in time 3-4 years.

beager 9y ago

I think it's a pretty amusing observation about the JS dev community to see some of the responses to this here. Some people are here for Irony Club, some people have no clue there's an Irony Club meeting, and some people are opening up their jQuery wounds and bleeding all over the room. One thing I'll say about jQuery vs doing POJS (Plain-ol' JavaScript, pronounced Poise, heh) is that jQuery comes from a world where browsers sucked and build processes for JS were virtually non-existent. The market share of sucky browsers is much smaller now, and we have sophisticated build systems for JS. All of the benefits of jQuery (normalization, removing boilerplate, etc) can be had with vanilla plugins that you can put in your project and forget about. The lingering damage of jQuery is that we have a bunch of jQuery devs in the world now who simply cannot write JavaScript. We've got to move past that.

allover 9y ago
> We've got to move past that. No, we've got to move past lazy generalizations. You've boiled down multiple issues to 'people only know jQuery'. Meanwhile the rest of this thread is dealing with more interesting and accurate specifics.
- beager 9y ago
  I have not boiled down multiple issues to that, I'm indicating that the problem with jQuery in long-term adoption is that patterns meant to help devs avoid the untenable realm of JS yesterday keep them sheltered from good JS practice today. For that reason, we should move past jquery.
  - goatlover 9y ago
    "We" should do whatever makes sense for the project at hand, be that vanilla, jquery, react, etc. There's a ton of different websites out there. jQuery might be a requirement of the codebase, or already loaded, or heavily used, etc. Or the developer might find it fastest to just drop jquery in for a simple site.

throw2016 9y ago

There is an unfortunate trend of people running down jQuery indiscriminately. Given millions of people used jQuery for years without issue it's difficult to believe those who benefited are going to run it down publicly because they found something better. The only people who would do this are those marketing something else. This is by far the worst part of tech forums, this kind of insidious marketing that seeks to 'force obsolence' on software and entire groups of people happily using it because some are promoting their own thing.

MentallyRetired 9y ago

DHTML, the framework!

fiatjaf 9y ago

See also https://svelte.technology/ https://svelte.technology/, the magical disappearing UI framework.

manigandham 9y ago

jQuery usually falls back to native methods if the browser supports it. Also build systems can easily remove unused code (webpack + babel-minify does great with ES6 on the whole bundle), and you can even pick and choose the exact components you need from the jQuery npm package.

emodendroket 9y ago

I mean when does it stop being "vanilla"? jQuery is written in "vanilla JS" too.

Spivak 9y ago
Completely counter to the author I would say everything is vanilla until you start compiling and pollyfilling. Once you start writing in idealized languages like TypeScript, CoffeeScript, or ES6 you're no longer writing vanilla JS.
- emodendroket 9y ago
  I could see that, or else maybe it's not "vanilla" if you start using something like angularjs which expects to mediate basically the entire lifecycle of your application. But I think in general the concept is ill defined.

tareqak 9y ago

Are there any kinds of dead code elimination tools for JavaScript? If <link> tags can take additional attributes / query string parameters, the CDN be smart enough to only send down the required code.

olavgg 9y ago

At my company we prefer using vanilla Javascript over all these (exhausting) frameworks! Especially many of the new features in Ecmascript 6 makes things much simpler. No more overusing bind(), template literals for building HTML and so on. Recently I've missed the way you create DOM elements like you do with React.DOM so I created a simple proxy function like this: let bai = {}; bai.DOM = function(){ return new Proxy({}, { get: function(target, name){ return function(args, body) { let newEle = document.createElement(name); if(args){ let keys = Object.keys(args); for (let i = 0; i < keys.length; i++) { newEle.setAttribute(keys[i], args[keys[i]]); } } if(body){ if(typeof body === 'string'){ newEle.textContent = body; } else { newEle.appendChild(body); } } return newEle; } } }) }(); With this you can create new DOM elements as following, document.body.appendChild( bai.DOM.div( {"id": "message"}, bai.DOM.p(null, "hello world") ) );

mike-cardwell 9y ago

It took me less than 10 seconds to find an XSS on this website. Literally, the first place anybody would look worked.

cuu508 9y ago

I've found http://microjs.com/ http://microjs.com/ useful quite a few times.

ausjke 9y ago

the issue is that I need bootstrap which requires jquery

javascriptChris 9y ago

I agree jQuery isn't really needed but at the same time it's simpler for people who may not understand JavaScript fully of willing to look at boring web API docs to replicate some of the functionality.

stevebmark 9y ago

Can you imagine any other language / ecosystem where you're encouraged NOT to use any libraries of any kind? The web is a weird place.

sAbakumoff 9y ago

jQuery is here to stay. It will outlive react angular vue and whatever shiny framework you have been using.

tomxor 9y ago

As someone who's written a lot of DOM code, i've tried dropping jquery (and do) but selectively. You cannot drop it completely without great pain. It's true that the DOM interface has stabilised and is now mostly consistent cross browser, however the API is massively unwieldy in places, from excessively long method names to irritating asymmetric potholes. TLDR; Jquery is not needed for cross browser now, it's needed to make using the DOM API not so ridiculously verbose and long winded. You need to use jQuery today because: you want your DOM code to be 1/5th the size, more legible, more debug-able. I still use native methods where possible where there is little difference, especially when performance is a concern.

temporallobe 9y ago

I'm so tired of this argument. There's no reason to drop jQuery for any of the reasons stated. Especially with modern JavaScript engines, the performance hit is negligible. Also, jQuery is especially optimized for complex DOM manipulation which Vanilla JS cannot do on its own. Sorry, but querySelectorAll is not the same as jQuery's powerful selector engine, and you can't chain thngs the same way either. Sure, it's less relevant now than it once was and for minor projects you could probably get away with a no-library approach, but who are we kidding here? Most modern web apps and sites are extremely library and framework heavy. It's complete bullshit to say otherwise. The only exception is of course for design-centric, static content web sites which tend to heavily lean on CSS for display logic. This article is just full of amateur and meaningless advice.

futurefriendly 9y ago

Read this thread but replace every mention of jQuery with "table layouts", the parallels are striking. jQuery has been a good friend for many years. It saved us from the drudgery of cross-browser support and gave us an enjoyable API for browser development. Technology moves on, today's browser APIs and tooling are light years ahead of what we had 11 years. You might not need jQuery, and that's ok!