What are the pros and cons of building an AJAX-heavy web app over one with persistent URLs? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 11 years ago.

Original Question: Is it a bad idea to make an all JavaScript website?

*Changed the question because this ended up being more of a discussion, but it could be helpful for others.*

In this case, I was thinking of making a website that initially delivers its overall layout using regular HTML (like a normal, basic web page), but then I plan to fill the content of the HTML content area dynamically, entirely with AJAX requests.

Users of the site won't ever be refreshing the page or going to a new page, and all other divs and elements that need to be generated will be created using AJAX (making use of lots of JavaScript functions that are on a cached external JavaScript page).

Although I'm not actually making a forum website, a forum's level of functionality is close to what I want to achieve. Lots of database reading and writing too.

Is this a bad idea? Am I not considering something that could make this potentially terrible? Is it good performance-wise (since I'll be doing so much client-side work and less server side work)?

I realize that the page wouldn't work for people who have JavaScript turned off, but that's not a concern in this case. I'm also not worrying about any mobile devices that don't support JavaScript, since I would probably just create a mobile-specific version of the site that doesn't use JavaScript).

Thanks!

UPDATE: First: Thank you for all the responses, everyone! I really appreciate it!

Just for clarification purposes, I thought this would be a good idea mostly because it seemed like I could just say, "Hey AJAX, just give me the raw forum post data for this page and I'll do all of the HTML building on the client side." Same DB access of course, but less server side page formatting work and less data transfer to the client.

And another 开发者_运维知识库important clarification: I'm not worried about search engine optimization because this forum would be a login-only network that should not be crawled or viewed by non-logged-in users.

---

Not a crazy idea at all, but I recommend against it since it'd be hard to maintain. You just got to know what you're getting in to. Facebook does something similar. The Google search interface, for example, also keeps you on the same page when you perform a search.

You might also be interested in:

Backbone.js http://documentcloud.github.com/backbone/

and BBQ (Back Button Query) http://benalman.com/code/projects/jquery-bbq/docs/files/jquery-ba-bbq-js.html

One disadvantage is that analytics scripts won't necessarily work properly on sites built this way, depending how you build them.

Edit:

One concern is that it won't be search engine crawlable. This can be overcome if you build the site well, probably using BBQ, and by following this spec:

http://code.google.com/web/ajaxcrawling/docs/specification.html

---

Couple of years back, that'd be an absolute NO. But now with the newer browsers, libraries like jQuery, YUI things can be reconsidered.

Disclaimer: I'm not saying an absolute YES.

Rather, it requires careful evaluation of your requirements, user experience expectations, performance levels etc.

If your primary user base is using IE6/7 or even 8, the page speed is going to be significantly slower than FF or Chrome. There are certain cases where you've to resort to server side rendering.

The list could go on an on but you're the best judge here (unless you can be more specific with your requirements).

Recently we rolled out a JS intensive website for a major news corporation. However, to keep it performant, we also leverage server side caching and few other techniques in conjunction with client side JS.

---

No, it's not a bad idea in and of itself, particularly if you don't care about support for browsers that don't have JavaScript enabled, but it does carry some caveats. For instance you'll need to put a fair bit of effort into working out how your JavaScript framework should be structured, and what tools you will use. If you don't come up with a solid solution then your website code can quickly degenerate into an unmaintainable mess. You'll also be spending a lot more time doing cross-browser testing, as the same JavaScript code may produce different behavior in different browsers (thanks mostly to IE).

As far as performance is concerned, you really aren't doing any less server-side work. The expensive server-side operations are your database queries, and you have to do those regardless of whether the server is returning a standalone web page or an AJAX (or JSON) snippet. In fact, depending upon how you structure your JavaScript client you could end up doing more work. For instance, if the JavaScript sends a separate AJAX request for each div on a page, that will be less efficient overall than allowing the server to create the content for all of the divs on the page as part of a single operation.

---

Its a good idea, but lets see what could be some troubling points

what i can think of:

• The web site wont be Crawlable by any Search Engines.
• the SOURCE CODE of your Web site can be Easily stolen, and everyone will be able to enjoy on your hard work.
• Pages Cannot be Liked in Facebook (facebook needs OG Tags)
• Hard to track analytics

---

Yes, it is. You should always provide a non-javascript fallback site for search engines and people with old browsers.