1

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.

closed as too broad by Robert Harvey, user40980, Blrfl, gnat, jwenting May 20 '14 at 10:13

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    You're probably asking the wrong question. The reason that web pages are so clunky nowadays is mostly because they load them up with so much crap like sidebar ads, popups, popunders, scripts, libraries and heavyweight graphics. – Robert Harvey May 19 '14 at 22:04
  • The amount of CPU and RAM used by a page in a browser depends entirely on how well it's designed and how much the page is expecting from the browser. Things have gotten worse, not better because people now have quad-core machines with 8 gigabytes of memory, browsers have gotten better (but more resource-hungry), and everyone's gotten lazy. – Robert Harvey May 19 '14 at 22:06
  • This is difficult to compare because a "browser app" will be written in Javascript, while an "installed app" will (usually) be written in a language that is not Javascript. The differences in efficiency will be related to other factors, not CPU and RAM. – Greg Hewgill May 19 '14 at 22:08
  • So you're saying the cpu and ram allocation to a web app is not limited in comparison to that of a c++ app for example? I know c++ runs more efficiently, although I'm not sure exact how big of a difference it is, but I'm also under the impression that a web page has less cpu and ram allocated to it in the first place. @RobertHarvey – user129679 May 19 '14 at 22:08
  • I'm saying that your question is probably not reasonably answerable in its current form. I'm saying that, if you can write your web app in a reasonably efficient way without loading it up with a thousand ads, you probably are worrying for nothing. – Robert Harvey May 19 '14 at 22:10
2

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 libraries with 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.

  • Wow. Excellent. Perfect answer. – user129679 May 20 '14 at 4:04
  • "Computers don't get bored or tired, so it doesn't make sense to worry about efficiency for its own sake." In the robot uprising of 2151... (+1'ed anyways) – h.j.k. May 20 '14 at 4:55
  • "Computers don't get tired" - true, but I get tired listening to the CPU fan whirring away at full speed when the CPU is pegged at 100% for some time. (and again when my electricity bill arrives :( ) – gbjbaanb May 20 '14 at 8:24
0

Perhaps the easiest way to describe the difference ot a web developer is to highlight asm.js and Google's Native client.

If javascript web apps were almost as fast as compiled languages like C++ then nobody would be working on making web apps attempt to be as fast, the fact they are shows that there is a performance and efficiency difference between the two systems .

Javascript JIT compilers are very good now, but they still lag native code. Part of the problem is the "expressive" syntax of javascript which is why asm.js is invented - its a very specific subset of javascript that is much more constrained, but that makes it much easier to compile into efficient code, and therefore allows it to perform much better. Its still slower than native code however, some benchmarks say "only "twice as slow, but then other benchmarks say normal javascript is only twice as slow. Benchmarks, huh!

Native client went a different tack, providing a sandboxed environment to run real natively compiled code. It doesn't integrate as well into the browser environment as javascript does, but that's mainly due to uptake and how the established environments are, not what they could be.

  • The "expressive syntax" of JavaScript is only relevant during parse time, which is a teeny-tiny fraction of compile time and completely and utterly irrelevant at runtime. – Jörg W Mittag May 20 '14 at 9:37
  • Nonsense. As long as you can add a string to a variable that contained an int, runtime perf will be very relevant. There are many other similar constructs that require more work at compile time too. This is why asm.is is fast, and why nobody writes it manually. – gbjbaanb May 20 '14 at 11:58
  • Type safety is a matter of semantics, not syntax. asm.js is fast because its semantics are designed to match those of an abstract CPU, it has nothing to do with its syntax. – Jörg W Mittag May 20 '14 at 12:27
-1

The current crop of Javascript interpreters are very, very fast as interpreters go. Not many "good" benchmarks available this one seems to be the least dubious -javascript vs C++ showing Javascript taking only twice as long as C++ on the same compute intensive benchmark compared which is astonishingly good for an interpreted language.

While nothing will beat well coded C as far as performance goes the down sides are enormous:-

  • much longer development cycles
  • poor built in text handling
  • no built in "collections" (C++ has boost/templates etc.)
  • build (and often code changes) required for each platform supported.
  • you need to distribute and install before you can run
  • you need to support old versions forever or find some way of forcing users to upgrade
  • you app will run natively inviting a whole raft of security issues