I was wondering what is considered best practice. Let's say I have a dropdown select widget. Should it be preloaded with content when the page is served up from the server or once it is loaded, should an AJAX request be made to retrieve the contents and then populate it?
I kinda like the idea of loading it empty and issuing an AJAX call to retrieve the contents. But is that going to result in slower page loading times. Especially if the page has several widgets that need to be loaded with content from the server?
Does it matter on the amount of content being loaded?
For the dropdown example, I meant the options in the dropdown. So if I had a dropdown of employees to choose, from I am referring to that list of employees. Do I load an empty dropdown and on init of the controller have it retrieve the employees and populate the dropdown?
But then I think about a datagrid of let's say 200 rows of emplyees and some employee data that is stored in a database. Do I load the page and when the page loads have a controller whose init function retrieves the dataset of employees and populates and displays the datagrid?
Or when the page is served up from the server does it retrieve the dataset on the server-side where it also creates the datagrid and it gets loaded then.
This is the programming world that I am used to having done mostly PHP, JSP and ASP stuff in the past. Only using JavaScript for some cool page effects, etc.
But I seem to like the idea of once the page is loaded (or being loaded), make AJAX requests to retrieve the data needed to populate the widgets/content on the current screen. I am just concerned that the loading of page might seem clunky or slow since I am now making more requests to the server to paint the page. The initial request for the page, and then a request for each dataset needed to populate a widget.
I think the best answer is "it depends on your framework". I've seen web frameworks that handle this problem both ways. I do think that, especially when a lot of data is being populated into the DOM, it's preferable from a performance perspective to load as much of the page as possible in the initial HTTP response, and only update as needed via AJAX. Note that for large data sets, the performance overhead of an additional HTTP request is relatively small compared to the impact of performing substantial DOM manipulation via JavaScript -- DOM manipulation can be extremely slow in some browsers.
You might get more detailed answers if you add which framework(s) you're using.
As you point out yourself, loading everything with AJAX is going to make the page slow. In fact, one of the best practices for speeding up web pages is to reduce the number of http requests.
That being said, there are some cases where AJAX makes the page load faster. One example is auto complete for a text box. If implemented such a feature without using AJAX that would require the web page to load every single possible query in the first load. The page would take forever to load all that data. But the auto complete would probably seem more response than normal once the page had loaded.
My advice is to start out with the most simple solution you can think of, and then add AJAX, cache and other optimizing features where needed afterwords.
It depends of the data you are displaying, if you want quick updates from the database the ajax approach is fine.
But if your data is fixed (or you don't care about updating it once the page is loaded) then I shouldn't go with the ajax approach, is more work (requesting json, parsing it, populating the select or whatever) and you don't gain much benefit.
Related
I know iframe and ajax comparisons have been asked many times. But I would like to add the good jQuery load() function, and also ask when to use which one.
I am certain they all have their own specific features, so I don't wanna know which one is faster and so on, I am more eager to recognize when to use which to retrieve the data from another page?
<iframe>
load();
ajax();
When to use iframe?
From this answer by Manishearth
Given that framing is deprecated, and AJAX has origin control, iframes
is pretty much the only way to embed another page into yours.
GMail is made from iframes. The smooth UX of GMail (you can still use
it when your internet connection breaks, smooth navigation without
having to reload every time) comes from iframes. Again, this could be
implemented in AJAX, but it's harder.
On the other hand, issues with iframes (CSRF, clickjacking, etc) are
well known to modern developers and they can take measures to avoid
that.
- When to use Ajax?
Form validation
This is almost a no-brainer. It's so much nicer when the form tells
you as you are typing if you've filled it out wrong or not. Having to
go to the server and then return an error message is not only old,
it's slow. Leave the server validation in the form, that's important
for accessibility. But for those who can support Ajax, tell them right
away.
Comments
Comments on blogs or even just articles are a great use of Ajax.
Comments can change all the time, and especially when a commenter hits
the comment button, it's nice to see the comment appear immediately on
the page.
Filtering data
If you've got a large table with a lot of data in it, a nice
application for Ajax is to add filters and sorters to the table.
Getting your Web table to act more like Excel is really useful to
people.
Surveys and polls
When you click on your vote, the poll would just switch to show you
the results. And before you comment, About doesn't yet support Ajax on
our polls - but it sure would be nice. Maybe we can give the About.com
developers an "Ajax call" of our own.
When to use load?
As far as load is concerned, in my personal opinion, it is used to
load documents into any element in DOM, but will have same
disadvantages as ajax over iframe with regard to cross domain
data. You can use load when the result you are returning is html
and this provides option to render the result directly to the DOM
element
UPDATE:
When to use AJAX
Basically, the main difference between ajax and load is that
ajax has more options that can be set before posting data to
server plus ajax can be used to store data in the server using
type="POST" and data returned from the server may be manipulated the
way we want unlike load which can be used only to render data.
To conclude - Security wise ajax/load is good but as said before if you know the loopholes of security using iframe you can take necessary precautions to prevent them too.
AJAX USAGES AND DISADVANTAGES
I am implementing page loading through ajax() and I would like to know if I can save some time when requesting a page through the jQuery function .get()
When running the .get() function I pass a parameter that will indicate to my PHP page that it is being requested by AJAX and that it should return only those parts that are marked as such.
For example, all my PHP pages have header and footer functions, so when these pages are called by my AJAX function, the header and footer functions will be skipped.
Will this save my any time and bandwidth in my .get() request and thus delivering the page faster? If not, is there any other way to accomplish this?
Long story short, "probably".
It depends on two things:
1) The efficiency of your back-end.
2) The speed of the network.
If your back-end is very slow, and your network speed is high, then you potentially will take a performance hit if it takes longer to create this "custom" version of your request than it otherwise would have. My guess is, though, that it won't, assuming your back end architecture is set up to put together component parts. If you have less component parts, in theory requesting only specific parts of the page should take less time to prepare the request. If you're sort of reverse-engineering things to remove component parts from an existing page/content set, then you might see a drawback. But, efficiency on the server side usually lies in database requests, etc, the kind of thing that usually happens no matter what kind of request you make.
If your network is slow and you don't have a bottleneck on the server side, then you'll definitely be seeing an increase in speed (though probably negligible).
All in all, however, unless you're delivering a half-meg of code per request (which in my experience is only true with bloated frameworks and enterprise-level platforms), then you're really not going to see a difference either way. HTML is a text-based format and the real things that impact your load times are requests for images, video, and other assets like that.
Another way to do this is rather than requesting HTML, you could request JSON. That means that you'd be only getting the content that makes up the page, and having javascript update it client-side as it comes in. This is much more complicated, but will make your application seem much faster.
I recommend the only-get-what-you-need approach (which seems to be what you're doing), however if you're in a startup where you have a funding runway to worry about, I'd say, "Get it done now, optimize it later".
Hope this helps :)
I have a webpage that I am working on for a personal project to learn about javascript and web development. The page consists of a menu bar and some content. My idea is, when a link is clicked, to change the content of the page via AJAX, such that I:
fetch some new content from a different page,
swap out the old content with the new,
animate the content change with some pretty javascript visual effects.
I figure that this is a little more efficient than getting a whole document with a standard HTTP GET request, since the browser won't have to fetch the style sheets and scripts sourced in the <head> tag of the document. I should also add that I am fetching content solely from documents that are served by my web app that I have created and whose content I am fully aware of.
Anyway, I came across this answer on an SO question recently, and it got me wondering about the ideal way to engineer a solution that fits the requirements I have given for the web page. The way I see it, there are two solutions, neither of which seem ideal:
Configure the back-end (server) from which I am fetching such that it will return content and not the entire page if asked for only content, and then load that content in with AJAX (my current solution), or
Get the entire document with AJAX and then use a script to extract the content and load it into the page.
It seems to me that neither solution is not quite right. For 1, it seems that I am splitting logic across two different places: The server has to be configured to serve content if asked for content and the the javascript has to know how to ask for content. For 2, it seems that this is an inappropriate use of AJAX (according to the previously mentioned SO answer), given that I am asking for a whole page and then parsing it, when AJAX is meant to fetch small bits and pieces of information rather than whole documents.
So I am asking: which of these two solutions is better from an engineering perspective? Is there another solution which would be better than either of these two options?
animate the content change with some pretty javascript visual effects.
Please don't. Anyway, you seem to be looking for a JS MVC framework like Knockout.
Using such a framework, you can let the server return models, represented in JSON or XML, which a little piece of JS transforms into HTML, using various ways of templating and annotations.
So instead of doing the model-to-HTML translation serverside and send a chunk of HTML to the browser, you just return a list of business objects (say, Addresses) in a way the browser (or rather JS) understands and let Knockout bind that to a grid view, input elements and so on.
I'm working on a project which needs to load via AJAX some HTML information on the page.But I'm not quite sure how to load that information.
I don't know which method is better for me:
1) Load the entire HTML with AJAX and then just append it to the page
or
2) Load only the data with AJAX and then build the HTML using Javascript(+JQuery)
The one I tend to use is the first method because it's the easiest one but also it is more expensive regarding the memory (the biggest file I have to load has about 7kb which is not too much)
The second one which is the hardest, involves a huge Javascript (Jquery) code to build the HTML(I have also to load the attributes for the element).And because I have lots of different HTML code to load I have to make lots of conditions (e.g. one for a button, one for a title, one for a textarea etc) and also I have to create variables that containes that HTML.
My question is what method is the best to use in my case?
I would always stick to the solution where I cleanly divide data/logic and view. This would probably the case in the first alternative. Making changes to HTML generated with JavaScript is quite hard.
I'd suggest another option: Use client side templates. Load the template and the data with an ajax call and then fill out the template using javascript. There are some libraries out there for this scenario.
I can imagine a couple of developers working: A full-time back-end developer and a full-time front-end developer.
The BE developer has to send some data for the FE developer to display it right. Thinking of programming as easy as possible, he chooses the first method described by the OP. Everyone is happy.
A few months later, the presentation of this very data needs to be updated. The manager quickly calls the Front-End developer, which says:
"Uhhh... No can do. The entire data already comes formatted directly from the server."
Oh noes! Would this have happened if the data came only as RAW DATA from the server? I wonder =)
the second method:
Load only the data with AJAX and then build the HTML using Javascript(+JQuery)
is much appropriate, one main advantages of these method is your ajax response will become faster.
Also, it is more logical to separate the logic from design.
Note: always the best solution is depend on your specific case.
I'm currently building a portfolio-website for an architect that has a whole lot of images on its pages.
Navigation is done with history.js (=AJAX). In order to save loading time and make the whole thing more "snappy", I wrote a script that crawls the page body for links to other pages and fetches these automatically in the background. So far, it works like a charm.
It basically keeps a queue-Array that holds all the links. A setTimeout()-Function works through them and fetches each page using jQuery $.ajax(). The resulting HTML is stored in a Javascript Object.
Now, here's my question:
What are possible problems that might occur when using this on different machines/browsers/operation systems?
I'm thinking about:
max. javascript object/variable size (The fetched HTML is stored in an javascript object)
possible performance problems
max. number of asynchronous requests?
… anything you can think of?
Thanks a lot in advance,
a hobby programmer
Although it might be a good idea to cache the whole website on the client side there are a lot of things that can cause issues:
Memory
Unnecessary load on the webserver
Loading uneeded pages into memory
Some users have a limit to their internet so loading the entire website is not smart in those cases
Once the user naviagets away or refreshes the entire "cache" is gone
What I would do is first try to optimize the server side.
Add a bunch of caching mechanisms from the database to the user, the "Expires" header can really help you.
And if that doesn't help I would then think about caching some pages(which ones are for you to decide) in the offline cache, see (HTML 5 Offline Features)
That way you are safe even on page reload, keep the memory to a minimum and only load what you need.
PS: Don't try to reinvent stuff that the browser already has :P
You should queue the async requests, and only launch one at a time.
And since you're storing everything in variables, at some point you (the browser) may consume to much memory, and the whole thing can become very slow. I suggest you limit the size of your cache to a certain number of pages.
You can also try to not to store fetched content - just fetch it and throw-out. Browser still will cache fetched pages and images in its internal storage, so subsequent loads will be much faster (of course if ajax library does not forcibly disable the cache i.e. by using POST)