Forgive me if the question is too subjective.
I do understand what it is. No need to explain that, please.
I just don't get why people find it useful. Same for live reload. The act of pressing CMD+R isn't something that takes time. If the actual refresh takes significant time, seems like one should just fix their dev environment.
I have a trust problem with such things. Seems too likely that they'll end up causing bugs. I fear that I'd spend an hour tracking down a bug only to find it was hot-module-reloading's fault. Or that everything is working in dev, but breaks in prod because prod isn't using hot-module-reloading and dev is. Perhaps this fear is misplaced.
I also find it tricky to know when the changes have taken effect. Seems simpler to just know that once you press CMR+R, your changes are there.
It's an efficiency thing. No matter how fast your dev environment is, when you press Refresh, it's going to take a second or two, since by definition things won't be coming from cache, and we're talking dev so there could be a bunch of HTTP requests that would be consolidated into a just a couple of HTTP requests in production. So if your workflow is save, switch to browser, hit refresh, you're sitting there for a couple of seconds. Every time.
With live-reload, hit save in your editor, and by the time you've switched over to your browser, the refresh is already completed or at least underway.
I was skeptical about the value of it until I started using it. Definitely noticed cycles were a little bit faster, sometimes markedly faster depending on what I changed and whether I flipped to the browser right away or not.
I haven't had trouble with it causing bugs. YMMV.
HMR relies on the maintaining of state. For a simple web app the reload may only take seconds. For a complex web app the steps required to get to a state may be long and complex, open to mistakes along the way. So you do your long list of steps, get to the bit you are testing and smack, a silly typo means you have to start over again. All that unnecessary repetitive work can be avoided, changing a job from hours to tens of minutes by using HMR. I have no problems trusting it for what it is designed to do.
You would never release without testing, and you would never test with HMR. HMR is for development, you only need to trust it to maintain a state while work through a module.
It scares me too... if I can't trust it 100% of the time (and I can't get away from refreshing 100% of the time), why worry with the extra complication of it?
It's refreshing to refresh. That's my new saying.
Related
I have a large project I'm testing locally where, intermittently, with no changes to the code, and with no common events, the site will suddenly display massive numbers of "invalid character" errors in basic js libraries like jquery. If you try to look at said js files in debug in the various browsers, they come up as gibberish as if they were compiled (they aren't)
The site will lose its formatting because of the lost access to various js libraries, and everything will misbehave. Hitting ctrl+F5 will randomly make it better, worse, or have no effect at all.
Rebuilding the site, resetting IIS, and restarting Visual Studio has no standard result. The only thing that is true is that after A Period Of Time, with no changes made or unmade to the code, the issue will clear as mysteriously as it arrived. Looking at the js files return to their un-gibberishy format, and all proceeds as if nothing has occurred.
It's a large project, and there are certainly packages and libraries that have updates which we're not in a position to update right now. It's the intermittent nature of the issue that's the most annoying - it'll happen with no changes made to the code, and fix itself as mysteriously. It's happening for all users, so it doesn't appear to be any one person's issue.
We're not seeing such a thing happen on out test and production servers, only which running and testing locally. It'll happen whether or not the VS debugger is on or not. There's no common trigger that we can find.
Anyone ever heard of something like this?
From what I can tell about this message, it appears when the driver encounters an error. The implication seems to be that the JavaScript code can't trigger this warning even if there's some kind of mistake in it, because of higher-level error checking.
But my code recently triggered it, just once and I haven't been able to reproduce it (and the code — in theory at least — sends the exact same commands to WebGL every time). So I just want to know if I should be debugging my code (I can't see any obvious errors), or if I should put it down to a hardware random / browser bug.
I can post semi-reduced code on request, but it's still about half a thousand lines and I certainly don't expect people to debug it for me, hence the more general is-it-possible question.
I'm struggling a little with what your question means by "trigger". When this error occurs, javascript is always in the causal chain, because WebGL doesn't run without javascript executing it, right? So certainly it's possible to trigger the error accidentally (unless you always trigger it on purpose, which I'm sure is not the case).
However, graphics drivers are notorious for being affected by many factors that are not under programmer control or necessarily detectable by the programmer, and therefore seem non-deterministic. That's why Google recommends that you try reloading the page when the error occurs. (A link to their guidance was here, but they moved or removed the page.) I've often had Chrome successfully display some WebGL after reloading a page, when the previous attempt ended in the "snag" error. (And I know you're aware of that.)
There are certainly times when WebGL code (like the various shaders on http://shadertoy.com/) work fine on some machines and not others, and work fine one minute and not the next, on the same machine. So that suggests that the "snag" error doesn't necessarily imply that your code is at fault.
However, articles like How to write portable WebGL can help you minimize risky practices in your code, and reduce the frequency of these errors.
I've lately been running into odd issues, which I'm starting to think are related to resource starvation in the browser.
In FF:
I'd been testing one of our web apps and suddenly things that should disappear after a couple seconds stopped disappearing. I tracked back to setTimeout just flat out refusing to work. After reloading the browser it was all clear, no issues.
In IE:
I regularly see issues where IE will refuse to do transparency all the sudden, simply reloading the page clears this up.
In both:
Though I can't say its related for sure, I see unexplainable behavior, things along the lines of variables not being available (undefined) when they should be.
Both browsers also show a steady increase in memory usage over time (memory leaks).
The javascript in the web app is heavy and it is a single load page (making those memory issues mentioned all the more painful). There are lots of in-efficiency, and various things that make one say "why would you do that?".
Has anyone encountered such things? Can you point out general resources that will help identify and resolve these issues?
You could try running your application against the Chrome Profiler http://code.google.com/chrome/devtools/docs/overview.html. You can profile the CPU and get snapshots of the browser heap, that should help locate any rogue stuff.
If your application is designed to work with the Internet Explorer: The Developer Toolbar also has a profiler.
I'm having a bit of trouble with IE 8 (and probably all previous versions). Firefox and Chrome/Webkit are seemingly fine.
Something is causing page rendering, scrolling, and basically all page interaction to become blocked. As best I can tell, Javascript execution is causing this to happen.
Specifically, I think there are two major responsible parties in my specific situation - Google Maps API (v3) and Facebook Connect.
In both cases, I am using the asynchronous load methods provided by both Google and Facebook.
I've tried a couple of things so far, to no avail:
Delaying execution with jQuery's $(document).ready(). This just prevents the locking until slightly later in the page load. Actually, since I use gzip compression, I'm not really sure it does anything - I'm not clear on how that works.
Delaying execution with window.onload. Same situation - the whole page loads, then it locks up while it grabs and executes the Facebook Connect code.
Using setTimeout(function(){}, 0). I'm not 100% clear on how this is supposed to actually work - as I understand it, it essentially is supposed to force the execution of the function's code to wait until the stack is clear. Unfortunately, this doesn't seem to do much of anything for me.
I think the problem is especially exaggerated for me because I am on a slow connection.
I can't think of any specific oddities with my site that would be a factor, but I won't rule that out.
So, my question:
Are there any best practices or existing solutions to this issue?
Is there something that I am obviously doing wrong?
The offending site is at: http://myscubadives.com/, if anyone would be willing to take a look at the specific implementation.
Thank you in advance for your time and help.
Sam
Yes, the browser (at least IE) suspends itself while Javascript is being executed. This makes things a bit faster, because it doesn't have to redraw and recalculate layout every time you make a change. However if your Javascript takes a long time to execute, this will seem like freezing. Synchronous XMLHttpRequests also count.
Unfortunately there is no pretty workaround. The typical advice is to use window.setTimeout() function with timeout set to 0 (or something very small) to split the workload in several parts. Inbetween the browser can manage to redraw itself and respond to some user interaction, so it doesn't seem frozen. The code gets ugly though.
In case of lengthy XMLHttpRequests you have no choice but to use the asynchronous version.
Added: Ahh, I see that you already know this. Should read more carefully. :P Did you also know that IE8 has Developer tools built in (Press F12 to activate) and that the Javascript tab has a profiler? I checked it out, and 2 seconds were spent exclusively in jQyery's get() method. Which gives me a strong suspicion that something is still using synchronous XMLHttpRequests.
Function: get
Count: 10
Inclusive time: 2 039,14
Exclusive time: 2 020,59
Url: http://ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js
Line: 127
I have a one page web app so there is no page refreshing. Sometimes I leave the page open overnight and I come back in the morning and start interacting with it again. Usually I find I have to refresh. Javascript performs incorrectly - edit-in-place loads weird data, ajax calls don't fire... It's nothing to do with the backend, it seems to just be the browser dumping it's memory, or something. There're no sessions involved.
How does Google calendar stay open for 3 days and still fire event alerts?
I have a 'keep alive' call that fires every 5 seconds, in an attempt to keep the browser on its toes, but it hasn't helped. What's the trick? IS there a way to tell the browser to hold everything in memory forever?
(I'm sure this is addressed in numerous places on the web, but I can't figure out what to search for.)
Possible things to look at:
Test on a couple different browsers to see if they have the same problem.
If they do then its almost 100% certain something in your code.
Otherwise its probably something with your current browser and perhaps some interaction with some portion of your code.
Seems trivial but a lot of people over look this in javascript, but make sure you are deleteing/freeing anything you allocate with new.
If you use any 3rd party libraries consider updating them or checking their forums.
Good luck!
When you refresh the page do you need to do any authentication because of a timed-out session or anything ? Because if all you really need to do is hit F5 and you're good to go, I would suggest you create an 'idle' timer in your app that does a window.reload() every hour if there is no interaction (IOW reset that timer each time there is an interaction)
Hope this helps