Having been primarily a server-side programmer(ASP.NET WebForms) I'm trying to get my mind wrapped around AJAX outside of the "catch-all" approach of using UpdatePanels in the Microsoft AJAX controls. My question has a couple parts:
Is JavaScript the only option for client-side scripting that will support server-side communication? If not what are the alternatives.
What is the "general" architecture of an AJAX application? Is it simply JavaScript(client-side script) interacting with server-side resources(data/remote functionality exposed through web services)?
I know these may seem like simple questions but given JavaScript's "nuances" AJAX still seems a bit like "black magic" to me. Thanks!
Here is the short and sweet version.
No, but it is really the only language that is supported across a wide range of browsers. If you only care about IE you could use VBScript, but it is not any extra effort to use JS and get wider support so pretty much everyone uses JS.
AJAX isn't as complicated as it seems. In a nutshell it is client side code that runs in the browser to modify the current page's layout or content based on data it queries from the web server using the XMLHttpRequest object.
The most complicated part is dealing with the different syntax/behaviors of the various browsers, which is why most people use a framework that abstracts most of that away.
Here is a simple "Hello World" script using AJAX:
<script type="text/javascript">
var http = createRequestObject();
function createRequestObject() {
var objAjax;
var browser = navigator.appName;
if(browser == "Microsoft Internet Explorer"){
objAjax = new ActiveXObject("Microsoft.XMLHTTP");
}else{
objAjax = new XMLHttpRequest();
}
return objAjax;
}
function getNewContent(){
http.open('get','newcontent.txt');
http.onreadystatechange = updateNewContent;
http.send(null);
return false;
}
function updateNewContent(){
if(http.readyState == 4){
document.getElementById('mySentence').innerHTML = http.responseText;
}
}
</script>
Source: http://www.openhosting.co.uk/articles/webdev/5899/
The final complication is parsing what you get back from the server into an appropriate form that the code can deal with. The most common optons are:
JSON: Easily parses into objects using JavaScript's EVAL function.
Nice for pulling back information
about a single entity with multiple
attributes.
XML: Somewhat easily parses using the DOM methods built into JS, but
more complex than JSON. If you need a
lot more control or want to do XSLT
transforms, this is a decent option. In theory it could be considered a little safer because it doesn't require passing arbitrary strings into EVAL which could execute malicious code on the client, but this is debatable.
Unstructured text: If you just want a single value back, the other
two methods can be a bit of overkill.
AJAX is generally the interchange, the runner if you like, of data between client-side and server-side, and of course visa-versa.
The advance of AJAX has come hand in hand with the rise of Open Source, the "Social" Web and a rapidly expanding network of developers both amateur and professional. This in turn has sparked the development of many JavaScript Frameworks (jQuery, Prototype, Mootools, Glow etc) which essentially remove, or at least mask very well, those "nuances" you mentioned.
AJAX isn't simply a client-side script interacting with a server-side script, though. XHTML and CSS for presentation, the Document Object Model for dynamic display of and interaction with data, XML and XSLT (and more recently, JSON) for the interchange, and manipulation and display, of data, respectively, the XMLHttpRequest object for asynchronous communication and then finally JavaScript to bring these technologies together (wikipedia).
AJAX/JavaScript isn't the only client side solution, other established solutions such as Java and Flash for example still have their place. But JavaScript is, for the best part, widely support by all modern browsers, and indeed the JavaScript Engines of these browsers is rapidly picking up speed, opening up many more possibilities for seamless interaction between the front-end and the back-end.
Hope I didn't waffle too much, you asked ;)
Is JavaScript the only option for
client-side scripting that will
support server-side communication? If
not what are the alternatives.
Yes, Javascript is what you will use. While there may be other options availabe such as VBScript, you will want to use Javascript because it is the most widely adopted.
What is the "general" architecture of
an AJAX application? Is it simply
JavaScript(client-side script)
interacting with server-side
resources(data/remote functionality
exposed through web services)?
That's exactly correct. Web services or generic handlers serve up the necessary data in either JSON or XML format, both of which can easily be processed with Javascript.
In my opinion, the thing about AJAX that slips up most ASP.NET web form developers is the asynchronous aspect.
All the current answers are good but they neglect one point. AJAX is not a script or language or technology as such, you cannot write something 'in' AJAX. AJAX is just a bundling term.
This is from Wikipedia:
Like DHTML and LAMP, AJAX is not a technology in itself, but a group of technologies. AJAX uses a combination of:
HTML and CSS for marking up and styling information.
The DOM accessed with JavaScript to dynamically display and interact with the information presented.
A method for exchanging data asynchronously between browser and server, thereby avoiding page reloads. The XMLHttpRequest (XHR) object is usually used, but sometimes an IFrame object or a dynamically added tag is used instead.
A format for the data sent to the browser. Common formats include XML, pre-formatted HTML, plain text, and JavaScript Object Notation (JSON). This data could be created dynamically by some form of server-side scripting.
JavaScript alternative VbScript ( if I have to name one and beware it is MS technology and works only with IE ), But practically speaking JavaScript is universally accepted solution for client side scripting.
For Ajax Please refer below SO discussions :
ajax-books-and-tutorial
ajax-tutorial
ajax-and-asp-net-tutorials
Related
I always wonder why this object is called like that?
The body of your request does not need to be in XML format. Also, data received from server can be fetched as JSON, XML, HTML, or plain text. XML does not play an essential part in this object. Is this some kind of a cliché? What is this object used to be when it was first created?
XMLHttpRequest was invented by Microsoft's Outlook Web Access team. This highly innovative team previously gave us remote scripting, which was the the beginning of "AJAX" style development. Remote scripting was like JSONP, but overly complicated (it used a Java applet, of all things). I don't remember whether it was possible to dynamically inject <script> elements in IE 4 or 5, but it seems like that wasn't possible. Otherwise, JSONP seems powerful enough to eliminate the need for XMLHttpRequest.
The Outlook team was transferring XML from server to client, so the ActiveX control was named to reflect its primary use at the time. It was included as part of the MSXML parser.
By the time Firefox got in on the game and implemented their own version, XMLHttpRequest was being used more like it is today, and less for XML, but Firefox used the same name anyway. With the two biggest browser makers creating an object with the same name, interface, and functionality, the w3c stuck with the existing name. It's too bad someone didn't make more of a stink about the misnomer and insist we call it something more accurate like just HttpRequest.
I don't know how or why "AJAX" became the popular term to describe the programming style where a web page interacts with the server without requiring a complete page load. "AJAX" is a worse misnomer than "XMLHttpRequest" since it not only implies XML is an essential aspect, but further provides no indication of server interaction. I can process XML with JavaScript asynchronously without ever communicating with a server.
Short
Yes, the XML part in the name is all wrong.
Long
The best explanation comes from the MS engineer who invented XHR:
This was the good-old-days when critical features were crammed in just
days before a release…I realized that the MSXML library shipped with
IE and I had some good contacts over in the XML team who would
probably help out—I got in touch with Jean Paoli who was running that
team at the time and we pretty quickly struck a deal to ship the thing
as part of the MSXML library. Which is the real explanation of where
the name XMLHTTP comes from—the thing is mostly about HTTP and doesn’t
have any specific tie to XML other than that was the easiest excuse
for shipping it so I needed to cram XML into the name.
-- Alex Hopmann The story of XMLHTTP
This clearly states that seeking affiliations with XML, no matter how reasonable they are, is basically overinterpretation of authors' intentions.
Sorry to spoil the fun.
AJAX stands for Asynchronous Javascript and XML. In the beginning all communication was with XML (HTML is also XML-like, and XHTML is XML). JSON came later. So it is for historical reasons. (Also take a look at this wiki page)
I was wondering if it is worth learning javascript first? Does AJAX require Javascript in anyway or is it just similarities in the markup language?
You should absolutely learn javascript. And because AJAX is achieved with javascript, by learning javascript you will also learn AJAX. AJAX is not a different language. It's a pattern that you could use to develop asynchronous web applications using javascript.
Also note that javascript is not a markup language.
First, learn the basics of JavaScript. It's a programming language, not a markup language. You don't need to become an expert immediately, but learn the basics — what it is, the basic structures (functions, control flow statements, variables, objects, etc.), that sort of thing.
Ajax is a technique for retrieving data in a web page without refreshing the full content of the page (or indeed, any of it if you don't want to). You perform Ajax operations (sending a request, interpreting the response) using JavaScript and some other things, such as the XMLHttpRequest object. Ajax isn't a part of JavaScript. They're just used together in the web environment.
(Side note: Although Ajax stands for "Asynchronous JavaScript and XML", the XML part of that is optional; you can do "Ajax" without using XML and in fact, many if not most people do. Ajax lets you send and retrieve all kinds of data, including XML but also including HTML, JSON, plain text, and lots of other stuff.)
Some references that may be useful:
JavaScript:
The Mozilla JavaScript pages
JavaScript: The Definitive Guide by David Flanagan (yes, an old-fashioned paper book)
Crockford's articles on JavaScript (a bit advanced, wait 'till you're ready). Crockford is smart and knowledgeable, but not everyone agrees with all of his conclusions. (I don't.) But it's good to read and understand his points, and make your own decisions. He's mostly right, most of the time.
My own anemic little blog (start with the oldest entries and work forward)
The ECMAScript specification (PDF | handy HTML version)
The DOM
DOM2 Core
DOM2 HTML
DOM3 Core
HTML5 Web Application APIs
(Speaking of which) The HTML5 specification. Parts of it are just codifying what web browsers actually do right now; other parts of it specify new stuff. Mostly you can tell which is which by checking whether the thing in question is part of HTML4. If it is, then likely the HTML5 spec tells you what browsers mostly do today. If it isn't, then it's new and browser support may be perfect, or may be non-existant. :-)
The API docs for the library you choose. There are several good ones: jQuery, Prototype, YUI, Closure, or any of several others. (jQuery is the most widely-used at present.)
Late answer, but here's an analogy if it helps...
Learning JavaScript is like learning to ride a motorcycle.
Learning AJAX is like learning a technique or trick you can do on that motorcycle, like pop a wheelie (though AJAX is more practical than that).
Learning jQuery is like getting some gear to (perhaps) make your motorcycle ride safer or more enjoyable, like a helmet and leather chaps and jacket, or a more comfortable seat and better shocks, or maybe some saddlebags.
So the base of everything is JavaScript. AJAX is just a term to describe something you do in JavaScript, and jQuery is a code library that you may enjoy using when developing in JavaScript, but isn't at all required.
To be more specific, AJAX is a technology that uses javascript for 'part of the work' (it stands for Asyncronous JavaScript and XML), and handling it properly requires knowing at least something about javascript. Also, using a javascript library such as jQuery or Prototype make it much easier to work with AJAX.
JavaScript is a language, AJAX is a technology performed using JavaScript (and usually a web server).
AJAX is 98% Javascript and 2% other. Even the JSON(Javascript Object Notation) you would use for the response data type format, if you choose to, is Javascript. I think this answers your question.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What is the difference between AJAX with jQuery and AJAX with JavaScript?
Actually only one of them is a programming language.
Javascript is a programming language which is used mainly in webpages for making websites interactive. In this context, when a webpage is parsed by the browser, it creates an in-memory representation of the page. It is a tree structure, which contains all elements on the page. So there is a root element, which contains the head and the body elements, which contain other elements, which contain other elements. So it looks like a tree basically. Now with javascript you can manipulate elements in the page using this tree. You can pick elements by their id (getElementsById), or their tag name (getElementsByTagName), or by simply going through the tree (parentNode, firstChild, lastChild, nextSibling, previousSibling, etc.). Once you have element(s) to work with you can modify them by changing their look, content or position on the page. This interface is also known as the DOM (Document Object Model). So you can do everything with Javascript that another programming language can do, and by using it embedded into wepages you also get an in-memory Object of the current webpage by which you can make changes to the page interactively.
In recent years JavaScript has also become a popular server-side language running in an environment called Node.js. This opened up a way for you to share common parts of your code between the browser and the server.
AJAX is a technique of communication between the browser and the server within a page. Chat is a good example. You can write a message, send a message and recive other messages without leaving the page. You can manage this network interaction with Javascript on the client side, using an XMLHTTP Object provided by the browser.
jQuery is a library which aims to simplify client side web development in general (the other two above). It creates a layer of abstracion so you can reuse common languages like CSS and HTML in Javascript. It also includes functions which can be used to communicate with servers very easily (AJAX). It is written in Javascript, and will not do everything for you, only makes common tasks easier. It also hides some of the misconceptions and bugs of browsers.
To sum up:
Javascript is a programming language (objects, array, numbers, strings, calculations)
AJAX and jQuery uses Javascript
jQuery is for simplifing common tasks with AJAX and page manipulation (style, animation, etc.)
Finally, an example just to see some syntax:
// page manipulation in javascript
var el = document.getElementById("box");
el.style.backgroundColor = "#000";
var new_el = document.createElement("div");
el.innerHTML = "<p>some content</p>";
el.appendChild(new_el);
// and how you would do it in jQuery
$("#box")
.css({ "background-color": "#000" })
.append("<div><p>some content</p></div>");
Javascript, for the purposes of this question, is a client-side (in the browser) scripting language.
jQuery is a library/framework built with Javascript. It is very popular because it (nearly universally) abstracts away cross-browser compatibility issues and it emphasises unobtrusive and callback-driven Javascript programming.
AJAX (Asynchronous Javascript XML) is a method to dynamically update parts of the UI without having to reload the page - to make the experience more similar to a desktop application.
EDIT:
It sounds like you're new to this. I would seriously recommend you check out http://www.w3schools.com/js/default.asp to get started. It's what I used to learn javascript and it's done incredibly well.
Of the three only javascript is a programming language. jQuery is a framework that is based on javascript and that simplifies some tedious tasks like manipulating the DOM, adding some effects and animations and most importantly doing it in a cross browser fashion. One of the tasks that is simplified by jQuery is AJAX which is a concept allowing a browser to send an asynchronous request to a web server allowing for richer web applications.
AJAX is technology.
Jquery is library.
Javascript is language.
AJAX is a method to do an XMLHttpRequest from a web page to the server and send/retrieve data to be used on the web page. It stands for Asynchronous Javascript And XML. It uses javascript to construct an XMLHttpRequest(varies between browsers).
jQuery is a javascript framework that can be used to manipulate the DOM (search and interact with the DOM). jQuery implements a high-level interface to do AJAX requests abstractly thereby giving multi-browser support in making the request.
So, Ajax is a technology paradigm, whereas jquery is a library so can't compare them.
AJAX is a way to talk to the server in the background.
JavaScript is a language that the browser understands.
jQuery is a JavaScript framework that makes life easier for people who want to program for the browser.
JS is a client-side programming language.
jQuery is a framework, but isn't the only one. Another JS frameworks are AngularJS, Mootools, NodeJS, BackboneJS, etcetera. With anyone of this frameworks you will do any action that pure JS can't do, or any "complex" (I don't find the correct word) action. As Void said, adapting his answer to my answer about frameworks: "makes life easier for people who want to program for the browser."
With AJAX you can communicate your Web page to the server. AJAX depends on JS to work.
Javascript is a scripting language, Not a programing language. Jquery and ajax are simplified version of javascript which helps manupulate queries of certain part of website without having to change the entire user interface of the website.
Is the use of server side javascript prevalent? Why would one use it as opposed the any other server side scripting? Is there a specific use case(s) that makes it better than other server side languages?
Also, confused on how to get started experimenting with it, I'm on freeBSD, what would I need installed in order to run server side javascript?
It goes like this:
Servers are expensive, but users will give you processing time in their browsers for free. Therefore, server-side code is relatively expensive compared to client-side code on any site big enough to need to run more than one server. However, there are some things you can't leave to the client, like data validation and retrieval. You'd like to do them on the client, because it means faster response times for the users and less server infrastructure for yourself, but security and accessibility concerns mean server-side code is required.
What typically happens is you do both. You write server-side logic because you have to, but you also write the same logic in javascript in hopes of providing faster responses to the user and saving your servers a little extra work in some situations. This is especially effective for validation code; a failed validation check in a browser can save an entire http request/response pair on the server.
Since we're all (mostly) programmers here we should immediately spot the new problem. There's not only the extra work involved in developing two sets of the same logic, but also the work involved in maintaining it, the inevitable bugs resulting from platforms don't match up well, and the bugs introduced as the implementations drift apart over time.
Enter server-side javascript. The idea is you can write code once, so the same code runs on both server and client. This would appear to solve most of the issue: you get the full set of both server and client logic done all at once, there's no drifting, and no double maintenance. It's also nice when your developers only need to know one language for both server and client work.
Unfortunately, in the real world it doesn't work out so well. The problem is four-fold:
The server view of a page is still very different from the client view of a page. The server needs to be able to do things like talk directly to a database that just shouldn't be done from the browser. The browser needs to do things like manipulate a DOM that doesn't match up with the server.
You don't control the javascript engine of the client, meaning there will still be important language differences between your server code and your client code.
The database is normally a bigger bottleneck than the web server, so savings and performance benefit ends up less than expected.
While just about everyone knows a little javascript, not many developers really know and understand javascript well.
These aren't completely unassailable technical problems: you constrain the server-supported language to a sub-set of javascript that's well supported across most browsers, provide an IDE that knows this subset and the server-side extensions, make some rules about page structure to minimize DOM issues, and provide some boiler-plate javascript for inclusion on the client to make the platform a little nicer to use. The result is something like Aptana Studio/Jaxer, or more recently Node.js, which can be pretty nice.
But not perfect. In my opinion, there are just too many pitfalls and little compatibility issues to make this really shine. Ultimately, additional servers are still cheap compared to developer time, and most programmers are able to be much more productive using something other than javascript.
What I'd really like to see is partial server-side javascript. When a page is requested or a form submitted the server platform does request validation in javascript, perhaps as a plugin to the web server that's completely independent from the rest of it, but the response is built using the platform of your choice.
I think a really cool use of server-side Javascript that isn't used nearly often enough is for data validation. With it, you can write one javascript file to validate a form, check it on the client side, then check it again on the server side because we shouldn't trust anything on the client side. It lets you keep your validation rules DRY. Quite handy.
Also see:
Will server-side Javascript take off? Which implementation is most stable?
When and how do you use server side JavaScript?
Javascript is just a language. Because it is just a language, you can use it anywhere you want... in your browser, on the server, embedded in other applications, stand-alone applications, etc.
That being said, I don't know that there is a lot of new development happening with "Server-Side Javascript"
Javascript is a perfectly good language with a self / scheme prototype style base and a C style syntax. There are some problems, see Javascript the Good Parts, but in general it's a first rate language. The problem is that most javascript programmers are terrible programmers because it's very accessible to get started.
One team at google built out Rhino on Rails, which is an MVC framework like Ruby on Rails which is written in javascript and runs on Rhino a javascript interpreter for the Java VM. In this case they had a requirement to use the Java VM, but wanted to get a language which was fast (javascript is fast), supported duck typing, and was flexible.
Another example is something like CouchDB, a document oriented database which uses json as it's transport format and javascript as it's query & index language. They wanted the database to be as web native as possible.
Javascript is good at string and dom (xml) manipulation, being sandboxed, networking, extending itself, etc... Those kind of features are the thing you often do when developing web applications.
All that said, i don't actually develop server side javascript. It's not a bad idea, but definitely less common.
We use javascript on the client because it is there, not because from a list of languages it was our choice. I wouldn't choose it for any chore on the server.
You can run any language you like on the server, in fact, as many as you like.
javascript is reliable and easy to use, but it is just too labor intensive for common tasks on the server.
I have used both Javascript (NodeJS) and compiled languages (such as Java or C#.NET). There are huge discussions on the internet about which is preferable. This question is very old (2009). Since then the Javascript world has changed considerably, whereas honestly the Java world has not changed much (relatively).
There have been huge advancements in the Javascript world with Typescript, amazing frameworks (such as Next.JS), reactive programming, functional programming, GraphQL, SSR etc.
When I look at compiled code, especially Java code it all still seems to be the same old tools - Spring (maybe SpringBoot) and Jackson. .NET has advanced server side, but not to the extent of the JS world.
Sure my list there can be used with several languages, but I believe Javascript has improved the software engineering world considerably.
Server side development with Javascript, Typescript and NodeJs is engaging, fun and productive. Use it and enjoy it. Like millions are today.
I was looking into GWT. It seems nice, but our software have the must work without JS requirement. Is it possible?
No, it isn't. GWT provides a windowing toolkit that is specifically designed to run on the client, not on the server. Degraded (e.g. non-javascript) code would need to deliver complete HTML to the browser, which GWT simply does not do. It compiles your java code to a javascript file that is delivered to the client and builds the UI by DOM-manipulation on the client. Then there's some code to talk back to the server, some implicit, some written by you yourself. This model does not lend itself well to degrading gracefully.
The only way to degrade somewhat gracefully is to provide a second, non-javascript UI or use another toolkit that doesn't render the frontend on the client but delivers HTML. Sorry.
You could degrade gracefully by creating an html structure that is just 'good enough' (with form posts, linked menus, etc) and then have GWT attach to each part of that structure, augmenting its behavior. For example, make an HTML drop down dynamic, replace a link to another page with a component that opens a lightbox, or replace a link to another page with an XML http request to do the same thing (e.g. cast a vote).
I've done this a number of times for clients.
It's the opposite way that most GWT gets developed, but it can work.
I was looking at this issue myself when designing my website. GWT isn't really any better than just writing Javascript files in that their syntax is almost identical. The true benefit comes when you share client and server libraries. Hopefully you've resolved this issue in the last two years, but at any rate here are a couple examples that you may find useful.
Creating Gmail: With GWT, you can create an EmailFormatter in a shared package that does the email listing markup so that your server doesn't have to. You could then add support for legacy browsers ("older version") by using the same EmailFormatter class on the server side.
Form verification: While is is absolutely necessary from a security perspective to validate user input server side, it is more convenient for most users to have Javascript check a form before it is submitted. You can use the same Java code with GWT to do this.