Jump to content

Which to learn and use JQuery or Vuejs?

pwuser1

By pwuser1,
in Dev Talk

 Share

Recommended Posts

adrian Hero Member

adrian

Posted
Posted

I don't really think it's one or the other. jquery is more a library and Vue a framework. I know it can be a fine line between the two, but something to be aware of.

jQuery is still everywhere and very useful for simple DOM manipulation tasks. Mind you I would also suggest that you should learn plain javascript first - having that foundation will serve you well and make it easier to pick up the next trendy JS framework. Also, why load up jQuery for one simple thing that could easily be achieved in plain JS?

Obviously Vue is becoming a popular framework, but a couple of years ago it was all Angular, and before that it was .... well you get my point. I do think that Vue is a good choice for a full blown framework right now though.

  • Like 8
Link to comment
Share on other sites
Ivan Gretsky Hero Member

Ivan Gretsky

Posted
Posted

Although Vue is being marketed as "incrementally adoptable" it is still aimed to become something react-like as I see it. That is a framework, that is to be used on a frontend, completely decoupled from the backend. In such architecture backend only serves data to a frontend via something like REST or GraphQL. And all the routing and markup generation is done on the frontend, in the browser.

ProcessWire surely can be used in that scenario (just follow the provided links), but in 99% of cases I heard about it is used in an "old-fashioned" way, with routing and markup generation done on the server (backend) and served via page reload, not ajax+in-browser state change+framework like Vue. That means most examples here on the forums will be more relevant to such a usage. Ryan is building at least his demo sites this classic way. Vue is something from the new frontend oriented world.  JQuery is something from that "classic" web-development world, which is still dominant.

JQuery is used throughout the PW core and modules code. And that code is a very good manual in itself. So learning JQuery with PW will be easier.

And (should it be first) PW API is known to be inspired by JQuery. Isn't it the ONE reason to learn JQuery first if going with PW?

So, for now, I would say JQuery is a better start to be used with ProcessWire.

  • Like 8
Link to comment
Share on other sites
Ivan Gretsky Hero Member

Ivan Gretsky

Posted
Posted
  1. Hey, @pwuser1! You could already reach some intermediate JQuery skill by now, spending half the time passed from the creation of this topic :rolleyes:. The basics are easy. Most of the times for the simple sites js+JQuery is about installing and configuring some plugins, using their docs pages and the official JQuery API reference (start by adding something like Magnific Popup to your site). But if you need some link to start with, I would recommend FreeCodeCamp course. The whole FreeCodeCamp thing is a hype so you'll feel yourself trendy))
  2. Just recently listened to an issue of ShopTalkShow, one of my favorite podcasts, that fits here perfectly. Could not resist to put  it here (for some controversy at least).

 

  • Like 3
Link to comment
Share on other sites
LostKobrakai Hero Member

LostKobrakai

Posted
Posted

I don't think specifically learning jquery is needed anymore. I'd rather try to improve your skills of using plain js, which should result in using jquery being more or less "reading the docs" if you need it. If the foundation in plain javascript is given or you start to have spaghetti code then look into the OOP features of js and frameworks like Vue/React/Angular. Additionally I'd like to add Svelte to the mix as well. It does look quite similar to Vue, but does include less of the features/magic one might not need in Vue. It's api look way more like plain javascript.

  • Like 4
Link to comment
Share on other sites
SamC Hero Member

SamC

Posted
Posted
On 25/12/2017 at 8:26 AM, Zeka said:

If you are new to JS world, IMHO, I would suggest this learning curve:

JS -> ES6 -> jQuery -> Vue / Angular / React

This is what I'm doing, been on plain JS for months. Still trying to get my head round that damn prototypal inheritance. My JS progress is so slow it's unreal, I just don't seem to get it. If there was another option for web programming, I'd be skipping JS entirely.

  • Like 3
  • Haha 1
Link to comment
Share on other sites
  • 6 months later...
siilak Jr. Member

siilak

Posted
Posted
On 12/24/2017 at 11:11 PM, pwuser1 said:

I want to make interactive websites with ajax as well.

There are nice and easy examples in GitHub for using Processwire Rest API with Vue / Angular / React

Whit them you can easily build nice websites with smooth page render, navigation and more.

Link to comment
Share on other sites
SamC Hero Member

SamC

Posted
Posted
On 12/26/2017 at 10:58 AM, LostKobrakai said:

I don't think specifically learning jquery is needed anymore. I'd rather try to improve your skills of using plain js, which should result in using jquery being more or less "reading the docs" if you need it.

6 months later on my journey and I completely agree with this.

Had to modify some jQuery the other day and it was super easy with a relatively decent background in plain JS now.

Link to comment
Share on other sites
  • 2 weeks later...
  • 8 months later...
szabesz Hero Member

szabesz

Posted
Posted (edited)

