Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 10 months ago.
Improve this question
So I actually saw a full ajax site somewhere (I forget where) and thought it would be something new and fun to try. I used an old site I had built and put it on a new server. With a little bit of jquery and ajax, I was able to make the entire site work on one page load.
My question is, what are some pros and (more likely) cons to this method?
Please note - the site works through a semi clever linking function. Everything works perfectly fine if the user doesn't have javascript enabled, the newly requested page loads like it would on any other website.
More detail -- Say the user loads the homepage of the site, then logs in. When they log in, the login box fades and reappears with user info. Other content on the page loads as necessary upon logging in. If they click a link, lets say "Articles", one column on the homepage slides up and slides back down with the articles. If they click home the articles slide up and the homepage content slides back down. Things like posting comments, viewing profiles, voting on things, etc. are all done through ajax.
Is this a bad method of web design? If so, why?
I am open to all answers/opinions.
IMO, this isn't "bad" or "good". That depends completely on whether or not the website fulfills the requirements. Oftentimes, developers working on AJAX-only sites tend to miss the whole negative SEO impact issue. However, if the site is developed to support progressive enhancement (or graceful degradation depending on your point of view), which it sounds like you have, then you're good. Only things to prepare for are times when the AJAX call can't complete as expected (make sure you're dealing with timeouts, broken links, etc) so the user doesn't get stuck staring at a loading icon. (The kind of stuff you'd have to deal with in any application, really.)
There are plenty of single-page websites out there using heavy JS and AJAX for the UI and they are great. Specifically, I know of portfolio sites for web designers and web app development teams that use this approach. Oftentimes, the app feels a bit like a flash app, but without the need for a special plugin.
"Is this a bad method of web design? If so, why?"
Certainly not. In fact, making web-pages behave more like desktop applications, whilst remaining functional to ALL users, is the holy-grail of web-design.
I say, as long as you consider ALL your users, i.e. mobile/text-only/low bandwidth/small screensizes then you will be fine. Too many developers just do it for their huge 19" screens and 10Mbps, that users to get left behind through almost no fault of their own.
It depends on the user
This relates closely to UX, IMHO, though of course it's on-topic for programming solutions.
All-AJAX is often called "managing state" 12 years after this Question was asked.
From my experience in:
Creating a platform for API plugins
Creating two of my own CMS web apps for different purposes
Managing many different WordPress.org sites for different purposes
Managing my own cloud servers for both PHP-AJAX and Node.js doing these calls
...it depends on what is most efficient for users.
Consider these scenarios:
Will users be clicking around this website all day long or for at least an hour adjusting many different options and <form> inputs?
Or will many users visit briefly to perform just a handful of quick tasks?
State-managed / all-AJAX is by far best for scenario 1, with Facebook and Gmail as prime examples.
Whole-page loads are more efficient for scenario 2, like blogs, especially with pages linked directly from search results. That might apply to webstores like Amazon, maybe, where users search Google to find one or two products, then leave.
Philosophically, I've heard that the difference is about the number of users and traffic, but I don't quite agree. It's more about how much clicking and <form> sending the primary target user will be doing.
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 months ago.
Improve this question
Some results on Google Search comes with AMP (Accelerated Mobile Pages) icon on theirs links, at least when using a mobile, as soon you click on the link instead of loading the site, google show you a cached version of it rather.
I want to disable this behaviour on my results, I see at least two good reasons for it:
When sharing the link it is a pain in the neck to have the huge google URL in place of the shorter one would be just with the original one.
Security: when you access any site and see a URL other than the site you wanted to load, you should distrust it, even if it looks like google (remember, you can get phished or even get caught in a trap hosted on gsites), Google should respect that instead of encouraging users to trust it just because the url looks like google! Even worst if combined with the first reason and you want to share the URL with a friend.
I have to remove the google AMP prefix ever and ever, there is no advanced search option or cookie that makes Google give the clean URL?
According to the AMP project FAQ you cannot:
By using the AMP format, content producers are making the content in AMP files available to be cached by third parties.
As a content producer I dislike Google adding their own URL, and branding around my content... From the consumer perspective looks like the content comes from Google. They say it is to improve speed, but you can see Google's intention behind this "free" technology.
A simple hack is to keep using AMP guidelines for the speed it provides to the page, but violate one rule (like add you own javascript that does noting).
Once pages have an error, google will not cache them.
By publishing AMP pages you let Google or any other AMP cache store and deliver your web page (which surprisingly seems to be legal):
Caching is a core part of the AMP ecosystem. Publishing a valid AMP document automatically opts it into cache delivery. (https://www.ampproject.org/docs/fundamentals/how_cached)
To stop AMP from caching, the project recommends to invalidate the format by removing the amp attribute from the <html> tag. I propose something else.
One thing I always disliked about AMP ist that it requires you to embed the JavaScript code directly from their server (https://cdn.ampproject.org/v0.js), effectively telling AMP about every single visitor to every AMP page. Embedding the code from your own server stops this privacy issue, disables caching, and still gives you the framework.
To do so you can build your own AMP framework using the source code:
https://github.com/ampproject/amphtml
But it's much simpler to just copy v0.js and all the scripts it fetches to your own server.
Odd because google says to remove the "amp" from the tag to not cache.
It said nothing about loading the js locally.
https://amp.dev/documentation/guides-and-tutorials/learn/amp-caches-and-cors/how_amp_pages_are_cached/
Is google wrong?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have zero web programming experience but has been in IT industry for a while, mainly as a CRM technical consultant. I'm familiar with VBScript and Javascript, not in a Web context but as general scripting tools. I'm good at designing business processes, database models and using DB queries. I have some basic understanding of GAE and Python by doing the tutorials by Google. I used to write some tools with C# and VB6 a long time ago.
So I've decided to build my first website on Google AppEngine, and I'm lost in so many choices and new skills to learn.
What I'm planning to build is a simple website where users can post short messages and vote upon them. Which requires a simple but dynamic front page, login/cookie handling, Reddit like post voting/aging and some data storage.
Maybe the first question is which framework should I use? I heard Flask is good for beginner to learn web programming and webapp2 is easy to start since it's integrated to GAE by default. I've looked at Django as well, it looks very powerful, but I couldn't decide.
Since my idea is largely based on a concise but dynamic front page, I guess something AJAX is a must. But I have no clue on where to start. All those Ajax, Jquery, ProtoRPC are so confusing. Which technologies should I use and where can I find good tutorials?
I am also looking for suggestions on potential challenges and anything I should learn to achieve my goal. Thanks!
Since your project is inspired by reddit, the web development course with Steve Huffman (the technical founder of reddit) will be extremely helpful for you.
https://www.udacity.com/course/cs253 - it's free if you just watch the courseware. He even explains their aging algorithms in the end.
This course covers the back-end side of building a python applicaiton with the default webapp2 framework on appengine. He doesn't cover the front-end besides the basics (HTML forms and tables, stuff like this).
Now, Jquery is a Javascript library which is used by about all of the dynamic websites. It is a convenient way to work with the DOM on the fly. Everything you can do with jQuery, you can do with plain javascript, it's just that jQuery is infinitely easier to work with.
This library is used on the front-end, and it doesn't matter what backend you choose. It is extremely simple and powerful and you can learn the basics at the free codeschool course try.jquery.com.
Basically, if you want something to happen on the page dynamically (the arrow becomes red once the user clicked on it), you use jQuery.
AJAX is asynchronous communication with the server, it can be done by plain javascript but jQuery provides a very convenient wrapper for doing it. Usecase: the user clicked on the arrow, you painted it in red with jQuery, you incremented the votes counter (again with jQuery), and now you need to send the upvote to the server without reloading the page. For this you perform jQuery.ajax() call, and pass the user data as a param.
So to wrap it up: you need to write javascript to make a dynamic page and jQuery is the most common library that helps you with this. You need AJAX to get and post data to the server without page refreshes, this is implemented in jQuery. You can use jQuery with any back-end framework that you choose. Start with the simple jQuery tutorial, then read about $.ajax call and it will be clear for you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Single Page Apps are well known. But PageAx seems to be less well known. I stumbled across it by accident in learning MVC and it has worked quite well for me so far.
(Note: I am aware that this is a topic which may be regarded as "not answerable" and "should be closed" yet I feel this is an important topic which has not yet been covered. Note that this is Single Page Apps vs. PageAx (not Ajax). I am looking for benefits/disadvantage type discussion. I am making up the name "PageAx" as I have not found a better term for it.)
SPA - communication with controller via Ajax and returning Json.
PageAx - communication with controller via Ajax and returning partial views which replace divisions.
Here are the benefits of PageAx as I see it, over SPA's:
Little to no JavaScript on the client.
I find Partial Views very easy to write on the server side.
Benefits of SPA over PageAx:
I can't think of any.
Disadvantages of PageAx over SPA:
Slightly larger payload (but I doubt it would be discernible by end user.)
I can't think of any other.
Disadvantages of SPA over PageAx:
Seems like the amount of JavaScript and required libraries present a fairly large learning curve (i.e., more so than MVC.)
So to re-iterate the question, are there any advantages to SPA over PageAx? The basic reason for the question is that I am starting yet another web project and need to decide which way to take it.
This depends on complexity of your application.
Returning JSON is beneficial because hey—that means you have a full-fledged API that you can reuse in a mobile app or a desktop client. Even if you later decide to completely re-do your frontend, you will already have a ready-to-use backend to code against.
Also, if your webapp is highly dynamic and interactive, replacing partial views may not be enough. You may want to have finer control over transitions (e.g. animating them). For example, see Medium-Style Page Transitions: you can't do something like this with partial AJAX views.
On the other hand, if this flexibility doesn't buy you anything, rendering partial views on the server may work very well for you. Here's David from 37signals blogging about it. He calls this approach SJR (Server-generated JavaScript Responses):
This doesn’t mean that there’s no place for generating JSON on the server and views on the client. We do that for the minority case where UI fidelity is very high and lots of view state is maintained, like our calendar. When that route is called for, we use Sam’s excellent Eco template system (think ERB for CoffeeScript).
If your web application is all high-fidelity UI, it’s completely legit to go this route all the way. You’re paying a high price to buy yourself something fancy. No sweat. But if your application is more like Basecamp or Github or the majority of applications on the web that are proud of their document-based roots, then you really should embrace SJR with open arms.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
What are some general (not specific to LAMP, .NET, Ruby, mySql, etc) tactics and best practices to improve page loading speed?
I am looking for tips about caching, HTTP headers, external file minification (CSS, JS), etc.
And for good tools like Google PageSpeed and Yahoo YSlow.
A "ultimate resource" wiki style checklist of "things not to forget" (moderated and updated by all the wizards here on SO) is the end goal. So folks don't have to Google around endlessly for outdated blog posts on the subject. ;)
I hope the "subjective" mods go easy on me, I know this is a bit open ended. And similar questions have been asked here before. And this material overlaps with the domain of ServerFault and Webmasters too a bit. But there is no central "wiki" question that really covers this so I am hoping to start one. There are great questions like this that I refer to on SO all the time! Thanks
Caching of page content
Load javascript at the bottom of the page
Minify css (and javascript)
Css and javascript should be in their own [external] files
If possible combine all js or css files into one of each type (saves server requests)
Use Google's jQuery and jQuery UI loaders (as it's likely already cached on some computers)
Gzip compression
Images should be the same size as the width and height as in the markup (avoid resizing)
Use image sprites when appropriate (but don't over do it)
Proper use of HTML elements ie. using <H#> tags for headers
Avoid div-itis or the more popular now ul-itis)
Focus javascript selectors as much as possible ie. $('h1.title') is much quicker than $('.title')
Make your dynamic content more static.
If you can render your public pages as static contents you'll help proxy, caches, reverse proxy, things like web application accelerators & DDOS preventing infrastructures.
This can be done in several ways. By handling the cache headers of course, but you can even think about real static pages with ajax queries to feed dynamic content, and certainly a mix between these two solutions, using the cache headers to make your main pages static for hours for most browsers and reverse proxys.
The static with ajax solution as a major drawback, SEO, bots will not see your dynamic content. You need a way to feed bots with this dynamic data (and a way to handle user accessing this data from search engines url, big hell). So the anti pattern is to have the real important SEO data in a static page, not in ajax dynamic content, and to limit ajax fancy user interactions to the user experience. But the user experience on a composite page can maybe be more dynamic than the search egine bots experience. I mean replace the latest new every hours for bots, every minute for users.
You need as well to prevent premature usage of session cookies. Most proxy cache will avoid caching any HTTP request containing a cookie (and this is the official specification of HTTP). The problem with this is often application having the login form on all pages, and which need an existing session on the POST of the login form. This can be fixed by separate login pages, or advanced redirects on the login POST. cookie handling in reverse proxy cache can as well be handled in modern proxy cache like Varnish with some configuration settings.
edit: One advanced usage of reverse proxy page can be really useful: ESI, for example with varnish-esi. You can put on your html render tags that the ESI reverse proxy will identify. ach of these identified regions can have different TTL -Time To Live- (let's say 1 day for the whole page, 10 min for a latest new block, 0 for the chat block). And the reverse proxy will make the requests in is own cache or to your backend to fill these blocks.
Since the web exists handling proxys and caches has always been the main technique to fool the user, thinking the web was fast.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
My friend and I are building a website together, and he is insistent that page refreshes are a thing of the past and that we should build the whole website in AJAX. His only reason why page refreshes are 'annoying' is that they are too slow.
However, the page is running fine without AJAX currently and when I click from page to page, it seems instantaneous to me. It doesn't seem that it would benefit from additional speed, but he just says I'm being stubborn.
I do want to use AJAX for certain features and pages within the site. I feel like I understand the pros and cons. He references that gmail is made in AJAX, but the url changes as I go into different mailboxes, so I don't think it is 100% AJAX.
I reference wikipedia, which is actually much more similar to our site, as an example of a highly succesful website which doesn't seem to NEED AJAX. But he says that's just one example, and that I am fixated on on wikipedia.
Some personal rant:
1. When I tell him that AJAX is great, but that most of the internet will still require page refreshes and page links, he thinks I'm crazy.
2. When I tell him that using AJAX when not needed will make the back-button useless, he tells me that I'm obsessed with the back button.
3. I think AJAX is something that can be added later to make functionality smoother on certain features, but that it is OK to build the core of the website without it for now.
What is your opinion on the matter? When is ajax really needed in a website?
Thanks
No, Ajax is not necessary for a website to be great. But it can improve usability if used correctly and not overused.
A site built entirely with Ajax and non-functional with JavaScript disabled is a nightmare. No navigation back/forward. No bookmarking. Not to mention its effects for SEO, that is the site will be invisible to search engines.
The golden rule: build the site in classic fashion then add little elements of Ajax to improve usability now and then.
For certain advanced functions it might be okay to be only available as Ajax, but try to make sure the most of the site is at least accessible in read mode when JavaScript is disabled. StackOverflow is a great example of that approach.
My rule of thumb is - what are you building: a website or a web application?
if its a website, content should just NOT be loaded via ajax. It breaks many assumptions that the end users have about the website. Other problems:
1. SEO
2. back button breaks
3. more work to do on your side to make the website UI consistent
4. placing relevant ads will be more complicated
An excellent example is wikipedia.
If its a webapp, then ajax can really help:
1. you can design better user interaction
2. the user will actually expect the app to behave like a rich app, and not like a website.
3. you can dramatically increase the responsiveness of the app using ajax.
I hope that helps.
Of course, AJAX is not necessary to build a great website. It can, however, improve the user experience in certain situations. It is necessary to carefully study and understand your requirements, the structure of your site, and the navigation your users will undertake.
One important thing to consider, however, is bookmarks. Using AJAX extensively makes it extremely difficult to be able to simply bookmark a certain spot or "state" of your website.
Sorry to not post on topic, but I agree with the answers other posted (AJAX in great if not used too much.) It also DEPENDS on the website, if it's more like a web app where you don't need SEO and bookmarks (like gmail) you can go with full ajax (try GWT), if it's content rich- go with just a little AJAX.
But what I wanted to underline is the relation with your friend: you have to be careful when you start a big website with somebody else. If your fight is too big for such a detail you'll have much more problems later.
Get a website that supports a lot of connections, see how they do things and you might understand where and when ajax is used. Start looking at StackOverflow for instance.
This entire site is serving 16 million
pages a month and we are doing it off
of 2 servers, which are almost
completely unloaded. The Microsoft
stack is a pretty good stack.
Joel Spolsky, StackOverflow.com
Form validation using Ajax is the way to go.
I hate clicking "Submit" only to have the page return in a few seconds saying my password is not strong enough or that user ID is already in use. It should be instantaneous while I'm filling in the fields!
As far as StackOverflow, I think it's great how when I click on "Show additional comments", I see the spinner and then they immediately appear. When I change the sort on the answers by "newest" say, I hate how the page refreshes.
I don't think you need Ajax for a site to be great. That said, more sites that are great make use of Ajax. Good RIAs are awesome.
I dont see a lot of ajax on Digg, ArsTechnica, LifeHacker, and the such. Those are all (subjectively) pretty good sites.
No, you don't need it. It just needs to perform well for what your intended audience needs.
Yeah I think you do need it, having to submit pages is so pre-millenium.
More seriously, if you are presenting data, I really think it improves the user experience if asynchronous calls to server are used and the returned data displayed without the need for a complete page refresh.
I remember the first time I saw it used (years back) I was extremely impressed, awed even.
Anyone got example of dynamic, data driven websites that look great and don't use ajax ?
AJAX is not an absolute NEED for a website application. It does not necessary mean that your page will be faster. A lot more things determine page speed, such as:
client side minifying (css and js)
image compression and sprites
server location
and much, much more
Of course, applying AJAX in some strategic point of your website will be where you will most benefit from it. Use it where there is likely to be a lot of activity from your users. I personally always make my website without any http requests handling at first, and then implement the rest by adding AJAX where there is the much concern.
I think your friend is being a bit too concerned about AJAX. Like everything in life, it always tastes better with moderation.
One potential downside of AJAX, when misused, is that content can't be bookmarked.
Try and follow the rule of thumb, that the user should be able to link to content by copying the URL from the address bar. There are several ways to achieve this, with traditional page loads being one.
AJAX is not a must for any website. But if your website has voting, save as favorite, or add to cart, etc ajax will definitely add value.