I'm still not sure how it catches all unhandled exceptions. I looked at the source code (http://rescuejs.com/rescue.beta.js) and it only seems to wrap setTimeout, setInterval, jQuery.fn.ready, and jQuery.event.add. What about exceptions in other functions? Or does capturing the e.backtrace have something to do with it?
Would love to know (and if this works out of the box, what's to prevent cross-domain scripts from communicating with each other by raising exceptions?)
It indeed appears to be unable to catch exceptions that happen in event handlers that aren't attached with jQuery or directly in <script/> tags not wrapped in .ready() events, which is interesting because doing so is totally possible: https://developer.mozilla.org/en-US/docs/DOM/window.onerror
There's an argument to be made for attaching event handlers any way besides using jQuery would be bad practice, but not waiting for .ready() to fire is totally normal for sites practicing Progressive Enhancement that put all the <script/> tags at the end of the <body/>.
We will add support for window.onerror eventually, but there are two reasons we haven't yet done this:
1. window.onerror gives you no backtrace
2. hooking into jQuery.event.add lets us tell you "this error happened when the user clicked that button".
We've not yet implemented the UI for 2. (48 hours is not so long as we thought!); but I remain convinced that suitable integration with various frameworks is a much better developer experience than trying to rely on just the error message. Being able to see both the source code where the exception happened (see http://rescuejs.com/assets/screen_341.png) and the user context in which it happens makes it considerably easier to fix the problem.
That sounds great, but what if, for example, you used a library that, following perfectly good practices, intentionally doesn't have external dependencies and hence doesn't use jQuery.event.add nor jQuery.fn.ready, and an exception occurs in it or a callback the page author passes to it?
window.onerror is available in all browsers. The issue of window.onerror is that the information it provides is not very good: there's no stacktrace and there's no detailed info, just a line number and a message.
It should be possible to get exceptions raised in event listeners too (including stacktraces) if you wrap the DOM prototypes. I do something similar in the exception catcher we use at Cue:
https://github.com/Cue/greplin-exception-catcher/blob/master...
Not only does it log stacktraces, but it also breaks Firebug. And you'll find out that most of your exceptions end up coming from JS injected by shady toolbars and malware on people's systems :-(.
Also check out http://ratchet.io which also supports debug-style logging so you can, for example, wrap console.log() to debug client-side issues in production.
That's a neat use of JavaScript Source Maps. Unfortunately, it looks like you would effectively need to make your non-minified codebase public. Any plans for ways to get around that?
Your source code is not that special. Really. Do you really think you have some clever trick nobody else has considered, and that you can successfully hide it behind minification? Come on.
Maybe the source is not special or unique, but not everyone wants to give away their work. Eg you just spent 6 months developing a product feature and by coincidence your competitor also launches the same feature 2 weeks later :|
Of course minified code is also usable, however it makes things just that little bit more difficult for rip off artists.
I'm all for free and open software, but some aren't, and they're free to feel that way.
While timmclean's comment does indicate that he was thinking about keeping your codebase private; most people minify their code to cut down on filesizes... so his questions is still valid.
I don't think I have any tricks clever enough to help anyone who can easily read minified code :)
I only want to prevent simple theft from copy/pasting of source code.
"essentially reconstruct"? That's generous language. You have to somehow determine the use of all variables and functions and what proper names for them would be. Outside of DOM calls, the logic and application layer is close to incomprehensible. See also the javascript of any large webapp.
Not for the security of the application, but to protect intellectual property. It's much less tempting to "borrow" snippets of code when it's been minified.
There are two ways of associating a sourcemap with a file in the spec: 1) http header and 2) //@ sourceMappingURL comment in the destination file.
You could expose the HTTP header only to to Rescue.js IPs, or alternatively they could conceivably provide an interface to make the map associations within the admin panel.
http://www.errorify.com/ is also using sourcemaps (and you don't have to make non-minified code public), with no dependencies (like jquery, ...), totally crossbrowser and provides optional code rewriting. And has unified dashboard http://www.errorify.com/features
When I tried to do this myself, I ran into a problem with lots of errors happening for reasons exterior to my app - People have strange plugins, that may fail; if the user navigates away from a page, before all javascript has loaded, it might cause unpredictable errors. You probably need to filter these out, to be able to use it for anything.
As other commenters have mentioned, Source Maps are the solution to this problem in general. The main reason we don't yet allow signup to RescueJS is that "create a source map" is currently beyond the state of the art for web frameworks. You can't "just" do it.
Over the weekend we spent a few hours trying to hook source maps into the asset pipeline for Rails based on https://github.com/sstephenson/sprockets/pull/311 and upgrading the 'uglifier' rubygem to work with UglifyJS2. We didn't manage to get it quite working within the time limit, but we'll try and push our work-in-progress upstream to get this ball moving again.
If your minifier/obfuscator supports creation of source maps, it's simple. You just need to set a flag to tell it to create the map along with minified JS and you're good to go. UglifyJS2 and Closure Compiler are among those that can create a source map.
Would love to know (and if this works out of the box, what's to prevent cross-domain scripts from communicating with each other by raising exceptions?)