What are the pros and cons of creating an AJAX-heavy web application over one with permanent URLs?

Question

The original subject: Is it a good idea to make a JavaScript site?

* The question has changed because it was discussed more, but could be useful to others. *

In this case, I was thinking of creating a website that initially delivers its overall layout using plain HTML (like a regular, basic web page), but then I plan to dynamically populate the contents of the HTML content area, making full use of AJAX Requests.

Site users will never refresh the page or go to a new page, and all other divs and elements to be generated will be created using AJAX (using the many JavaScript functions that are located on the cached external JavaScript page).

Although I actually do not create a forum site, the level of functionality of the forum is close to what I want to achieve. Also a lot of reading and writing database.

It is a bad idea? Aren't I considering something that could make this potentially terrible? Is this good in terms of performance (since I will do so much work on the client side and less work on the server side)?

I understand that the page will not work for people who have JavaScript disabled, but this is not a problem in this case. I am also not worried about any mobile devices that do not support JavaScript, as I probably just create a version of the site that does not use JavaScript).

Thanks!

UPDATE: First: Thanks for all the answers, everyone! I really appreciate that!

Just for clarification, I thought it would be a good idea, mainly because it seemed to me that I could just say: “Hey AJAX, just give me the forum source for this page and I’ll do everything from the client side HTML " Of course, the same access to the database, but less work on formatting on the server side and less data transfer to the client.

And another important clarification: I do not care about search engine optimization, because this forum will be a network only for entering the system, which should not be crawled or viewed by unregistered users.

Answer 1

Not a crazy idea, but I recommend against it, as it will be difficult to maintain. You just found out what you're driving at. Facebook is doing something similar. For example, the Google search interface also keeps you on the same page when performing searches.

You may also be interested in:

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

and BBQ (request with a back button) http://benalman.com/code/projects/jquery-bbq/docs/files/jquery-ba-bbq-js.html

One of the drawbacks is that analytics scripts will not necessarily work correctly on sites built in this way, depending on how you create them.

Edit:

One of the problems is that it will not be crawled in a search engine. This can be overcome if you build your site well, possibly using BBQ, and following this specification:

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

Answer 2

A few years ago this would be an absolute NO. But now with newer browsers, libraries such as jQuery, YUI stuff can be redefined.

Disclaimer: I do not say absolute YES.

Rather, it requires a thorough assessment of your requirements, user expectations, performance levels, etc.

If your main user base uses IE6 / 7 or even 8, page speed will be significantly slower than FF or Chrome. There are certain cases when you should resort to server-side rendering.

The list may go on, but you are the best judge here (unless you can be more specific with your requirements).

We recently released an intensive JS website for a large news corporation. However, to maintain performance, we also use server-side caching and several other methods in conjunction with the client side JS.

Answer 3

No, this is not a bad idea in itself, especially if you do not care about supporting browsers that do not have JavaScript, but it has some caveats. For example, you need to work hard to develop the structure of your JavaScript structure and which tools you will use. If you haven’t come up with a reliable solution, then your site code can quickly degenerate into an unbeatable mess. You will also spend much more time on cross-browser testing, since the same JavaScript code can lead to different behaviors in different browsers (mainly thanks to IE).

In terms of performance, you really don't do less work on the server side. Expensive server operations are your database queries, and you should do this regardless of whether the server returns a stand-alone web page or an AJAX fragment (or JSON). In fact, depending on how you structure your JavaScript client, you may work more. For example, if JavaScript sends a separate AJAX request for each div on the page, it will be less efficient overall than allowing the server to create content for all sections on the page as part of a single operation.

Answer 4

This is a good idea, but let's see what some troubling points might be.

what can i think about:

• The website will not be crawled by any Search Engines.
• The CODE SOURCE of your website can be easily stolen, and everyone will be able to enjoy their hard work.
• Pages cannot be viewed on Facebook (facebook needs OG tags)
• Difficult to track analytics

Answer 5

Yes it is. You should always provide a backup site other than javascript for search engines and people with older browsers.