JSDOM Support in the Browser?

[Marak]

It occurs to me it might make sense to port JSDOM to the browser so we can have the same DOM like APIs when interacting with HTML on the browser.

I've been reading up on the browserify library. I think it might be useful in getting JSDOM working in the browser. https://github.com/substack/node-browserify

@substack do you have any idea on how to pull this off? could be really powerful...

[ghost]

Well there are no C bindings so it should be theoretically possible, in theory.

[heapwolf]

it would certainly be interesting to try this, perhaps porting some C bindings to javascript would help...

[jfhbrook]

I gave it a shot, I thought this gist might come in handy.

[dominictarr]

what, no C bindings?

reimplement in C (for performance) and then run in browser with this: http://bellard.org/jslinux/

hang on, ill post this as a separate issue.

[tmpvar]

@Marak, is there a use case for this beyond webworkers?

[Marak]

I just think that the browser could really benefit from having a DOM.

[tmpvar]

The browser does have a DOM ;)

[Marak]

I'm pretty sure it doesn't.

[tmpvar]

heh, there is a valid use case here though. webworkers do not have access to a dom, jsdom might fill that gap.. not sure what the use case is though.

[Qard]

[JerrySievert]

i threw together some benchmarks for this.

i had to simulate the JSDOM in the browser, as it is all theoretical at this point, but figured the benchmarks would still stand on their own.

[novemberborn]

I'm using JSDOM to parse and compile templates, including HTML parsing. Being able to run that in (a modern) browser would be quite lovely since it saves me having to run a Node server just to get compiled templates.

[tommedema]

@novemberborn, I'm confused, can you not use jQuery on the browser to achieve such parsing?

[novemberborn]

@tommedema innerHTML doesn't parse full HTML syntax, so my guess is no.

[tommedema]

@novemberborn, why do you not simply traverse through all dom elements in the document? $(document).descendents()

[jfhbrook]

@tommedema @novemberborn It's a bit tough to traverse dom elements without a dom, hence the need for jsdom. Clearly.

[tommedema]

@jesusabdullah, can you explain how one can traverse through all document elements in the browser, using for example jQuery, when this browser does not have a Document Object Model? I am sure you are absolutely correct, I'm just a bit confused as to why browsers do not have a DOM.

[jfhbrook]

@tommedema Traverse through document elements? Why would you have to do that?

[tommedema]

@jesusabdullah, I'm not saying you have to do that, I am merely saying you can do that. The question is how one would be able to do such thing if there is no Document Object Model. If this is only possible with a DOM, that directly implies that browsers do have a DOM. This is why I am asking you how this would work.

[Marak]

This started as funny, now I'm not sure anymore.

[JerrySievert]

To be fair, the idea of dom manipulation from web workers is appealing, but I don't think this is the right solution. A bit of thin shimming as a communication layer could do a good job of handling that.

[novemberborn]

@Marak, the issue got off-topic by some confusion around jQuery and the use cases. Still, if JSDOM has no native bindings, it'd be lovely if it could work in the browser so you can do more DOM parsing than you could do using innerHTML, with the exact same output as server-side usage of JSDOM would yield.

[tommedema]

So I guess noone is going to explain how exactly a browser does not have a DOM? :) It's very much on-topic, since this request only makes sense if there is indeed a lack of a DOM (or if jsdom is in any way an improvement to a "browser's DOM" (if existent)).

Even Google talks about browsers having a Document Object Module, see for example http://code.google.com/webtoolkit/doc/latest/DevGuideUiDom.html (Developer's Guide - Accessing the Browser's DOM).

I'm not saying you are wrong, though.

[novemberborn]

@tommedema Yes, the browser has a DOM. I don't think it necessarily exposes utilities to parse arbitrary markup into a DOM tree, especially if that markup may include doctypes, <html> tags, etc. And even if it did, would it give the same output as server-side JSDOM?

My specific use case is using JSDOM to parse a template snippet, which isn't your typical "I need to run JS against a DOM but in Node".

[tommedema]

@novemberborn, I see.. that explains. Thank you.

