Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Client-side JavaScript to Replace Server-side HTML

zx2c4 (716139) writes | more than 3 years ago


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?"
Link to Original Source

cancel ×


Sorry! There are no comments related to the filter you selected.

Search engines? (1)

cbiltcliffe (186293) | more than 3 years ago | (#36070422)

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 to be the way the majority of the web works.

There are probably more issues, but this is the one that popped into my head within the first 1/2 second of reading the question.

Re:Search engines? (1)

zx2c4 (716139) | more than 3 years ago | (#36078508)

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: [] .

Re:Search engines? (1)

cbiltcliffe (186293) | more than 3 years ago | (#36134588)

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 for everybody?

Re:Search engines? (1)

zx2c4 (716139) | more than 3 years ago | (#36134666)

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 [] .

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?