PlainJS – Vanilla JavaScript Repository

https://plainjs.com/

by shakes • 9 years ago

210 156 9 years ago

plainjs.com

AndyKelley• 9 years ago

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

projectramo2• 9 years 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.

EGreg3• 9 years 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 :)

beager7• 9 years 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?

tentaTherapist2• 9 years 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.

dualogy• 9 years 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

shortstuffsushi4• 9 years 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• 9 years ago

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

allover2• 9 years ago

jQuery is more than the DOM api.

projectramo2• 9 years 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• 9 years ago

https://en.m.wikipedia.org/wiki/Poe's_law

spankalee• 9 years ago

Web Components

freshyill• 9 years 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.

Touche4• 9 years 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• 9 years 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• 9 years 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.

jordache4• 9 years ago

who still uses jquery? to create usability mockups?

chickenfries• 9 years ago

This is like asking "who still uses wordpress." Outside of the HN bubble, everyone still uses jQuery.

dmitriid9• 9 years ago

Even inside HN bubble people regularly drop into jQuery from inside their Reacts and Vues and Polymers. Just because it's super convenient

jncraton• 9 years 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

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• 9 years 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.

_ZeD_• 9 years ago

like, everyone.

jonknee3• 9 years ago

I'm going to shock you here, but jQuery is more popular than React. By several orders of magnitude.

https://w3techs.com/technologies/overview/javascript_library...

nextlevelwizard• 9 years ago

Single reason why I should not use it?

emodendroket5• 9 years ago

Someone on HN might make fun of you.

dmitriid9• 9 years ago

Simple: You don't need React/Vue/Polymer for everything.

Personal anecdotal evidence: helping a friend create a very simple dashboard of running jobs returned by a REST service + stats returned by the same service etc. I've yet to find a reason to use jQuery, much less a bigger framework.

woah2• 9 years ago

I think you meant "who still starts new projects with jQuery?", and you got a bunch of replies to "who still maintains jQuery codebases?".

jordache4• 9 years ago

I will make the assertion that jQuery is only useful for lightweight DOM manipulating. Any more complex than that, one would use a JS framework to implement the client experience. In this case, you would not want to jQuery.

So essentially we are talking about server side apps that still leverages jQuery to achieve some level of dynamicity on the front-end.

gizmodo59• 9 years 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.

EGreg3• 9 years 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-627• 9 years ago

Why not try rolling your own?

* http://projects.jga.me/jquery-builder/

* https://www.ericponto.com/blog/2014/10/05/es6-dom-library/

rhizome2• 9 years ago

How do I get jQ without <IE9 support?

batat• 9 years 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....

[2] https://github.com/ThibaultJanBeyer/DragSelect/blob/master/s...

Touche4• 9 years 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• 9 years 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.

aurbano2• 9 years ago

Dead code elimination (i.e. UglifyJS) should do away with most unused code from a library - so with a proper build system this shouldn't be a big concern...

madeofpalk4• 9 years ago

removeClass and hasClass are interesting choices considering browsers ship with these APIs

jlukic• 9 years ago

These utility functions and shims are "per" component. This means that functions like extend will be repeated many times in different idiosyncratic code across app.

Imagine your app uses, modals, dropdowns, multiselects, search autocompletes, sliders, rich text areas etc. Instead of having one cached utility library upfront you have many hidden utility libraries scattered around each component, which makes it difficult to say clearly that jQuery is always larger.

The other issue is maintainability. When you're working with third party components, hot-fixing an OS library can be fairly daunting if you need to also learn their own internal class structure, selector helpers, dom manip functions. Doing this in jQuery, it's fairly easy to fork the codebase and plop in a .clone() or .append() to fix a stale issue.

twhb4• 9 years ago

Your JS knowledge appears to be severely outdated. Instead of the first you can now write:

    Object.assign(target, object1, objectN);

The second:

    element.classList.add(className);
    element.classList.contains(className);

And the third has been fixed at a community level, as we've learned the value of API strictness, obviating such checks.

I don't think anybody was against jQuery back when the alternative was helper functions, I certainly wasn't. But that's five years ago at this point. Modern JavaScript looks nothing like the code you posted, it's actually been built up into a pretty good language.

sosuke• 9 years ago

Perhaps the examples are just a reflection of having to support Internet Explorer?

csomar• 9 years ago

You are ignoring browsers support. One of the main reasons I suggest using jQuery is browser support. Another solution is to use a transpiler like Bable.

padseeker2• 9 years ago

Are you absolutely certain that everything that jQuery does can now be done in a clear and concise way using plain Javascript? I've written some fairly complex jQuery selector over the years, perhaps I'm wrong but I something tells me that while the simple use cases can be done with plain old js the more complex selectors might not be so easy.

I find this debate so aggravating. I'm glad you can do some of the stuff jQuery does using modern vanilla js. Perhaps jQuery is overkill for doing one hide/show (or toggle) action on the page. But what about the more complex stuff. What is primary motivation behind this nagging issue, of the load time of jQuery?

I suspect it is that many developers have some obsession over shaving a few milliseconds on their load time. For jQuery? One library? Is it that bad that you need to write vanilla js? So you can save a few milliseconds?

