Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think a lot! For example, the new https://www.whitehouse.gov uses jQuery.

When you just want to add a small bit of interaction to a mostly-static site, jQuery can help.

There's a current trend to complicate things with a JAM stack that really don't need to be complicated.

I've seen people propose something like

    [NodeJS/Ruby/PHP backend] 
      -> GraphQL API 
      -> React Frontend 
      -> static html
Where really they could have just gone with

    [NodeJS/Ruby/PHP backend] 
      -> static html


I do think in some cases SPA make sense, but in many other cases just using a bit of jQuery/vanilla js to add a bit of interaction is enough. Server side rendering is way easier to do and is often faster to load for the client.


SPA make sense whenever you want to write a proper application running in the browser. When you just want a website, stop the SPA madness.


> When you just want to add a small bit of interaction to a mostly-static site, jQuery can help.

For very small amounts, perhaps, but honestly, even then I think it has limitations. As an anecdote, about six months ago, I needed to add a couple of dynamic forms to a static site. The forms were a simple contact us, and a mailing list sign up form, and only needed to handle the states of Open->Submitting->Thanks|Failed->Open, while preventing double submissions, etc.

I wrote the first one in jQuery (site was already using it due to the theming), and making sure handled all the various edge cases, and fixing one bug didn't cause another was far harder and time consuming than it should be.

Out of frustration, I wrote the other form in VueJS, and hacked the whole form in about an hour or two. My take away was that anything involving state in jQuery can get overly complicated very quickly.


> When you just want to add a small bit of interaction to a mostly-static site

Then I'd reach for Alpine. Very lightweight, and I can use the fetch API instead of $.ajax.


Jquery has been around for 14 years. That framework..16 months.

You want to be as confident as possible you can bump to a new version on your old site in 4 years if you have to? Use Jquery.


Plus it's easier to hire for. Chances are more developers have experience with JQuery than <new hot js library>.


Or just fork Alpine and fix it. It’s javascript, not rocket science.


Perhaps even htmx?

https://htmx.org/


This looks very cool, thanks.


or Lit-Element.


whitehouse.gov uses jquery because its wordpress


To be fair the first case is only static for the initial load then becomes a single page application


Yeah, but very few sites need to be SPAs. SPAs come with a tremendous amount of extra requirements that, over time, can mire projects in cruft.


There's no need to complicate static sites with jQuery. All it does can be achieved with vanilla.


Vanilla has always been able to do what jQuery can, otherwise jQuery wouldn't exist. It all depends on what your threshold for abstraction and verbosity is. That is going to depend on what you are doing and who you are.


Exactly.

I mean, all you really need is a Turing Machine, but they're not very pleasant to program.

Same thing with vanilla JS and jQuery.


> All it does can be achieved with vanilla.

Well, yes. Every JS library can be written in vanilla JS. The point of jQuery, React, etc. is to make it easier for the programmer to reason about what is going on while avoiding bugs.


I tend to agree, and unless you have to support like IE prior to IE9 it will probably easily support all of your target browsers.


Promises aren't available in IE11, and as the last "true" IE, I imagine it'll be around a bit longer than it should be.

I recently had to rewrite a bunch of vanilla promise-based code to use jQuery promises once I realized IE11 didn't work.


As a competitive code golfer, I can confidently say that vanilla JS has never offered the raw performance of jQuery.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: