Forward and back on <webview> slow, other questions


#1

I’ve been enthusiastically playing with electron for a bit now, finding it vastly superior to nw.js – BUT… I’ve hit a few minor snags and questions.

.forward() and .back() are both painfully slow, even compared to loading actual pages. There’s almost two seconds of overhead from when the click on my control is released, and the actual fw/bk gets fired. Since I’m trapping onclick on my forward and back anchors to fire it, cancelling the anchor’s bubbling/cascading/event, and trapping dom-ready, page-title-set and did-stop-loading I log using console.log the time between sending the .back() and those three events, and the first one to fire – page-title-set – comes up after about a second and a half; this is a ridiculous amount of time when the sites being visited load in less time than that with a cache-empty first-load… What gives?

Half tempted to see if storing my own history when page-title-set fires (filtering redirects?) and then force-loading it would be faster than the provided methods. Hell from what I’m seeing it would be faster to trap forward/back by deleting the webview and making a new one in its place than the built in methods.

I’m also a bit dismayed at the lack of history being exposed – I know this stems from the HTML and JS spec, but really what good is back(amount) if you don’t have any clue how many history items are even there?!? Doesnae make the least bit of sense to have methods like goToIndex or goToOffset if you can’t actually access the full ‘history’ itself?

I’m also a little curious – are we able to configure things like cache sizes, cache storage location and so forth? I do like that in addition to .reload() there’s .reloadIgnoringCache(), but more control over the webviews would be nice.

Is it possible to block client scripting in a webview, but NOT injected scripts from the hosted page? The documentation’s a bit unclear on that.

Also wondering if there’s a way to trap when a file would be downloaded so I can handle and/or block that.

Finally I’ve not tried it yet, but do .preload() scripts execute before or after the DOM is ready or the markup is fully parsed. I’d like to be able to play with the markup/DOM BEFORE any scripts present on the page fire, and not sure if we have that level of access.

Still for all my questions and the forward/back problem, I’m WAY farther along and WAY happier trying to use this to make a web app than I have been with anything else. This has actually lit a fire under my arse.

Oh, and if it helps any with the fw/back issue I’ve tested on three different systems:

Windows 7, i7 4700mq, 12 gigs RAM, GTX 765m video

Windows 8.1, Celeron Q1900 (2ghz quad), 16 gigs RAM, GTX 650ti video

Windows 10, i7 4770k, 16 gigs RAM, GTX 770 vid

I also for laughs tested in a hackintosh build and Mint under VirtualBox on the 8.1 machine, no difference. It’s actually funny because normal page navigation feels faster than Chrome or Vivaldi – but forward/back is like driving a 1984 Yugo GV with the parking brake on.


#2

To be honest, I don’t think anyone has really tested forward or back performance before because Electron isn’t designed to be a web browser. It’s designed to be an application framework that uses web technologies. If you look at how Atom works, there’s no calls to forward, back or reload; or cache sizes or locations. It’s all just a single-page application where the DOM gets modified over and over and over again.


#3

Thing is, it exposes better than anything else I’ve tried, apart from that one oddball shortcoming… I really wonder what is taking so long for it to pass the call.

I’m gonna try a few different things to see if I can work around it.