CODEWITHSUNDEEP
domasynchronouswebhtml
Maxim
Maxim

Reputation: 21

Dynamic asynchronous forms and web pages without using client-side Javascript possible?

I am trying to find out if it is possible to develop dynamic asynchronous forms and web pages without using any form of client-side programming or scripting. So basicaly I'm trying to have the benefits of AJAX and DOM manipulation without using Javascript at all. If possible I'd like to have all the programming done server side in Python or a similar language. I'm trying really hard to circumvent using Javascript in web development. I just don't want to get into it or remotely touch it with a stick.

I came across AHAH (Asynchronous HTML and HTTP) and it seems interesting. However I was reading that the (X)HTML retrieved "cannot be on local on your file system". Apparently, "you must FTP your HTML document onto a Web site. And the HTML document(s) that you are fetching must also reside on a Web site." (source: http://www.xfront.com/microformats/AHAH.html) Anyone tried this and can confirm this? I find that not very practical. It would make more sense to host everything in the same file system on the same server.

Also a disadvantage of AHAH is that it seems to not be able to manipulate the DOM, meaning it is somewhat restricted to what it can do. Your placeholder have to already be there in your web page and then you can retrieve (X)HTML fragment to fill these placeholder.

Does anyone know of some ways to have dynamic asynchronous web pages and also manipulate the DOM without using Javascript? I'm okay with anything server-side since I can pretty much use any language that I want. Worst case scenario I guess I could have a nice interactive web site without having to manipulate the DOM, but I think modern web sites have to be asynchronous. It is kind of a deal breaker for me, having to reload a page for every slight changes.

Upvotes: 2

Views: 2044

Answers (3)

Paul Sweatte
Paul Sweatte

Reputation: 24617

The only other option is:

The static XML files residing on your server must be handled in three different ways:

If the XML file contains the <?xml-stylesheet ?> directive, it can be sent to XSLT-capable browsers directly.

If the desired XSLT style sheet has to be inserted into the XML data, the file has to be read and processed by a server-side script and sent to XSLT-capable browsers as an XML data stream.

For all other clients (including search engines), the XSLT transformation is performed on the server.

Due to the varying client requirements, the static XML files cannot be served directly, but instead have to be processed by a server-side script accepting the filename and XSLT style sheet as input parameters. The URL to download a static XML file would thus be similar to this:

sendXML.asp?file=filename&xsl=stylesheet

Include an <iframe> tag in the XSLT stylesheet to trigger a request to the server. The response to the second request would set an XML cookie

Output an XML document if the cookie is set, or the transformed HTML markup if the cookie is not present

With this solution, server-side XML-to-HTML transformation will be performed for visitors without XSLT capable browsers, as well as for search engine spiders. A cookie set with an automatic browser-check is used in the framework presented in this article to identify XSLT capable browsers; all other visitors receive traditional HTML markup generated on the server

References

Upvotes: 0

Wiktor Zychla
Wiktor Zychla

Reputation: 48230

By "local on your filesystem" they probably mean that the HTML cannot be fetched from the client filesystem, which is true of course. The remaining part makes sense then, all content has to be downloadwd from the server.

It possibly sounds tempting to be able to create dynamic client side applications by coding the server side only and just send updated fragments of web pages through the wire.

In practice, there are just too many restrictions, things you could do with a bit of client-side script but you can't because of your paradigm that everything has to be created server-side.

Truth is, Javascript is not that bad as it looks at first. With a good handbook and established libraries (jquery at least) you will find it to be just a new tool in your toolbox.

Upvotes: 1

jamesmortensen
jamesmortensen

Reputation: 34038

This isn't what you want to hear, but just learn JavaScript. It's a great skill for any Web developer to have regardless of what server side language you use. I've never heard of any other form of client side scripting, except VBScript, but I don't think it gets used anymore and is only supported in IE. See the VBScript Wikipedia article for more details.

I'll also add Flash to this list. If you build a website in Flash, or Flex, or anything using Adobe's flash platform, you can use ActionScript instead of JavaScript, but it's not really what I would personally consider a modern website, and this comes with it's own set of problems, like requiring all website visitors to install a plugin.

Now, even if there were some obscure way to handle client side scripting in the browser without JavaScript, consider that it's not going to have the same community backing. The cool thing about JavaScript is that there are so many Web developers versed in it. Regardless of whether your server-side language is C#, PHP, Python, Perl, Ruby, Java, or even server side JavaScript, you still must know some JavaScript in order to call yourself a Web developer.

Consider that there are all these people out there who have written powerful tools to help make development easier for others so we all don't keep writing and rewriting the same code over and over and over again. For instance, jQuery, AngularJS, and Bootstrap are all examples of how everyone benefits when there exists a large community of developers using the same tools. Go and use some language no one has ever heard of, and you'll find yourself alone, with nothing but the crickets breaking the silence and no one to bounce ideas off of if you get stuck. Hope this helps!

Upvotes: 2

Related Questions