When does it become unavoidable and when would you want to choose JavaScript over server side when you have a choice?
+27
A:
When you need to change something on your page without reloading it.
Quassnoi
2009-01-23 22:53:32
Concise.Edit: Oddly enough, I hit "Add Comment" and the AJAX is not working. Irony.
Joe Philllips
2009-01-23 23:14:20
+5
A:
Designer perspective:
- When you want to give more interactivity to your web page
- When you want to load stuff without reloading (i.e.: ajax for example)
When you shouldn't use:
- When You don't want to spend 1000 hours in pointless tries to disable the back arrow of your browser :)
fmsf
2009-01-23 22:57:39
+3
A:
Google maps would not have been possible without JavaScript. At least not in the form we know (and love) it today. So, depending on your ambition (and requirements) clearly: sometimes JavaScript is unavoidable, even though there exist technologies that take another approach that might have worked equally well (Java Applets, RIA technologies, etc).
If I had the choice I would probably chose JavaScript over a server-side implementation for a large number of applications, but then again, it is not a black or white picture. The server will remain important for web applications for a very long time to come.
Seventh Element
2009-01-23 23:12:08
A:
Try to keep it natural. Use it to enhance little things, do not built your whole application on JS.
IceHeat
2009-01-23 23:14:13
I disagree. I *might* say do not build a whole web SITE in JS but I would not definitely not say do not build an entire APPLICATION in JS. If I'm building an application that happens to reside on the web, I want it to look like a real application, not a web page.
Kevin
2009-01-23 23:49:19
+2
A:
Yes, you do. Now take out your textbook and turn to Chapter One. ;)
Honestly, though, to answer your question, I don't think it's ever "unavoidable," no; you can always code for the absence of JavaScript. (Indeed, usability best practices dictate you at least try to "gracefully degrade" the user experience for browsers that don't support it, or for users who choose not to.) In the beginning, of course, there was no JavaScript -- but there was still the Web. It just, well, kinda sucked.
There's no simple answer, but if you absolutely must have one, the most straight-ahead one I can think of is to use JavaScript to improve the user experience. Secondarily, use it to shift the workload from your server toward the browser (Hello, Ajax!) -- validation, state, etc. Those are two big reasons, broadly stated, IMO.
Christian Nunciato
2009-01-23 23:27:25
making the client's computer do the work instead of the server is a great point, one that I would've made if you hadn't beat me to it.
matt lohkamp
2009-01-24 02:41:12
+2
A:
At a stretch, you could do everything via server-side programming. Some things will be painfully slow and difficult to pull off right, but it is possible. If you want to see something clever done with nothing more than CSS, try out the search feature on lxr.mozilla.org with scripting disabled.
Practically though, the best places to use javascript are where it'd otherwise disrupt the flow of what the user's doing - the AJAXy things on here are all pretty good examples, as is the realtime preview (everyone should have one of these!)
If it provides significant benefit, then it's completely fine to use it. But please, don't make it required unless the server-only equivalent is needlessly complicated.
Ant P.
2009-01-23 23:52:20
Could you really do 'everything' through server-side code? What about animation? Or 'onInput'-type events? What about asynchronous http requests? To be fair, I only really know PHP, but I've played with ASP. NET and Cold Fusion (ew) too, and non of them offer that functionality.
matt lohkamp
2009-01-24 02:40:04
+1
A:
I never want to choose JavaScript, but it becomes unavoidable when clients want a decent web app. JavaScript has the unique feature of low latency feedback in a browser - server side code doesn't.
Also, there are a (rather limited) number of times when it's actually easier to bust out some JQuery for formatting rather than dealing with ASP.NET's event model to manipulate client elements. But, I'd say those are relatively few.
Mark Brackett
2009-01-23 23:57:08
you don't have to be so begrudging about admitting that you occasional use javascript - it's not a dirty word, or anything. Especially with libraries like jQuery, JS has really grown into a totally legit and in some areas nearly indispensable tool.
matt lohkamp
2009-01-24 02:36:20
@matt lohkamp - I find JS to be less maintainable than most of my alternatives. I also don't particularly like it - though JQuery makes it a good bit nicer.
Mark Brackett
2009-01-24 15:06:03
+1
A:
If you are looking for a responsive UI and want to avoid JavaScript, consider some of the RIA technologies such as Flex, Silverlight or JavaFX. I've been developing with Flex since v1.5 and find it very capable and productive. Silverlight is getting significantly better with each release, too.
cliff.meyers
2009-01-24 02:03:06
keep in mind, though, that flash, java, and silverlight apps are all inherently unaccessible, and the time you spend accommodating that maybe very well equal the time you would've spent using something like jQuery.
matt lohkamp
2009-01-24 02:34:39
When it comes to Flex, 'inherently unaccessible' is overstating it. Most Flex components are accessible, and while the developer has to take care to ensure compliance, it's not an undue burden.
Mike Sickler
2009-01-24 04:55:45
28 of the Flex framework's components have excellent accessibility support built-in and have been tested with the JAWS screen-reader. On the other hand, screen readers can have big problems with the partial page refresh technique used in many AJAX-based applications.
cliff.meyers
2009-01-24 21:38:53
A:
A good way to measure the breadth of your skills is when "Do I have to use ..." starts disappearing from your conversation. Hopefully you get to the point where a language is just a language, and you develop a feel for what the right tool is for the job, and can use it as comfortably as any other language.
If it's any consolation, there's increasing evidence that there's enough conventional wisdom and available toolsets that developers are increasingly preferring javascript. I personally like it for its conciseness and easy exensibility - once you get to know it.
le dorfier
2009-01-24 02:59:25
its not about language preference, its about philosphy of the approach. I meant it more in the sense of client side vs server side, not as a criticism of javascript per se.
zsharp
2009-01-24 03:34:52
Hmmm ... "When is it unavoidable ..." sure sounds like you don't want to go there.
le dorfier
2009-01-24 04:02:34
+1
A:
GWT is a nice system that compiles java code into javascript which becomes kind of like a "Machine language" for the browser--you never have to consider it.
I believe most google apps are written using GWT. It's pretty slick.
All your source code is pretty much straight Java using a library somewhat like Swing.
Bill K
2009-01-24 03:34:37
A:
You don't have to.
But if you want to provide UI extras like autocomplete, drag and drop, richer form entry fields, etc.…, Javascript is your only answer.
Of course you can abstract that Javascript generation out to the server side but you'd still be tussling with Javascript, albeit via programmatic code generation.
Naum
2009-01-24 04:45:28
A:
When you create a Rich Internet Application which gets loaded into a browser and which communicate to a Web Server with an Open API (like SOAP, JSON etc)
Sergey Ilinsky
2009-01-24 09:02:33
+1
A:
JavaScript is not a necessity but, coupled with the DOM API, it provides a very useful medium for gradually improving the user experience of your site. Obviously the extent to which this is true is dependent on how well you execute these enhancements, don't just use JavaScript for the sake of it; it's a design decision, and should not be taken lightly.
A:
"Javascript over server side " JavaScript is client side, not server side. You would still need to run server side stuff to get the data from the server. Javascript just gives you more control on how the client receives the data from the server.
JavaScript is unavoidable when you want a certain dynamic feature on your website which is not supported by default. Dynamic feature - without JavaScript: you can use CSS to change background of an element when the mouse is over the element. You can do the same thing with using JavaScript. - Only in JavaScript: When you click the element with your mouse, the element disappears. Don't think it is possible in CSS(maybe you be able to use :active in CSS on some elements. Never tested it myself).