Also worth noting that there is a 7 page book related to the rejection craze of jQuery and other libraries: https://www.oreilly.com/programming/free/native-javascript-apis.csp 

Quotes:
"If you’re using native APIs in your application logic, you can’t help but know what browser is being used because you need to account for browser differences. That means your application logic will always need to be updated as new browsers and new browser versions are released. That’s a recipe for disaster. ... You should absolutely be using a JavaScript library to abstract away browser differences for you. ... Libraries like jQuery, YUI, and Dojo abstract away browser differences behind facades, which allow you to focus on building your application logic in a browser-agnostic way. ... So, keep using your favorite JavaScript library. Don’t be tempted by the draw of native APIs simply because you can avoid downloading an external library. Using native APIs comes with a high cost of maintainability down the road."

People write spaghetti code because they do not know JavaScript well enough and/or do not use appropriate design patterns, which is not jQuery's or other libraries' fault. One can just as well produce unmaintainable code by using any framework out there.

Here is the case of UIkit 3 which relies on its own 132k JS library which is only partially documented: https://github.com/uikit/uikit-site/blob/feature/js-utils/docs/pages/javascript-utilities.md They say: "...allow you to write simplified Vanilla JavaScript and replace the most common functions of jQuery"
So they got rid of jQuery by partially re-implementing its features. Good to know... Now if I add jQuery I have overlapping feature sets and the visitor of the site has to download more assets ? Is it an improvement?

At the same time the current full version of jQuery (3.3.1) is 87k and one can use versions leaving out features not needed (say AJAX or effects if not used on a site), so it can further be trimmed if the projects allows.

Introducing a mature and maintained JS library called JsViews:

Currently, I have started to build upon a library which can either be used along with jQuery or without it: https://www.jsviews.com/
It is from one of the jQuery authors. Worth checking out the examples, eg.: https://www.jsviews.com/#samples/computed/team-manager

JsViews can be used without precompiled JS templating – so it is easy to get started – and it is still very performant that way. One can also use a builder to precompile the templates if needed (think of the needs of overly complex JS apps and NOT websites). By using JsViews one can rely on declarative programming and build upon design patterns built in. By adding jQuery to it, code becomes shorter, easier to read and maintain.

Edited by szabesz
typos
  • Like 7
Link to comment
Share on other sites
LostKobrakai Hero Member

LostKobrakai

Posted
Posted

I'm really wondering when this book was written though. I've not had major problems with differences in browser implementations in years. The bigger problem is support of APIs, which might not be present in all browsers, but those are imho better solved by adding polyfills, which can be removed once browser support numbers are high enough without changes needed to be made to the actual javascript. I mean jQuery is still a valid choice today if you need it. I just feel the number of times you really need it is diminishing. Browser APIs getting better is one reason for that and the move away from imperative DOM manipulation to more abstracted view libraries is another. jQuery's move to slimming down it's core size might also have been just a notch to late, when everybody was already migrating of of jQuery.

Edit:

On 4/7/2019 at 8:53 AM, szabesz said:

If you’re using native APIs in your application logic, you can’t help but know what browser is being used because you need to account for browser differences. That means your application logic will always need to be updated as new browsers and new browser versions are released. That’s a recipe for disaster. ... You should absolutely be using a JavaScript library to abstract away browser differences for you. ... Libraries like jQuery, YUI, and Dojo abstract away browser differences behind facades, which allow you to focus on building your application logic in a browser-agnostic way.

If you're using jQuery in your application logic, you can't help but know how you directly manipulate the DOM and need to account for all the details needed to change it. That means your application logic will always need to be update if you want to alter behaviour down to the updates to the DOM needed (e.g. change detection to keep changes minimal for performance reasons). That’s a recipe for disaster. You should absolutely be using a javascript view library to abstract away what parts of the DOM need to be updated. Libraries like Vue, React, Svelte, … abtract away the low level DOM manipulations behind facades, which allow you to focus on building your application in a rendering-agnostic way. This goes as far as using e.g. reactnative outside the browser.

Arguments like that can be made for any layer of abstraction out there. It's a matter of which level of abstraction makes the most sense for a certain project to be written in. 

  • Like 1
Link to comment
Share on other sites
LostKobrakai Hero Member

LostKobrakai

Posted
Posted

As I've mentioned svelte already and the filesize argument was used:

https://v3.svelte.technology/repl?version=3.0.0-beta.22&example=onmount 
This example downloaded and compiled results in a 4kb javascript bundle. I'm quite sure even just the code using jquery would need about half of that size to do the same excluding jquery itself. So there are more modern ways to have the benefits of a nice view library in javascript without the need for bloated runtime library code. Svelte has a tiny runtime library, which can even be tree shaken (only include what's needed), while the heavy lifting is done at once at compile time. The better part of your file size bundle will only consist of the actual stuff you build using it. 

It's only sad that it's currently in a "please don't start using v2 anymore, but also wait till v3 is done" phase.

  • Like 1
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...