Hi Booth,
I don't know that I agree with that.
My experiment with a simple single page app showed me some real advantages of single page apps.
1. A single page app does not download everything needed for a new page each time a user requests information from the server. The amount of information downloaded from the server is minimized. This has at least three advantages:
a. It makes transitions to new page content faster, providing a good user experience. This would be especially appreciated by users who are limited by slow internet connections.
b. It saves bandwidth and reduces load on web servers (but I repeat myself). This would become increasingly important when you have large numbers of concurrent users.
c. It saves money for mobile users who have to pay for information they download.
2. Code maintenance was greatly reduced. Even for a small website like mine, it can save time and avoid mistakes. For example, I have three lists of navigation links in my index.html file: one list for the drop-down menu for mobile users, one list for the desktop navigation bar, and one list for the footer navigation links. With a single page app, the only place I ever had to change these links was the index.html file. Now that I am going back to having multiple HTML files, if I want to change a link, I have to change it three times in every page of my website. This can be more time-consuming and introduce the possibility of errors.
I would definitely use SPAs for other projects.
Heck, if someone drops an easy solution to the issues into my hands quickly enough, I might be persuaded to keep this website an SPA. ;-)
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
1.217.773.4486 ext. 12676
kcookson@xxxxxxxxxxxx
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Booth Martin
Sent: Tuesday, August 04, 2015 1:01 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] A Responsive Single Page App (SPA) with 3 Issues to Consider
Totally agreed. With today's state of the art, the game is not worth the candle.
My bet would be that in a few years time there will be new solutions that are cheaper, quicker, easier, and have way more flexibility.
This is a new paradigm, so either give up all else and commit to this and fly on the leading edge or hang back and take a sleigh ride on the crest of the wave. Either way works but trying to do both usually ends with soiled underwear.
In my opinion.
On 8/4/2015 12:42 PM, Kelly Cookson wrote:
One thing I have grown to dislike about having a single page app is browser caching. I make changes to the files used for content within the single page app, but I often have to clear my browser cache for the changes to show up.
Add this to the fact that users cannot add particular "pages" to their browser favorites. A favorites link always takes the user to the home page.
I'm guessing there are methods for getting around these issues. If this were going to be a large website that a business had to spend money to maintain, or a website used by tons of people where maximum performance was a necessity, then I would probably do more research to resolve the above issues. I definitely see the maintenance and performance benefits of single page apps.
But this is just a hobby site and unlikely to be used by many people. I don't mind spending time on it because, well, that's what hobbies are for...spending time. So I'm going back to making it a traditional web site with multiple HMTL files.
The link http://www.socialhope.info/code/SocialHope_REBOOT.zip will continue to have the source code for the single page app version of the website, for those who find this thread in a search or simply want to download the code later.
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
1.217.773.4486 ext. 12676
kcookson@xxxxxxxxxxxx
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
midrange.com
