We Keep Coding

What is the difference between the two javascript codes? [duplicate]

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 9 years ago.
Improve this question
What is the main difference between JavaScript and jQuery. I know the minor difference like jQuery is high performance more reliable.

jQuery is a JavaScript library.
Read
wiki-jQuery, github, jQuery vs. javascript?
Source
What is JQuery?
Before JQuery, developers would create their own small frameworks
(the group of code) this would allow all the developers to work around all
the bugs and give them more time to work on features, so the
JavaScript frameworks were born. Then came the collaboration stage,
groups of developers instead of writing their own code would give it
away for free and creating JavaScript code sets that everyone could
use. That is what JQuery is, a library of JavaScript code. The best
way to explain JQuery and its mission is well stated on the front page
of the JQuery website which says:
JQuery is a fast and concise JavaScript Library that simplifies HTML
document traversing, event handling, animating, and Ajax interactions
for rapid web development.
As you can see all JQuery is JavaScript. There is more than one
type of JavaScript set of code sets like MooTools it is just that
JQuery is the most popular.
JavaScript vs JQuery
Which is the best JavaScript or JQuery is a contentious discussion,
really the answer is neither is best. They both have their roles I
have worked on online applications where JQuery was not the right tool
and what the application needed was straight JavaScript development.
But for most websites JQuery is all that is needed. What a web
developer needs to do is make an informed decision on what tools are
best for their client. Someone first coming into web development does
need some exposure to both technologies just using JQuery all the time
does not teach the nuances of JavaScript and how it affects the DOM.
Using JavaScript all the time slows projects down and because of the
JQuery library has ironed most of the issues that JavaScript will
have between each web browser it makes the deployment safe as it is
sure to work across all platforms.
JavaScript is a language. jQuery is a library built with JavaScript to help JavaScript programmers who are doing common web tasks.
See here.

