Slashdot Mirror


Proof of Concept For Ajax Without JavaScript

JonathansCorner.com writes "Even if Ajax was backronymed to 'Asynchronous JavaScript and XML,' it works with JSON substituted for XML. Here's a proof of concept that JavaScript/VBScript are not strictly necessary either. The technique, besides being used standalone, may be useful to provide a better 'graceful degradation' for Ajax applications used by clients with scripting turned off."

1 of 148 comments (clear)

  1. client side BAD IDEA by unity100 · · Score: 0, Redundant

    im repeating this in every discussion related to client side. there are innumerable reasons why client side is a bad idea and it shouldnt be leaned on. ill recide :

    - it is something that happens in a remote client pc, on which you dont have any control. there may be one small applet running in the tray, and it may fuck up execution of your code on that pc, costing you a visitor/sale/whatever.

    - client side scripting is a VERY good channel to infect visitor pcs, and this is why trojans, viruses are being written exclusively on client side stuff for a decade or more.

    - due to the above fact, privacy, security, firewall, antivir programs etc are very hostile to client side scripting, and scrutinize it. most cause failures in client side with execution, or block it altogether, killing your site for your visitor. you wont know any of these cases unless some enterprising visitor can understand whats going on and report - even then you will lose heaps of visitors for every report you get.

    - on the web you cant take risks - every visitor is important in our time. therefore, the above problem constitutes a very good reason why not to use client side scripting - you must make sure you catch every visitor.

    - scaling and shit. you cant trust it. it is something that also happens on client side, according to the code you have written, and even the scaling back code itself is prone to the issues above. it may get locked up due to some app causing it to malfunction, it may be prevented by security programs, it may fail due to lack of memory, it may fail due to innumerable things.

    - EVEN if it doesnt fail, you still wont know how did your website present itself on the other side. maybe some important widgets malfunctioned, so the client cant order now ? or communicate ? you will never know because most visitors will just close down your site and move away, instantly forgetting that they have ever been at your site.

    .......

    thats why you need to go with server side scripting :

    - ALL the parameters are under your control. you will be sure your code executes, doesnt run out of memory, successfully completes and sends the result to the client, in acceptable speed.

    - Because youre sending pure html and css to the visitor client computer, you will be sure that what you sent has reached them. there is little reason as of now for security programs to shun html and css, or any runaway or irrelevant app causing any lockdowns, crashes or any other issue. what you produced serverside, goes to client side much more probably than client side.

    and many more.