I have been working on a project, where I'm making AJAX call to load 100's of record from database, which would then be rendered on a slider.
To be precise, the data I would be fetching is the 'Image Path' for all the images, and other details such as 'the size of slider thumbnail', 'number of thumbnails to show', etc.
For this list of data, I have 2 options:
1. To generate the HTML on the server-side and send it to client, where it will be applied to the slider.
2. To generate and send json data to client. Parsing this json data and generating the Slides for the Slider.
I'm confused as to which approach to use, for better overall performance for client/server. Google search and reading articles states me that using json data is a faster. However, after performing few initial test to fetch and render HTML shows that generating HTML on server side and sending it to client for rendering is much faster than sending the json data to the client and preparing the HTML for rendering.
It would be great if someone would put a light on this issue, where the server gets about 4k-5k hits per hour.
There's a lot of really great discussion around this topic, however I tend to side with client side rendering. My reasoning is 1. If your server is getting hit very often, server side rendering slows down the response time of your server and can cause really long queue times, and 2. Because you're making the request separately from your markup and styling, you can have a splash page or some waiting animation on the user side as opposed to having them sit at a white screen while your server is compiling everything. This is just my opinion, but I've found client side rendering to provide the best UX as well as offloading computations from your web server is often a good idea
I like the answer on this link.
A Short Description what it is about (Copy-Paste):
I'm a bit on both sides, actually :
When what I need on the javascript side is data, I use JSON
When what I need on the javascript side is presentation on which I will not do any calculation, I generally use HTML
The main advantage of using HTML is when you want to replace a full
portion of your page with what comes back from the Ajax request :
Re-building a portion of page in JS is (quite) hard
You probably already have some templating engine on the server side, that was used to generate the page in the first place... Why not
reuse it ?
I generally don't really take into consideration the "performance"
side of things, at least on the server :
On the server, generating a portion of HTML or some JSON won't probably make that much of a difference
About the size of the stuff that goes through the network : well, you probably don't use hundreds of KB of data/html... Using gzip on
whatever you are transferring is what's going to make the biggest
difference (not choosing between HTML and JSON)
One thing that could be taken into consideration, though, is what resources you'll need on the client to recreate the HTML (or the DOM
structure) from the JSON data... compare that to pushing a portion of
HTML into the page ;-)
Related
I'm building a pretty straightforward Node/Express web app that pulls in data from the Reddit API, does some manipulation on it, and then plan to visualizes said data through Charts.js client side. However, being relatively new to fullstack dev work, I'm wondering how to best approach the data manipulation aspect.
Currently, I have 100 comments being pulled at a time and am doing manipulation on those posts server side and then pushing that JSON to the client side for the data viz. Since there is no data persistence between searches and the data itself isn't confidential, is it more efficient to just send the original JSON for data manipulation to be done client side as well?
There is no best approach, just different tradeoffs depending on what you choose.
Parsing on the server:
Some Pros:
You are able to reduce the amount of front-end code needed.
You can hide any code from the client that you don't want users seeing
You have better control/understanding of what resources the parsing computer will have
Some Cons:
You need to Parse all the data for every request!
Parsing in a client:
Lets keep this DRY:
Some Pros:
Opposite of servier side parsing con
Some Cons:
Opposite of server side parsing pros
Recommended Approach:
Weigh the pros/cons of each method, think about the required resources needed for the maximum scale you would ever expect, multiply those resources by 10, and then make a decision.
In general is it better for performance to do lots of data calculations on the server side or on the javascript side?
I have a bunch of data that i'm displaying on a page - and I'm wondering if I should format/ parse/ make calculations on that data on the server side (in python) and return a template or if I should return the data as is and do all my calculating/ formatting on the javascript side?
Are there any general rules of thumb when making these decisions?
Examples of things i'm calculating - converting timestamps to dates.
This depends a lot on what you are trying to do. If the chart is dynamic and animated, doing it client side with js may be the only choice. It also depends on how much data you have. I would not recommend doing it in js if you have over 10mb of raw data.
First of all you should consider change you data format for storing a data for displaying. It should be stored already in the convenient way for displaying it - that does not requires any processing at all.
If you still need some recalculation of data consider doing it server-side as this gives you possibility of caching this result (for example in mamceched) as this make no sense to calculate them on every page refresh.
The worst option is recalculating them client side, as this can bring hard to detect noticeable performance issues on client browser (eg. on larger data) and you could be unable to see this kind of problem in your testing environment (you could see that your server is slowing down, but it is very hard to see that some clients renders your page very very slow - unless they write to you).
In addition to the facts stated by thedk, you should also keep in mind that calculations you do on client side are more likely to fail because the client may not fulfill certain preconditions. Think of disabled JavaScript or an unreliable internet connection. You generally have no control over your data as soon as it has left the server.
So, it would be highly advisable to move only unimportant calculations to the client side. Something like datetime formation might be okay, but don't try to parse your whole website with JavaScript. Your website should work (and look acceptable) even if JavaScript is disabled on the client.
I use third-party JavaScript grid control. The matter is, it renders completely on client side and takes much time for this (creating DOM and corresponding JS objects). It can be normal for PC, but completely bad for mobile browsers like iPad's Safari (for about 1 minute rendering time). I apply many different optimization tricks, but the main problem is grid's rendering time.
So, I wonder, is there any ability to perform rendering of HTML page on server side and return to the client completed page with JS objects?
By another words, I need to launch web page on server side, get the resulted DOM and JS objects and return this to client, like it was performed on client browser.
So, I wonder, is there any ability to perform rendering of HTML page on server side and return to the client completed page with JS objects?
No. You can produce either HTML or JavaScript on server side, but the actual execution of the JavaScript and rendering of the control is not a task you can delegate to the server.
I don't know what is causing the actual performance issue, but you may want to look into paginating your results on server side so the client needs to render only one pageful at a time.
I'm calling a webservice currently from the backend. However, the page is taking a while to load and I'm starting to wonder, will the page load faster (in a perceived way) if I use javascript to load the data instead of the backend?
Basically will using a REST service to load the data on the client side make the page load seem faster than loading the data on the backend with a SOAP call? Does page_load fire first or the javascript calls?
In terms of the difference between calling a SOAP service on the backend vs. calling a REST/JSON service on the front end - your page load times may be percieved as faster if you let the frame of the page load, and display a "spinner" when you load the data from a REST service.
Your question is a bit ambiguous since it's not clear that's what you're asking.
Well, REST vs. SOAP isn't really a comparison anyone can make in terms of speed/performance on a website. REST refers to a conceptual semantic model of how to make calls to a service. SOAP, on the other hand, refers to both the semantics of the call, as well as the data format. REST, by comparison, says nothing about the data format (although JSON is typically assumed - but nothing about REST precludes XML or any other data format).
JSON vs. SOAP, however, is a different story.
JSON responses will be easier / faster to parse on the client side than SOAP messages will (assuming you're using standard javascript stuff which works cross-platform, and no fancy plugins).
Load time? SOAP is a LOT more verbose than JSON, and requires additional characters to transmit the same values... so maybe a small delay due to the relative sizes of the messages being sent.
Processing time on the client side? JSON definitely has the edge.
Ease of use on the client? JSON - hands down.
I see this question not as much as a comparison between REST and SOAP, but rather a question about where the service should be called - backend or frontend. Backend code always executes first, before any frontend code, by definition - it just sits on the server, and runs before the response is returned. The javascript runs after the response is returned and the page is loaded.
Steve gave a very good overview, but it doesn't talk at all about backend v.s frontend. Generally speaking there will be no difference in performance or at least no difference that can be predicted. It all depends on the server condifuration and client computers (where the Javascript executes).
The difference (as Steve also mentioned) is in perceived performance. Here, I would always recommend that you call services from the frontend. There are a couple of reasons:
You can display a visual indicator before you call the service to inform the user of the lengthy operation
You can do a partial update of the UI on each next call to the service. If you call the service in the backend, you would have to essentially do a postback (go through the whole lifecycle of your ASP.NET page). This is slow and not visually appealing.
Actually if you are calling a service from the backend I see no point in having a service at all (assuming it only returns data to bind to the UI). You can just use the old Webforms way to construct the UI and return the response directly in your ASP.NET page.
As a conclusion - many of the benefits of web services come when you call them from client script.
Without looking in your code i cant realy say whats wrong/ why is site loading not fast enough.
REST and SOAP are definied standarts for comuniation between client and server.
I prefer REST over SOAP.
The direct answer for your question is: Page_Load event will load before your Javascript background calls. I recommend using javascript with background loading when your page has several web controls that load too much data, draw elements or doing heavy calculations that take much time and affect the user experience and application performance. You need to give the user the ability to load the page and seeing the progress of each element loading (so that he don't get bored while browsing). REST calls with JSON is recommended for this case.
Web-Applications these days make extensive use of Javascript, for example various Google Products like Gmail and Calendar.
I'm struggling to how NOT having duplicated logic server and client side.
When requesting a page or state of the application, i would prefer to send the complete UI, meaning: not just some javascript, which in turn makes a dozen ajax requests and builds the user interface.
But here lies the problem, the logic deciding what to show or not has to be written once in the server-side and once in the client-side language.
Then i was wondering if it was somehow possible to process your javascript logic server-side and send the whole to the client, who in turn can continue using the application with all the advantages of a responsive ui, but without disadvantage of the initial loading/building of the user interface due dependency of background ajax requests.
I hope the explanation of my problem is a bit clear, because i'm not the most fluent English writer. If you understand what i mean and if you can describe the problem a little better, please do... thanks!
So my question is:
Is something like this possible and or realistic?
What is your opinion on how to tackle this problem?
;-)
When we started our web app, we had the same kind of questions.
It may help you to know how we ended:
The backend (business logic, security) is totally separated from the frontend (gui)
frontend and backend communicate through JSON services exclusively
the JSON is rendered client-side with the PURE templating library
and the backend is Erlang (anything streaming JSON would be ok too, but we liked its power)
And for your question, you have to consider the browser as totally unsafe.
All the security logic must come from the backend.
Hiding or showing some parts of the screen client side is ok, but for sure the backend decides which data is sent to the browser.
Seems you describe Jaxer.You can write everything in JS. Also, there is GWT that allows to write whole thing on Java
Then i was wondering if it was somehow
possible to process your javascript
logic server-side and send the whole
to the client, who in turn can
continue using the application with
all the advantages of a responsive ui,
but without disadvantage of the
initial loading/building of the user
interface due dependency of background
ajax requests.
Maybe the apps you're looking at just use Ajax poorly.
The only content you can pre-process on the server is the content you already know the user wants. For example, in an email app, you could send them a complete view of their inbox, pre-processed on the server and fetched with a single request, as soon as they log in. But you might use AJAX to fetch a particular message once they click on it. Sending them all the messages up front would be too slow.
Used correctly, AJAX should make your pages faster, because it can request tiny updates or changes of content without reloading the whole page.
But here lies the problem, the logic
deciding what to show or not has to be
written once in the server-side and
once in the client-side language.
Not necessarily. For example, in PHP, you might write a function like displayWidgetInfo(). You could use that function to send the initial widget information at page load. If the user clicks the widget to change something, send an AJAX request to a PHP script that also uses displayWidgetInfo() to send back new results. Almost all your logic stays in that single function.
Your instincts are correct: it's bad to duplicate code, and it's bad to make too many requests for one page. But I think you can fix those problems with some refactoring.
I understand what you're saying.
But I don't think you should be having much 'logic' about what to build, on the client side. If you did want to go with a model like you're proposing (not my cup of tea, but why not), I don't see why you'd end up with much duplicated.
Where you would normally show a table or div, you would just output JavaScript, that would build the relevant components on the client side.
I would consider it just as another 'View' into your data/business logic model.
Have you go a small example of a problem you're coming up against?
I understand your question in this way:
Suppose we have an html form on web-page. There is a field for name and surname. We have to check it for validity both on client-side (with JS) and Sever-side (on php script while processing form inputs). So here is the duplication - regex check on both sides. So what is the way to prevent it and combing these logics?