Please create an account to participate in the Slashdot moderation system


Forgot your password?

Submission + - Client-side JavaScript to Replace Server-side HTML ( 4

zx2c4 writes: "I've recently finished writing a simple photo gallery web application that scans a directory tree of photographs and generates static JSON files and thumbnails. There is then an accompanying web page that consists of a single index.html with some heavy JavaScript that fetches the JSON files and writes the layout of the page. You can navigate various pages and switch between different views, all without loading a different HTML page, but because the information is downloaded from the JSON files via AJAX. The app uses hash URLs to mimic navigating through a normal web page. It's all very similar to how GMail works, really. So, we've all seen AJAX used in a low key way at a zillion places around the Internet. But what I'm wondering is — do you suppose that the future of web applications will be in doing all of the page structure in client-side JavaScript, and that servers will only serve up the static index.html/scripts.js/styles.css and then a bunch of (dynamic or static) JSON files? Are the days of having a server dynamically write the actual HTML over? Do you expect to see nothing but JavaScript apps doing all the display for JSON data? Do websites still have a responsibility to display with out JavaScript as a requirement, or have we all got to accept that JavaScript is here to stay, and will be in the future responsible for most HTML writing?"
This discussion was created for logged-in users only, but now has been archived. No new comments can be posted.

Client-side JavaScript to Replace Server-side HTML

Comments Filter:
  • Well, there's a huge problem I see with this method:

    Search engines.

    If you don't want your site to show up on search engines well, or indeed at all, then sure. Load it up with Javascript and JSON, and do everything on the client side. If you want to actually be indexed, and searchable for the majority of web users, you'd be an idiot to set up any such site.

    Since the vast majority of site owners, from businesses to blog writers with delusions of grandeur, want to be indexed, I don't think this is ever going

    • by zx2c4 ( 716139 )

      Actually that's not true. With the AJAX Crawl Spec, search engines can read AJAX pages. []

      Basically, it rewrites!/someajaxstate to, and then it's the responsibility of the server to render it statically. PhotoFloat uses HtmlUnit to do serverside javascript execution. I wrote about it here: [] .

      • So basically, you're trying to offload processing onto the client using JS, while at the same time, ensuring this processing can be done on the server for search engines, when they use this special GET request.

        This leads to two separate code bases, which may or may not render the page in the same way, giving twice (at least) as many opportunities for security holes, and basically causes code updating nightmares.

        If you've got to have the code to create the page statically on the server, why not just use it f

        • by zx2c4 ( 716139 )

          You're mistaken. It's actually implemented by running the client-side javascript page in a headless webkit browser: Simple code [].

          Though, google recommends using HtmlUnit [].

Research is what I'm doing when I don't know what I'm doing. -- Wernher von Braun