I can see why this would be useful, if you are able to get the exact HTML of a page (you probably have to route it through a server or save it as a static string in your code, as each browser modifies HTML before rendering it). Every

[Morriz]

Bump.

I am trying to make my node stack work in other js environments as well. Titanium Appcelerator is great for quick and dirty demo's, especially if you only have to code your app once for each environment. So far I have been able to make it work on Node and in the browser. See backbone-everywhere.

I am now missing out on jsdom not being able to be packed with browserify. Real enuf use case for you?

[tmpvar]

@Morriz, can you open a separate issue for that? I can definitely see the benefit of being able to run jsdom on multiple platforms. To what extent will need to be resolved though.

[Morriz]

Sure. I will refer to 'other javascript server environments'.

[davidmarkclements]

I have a use case for jsdom in the browser,

img src tags are not fetched if by wrapped in noscript tags (e.g. lazy loading, responsive images), because the contents of noscript tags are not added to the dom

we can extract (with some difficulty on some browsers) the contents of the noscript tags - it would be great it we could interact with content of the noscript tags as dom elements (e.g. alter the src attribute for img tags that have a certain classname) without making them part of the dom (which would of course, begin to load the src URIs).

[btakita]

I have a use case. I'm using browserbuild & TDDing using Jasmine. I'm running the tests in node.js for quick development, & running the browser version of Jasmine on CI.

I'd like to be able to use a consistent api on both the node.js server & browser. I can build a shim of some type for now, but it would be great to have it supported.

[rattrayalex]

In my case, I am using browserify to use libraries that call jsdom as a dependency. So while I can replace the call to jsdom with a simple window.document, I now will have to submit a PR to the library to handle the browser separately, since it doesn't have jsdom's API (eg; childNodes._toArray())

[domenic]

jsdom works in the browser with browserify now

[rattrayalex]

Ah, awesome. Looks like it (almost) does (though you have to run npm install in the jsdom dir inside your node_modules due to reqs being in devDependencies).

But I'm running into an issue with module.parent being undefined (line 61 in jsdom.js of release 1.0.1, appears to be in master too). Not sure if this is user error or what. But I don't believe browserify supports module.parent since it's maybe deprecated? see browserify/browserify#41

[domenic]

@rattrayalex can you open two issues for those things, with repro preferably? jsdom should work out of the box browserified; we even have tests running on Sauce Labs against it.

[rattrayalex]

Huh k will do.
On Oct 10, 2014 10:00 PM, "Domenic Denicola" notifications@github.com
wrote:

@rattrayalex https://github.com/rattrayalex can you open two issues for
those things, with repro preferably? jsdom should work out of the box
browserified; we even have tests running on Sauce Labs against it.

—
Reply to this email directly or view it on GitHub
#245 (comment).

[danvitoriano]

Any update on this issue? I'm facing the same problem with require on browserify. Tks!

[domenic]

Nobody had provided a separate issue with repro steps. Our CI runs jsdom in the browser using browserify every day so it probably is not broken.

[bogas04]

It's 2016, can browsers get their DOM now ?

[Joris-van-der-Wel]

sure, jsdom even works in Web Workers

[bogas04]

@Joris-van-der-Wel only for browserify bundles or even for webpack ? Coz I'm getting fs module not found when I use it in one of my module

[Joris-van-der-Wel]

We only test (CI) jsdom with browserify at the moment, I've never tried webpack. browserify automatically translates node.js core modules to a browser equivalent, which is what jsdom expects. I am not sure if webpack supports that.

However you could use browserify to generate a standalone bundle of jsdom (the generated bundle will try to detect what module system you are using), and then include that in webpack.

Here is something that you can try:

browserify -r jsdom -s jsdom -o jsdom.js

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <script src="jsdom.js"></script>
    </head>
    <body>
        <p>hi</p>
    </body>
</html>

Now open the developer tools in chrome, and you can try typing something like jsdom.jsdom('<div>foo</div>').documentElement.outerHTML in the console

[bogas04]

This is awesome. Thank you so much!!