jQuery is a JavaScript library, that can be used for communicating (selecting html elements, attaching event listeners, animations etc.) with the DOM, creating and consuming AJAX requests, as well as other things in a more easier way rather than using plain JavaScript. jQuery is written in JavaScript. It should be mentioned that browsers parse only HTML, CSS and JavaScript files. Hence, all JavaScript libraries/frameworks (jQuery, Knockout, Angular) are written in JavaScript or in languages like TypeScript that transconpiles to JavaScript (e.g. Angular 2). They provide you the opportunity to write less lines of code or to create interfaces following patterns like MVC (e.g. Angular), MVVM (e.g. Knockout) as well as other patterns, but under the hood, they are all result in a JavaScript file.
An example in order to understand why using jQuery you write less do more is the following.
Let we have the following input element
<input id="button1" type="button" value="clickMe"/>
Also, let that we want when someone clicks on the button to be notified through an alert box showing to the user a 'Hello' message.
If we had to do this using plain JavaScript, we would have written the following:
document.getElementById("button1")
.addEventListener('click', function(){
alert("Hello");
});
On the other hand, if we were using jQuery, we would had achieved the same result by just writing this:
$('#button1').click(function(){
alert("Hello");
});
Using jQuery makes things more clear than using plain JavaScript for the same purpose. (write less do more is jQuery's moto)
Furthermore, jQuery handles pretty well the theme of browser compatibility, you can use their API pretty easily without wondering too much as if you should do in case of using plain JavaScript.
Below I have added snippets for the code above:
document.getElementById("button1")
.addEventListener('click', function(){
alert("Hello");
});
<input id="button1" type="button" value="clickMe"/>
$('#button1').click(function(){ alert("Hello"); });
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<input id="button1" type="button" value="clickMe"/>

Javascript is a programming language whereas jQuery is a library to help make writing in javascript easier. It's particularly useful for simply traversing the DOM in an HTML page.

Javascript is base of jQuery.
jQuery is a wrapper of JavaScript, with much pre-written functionality and DOM traversing.

jQuery was written using JavaScript, and is a library to be used by JavaScript. You cannot learn jQuery without learning JavaScript.
Likely, you'll want to learn and use both of them.
go through following breif diffrence
http://www.slideshare.net/umarali1981/difference-between-java-script-and-jquery

jQuery is a multi-browser (cf. cross-browser) JavaScript library designed to simplify the client-side scripting of HTML.
see http://en.wikipedia.org/wiki/JQuery

Should Javascript be used to modify HTML?

I just recently started learning javascript and have a question regarding the'proper use'. I'm still trying to identify the role of Javascript within a website, and I'm curious whether or not it would be considered ok to have Javascript modified the HTML of a web page.
Let's say I have a panel on a web page. This panel houses a list. I would like users to be prompted to add items to this list.
I was thinking that it would be possible to use Javascript to generate list items to add to the list. However, this would be modifying the actual number of HTML elements on the web page... For some reason, this just seems 'hacky'. When I think of HTML, I think of a static structure that should come to life with CSS and Javascript.
So my question: is it considered okay to have Javascript modify the HTML of a web page? What about the case of adding items to a list?
Thank you!

Javascript is a programming language designed so it can modify the document that is being displayed(the DOM), the actual HTML is never touched.
Javascript has a place on a website and modifying the document/dom is perfectly acceptable and without it, would make javascript almost useless. CSS is great for certain tasks, but you can't do everything in CSS, though CSS5 is coming pretty close for many tasks.
Rewriting the entire DOM IS bad practice, but using it to shift an element's position based on an action, or creating a popup overlay is perfectly acceptable.
Remember the gold rule:
Modify as little as possible to accomplish the goal.

What matters is the user's experience of the (HTML) document. The representation of "the document" can change by utilising a language like javascript that "manipulates the DOM" - and the DOM is like an instance of the HTML document, or "document session" if you will.
So in a way, no, the HTML is touched. It is positively manhandled by javascript - indirectly and in a non-persistent way. But if you want to be pedantic... we say it isn't and leave half the readers confused.
When to use javascript and when not to. It's swings and roundabouts. You need to learn (mostly from experience) when one particular tool suits the situation. It usually boils down to some core considerations:
HTML is for markup. Structure. Meaning.
CSS is for style, feel, appearance.
Javascript is for those situations where none of the above work.
And I'm neglecting to mention server-side processing with the obvious disclaimer that all processing that ought to be done in privacy is done on the server (with a programming language like PHP or Ruby for example).
Sometimes you get the grey area in-between where you can do something either way. Those situations you may ask yourself a question like... would it be processed quicker if the client (user's computer) processes it, or the server... and that's where experience comes in.

It depends on the case to decide if you should manipulate DOM directly or let the JS do it.
If you have a static html page, just do your html and hand craft the
DOM. There is no need for JS to get a hand here.
If you have a semi static html page where the user actions change
part of it - then get the JS to do the changing part.
If you have a highly dynamic html page (like single page app) - you
should get the JS to render html mostly.
Using plain JS however is not the best for you in this age of great JS evolution. Learn it -but also learn to use good libraries and frameworks which can take you to the track very fast.
I recommend you to learn Jquery and Angular 2 which make you feel like learning a super set of JS straightaway.

Short disclamer: Javascript may modify DOM content in a browser but never change original HTML served from Web server.
Modern Web is unthinkable without javascript. JS allows to make static HTML interactive and improve User Experience (UX). As any sharp tool JS can produce a masterpiece out of nearly dead page and cut throat to a blooming static content.
Everything is up to the developer.
When not to use JS
Do not use JS to deliver ever-green content to the page. Web bots (crawlers) don't run JS, and you message "I come to this world to testify to the truth" may appear "a voice of crying out of desert" and be non-indexed and thus unread.
When JS in the must
Every time your page visitor does something the page should respond with proper action (using JS or, if possible, just CSS).
This is especially important when a prospect fills in a form. To err is human so a developer via JS should help the visitor to make wrong things right. In many cases it is possible without requesting server and in even more cases the answer should come from the server. And JS is your best friend in this case.
Javascript never lives alone. Browser object is its trustful ally. Most modern browsers support XMLHttpObject A.K.A AJAX (you may remember this name from ancient Greek history) which communicates with the server without reloading the page.
The idea of AJAX which stands for Asynchronous Javascript And Xml is to send request and receive response from the server asynchronously without blocking page in the browser.
Native javascript may be difficult to understand to many beginner developers. To make thing easier there are a lot of JS libraries with jQuery being most known.
Returning to the OP's question, Should Javascript be used to modify HTML?
The answer is: It Depends.

Somebody help me to answer me why do we use script in asp.net? [closed]

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
when i use asp.net to coding for website. Asp.net in server call sql server (ado.net, linq or entities framework) and get back data, send for clientside. i use some control as girdview to show data. actually, i do web optimization ( sql server - store procedure, create index, partition => faster, acceleration for get data. Website: UI simple, do not use too many effects)
but why in client-side, when server return data for client, many people always are going to use script (such as javascript, jquery, node js, angular js, bootstrap, react, google o/i....) to show in webpage.
so, it slower or faster when we use girdview?
And when User (people in clientsite) stop scrip in browser, it's mean, Manufacturers allow user or offer to stop script on browser in clientside., so why do we user them ( *.js), when User can stop script?
Even many people use asp.net (new version - 2013) in server, they also use script in there. so asp.net + script in server is faster or slow when we only use asp.net?
please, help me answer.
(I'm apologize because my English is not good.)
Thank you so much.

In the early years of Web development, Javascript on the client side provided for considerable enhancement of the client's "user experience" that static HTML delivered from the server did not. This includes such things as the enabling or disabling of certain interface features based on user input, the appearance or hiding of certain regions of a display based on user input, or combination of other pieces of data.
As web development evolved, the need for even more robust client-side interaction with back-end web servers became evident, and the "frameworks" you mentioned all work in various ways to improve the design, responsiveness, and behavior of a web-based application in ways beyond just enabling or disabling a button. This amounts to complex data binding, callbacks to web services, reducing server round-trips, and creating rich client interfaces, to name only a few.
They're all tools, each with their own role, each working to make web applications a bit more robust than those of the generation before them.

If I understand your question right, the answer comes down to speed and preference.
Firstly, if you disable client-side javascript, your asp.net controls aren't going to really work anyway. You'll find few places that still disable this so it's not really a concern people have anymore.
Secondly, it comes down to where you want to focus development effort and what kind of developers you have. If you have a lot of people used to working backend (C#) and want to stay there, then using asp.net controls and the like make development easier.
If you have javascript developers or people who want to use it, then you have more options that allow you to more decouple your server-side code from your front-end code. This can work out well for maintenance purposes.
The real point is that if you can utilize ajax (http://www.w3schools.com/ajax/default.asp) within your web application, you can make it a lot more responsive. ASP.NET Controls can often cause your page to refresh and cause unnecessary server-side computing to get the data and re-render the entire page (or partial page with asp.net mvc). Using new technologies like angular and others you listed, you can focus data computation and network traffic only on what's important.
For example, if you need a table to change what data is loaded, you can make an ajax request JUST for the data you need to load and then just render that portion on the client.

First of all, every "script" you mentioned (jQuery, AngularJS, Bootstrap, React) is a library written in JavaScript. Except node, which isn't even front-end. And I'm not sure what did you mean by google o/i... JavaScript is currently the only language which works in all browsers.
Initial purpose of JavaScript was to check form values before sending data to servers. It quickly evolved past that, although the usage was throttled by browser adoption, which is still a problem today.
Nowadays we can use JavaScript to render whole webpages. First when opening the page, it can help with rendering, meaning that server doesn't have to do all the work, but can just send plain data, usually in JSON. It's also used to add content to page later, without reloading the page (AJAX). Most well-known examples are real-time chat systems, like the one on facebook. This greatly improves user experience, I can't imagine how terrible it would be if whole page would reload to display a single new message.
Although user can disable JavaScript in their browsers and this would mean the page probably won't work, except if there is fallback design for such cases, I do not know why would someone disable it. And to be honest, probably most of the regular users don't even know this can be done and where is the setting to disable JavaScript.

UI Development - JavaScript vs Ajax

This is a design question. I find myself going back and forth between two UI design styles.
The UI on a prototype I developed recently relied heavily on loading the elements of the UI as partial views via AJAX. I did not like that approach because I had to do a lot of requests to the server while my page was loading. However, the plus of this design was that I could easily edit the partial view templates, so the code was easier to manage.
In the next iteration I decided to package all the information at once and then use JavaScript to generate partial views and plug this information into it (and only use Ajax when on-demand up-to-date information was actually needed). My page loads faster, but I find myself generating a lot of HTML snippets in JavaScript, which is getting harder to manage.
As I see it, using Ajax you get:
Easier to maintain (+)
Longer UI response times (-)
And with JavaScript only, you get
Faster UI response (+)
Easier to handle server-side errors (+)
Harder to maintain (-)
So, There are a few things on which I would like to hear your comments:
I do not like using Ajax unless I don't have a need for actual on-demand data. Am I wrong?
Are there frameworks/libraries that would make managing HTML-generating JavaScript code easier?
Are there any other pros/cons of the two approaches that I have missed?
Thanks,

There are templating libraries for JavaScript, if you want to get that involved. In general I would avoid manually sticking together HTML strings from JS unless there's a particular need to (eg in some cases for performance when dealing with very large tables).
HTML-hacking is difficult to read and prone to HTML-injection security holes when you don't get escaping right.
Start instead with the DOM methods, and use DOM-like content manipulation libraries to make it easier. For example, if using jQuery, do this:
$('<a>', {href: somelink, text: sometext})
and not this:
$(''+sometext+'') // insecure mess
There doesn't need to be a big difference between fetching data through XMLHttpRequest vs including it in the HTML document itself. You can direct a bunch of JSON data to the same function that will build page parts whether it was just fetched by XMLHttpRequest in an update operation, or included in function calls at document load time.
When including data in the page you will generally need to include a timestamp they were generated in any case, so that if the browser goes back to the page a while later without reloading it, the browser can detect that the information is now out-of-date, and cue up an XMLHttpRequest to update it.
The usual question when you're creating your page content from data with client-side JavaScript is, are you going to fill in the initial static HTML version from the server too? If so, you're going to be duplicating a lot of your content generation work in both client-side JS and the server-side language(*). If not, then you're making the content invisible to non-JS user agents which includes search engines. Whether or not that matters to you typically depends on what the app is doing (ie does it need to be searchable and accessible?)
(*: unless you can use server-side JavaScript from something like node.js and re-use your content generation code. This is still a somewhat rare approach.)

Why not look at integrating require.js into your workflow? I'm not entirely sure how it would work with templates, but included in their pipeline is the ability to package all required script files into a single .js to be served by a single server request/response.

I have no personal experience about it, but Closure looks promising. The thing about its templates being usable on both server and client side might be of interest to you. Here is what was said about using it in Google+:
The cool thing about Closure templates is they can be compiled into both Java and JavaScript. So we use Java server-side to turn the templates into HTML, but we can also do the same in JavaScript client-side for dynamic rendering. For instance, if you type in a profile page URL directly, we'll render it server-side, but if you go to the stream say and navigate to someone's profile page, we do it with AJAX and render it client-side using the same exact template.

When working with remote data after a page is loaded, for small datasets I prefer returning data only and adding to the UI with templates.
For large datasets, I recommend using your partial views to render the html on the server to reduce overhead in the client as #bobince mentioned.
For client-side state tracking, check out Knockout at http://www.knockoutjs.com. It uses an MVVM approach with data models bound to UI elements and makes it very simple to send the data back to the server via AJAX. It works with the jquery.tmpl template library out of the box or you can integrate another library of preference with a little more effort.
As far as managing templates, it's easy enough to store common templates in an object, either on the server to be retrieved with your remote data, or in a javascript object on the client.

Understanding AJAX

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