Overall only: JS Only Vs web applications only

Question

When developing a web application compared to a website, what are the reasons for using multiple HTML pages instead of using a single html page and doing everything through Javascript?

I would expect that it depends on the application - maybe - but any thoughts on this subject will be appreciated.

Thanks in advance.

EDIT:

Based on the answers here and some of my own research, if you want to make a one-page site with a full JS site, some useful tools seem to include:

JQuery Plug Ins:

JQuery story: http://balupton.com/projects/jquery-history

JQuery Address: http://plugins.jquery.com/project/jquery-address

JQuery Pagination: http://plugins.jquery.com/project/pagination

Frames:

SproutCore http://www.sproutcore.com/

Cappuccino http://cappuccino.org/

Possibly JMVC: http://www.javascriptmvc.com/

Answer 1

page-based applications provide:

• the ability to work with any browser or device
• simpler programming model

they also provide the following (although they are solvable by many js frames):

• bookmarkability
• browser history
• Refresh or F5 repeat action
• indexability (if the application is open and open)

Answer 2

One of the main reasons will be how you can find your website.

Doing everything in javascript will make it difficult for search engines to crawl all the content on your site and, therefore, fully index it. There are ways around this (with Google's latest AJAX SEO recommendations), but I'm not sure if all search engines support this yet. In addition, it is a little more complicated than just individual pages.

The big problem, whether you decide to create multiple HTML pages, or if you decide to use some kind of structure or CMS to generate them for you, is that different sections of your site have a unique URL. For example, the about section will show a URL, for example mywebsite.com/about, and that URL will be used in the actual "about" link on the website.

Answer 3

One of the biggest crashes on single-page Ajax websites is complexity. What might otherwise be spread over several pages unexpectedly finds its way on one huge main page. In addition, it can be difficult to agree on the state of the page (for example, tracking, if you are in edit mode or preview mode, etc.) and interface settings to match.

In addition, one main page that is heavy in JS can be drag and drop in performance if it needs to load several large JS files.

Answer 4

In the OP request, I will talk about my experience with JS sites. I wrote four relevant sites: two JS-heavy ( Slide and SpeedDate ) and two JS-only ( Yazooli and GameCrush ). Keep in mind that I'm a JS-only-site fanatic, so you mostly read John Hinckley on Jodie Foster.

• The idea really works. It produces exquisitely responsive sites with very low maintenance. My assessment is that the cost of bandwidth, processor, etc. It is 10% of the cost of launching a similar site based on pages.
• You need less, but better (or at least better trained) programmers. JavaScript is a powerful and elegant language, but it has huge problems that do not have a more rigid and unimaginable language such as Java. If you have a whole bunch of mostly mediocre guys working for you, consider JSP or Ruby instead of JS-only. If you need to use PHP, just shoot yourself.
• You must save the base state of the session in the anchor tag. Users simply expect the URL to represent the state of the site: reload, bookmark, back, forward. The jQuery Address plugin will do most of the work for you.
• If SEO is a problem for you, explore Google Ajax Crawling . Basically, you make a very simple parallel site, just for search engines.

When will I not use JS-only? If I were to create a site that was almost completely satisfied, where the user did nothing but move from one place to another, never interact with the site in a complicated way. So Wikipedia and ... well, what about that. A large reference site with lots of data to read by the user.

Answer 5

modularity. Multiple files allow you to clearly break down different workflow paths and parts of a process most likely, your business rules are something that usually does not directly affect your layout rules, and several files will better help you edit what you need to edit without risking breaking something unrelated.

Answer 6

As a rule, I would say that you need to go with several pages if this does not make sense. I know this is vague, but actually it is not. Think about how different parts of your site split naturally - do your site have different “views” (sections / pages), each of which has its own logic? (For example, a social network where each user gets their own page.) Or does the site have only one real "view" that the user spends the most time? (For example, a word processor that really has only one page.)

In addition, I would say that the more “desktop” applications, the more you should rely on a single-page solution based on Ajax. If you cannot display the application as your own desktop application , then you should probably use a multi-page approach.

---

However , as Andy mentioned in another answer , if the content of your site should be searchable, you should keep dynamically generated to a minimum or at least provide a separate static version of your site for search engines and users without using JavaScript.

Answer 7

I just developed my first application using only one page.

.. he is confused

My idea was to create an application that maximized the working environment. In particular, I wanted a detailed overview of some application data to be displayed in a pop-up window that would maintain its state regardless of the application section in which they were located.

Thus was born my Frankenstein.

What ultimately happened due to budget / time constraints is a code that got out of hand. The various sections of my JavaScript source got confused. Maintaining the proper state of different views, I was ... difficult.

With proper planning and technique, I believe that the “one page” approach is a very simple way to discover some very interesting possibilities (for example, widgets that maintain state in application sections). But it also opens up many ... many potential problem areas. including...

• Flooding the global namespace (if you don’t have your own ... do one )
• Organizing code can easily get ... out of control.
• Context is very easy

I am sure there is more ...

In short, I would strongly recommend that you stay away from JavaScript dependency for compatibility issues. What I understood is that you just don't need to rely on JavaScript for everything.

---

I am in the process of removing JavaScript dependencies in loo Progressive Enhancement . It just makes sense. You can achieve the same or similar effect with properly encoded JavaScript.

The idea too ...

• Design a well-formatted, fully functional application without any JavaScript
• Style
• Wrap everything with JavaScript

Using Progressive Enhancement, you can develop the application as possible for the user as possible.

Answer 8

For some additional arguments, see the Single Page Interface Manifesto and some (mostly) negative reaction to it in Hacker News (link at the bottom of the SPI page):

Single page interface manifest: http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php

Answer 9

stofac, first of all, thanks for the link to the single page interface manifest (SPI) manifest (I'm the author of this boring text)

That said, SPI! = Do everything through Javascript

Take a look at this example (server-oriented): http://www.innowhere.com/insites/

Same thing in GAE: http://itsnatsites.appspot.com/

Learn more about the GAE approach: http://www.theserverside.com/news/thread.tss?thread_id=60270

In my opinion, coding a complex SPI application / website entirely in JavaScript is very complicated and problematic, the best approach, in my opinion, is "hybrid programming" for SPI, a combination of a server center for large public administration and a client (for example, manual JavaScript) for special effects.

Answer 10

Doing just one page with ajax everywhere will lead to browser / back breaking and will annoy the user.

Answer 11

I completely despise only JS sites where this is not needed . This additional condition matters. As an example, consider the frequently quoted Google Docs, in which case it not only helps to improve the experience, but is also necessary. But some parts of Google’s help were JS-only, but it doesn’t add anything to the experience, it only shows static content.

Here are the causes of my frustration:

• Like many, I am a NoScript user and love him. Pages load faster, I feel safer and avoid more distracting advertisements. The last point may seem bad for webmasters, but I don’t want anyone to be rewarded for pushing annoying screaming things at me if tactless advertisers go out of business, I consider it a natural choice.
  Obviously, this means that some visitors to your site will either turn away or feel concerned about the need for a temporary exception. It reduces your audience.
• You are duplicating efforts. The browser already has an excellent history feature, and you don’t need to reinvent the wheel by redrawing the previous page when you click the back button. To make matters worse, the page should not require re-rendering. I guess I'm a student at If-it-ain't-broken-don't-fix-it (from Don't-Repeat-Yourself U.).
• No HTTP headers when moving "pages" in JS. This means that no cache controls, no expiration dates, content cannot be adjusted for the requested language and location, no meaningful answers “page not found” or “inaccessible”. You could write error handling procedures on your uber page that respond to failed AJAX selections, but this is more complicated and rethought, it is redundant.
• No caching matters to me, without it, proxies cannot work efficiently, and caching has the greatest effect of reducing the load. Again, you could imitate some caching in your JS application, but this is even more complexity and redundancy, a higher level of memory usage and a lower user interface in general.
• The boot time is longer. By loading as much Javascript on your first visit, you cause a longer delay.
• The added complexity of JavaScript means more debugging in various browsers. Server-side processing means debugging only once.
• Unfuddle (bug tracker) left a bad taste. One of my most unpleasant web experiences was forced to use this service with an employer. On the surface, this seems well suited; The JS-heavy section is private, so there is no need to worry about search engines, only repeat visitors will use it, so you have time to disable protection and you should not forget about the initial loading of the JS library.
  But using JS is pointless; most of the content is static. Pages were still received (via AJAX), so the delay is the same. In favor of AJAX there should be a poll in the background to check for changes, but I would not receive a notification when the visible page was changed. Sections had different styles, so when switching to them, when loading external style sheets using Javascript, there was a bad resale. Ease of use was sacrificed for whiz-bang "Look at our Web 2.0 features." Such a business-oriented application should focus on search speed, but it turned out to be slower.
  In the end, I had to abandon the use, as this disrupted the work of the team. This is not very good for the relationship between customer and seller.
• Dynamic pages are harder to save for offline use. Some mobile users like to download them in advance and turn them off to save energy and data usage.
• Dynamic pages are harder for a screen analyzer. Although the number of blind users is probably less than that of NoScript or mobile, it is unforgivable to ignore accessibility, and in some countries even illegally, see the Law on Discrimination Against Persons with Disabilities (1999) and the Law on Equality (2010).

As mentioned in other answers, “best progressive”, née “ “ unobtrusive Javascript ” is the best approach. When I need to create a JS site (remember that I don’t mind it in principle, and there are times when it is valid) I look forward to implementing the aforementioned AJAX workaround and hope that it will become more standardized in the future.