Can you have a sophisticated selector for Event Delegation without using jQuery but make the code concise and easy to read? What about child selectors ("ul.thisClass > li.thatClass" > span.otherClass").

I like jQuery because the syntax makes sense, its clear and concise, you can do complex things with less code. Maybe some of the new stuff can be clean and concise and easy to read, but all of it? I have my doubts.

jswizzy• 9 years ago

The real problem is JQuery isn't modular and it is tightly coupled with your code.

manigandham2• 9 years ago

If you're using a build system like webpack you can use Babel/minify to get rid of unused code or pick and choose your modules directly from the npm package.

nightski• 9 years ago

I've thought a lot about this and honestly I'm curious if this would even be an advantage. Currently I can pull in jQuery from a CDN and it is likely used by many other sites. If I have a custom version of jQuery, now it is guaranteed to need to be loaded. Is it truly a win?

zamalek• 9 years ago

I don't think that burying jQuery is the best idea, too. It is a very well-designed library. What we really need is a library of functions to make the native APIs less awful and verbose - which exists: Zepto.js.

Ultimately mutating the DOM directly is just an awful job - it's solving problems that are ancillary to the problem that you are trying to solve (making great UIs). React and Vue feel like sensible abstractions, although there's still a far better but undiscovered solution to this problem.

dheera• 9 years ago

Vanilla JS is more about being agnostic to the framework and framework version the developer is using. Not everyone uses jQuery, and if you library depends on it, you now require several tens more kilobytes of bloat to be loaded just for your thing to function.

g00gler2• 9 years 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• 9 years 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

megous5• 9 years 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.

g00gler2• 9 years ago

Very true, nice codes :). Would be nice if we could write that without transpiling.

91bananas• 9 years 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.

emodendroket5• 9 years 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?

Spivak2• 9 years 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.

hw2• 9 years 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.

currysausage• 9 years ago

What I'm looking for: libraries instead of one-size-fits-all frameworks. Libraries annotated for Closure Compiler's advanced compilation mode, so I can automatically tree-shake all the code that I don't need.

m_mueller• 9 years ago

Could you give a common example from jQuery core that could be left away? I'd hate if I find a documentation about a method for a jQuery object only to find out that I don't have that extension yet. IMO its size is just about right.

alistproducer2• 9 years 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?

disconnected2• 9 years 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.

madeofpalk4• 9 years 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.

megous5• 9 years ago

'each' is not. forEach is.

disconnected2• 9 years ago

"each" and "filter" were used as examples of what you can do.

You don't have "on", "off" and "trigger", for example.

mark242• 9 years ago

The sizzle library that jQuery uses takes advantage of querySelectorAll.

https://github.com/jquery/jquery/blob/2d4f53416e5f74fa98e0c1...

...only with a ton of wrapper code around it in order to support IE9 and below. If you don't have to support ancient browsers, there's no reason you can't write QSA code.

var nodes = document.querySelectorAll("li"); for(var i=0; i<nodes.length; i++) { nodes[i].classList.add("foo"); }

Yes it's slightly more code. It's also going to run a hell of a lot faster on, eg, a mobile device.

52-6F-627• 9 years ago

Lol. You beat me to it. Kudos.

megous5• 9 years ago

I prefer:

    for (let node of document.querySelectorAll("li"))
        node.classList.add('foo');

or:

    Array.from(document.querySelectorAll("li")).forEach(node => node.classList.add('foo'))

And if any particular pattern repeats in the code I'm writing I'll just create a helper function for that pattern (most of the time locally). Like:

    let qsa => s => Array.from(document.querySelectorAll(s));

There's nothing to test about that.

megous5• 9 years ago

Or use fetch()

52-6F-627• 9 years ago

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

---

jQuery selectors were matched in native JS by `document.querySelector()` and `document.querySelectorAll()`

Pretty sure `querySelectorAll()` operates quite the same as jQuery's selector which returns an array of element objects that you can perform actions upon. The primary difference being that you'll have to run the actions in a loop over the array if you want to perform them over the entire selection. Eg:

   let elements = document.querySelectorAll('li');
   for(let i = 0; i < elements.length; i++) {
     elements[i].addEventListener('click', e => {
       console.log(`This element is ${elements[i]}`);
     });
   }

You could write a helper in a few lines to handle that throughout your codebase if it's commonly used.

yunyu• 9 years ago

You can wrap that in Array.from() to take advantage of foreach, filter, etc..

dmitriid9• 9 years ago

jQuery selectors were matched in native JS by `document.querySelector()` and `document.querySelectorAll()`

Funny how the first words of your statement are completely negated by the last half of your statement.

jQuery:

   $(<any selector>).anyfunction

This will work regardless of the number of elements returned by the selector: 0, 1, or any number.

The so called matching `document.querySelector()` and `document.querySelectorAll()` cannot come even close to the ease of use of jQuery's selectors.

`document.querySelector` returns one element only. It will be the first element matched, even if you have more.

`document.querySelectorAll` returns a pseudo-array of elements (in reality a NodeList) that lacks most of functionality of arrays, and you cannot apply any DOM functions to it without iterating through the entire list.

jQuery came out in 2006. It took w3c several years after that to come up with something resembling jQuery's selection function. 11 years later there's still not a single method in the entire DOM API that comes even close to jQuery's simplicity and expressiveness.

tomcam• 9 years 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.

talindras• 9 years ago

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

woah2• 9 years ago

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

beager7• 9 years 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.

allover2• 9 years 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.

beager7• 9 years 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.

throw2016• 9 years 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• 9 years ago

DHTML, the framework!

fiatjaf• 9 years ago

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

manigandham2• 9 years 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.

emodendroket5• 9 years ago

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

Spivak2• 9 years 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.

emodendroket5• 9 years 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• 9 years 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• 9 years 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• 9 years ago

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

cuu508• 9 years ago

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

ausjke• 9 years ago

the issue is that I need bootstrap which requires jquery

javascriptChris• 9 years 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• 9 years 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• 9 years ago

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

tomxor• 9 years 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• 9 years 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• 9 years 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!

PlainJS – Vanilla JavaScript Repository

Related Stories