Skip to content

Querypath vs jQuery difference #17

Closed
Closed
Querypath vs jQuery difference#17

Description

@jakejackson1
jakejackson1
opened on Dec 7, 2022

From querypath created by Jelle-S: technosophos/querypath#113

First of all, I love this library!

On the homepage of Querypath, the library is described as "jQuery for the server". And after using it a couple of times, that's exactly what it is!

But -and I don't think this is a real "issue"- I found a quite large difference with jQuery and I was wondering what the reason for this difference is (and I'm guessing it's performance and memory usage, but I just wanted to check to be sure).

Ok, so in jQuery you can do the following:

var $body = $('body');
// $body represents the body DOM element.
$body.find('div.changeme').text('I am changed');
// $body still represents the body DOM element.
var $some_element = $body
    .find('#footer')
    .find('#copyright')
    .find('.some-class')
    .find('.some-element');
// $body still represents the body DOM element.

If you do the same in Querypath, the $body variable would change constantly:

$body = qp('myhtmlpage.html')->find('body');
// $body represents the body DOM element.
$body->find('div.changeme')->text('I am changed'); 
// $body now represents div.changeme and we would need
// to call $body->end() for it to represent the body DOM
// element again.
$some_element = $body
    ->find('#footer')
    ->find('#copyright')
    ->find('.some-class')
    ->find('.some-element');
// $body now represents .some-element and we can only
// use $body->end() once, twice would result in an empty
// QueryPath object, so we can only go as far back as .some-class.

The alternative would be to clone $this on each call and set the matched elements on the cloned object and then returning the clone in stead of $this. I can imagine how that could be a memory issue, but I'd just like your thoughts on this.

Activity

  1. jakejackson1 commented on Dec 7, 2022

    @jakejackson1
    jakejackson1
    on Dec 7, 2022
    MemberAuthor

    Hmm... commenting via email has really bad formatting.

  2. jakejackson1 commented on Dec 7, 2022

    @jakejackson1
    jakejackson1
    on Dec 7, 2022
    MemberAuthor

    Over the course of QueryPath's history, I've changed this a few times based
    on feedback.

    In QueryPath 2.x, find() (and most traversing methods) was destructive. To
    get around that, I also provided the branch() method, which worked like
    jQuery's find() function (e.g. is non-destructive).

    In QueryPath 3.x, find() is non-destructive (works like jQuery) and
    findInPlace() is destructive. Like you suggest, find() basically clones the
    base object and then queries it.

    The rationale for QP2's model was, as you guessed, memory management and
    speed. But when I rewrote the internals on QP3, those weren't so much of an
    issue. So we put it to a pole, and most people voted to move back to the
    jQuery model.

    With all of that said, it's been so long since I've spent any real time
    reading the jQuery documentation that I'm worried I might be diverging
    unintentionally. If you do catch things, please let me know!

    In fact, if you're interested, you may be able to weigh in on issue #112.
    I'm trying to figure out how to handle selectors passed to children(). I
    think I broke QueryPath 3 when I changed the querying engine.

    technosophos/querypath#112

    Thanks!

    Matt

  3. GravityPDF
    locked and limited conversation to collaborators on Dec 8, 2022
  4. jakejackson1
    converted this issue into a discussion #33 on Dec 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions