This question already has answers here:
How do I hide javascript code in a webpage?
(12 answers)
Closed 8 years ago.
I have a site whereby I can currently use firebug to look at all the angularjs files.
Is there anyway I can hide these so people cannot use tools to view them?
No you can't, the browsers need to see the code to execute it.
No. JavaScript files will always be accessible from client tools like IE dev tools or Chrome or just about any other browser's dev tools. You can take steps to make the js harder to read, but it will still be accissible
Yes, but the way is to stop people from accessing your site, which is probably worse. The way JavaScript works on most sites ( other than ones built on Node ) is that it is run in the browser and to do that it must be sent to the browser.
The reason it doesn't matter is that nobody wants to steal your code.
You need to remember that nothing you want to be kept secret should be in that JavaScript- run that on the server and pass the results out to front end - and for production you should probably be minimising your code anyway which provides a lot of obfuscation, but in general it is not worth worrying about.
You cant. But you can minify them using for example Google's closure compiler or Microsoft Ajax Minifier. Minifying not only makes your javascript less in size, but also gives an obfuscation to your code, so it is much more harder to understand
Related
I'm a beginner web developer. I often use Firebug to debug my JavaScript.
Problem is that there are some script files from my page's UI that have a lot of code and this causes my web browser to be unresponsive, i.e. I get a dialog saying the script is unresponsive. Basically this happens when I am within Firebug's Script panel.
How can I deal with this?
I tried finding solution to this problem and nothing.
As for the answer I think the best was posted by #Pablo(can't assign answer to comment unfortunately) and it is simply trying out Google Chrome console. None of the problems I mentioned exists here.
Cheers guys!
I have had the same problem debugging some of our older scripts that make extensive use of the eval() function.
This causes many scripts to be displayed within the Script Location Menu. (Each dynamically generated script is represented there.)
A possible solution, given that it was caused by the number of files in my instance, might be to see if you can bypass the problem entirely by utilizing fewer source files for the same code. Using a 'built' version of whatever frameworks you use might alleviate the problem. (Particularly if they still are debug-able in a built form.)
If that does not work, you might try debugging using Firefox' built-in debugger (available via Ctrl+Shift+S. (Or switch to another browser to do the debugging, but that is obviously a far less desirable solution.)
I have been using tools like OptiPng for a long time and am wondering if there is any equivalent, that runs in JavaScript only inside the browser.
Just curious if a framework/plugin exists to optimize images in JavaScript?
I found pixtastic project. Not sure about performance but this sounds possible. http://www.pixastic.com/
Some thorough search later:
This SO question has all the necessary links. There is an imageMagick version in Javascript (found here).
Also, in theory it's possible to port to Javascript using emscriptem (see here)
ProcessingJS also provides a resize method.
Enough to get started.
This question already has answers here:
Why is jQuery not integrated within the browser
(7 answers)
Closed 4 years ago.
It seems like a good idea to me. or add the additional features to Javascript itself?
Because it's just one library of many. It may be popular but it's far from being the only choice. And it would also cause it to freeze at a particular version and make improvements much slower.
Plus there is little advantage anyway. It's fairly small and you can set it to be cachable indefinably by the brower so it will only be downloaded once anyway - if you have a new version it will have a new filename, so there is no harm in making it never expire.
I think this question should be a bigger discussion, but these answers are all bogus.
This is also 2 years later of course.
"it's just one library of many" - include the top 11 then.
"couldn't agree on common standard" - Kind of making jQuery a standard of it's own at this point.
"updated more often than browsers" or "make improvements slower" - So the browser won't have jQuery-1.9.x until next browser update, just don't put it in your project yet.
"Cache anyway" - Sure, it's still a transfer that doesn't have to happen, and there are a lot of people that haven't done a lot of surfing on their new device that you still want your site fast for and so on.
The thing is it is totally doable and would be better for the internet load; by how much is debatable. I could really see chrome at least replacing any net transfer to their CDN with a local copy, but I'm sure there is some legal, security or net neutrality issues with that. Just like I'm sure the main reason has something more to do with such matters and not these lame technical excuses that are obviously not thought through.
This could benefit other libraries too if developers could rely on the speed and availability of a complete library of tools like dojo, and not have to pick and choose just to cut weight. And also as most libraries have adopted the AMD or requireJS approach to package their projects, I believe there is a good argument for the enabling the browser to at least be informed of it's dependencies.
jQuery exists just because they (browser makers) couldn't agree on common standard.
You can consider jQuery to be a JavaScript plug-in. And browsers do not ship with plug-ins, otherwise the purpose of plug-ins would be irrelevant.
Plugins get updated more often than browsers - within a week the browser version of jQuery would be out of date :)
There's also the issue of versioning. Certain sites and extensions of jQuery require a certain version of jQuery. Right now it's up to the application to decide which version to use.
Probably because browsers are hard to update. Some freature of JQuery may eventually make their way into javascript, and I believe some of it has just recently. (well the idea's anyways) It takes years to add a feature to something like javascript, where the JQuery library can just release a new version.
There is actually a firebug or firefox plug in that allows you to inject JQuery into the page.. but thats just a development tool
Adding jQuery [type] functionality to the browser's in-built JS implementation (or making it a 1st-class plug-in) would overcome one basic problem:
As many have said, jQuery is a JS library - meaning, in case the penny didn't drop - that it is written in JS and has to be interpreted at run-time.
Embedding it would mean that it could be written in native code for the OS, making it much more performant.
This question already has answers here:
How to debug obfuscated JavaScript?
(4 answers)
Closed 4 years ago.
I'm using django-compress to shrink my JavaScript files. However, I am now having trouble debugging through it because everything is squished. I believe Stack Overflow use some kind of JavaScript compression too. How do you go about to debug through your JavaScript code on the live site or on your development machine with the code well formatted?
Firebug has all the code in one line which makes it hard to dig through.
The simple answer is you don't debug through a compressed file - you use an uncompressed version for development.
I see an answer has already been accepted, but I am adding a new answer since this is the first result I got on Google and think this new info may help someone.
Some browser DevTools now support Source Maps to map built javascript to is unbuild readable state. You have to minify and/or combine the JS with a tool that supports creating Source Maps. But if you do you can see the original code when debugging the minified/combined javascript.
Find more info here:
https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#source-maps
If you are using Google Closure, then there is a plugin that allows you access the unminified version of the code. See the documentation on the Inspector and the source mapping feature.
Some suggestions:
Don't compress until you deploy to production
Reload your source code after the compress code; it will write over the compressed code
When it's worth the investment, I take compressed code and manually uncompress it
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 14 years ago.
Improve this question
Does a tool exist for dynamically altering running javascript in a browser? For example, to change the values of javascript variables during runtime.
So, Firebug really is one of the best options - or, if you are a developer that owns Visual Studio and want to debug using IE, you can do that. Let's assume you will do this with Firebug using Firefox.
First, determine where you want to alter the code and place the following line just before the line you want to start messing with:
debugger;
That will cause Firebug to stop the execution of the script at that point, at which point you can then step through the code and alter the values of variables.
You can also use Firebug to place breakpoints in by clicking to the left of a line of code in the script window of Firebug:
Firebug , or Venkman Javascript Debugger .
Look into the javascript shell here.
It is like a debugger in your browser.
You can run/alter any javascript function on the active document object.
Very nifty for debugging/handling other peoples javascript, on sites where you do not have access to the source/server.
Did I mention it has tab-completion? it's awesome.
Opera 9 comes now bundled with Dragonfly (FireBug equivalent), and I've understood that it, too, can edit JavaScript on the fly. It's at least a feature to come, if they haven't had the time to include it, anyhow.
Have a look at Firebug
As mentioned by others, Firebug allows you to set breakpoints in your JavaScript (although I haven't had great success with hitting breakpoints when my JavaScript is IN an HTML document as opposed to an external file) which will interrupt the execution of a function during runtime.
It also allows you to view the DOM objects and all of the properties (which includes your JavaScript variables).
There is also a Lite version of Firebug that will work in non-Firefox browsers.
Mozdev has a tool called MozREPL. Not only can you alter and redefine the code on the fly, but you can get access to the underlying browser code as well. It's really cool.
It opens up a port on yoru computer amnmd allwos you to attach a telnet session (from local host only) to it to start executing code. You can also open that port up to connections that are not from localhost.... (but beware, that is pretty insecure and dangerous, etc. etc.).
It comes with an emacs minor mode that lets you send various regions of text right to mozdev, and provides a very nice interaction mode. I've further expanded it to set Firebug breakpoints right from emacs, and launch selenium tests. Basically I can script my browser from my editor. Its pretty cool. At some point soon I am going to release the source code.
JavaScript has an eval() function, you can build your string and then run it.
<script type="text/javascript" language="javascript">
example = function() {alert('first');}
example();
eval("example = function() {alert('second');}");
example();
</script>
The code above is an example of how eval can be used to change existing code.
#eyelidlessness, this shows that you can change existing code. Your edit to the question clarifies the original question, but therefore make my answer look invalild, but at the time it was originally posted it was a valid point, the original poster should have made the question clearer.