As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
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?
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:
Coding Horror: The Great Browser JavaScript Showdown
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.
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)
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.
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.
I would imagine that in most cases it is much quicker than a post back!
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.
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!
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...
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.
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.
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
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.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
It seems with HTML5/CSS3, there is a larger push towards CSS-only animations, effects, navigations, etc.
Is this purely because of the tendency of C/Java/etc developers to use JavaScript 'incorrectly' (mostly in a semantic sense, I guess)?
Or is there an advantage of CSS over JavaScript? If so, why would CSS be better? Is it faster?
Also, semantically-speaking, shouldn't CSS only be used for styling/positioning? So is CSS starting to go outside the bounds of what it was designed for?
Is this purely because of the tendency of C/Java/etc developers to use JavaScript 'incorrectly' (mostly in a semantic sense, I guess)?
No, you've just about missed the point by a mile. The main reason people use JavaScript is because they want to support as many browsers as possible. CSS3 is a new technology, which only the latest and greatest browsers understand, whereas JavaScript has been around for decades.
Or is there an advantage of CSS over JavaScript? If so, why would CSS be better? Is it faster?
Yes, because the browser knows best how to make use of system resources to perform animations, and it can do that job best when implementing them natively using CSS (e.g. hardware acceleration). With JavaScript, you're relying on a browser's scripting engine to calculate animations for you, which can get very expensive.
But as mentioned above, the greatest drawback is lackluster support.
Also, semantically-speaking, shouldn't CSS only be used for styling/positioning? So is CSS starting to go outside the bounds of what it was designed for?
Broadly speaking, it has always been meant for presentation — separating that as a concern from content and structure, when HTML was riddled with presentational attributes munged all over the place, spelling development hell for any frontend developer of their time.
All these fancy effects you describe can easily be categorized under presentation (i.e. they don't have anything to do with application logic, business logic, content, data, etc), so it would seem apt that they should be done with CSS. And that brings us where we are today.
So, to summarize:
JavaScript is used when browser support is a foremost priority (and in business applications it almost always is). It is also often maintained as is if it's too costly to convert or migrate to another technology.
Otherwise, CSS is used. Of course, a JavaScript fallback is often provided. You'll often see this in experiments or new/startup projects.
I can't see a VS here. Actually I think a great web app should be made mixing both of them!
I like to think about JavaScript for user interactions and CSS for design. That's how I decide which one I should use for a specific purpose.
Now days you have a lot of great works from brilliant people in order to solve the compatibility issues. E.g.: http://modernizr.com/
One major issue is that not everyone's browser has Javascript enabled. So if you can achieve the same effects with HTML5/CSS3 it has the advantage that it will work on all modern browsers regardless of whether or not they have Javascript enabled.
Yes, css is faster than javascript.
In addition, javascript require additional http request, while you can avoid that if you'll use only css.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm implementing typical server-push (comet) application. I'm choosing between two options: the longpoll XHR and iFrames. What are pros and cons of these? I know about the cross-site restrictions and that iFrame is pretty heavyweight component... are there any other differences? For example the "reliability" of the transport or level of control over the component?
What do you think, is there a single right answer which approach is better or there are use cases for both of them?
Thanks in advance.
P.S. I got a pretty good working XHR implementation, but I want to consider the alternatives.
you should use socket.io or an equivalent library. It supports both ways you mention and more:
http://socket.io/#transports
However, let's assume your using an appropriate abstraction layer, and now want to decide which transport to use. :)
IMO, the deal-breaker for iframes is error handling. The continuously loading iframe technique makes it much harder to do error handling. You're not informed via a convenient event of 404s or timeouts, so you have to set an interval in the JavaScript to watch for errors.
Supposedly iframes have less overhead than making a new XHR/HTTP request to reconnect after every message, but when I tried it all I saw was increased memory overhead on my server and zero responsiveness improvement; probably it depends on your choice of backend.
Another interesting factoid is that browsers are limited to two concurrent requests to a server by the standard, but Mozilla made an exception for XHR only:
https://developer.mozilla.org/en/XMLHttpRequest
When you're making long requests, the 2 connection limit is really important: if you tie up both pipes, nothing else will be able to get through! You have to be care to set up a single channel that all the code on the page shares. But on Firefox, you now get some wiggle room, if and only if you use XHR.
Iframes do have the advantage of being able to make cross domain requests.
I would suggest a third option: websockets. The websockets api is an evolution from long polling and is developed for real time client-server communication.
The protocol isn't supported by all browsers so you actually still need to support long polling when websockets aren't available.
There are libraries that degrade nicely (if websockets are available they use those, else they fall back to long polling). You have socket.io (supports all browsers). A jQuery alternative is jquery-graceful-websocket. Both libraries expose the websocket api but fall back to alternatives for the communication if necessairy.
One thing to potentially worry about if it's going to be smartphone friendly is that carriers can and will mess with data as it goes through their network. Normally to compress it.
Since the iframe method kind of streams a webpage with some JS in it, it looks more like a webpage to the carrier and is more likely to be messed with by a carrier. In this instance, them cacheing it up so that it can't leak through would be my primary concern - they are unlikely to change the meaning of your actual JS.
An XHR (especially if you're actually returning XML) is less likely to be messed with by the carrier.
Of course, a good carrier will understand what is going on and let both methods work. Not all carriers are good, though.
A difficult thing to judge and plan for but worth considering.
I don't know what you mean comparing iframe to longpull, but in my opinion iframes are very risky and make developing harder many times because of mentioned by you browser restrictions. And from the other side longpull XHR should be simplier to implement with your current XHR implementation. It also gives synchronizing comparing to asynchronous XHR.
Certainly XHR is the cleaner solution and has all the previously mentioned benefits.
Since the code is easily implemented, I suggest you do both and test on a number of platforms. Create two apps which will display the number of missed polls, and beg a dozen friends to run the app on as many of their devices as possible.
Then report back!
I think longpoll XHR is a better route to go for a couple of reasons:
It's the future. iFrames are loosing ground fast.
I think it's a better seperation of data and display. You can get the data, and then handle the display in the client. This will also allow you to have the same data source and display it differently for different platforms. Display in a PC web browser would be different than display on the iPhone.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
we know JavaScript is one of the most popular and widely used language in front end.i wonder it is not widely used in back end ?
It's becoming more widely used thanks to Google's V8 engine. Take a look at Node.js. I think poor performance limited it's effectiveness before.
Node.js lets you write multi-threaded custom web services in the blink of an eye and in a mostly OOP manner. I think you'll see that Javascript on the back-end is just beginning it's run.
I think the only thing holding it back is — as others have said — the lack of a neatly packaged and standardized (for Linux at least) drop-in solution. This solution would then need to be picked up by the major hosting companies and added as part of their product offerings for it to really take off IMHO. If that happens then I think you'll find that it will explode into the back-end server space.
Microsoft has offered the ability to program back-end systems with "Javascript" (AKA JScript) since 1998 with it's ASP offering. You still can develop ASP.NET applications with JScript. So it's nothing new. I think the reason it isn't widely used for ASP or ASP.NET applications is because VBScript is the "default" and C# seems to be the preferred language for more experienced professionals. But there is nothing stopping you except company policies which often restrict developers to a single language for corporate development. One reason JScript might not be used much by corporate entities is that it "appears no longer to be actively developed." In fact Microsoft never really "marketed" JScript to developers. Or at least not nearly as much as they did C# & VBScript. So I think that may have held it back.
JavaScript is popular and widely used on the front end because it has critical mass, not necessarily because it's an excellent language. Nobody makes the decision to write JavaScript for client-side code; they simply must, because every browser supports it. On the back end, other languages (Java, PHP, Python, Ruby, ...) offer advantages that JavaScript can't.
Edit: In 2022, I received reputation for this answer, which inspired me to revisit it. Twelve years later, of course, JavaScript is commonly used on the server side, although in many cases it's a compilation target rather than being used. The engine for this has been Node.js. Along with a language like TypeScript or PureScript, you can achieve good performance and reasonable developer ergonomics, as well.
I'm not an expert on this, but Douglas Crockford says in "Javascript: The Good Parts" that JS essentially became popular in the browser by accident, not because of merit.
"Javascript is a language with more
than its share of bad parts. It went
from non-existence to global adoption
in an alarmingly short period of time.
It never had an interval in the lab
when it could be tried out and
polished... when Java applets failed,
Javascript became the 'Language of the
Web' by default. JavasScript's
popularity is almost completely
independent of its qualities as a
programming language."
Different browsers implement it differently, and it's harder to say what's correct than it is for languages with a standard interpreter.
It does have good features, as Crockford's book explains, and node.js may prove that it's great for server-side development. But so far, where people have had choices, they've mostly chosen other languages.
Short answer: Because there are far better alternatives.
Long answer: Because it is wholly interpreted (and often not well - e.g. IE6), provides no standard I/O mechanisms other than what the environment gives, has a loose grammar that results in difficult to verify code, and many people find prototype-based OO a lot harder to deal with than class-based OO.
I'd say it's just an accident of history. Javascript was born at Netscape as a client-side language and never made the transition.
Comparing it to the prominent server-side web languages today, I think the most obvious difference is that the batteries aren't included with Javascript. There is no standard library.
Compare that to Python, PHP, ruby, etc which all have fantastic standard libraries that make web programming far more palatable.
On the server people are not obliged to use a specific language, and JavaScript is so free-form that code becomes very difficult to maintain.
That's why the largest percentage of people choose something else.
I think the answer might be that what's good for client-side isn't always good for server-side. For example, Javascript (ECMAScript in general.. also ActionScript) is a very lax and forgiving language, that allows you to get away with lots of stuff. In the client-side this is often not only acceptable but also preferable. You often want your UI to be as smooth and forgiving as possible, to improve user experience.
On the server side, however, it's usually a different story, and that's why, I believe, the languages that dominate that side are more strongly typed and rigid.
There's also the issue of scale. What works for the generally smaller code-base of a client-side UI application doesn't always work for the server side, which has to deal with a host of issues that aren't really a major concern in the client-side. e.g. performance, packaging, scalability - these are much more important to server code than to client code (usually) and so it's understandable why people would not choose JS for server side work.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
When we make a website with some interactivity (not whole flash site). should we always find a way JavaScript way before to use Flash? Should we consider Flash a last resort, if possible?
It is true Flash will not be indexed by Search engine. and it will not run on apple devices.
Will javascript also perform better than flash, in terms of speed?
Edit:
And how to know , the effect which we want to achieve and possible in Flash , can be possible in javascript?
Flash has it's advantages. I personally love JavaScript and are always surprised what is possible without Flash. But on todays browsers you can do a lot more with Flash and it ill perform a lot faster.
In the bright future, you might be able to do almost everything you can do with Flash using JavaScript and the canvas element. But until the majority of all browsers will support that, there are some things you can only do with Flash.
I don't use flash on any of my projects anymore and I also have a lot of fance stuff on them. But I also have a fallback for non-JS users and you should also have that for non-Flash users. and because a JavaScript application/widget is build using HTML and CSS, such a fallback is much easier to realize than doing it with flash.
I don't say, that you should not use flash at all, but you should make yourself a list of things you want to have on your website and than search for JavaScript libraries or plugins that can do that.
Isn't anyone bored with this question yet? There are tons of answers/non answers on the internet. One could write a book about Flash advantages & disadvantages, actually many books :) I personally don't think there's a rule you can apply to every project that will let you know if you should or shouldn't use Flash. This is a personal choice , based on the type of project you're dealing with , the languages you're comfortable with and the objective you're trying to achieve.
Some clients won't care about not being able to be accessible on Ipads, some others will. You don't tackle a business site the way you would tackle an artist portfolio. Keep your options opened and , more to the point, master as many languages as you can and when you do, I have no doubt you won't bother with this question again.
so:
should we always find a JavaScript way before to use Flash?
why not? if JS can do it with similar quality & performance, why go Flash?
It is true Flash will not be indexed by Search engine.
Google has made a lot of progress in indexing Flash content so it's not entirely true
and it will not run on apple devices.
False. It will run on most apple devices, of course not the Ipad!
Will javascript also perform better than flash, in terms of speed?
that would depend on what you're trying to do
And how to know , the effect which we want to achieve and possible in Flash , can be possible in javascript?
Some level of understanding of both languages would help
I'd say no, but then again I might be bias.
Flash is good for its own certain points and needs. I think that it has received bad press as it has been misused a lot, it is not a replacement to other languages but has been used that way for quite a while. It should be used when needed, rather than an instant fix to make things look "cool" or "modern".
Flash is good for application based design, multimedia and complex animations. This admittedly is rather fuzzy, but it's hard to define nowadays closer than that. Javascript on the whole is a very powerful tool, and the new HTML <canvas> tags allow a great flexibility on what can be accomplished with JS, CSS and HTML, but requires specific support that isn't guaranteed on all browsers (10% of people still use IE6 supposedly) so it's very much a gamble on who your target market is to what you should be doing.
On the whole if you know what you are doing it is possible to do nearly all that flash does in javascript/css/back end technologies, but it is less encapsulated than a flash example, and as far as I know flash is more efficient in its resource allocation and can take advantage of CPU enhancement, where javascript can't as of yet. It all depends on specifically what you are trying to put together and how complex/portable you want the code to be. If you are putting together a 3d shooter, use flash, if you are trying to move a <div> 5 pix to the right, use javascript.
Flash in itself will run on "apple devices" except for the iPhone and offshoots of this technology (iPad for example) but will still run in safari etc. on macs. and is constantly getting better at being indexed on search browsers, and there are get-arounds for that anyway, so that shouldn't be the reason for stopping you.
Have a look at jquery examples like this page to see some of the fun things you can do, and maybe some inspiration.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As users, we love the power of Greasemonkey. As developers, it can complicate things.
Some people advocate defensively disabling user scripts; others are willing to die to defend them.
Is there a middle ground? How can we reduce the threat of an evolutionary arms race between users and unscrupulous advertisers?
Any control you think you have over which user agents your site visitors use is illusory. However, the vast majority will be using vanilla IE/Firefox/Safari. But, if you've a site where the audience has adopted a Greasemonkey script en masse, then treat that as a strong vote from your users that the site needs to change!
If your users are using a Greasemonkey script and coming back, take it as good fortune: there's something they need that you're not giving them, and they haven't left yet.
If they didn't have Greasemonkey, they'd be gone. What can you do to keep them?
If someone uses a browser plugin or modification of any kind, you shouldn't attempt to block them or disable it- that's just likely to result in more problems.
On the other hand, you shouldn't support them either; if it works, let it work, if it breaks, let it break.
Lots of people use dodgy browser add-ons, sometimes unintentionally and occasionally without any choice (Corporate IT imposes some dodgy IE modification on them). Try to play nicely with everyone.
I agree with MarkR (+1, by the way).
The application is on the client side...
So whatever web designers will try to do to stop some feature, they will either anger their users, have them hack away another solution, or move away to friendlier sites.
(I hate it when some broken down site needs me opening my Firefox debugger to enable me to complete my correct for just because some braindead developer forgot to declare his i loop variable and thus, making it a global... And I did it again less than two days ago)
As online apps should never rely on client-side controls and protections (i.e. testing the date value on client is a cool bonus, but testing it anyway and always on the server is the thing to do).
To the worst thing that could happen would be for the app to break on the GM user because of some faulty script. But from the server viewpoint, it should remain pristine.
... Thus, the client should be held responsible...
That means that whatever hack the user adds to his browser, the user is then on his own. At the very best, he/she could discover some hidden bug and report it. On the worst side, the site won't work properly
...Now, does it means client/server cooperation, too?
Most people using GM or whatever to enhance a site is showing that the site does not suit exactly is tastes. The good thing, like Rich wrote down, is that they are still on your site, and not elsewhere.
Either the "enhancement" is for his/her own very personal taste, and, hey, what's the problem if he/she wants to see your black-on-white web page with yellow-on-blue? Or perhaps the "enhancement" adds a lot of value to your site. In this case, I guess that what you want is to either offer the same features for everyone (thanking the author of the GM for his idea could be a good idea), or perhaps support it as an optional feature ("click here for advanced experience") or... an GreaseMonkey script?
I don't see why developers should hate it?
Advertisers? Nowadays, I doubt people write GM scripts to get rid of ads, they use AdBlock [Plus] instead...
In general, I write GM scripts to improve something lacking in the sites where I go frequently, so if you try and take measures to disable GM, I would be very upset and might boycott the site.
Beside, I guess that the number of people knowledgeable enough to install GM (even those using pre-made scripts) is quite small with regard to total number of visitors.
We've got accept the reality of our platform: once your website is in the (computer) memory of the viewer, they're able to do whatever they want with it, without your permission. Popular sites that try to dictate their own viewing terms to their audience often suffer immediate and angry backlash - instead of trying to do it your way, let the users do what they want, embrace it, and you'll end up providing a better service, which your users will appreciate and reward.