Sometimes I hear the argument against doing things on client side using javascript. People say stuff like "JavaScript is inefficient...or slow". I'm wondering if there actual facts supporting this conclusion?
+2
A:
That depends alot on the browser's javascript engine.
Over all, it's a scripting language, so it won't do as well as C++ or another compiled language. However, it's good at what it was intended for, and that's drive web pages.
Zack
2009-05-11 14:04:49
A:
Well, it depends. What are you comparing it to? It differs alot between differnt browsers.
It can be really well performing, or the opposite, depending on the code written.
You HAVE to use JavaScript to do certain things, like manipulating the dom for example.
alexn
2009-05-11 14:05:54
A:
I would imagine that in most cases it is much quicker than a post back!
Stevo3000
2009-05-11 14:06:14
If you're going to down-vote atleast explain why!
Stevo3000
2009-05-12 07:44:11
A:
I would say it's incorrect answer. How would you measure JavaScript performance and that would you use for comparison. I guess as long as JavaScript is the only option for client side web programing (I'm not talking about VBScript) you cannot really say anything regarding it's efficiency.
Artem Barger
2009-05-11 14:06:34
Yes you can, you can determine if it is better to push processing to the client or the server. You can also determine what to keep and what to cut, some things simply cannot be done in ie6 at any speed.
garrow
2009-05-11 14:22:06
Probably I misunderstood the question. I was thinking about does the use of JavaScript is efficient at all. And yes your are completely right, there are various concerns regarding there exactly put logic of producing different computation. As a rule of thumb the logic should be divided as following: "There is shouldn't be any business logic at front end". So main purpose of JavaScript is to make dynamic looking stuff and improve user experience. And I'm still doubt how you can measure JavaScript efficiency on that.
Artem Barger
2009-05-11 15:13:56
A:
Also depends on how you write your code. If you follow best practice it's fine and as said before, it's better than postbacks!
Fermin
2009-05-11 14:07:50
+11
A:
There are really two factors to Javascript performance:
- Your code
- The scripting engine running your code
Your code is the easiest factor to fix. As you develop, optimize your code as best you can. Easy.
The second isn't always as easy. I've had some applications where performance on one browser was excellent and another was slower than mud. Others run great across the board. Best you can do is test, test, test, and test again. If you want a good article, check out the link:
Justin Niessner
2009-05-11 14:08:40
Three factors! The browser is the third one and usually the slowest. Remember that the DOM is not a part of Javascript, but of the browser.
svinto
2009-05-11 14:23:53
A:
You can only really answer that question in the context of a specific problem you're trying to solve. Post an example and then we can debate the merit's of various technologies...
John Weldon
2009-05-11 14:08:53
A:
Javascript is not inefficient, efficiency does not depend on the language. Interpreters might be inefficient. For instance Firefox interpreter runs very slow in FF for Linux and much better in FF for windows. Chrome has implemented an interpreter which is much faster. There are Javascript interpreters that does not run into a browser, they are usually faster.
Miquel
2009-05-11 14:09:32
+1
A:
Javascript is FAST if you use it properly. Otherwize it behaves bad. Eg: an unlimited loop can hang your browser. (But browser will ask you whether to stop the execution)
lol, um, isn't that how EVERYTHING is? if a c++ program has an unlimited loop, the OS will ask you if you want to kill the program.
Darren Kopp
2009-05-11 14:27:08
@Darren: if a C++ app (or any other desktop app) has an unlimited (usually called "infinite", no?) loop, the OS will only ask you to kill it if it is misbehaving in some way. Usually this means it's not responding to signals. If no signals are being sent (including any sort of ping signal), it will let your program run forever without interrupting. Not so with JS in a browser.
rmeador
2009-05-11 15:38:42
+1
A:
The choice of what tasks to perform on the client versus on the server is an important one, and the efficiency of JavaScript as a language is not the only factor which needs to be considered.
Data which will be manipulated on the client must be transmitted to the client. If the script does not need all of the information which will be pushed down to the client, then page load time will suffer, and the filtering operation will be done on the less-efficient end of the link (i.e. you will pay for the network transmission time before the user gets their information).
Business rules which run on the client will be exposed to curious end users.
Validation business rules which are run on the client must be run again on the server, because you cannot trust code running in an environment you don't control.
The different browsers and even between ECMAScript implementations available within a given browser family make this question nastily subjective and subject to a lot of variation.
Tetsujin no Oni
2009-05-11 14:11:51
A:
I guess what people are trying to tell you is: do what you can on the server, instead of putting all of the code in the client side.
Javascript performance differs from a browser to another (or from an interpreter to another), but javascript shouldn't serve the same purposes as server-side languages.
Flávio Amieiro
2009-05-11 14:12:38
A:
I'm a 'numbers guy' so when anybody says things like "well X is slow" or "of course, because Y is fast" that really gets my goat. So for starters, you need to use real data if you're going to make any kind of assessment:
JavaScript Performance Rundown
I also think watching Dromaeo in action is kinda cool
slf
2009-05-11 14:17:58
A:
Modern browsers are implementing more and more just-in-time compilation to their interpreters.
My rule of thumb is that if you can't rely on JavaScript being turned on, do as much on the server as you can. If you absolutely know that JavaScript is on, do as much in the client as you can and you'll save on bandwidth and server load.
Nosredna
2009-05-11 14:23:43