I'm a web developer. I feel like I develop less resource-intensive functionality often times, because I have this feeling that if I ask too much of the web app (animation, calculation, connections, etc), it will get lagged for users with slower computers. I've been curious for a while now about just how much difference there is in the capability (resource allocation) of a web (interpreted) app vs a compiled one. Also, I've heard that interpreted (JS, for example) programs are very inefficient and resource-hungry in comparison to compiled ones (C++, for example). Google's V8 JS Engine is said to make JS  faster, but I still see people talk about JS being much less efficient than C++.The reason that I ask this question is to separate fact from biased opinion. Is there a difference in available CPU & RAM between a web app and a compiled one? Is there a large efficiency difference between a program written in (an interpreted language) JS versus one written in (a compiled language) C++?Edit: I realize that we are comparing apples and oranges here. There are some really well-defined aspects of choosing between C++ (anything compiled) and JavaScript (web) when developing a client application, and this is one side aspect of that decision that I would not want to be misinformed about if it were to come up at any point in my career. 
Is there a difference in resource allocation & efficiency between a web app and a compiled one?
web development;web applications;efficiency;applications;browser
Is there a difference in available CPU & RAM between a web app and a compiled one?You web app is running in the context of the browser and it's extensions, the browser requires some memory and CPU cycles for its housekeeping chores. That memory and those cycles are therefore unavailable to your application. On a fully loaded desktop the fraction of the CPU cycles or memory needed for browser housekeeping is tiny relative to the available cycles and memory. On a low-end smart phone it may have a more significant impact. Is there a large efficiency difference between a program written in (an interpreted language) JS versus one written in (a compiled language) C++?A program running in a JavaScript interpreter or in some other VM is going to have some overhead that a compiled language is not going to have. In some cases this overhead is significant, in other cases it may allow for optimizations that actually make the interpreted program faster than the compiled program. It depends on what problem you are trying to solve. Ask yourself these questions:Do I needed unconstrained access to the machine's hardware?Do I need to replace functionality of the OS's or the language's runtime librarieswith custom behavior of my own design? For example, do I need to turn off the standard memory allocation system and implement my own?Am I running a computation so involved that it will be difficult to complete it in a timely fashion without using every last jot and title of the system's capacity? Think about Bitcoin mining, protein folding simulations, or real-time process control.If you answer yes to any of these questions you may need to use assembly, C, C++, or some other system programming language.Some tasks, say rendering streaming video, are computationally very complex, but everybody needs them, so the C and C++ programmers writing the browser wrapped them as libraries that get invoked by HTML5 or JavaScript. It's no less efficient to call these libraries from JavaScript or via an HTML5 tag than it is from a C++ program.Computers don't get bored or tired, so it doesn't make sense to worry about efficiency for its own sake. It only becomes a concern when it becomes so inefficient that the performance constraints of your program can't be met. Back in 1987 just putting up a few windows, buttons, and scalable fonts required almost every cycle a CPU could provide, so compiled languages were the only game in town. Nowadays, if the main job of your program is to interact with a human dragging windows and clicking buttons, your computer is going to spend most of its time twiddling its figurative thumbs, and other concerns, like development time, become more important. 