Is it possible to create dynamic HTML page with Javascript ? Now or tomorrow...
(Is it possible to see javascript replacing PHP, ASP, JSP or ASP.NET ?)
It sounds like your question is whether JS can be used for server-side code. The answer is yes - the most popular is certainly Node.js, which I highly recommend.
It's not up to version 1 yet, but it's already being used in production by a bunch of high-profile companies.
For more info, see this SO question.
Dynamic HTML (DHTML) is defined as JavaScript + HTML + CSS. From wikipedia:
Dynamic HTML, or DHTML, is an umbrella term for a collection of technologies used together to create interactive and animated web sites by using a combination of a static markup language (such as HTML), a client-side scripting language (such as JavaScript), a presentation definition language (such as CSS), and the Document Object Model.
But, it sounds like you are asking about using JavaScript on the server. ASP uses JavaScript (or vbscript). ASP.Net can use JScript.Net. Node.js is a newer server implementation of JavaScript.
The thing about server technologies like ASP or JSP is that there is more to them than just the programming language. They include frameworks and templating engines. JavaScript can't do this on its own because it requires things like declarative syntax. But, as a language, JavaScript has been used on the server for a long time.
Yes, you can take a look at Node.js which is a server implementation of Javascript.
If you want to do this without any server-side code. Yes you can by using a templating system. You consume all of the site information, usually in JSON format, then generate all HTML client-side.
http://net.tutsplus.com/tutorials/javascript-ajax/quick-tip-an-introduction-to-jquery-templating/
Of course, you need a method to update the data files to make this "dynamic".
Related
I am learning HTML DOM. I am curious if there is any other programming language other than JavaScript that can access and update the content, structure and style of HTML elements through the HTML Document Object Model.
There are DOM APIs for just about every programming language out there.
C/C++
Perl
Python
Matlab
And the list goes on.
If you are asking about programming languages supported by web browsers, then JavaScript is the only practical one although there are others (TypeScript most notably) which can be transpiled to JavaScript before being sent to the browser.
If you want to access the DOM in the browser, you must use javascript only.
for example if you want to open popup after user click on some button in your site, only javascript can do it for you because it is client side programming language for browsers.
But if you want to read some HTML page in your program you can do it in any language. the only thing you need is a HTML parser.
for example if you want read products of an online store you can get html text content and then use HTML parser to read it in your programming language.
In the browser? Basically only JavaScript, at least these days.
But many other languages can work with a DOM, or event the browser DOM, like VBscript, Visual Basic, or Java (even from Applets).
I'm building a plain old HTML website that I'm putting a little Javascript into. Out of curiosity, I've been considering using other languages to accomplish the tasks that I want to achieve using Javascript, which include locating (and ordering) objects by date and tag variables.
Is it at all possible to incorporate C# in my JS code, referencing a library located somewhere in the site's directory? Would it theoretically be possible, or would I essentially just be translating the C# into the equivalent Javascript?
Sorry, you can't. Browsers can only run Javascript code. There are other languages (coffeescript, typescript, etc) that "compile" to javascript, but in the end the only valid language for client side scripting is Javascript.
There are some "C# to javascript" translators, however that only gives you a similar syntax, but not the wide standard library that .NET Framework comes with.
What you can do however is run your C# code on server side (you can run ANYTHING there, since it's completely under your control) and then use AJAX to call it. This is known as a "web service" and it's a pretty standard practice.
I have the project and the ticket is "Read the file.xlsx (Excel) on server" but the customer ask to use the HTML5 to apply this task.
As I knew, HTML5 is the client language, it makes template, form...etc. But cause the HTML5 is very new with me, I don't understand all the new attributes so this task makes me confused. Can anybody give me the answer for this.
Hope the answers given by people before me helped to demystify your belief that you could use HTML5 as a server side language, which is not a server side language but a powerful markup language. But, client side markup/scripting languages (HTML5, JQuery, Ajax etc) have come a long way that you could now do SOME of the tasks you'd do at server side at client side. But, with the use of some external libraries (They could be open source or commercial). The main disadvantage is your dependency to these libraries.
Here are few options if you (or your Boss) decide to use only HTML5 to do the task at hand.
http://codetheory.in/parse-read-excel-files-xls-xlsx-javascript/
http://blog.teamtreehouse.com/reading-files-using-the-html5-filereader-api
And, read the answer here at SO.
Cheers!
No. HTML5 is not a programming language. It's a markup language. You can use JavaScript however.
What your ticket most likely meant was to parse the Excel file, and display it on the client-side using HTML. And by mentioning HTML5, it most likely meant that you are free to use modern APIs rather than restrict yourself to older APIs in support for older browsers.
You can parse Excel with the server-side language of your choice and convert the data structure into a suitable format for rendering on the client-side using HTML. I also suggest you look for frameworks that allow spread-sheet like functionality, like jqGrid.
Also, before diving into the project, I suggest you clear things up with your client what that directive actually meant. Clients aren't usually techy, and it's up to you to translate their requirements into project specifications.
There is a great bookmarklet script that takes a HTML document and, using javascript, strips out the main article content (like Instapaper, but better).
I want to know the most efficient way to use this same javascript script on the server side with Rails 3.
Is it even possible? The ideal would be to be able to request a URL from the server (in Rails) and then parse the response using the javascript, and return the processed text (and then persist it to a db).
I was thinking of just adapting the script in Ruby, but this seems silly, especially since jQuery and javascript itself have a bunch of built-in functions for parsing a DOM. On the other hand, the script uses DOM constructions from the browser, so it might require a server-side browser?
Any suggestions?
We actually do this very thing in one of our webapps. If you want to implement this functionality server-side in your Ruby on Rails application, your best bet is to use a Ruby HTML/XML parsing library, such as Nokogiri.
I wrote an article specifically explaining how to strip out the important information from a linked webpage, like Instapaper does, using Ruby + Nokogiri.
Create a Printable Format for Any Webpage with Ruby and Nokogiri
Maybe run the script in something like Rhino Shell and capture the output?
Node.js comes to mind when speaking about server-side Javascript.
I think the Javascript stuff of readability could also be translated into Ruby but this would probably require some serious amount of work.
This seems like a somewhat common issue and I'm wondering what the common pitfalls, best practices, best approach, security concerns, etc., are when creating javascript on the server to be later loaded client side.
FWIW, I'm doing this in Ruby and I'm using JQuery as well. It's basically a form builder. Here's what I'm doing:
I have an admin form builder that dynamically creates the static form inputs (eg select, radio, checkboxes, and a couple of more complex inputs as well) I need to create corresponding javascript event handlers (using jquery). I basically have html builder lambdas and event handler lambdas that are mapped to each predefined input type: ie select has something like {'select'=>[select_builder_lamb, select_js_handler_lamb]} so I can look up the html type and then generate the needed code allowing the administrator to create a form "to their liking". This is working great.
Now I have to figure out whether to serialize this and then reload it when the registration page is requested, write out the javascript to an "unobtrusive" file, or store the raw html and javascript in the database, etc. No problems with the generation itself - so if the high level is: 1) make html & javascript 2) persist for later use 3) use for an http request - my question is for steps 2 and 3.
If you have experience doing this kind of thing and could provide some forwarning and wisdom it would be deeply appreciated!
A few things that spring to mind:
Code Separation
Although embedded JavaScript within an HTML page is widespread, many consider the practice of code separation to be good. In this respect I am referring to the placement of the JavaScript in a separate file. This is part of a broader concept known as Unobtrusive JavaScript
As web developers, we are required to know many different technologies, e.g. some of:
Server Script (PHP, ASP, Ruby, etc)
JavaScript (and framework)
XML
HTML
XSLT, XPATH
CSS
SQL
Imaging a code file that contained all of these! It would be chaotic!
Outputting JavaScript from the server precludes the separation of JavaScript into a separate file. If we separate these out then our code becomes more modular, reusable, readable and testable, which leads me to...
Unit testing
You may not personally be using a unit testing framework, however the modularisation of JavaScript is essential for creating independant testable (and reusable-testable) modules.
Script that is output on the server is not modularised, but more importantly is not static, so is difficult to fit into any unit testing framework.
Tag Soup
Although it is possible to code against this, mixing of client and server script has a tendency to produce tag soup, making it hard to read and maintain.
Debugging
I'm not sure what IDE you are using, but mine allows me to step through the JavaScript that I have written. Outputting it from the server mean's I can't do this.