To load data or not to load data, that is the question…
I wanted to talk about a trend I’ve been seeing as a web developer lately. And by web developer, I mean strictly in the .NET space, meaning technologies like ASP.NET MVC and to a lesser extent, Web Forms. So what is this trend? I’m glad you asked.
The trend seems to be the move from server-side heavy development to client-side development involving frameworks like jQuery, KnockoutJS, Backbone and others. It used to be that the bulk of a web developers work would be on the back-end; creating the data layers, the business logic layer, and then throwing all that data to the client where it would get rendered. The page would be requested, and before sending anything to the browser, you’ve done a database call (or two, or three, etc.), constructed the data as needed to render, then send the entirely processed chunk of HTML to the browser. You might have some JavaScript on the client side to hide this or that depending on usage, but that was it. All of the business logic as well as the rendering of HTML happened on the server and was sent to the client. Even with MVC this was still happening, as views are processed to produce the proper HTML on the server, which is then sent down to the client.
But now, it seems like the back-end has become nothing more than a data repository, and the bulk of the work has been shifted to the client to process data and render it. What I’m seeing more and more (and what I’ve started to do in some of my own work), is when a page is requested, very little HTML is sent to the browser. I’ve seen some projects where the entire HTML for a given page was generated in JavaScript on the client, and the only HTML sent in the initial response from the server was a wrapper div or two. Everything else happened client side. Talk about dynamic.
Even now, you don’t even have to hit the database for any data when a page is requested. You can essentially send down a skeleton of HTML, and then when the browser gets the response, make an AJAX request to a service endpoint (WCF, old school ASMX, .NET Web API, choose your poison) to get a chunk of JSON, then construct the HTML you need from that. And I’ve been leaning more and more towards that method of web development. Why? Can’t really say for sure, at least not right now. It just feels right to do it that way. It makes sense to me.
It has prompted me to ask this question: Is it better to send data with the initial request, or make the request after the page has been loaded by the browser? That might not make sense, let me clarify a bit.
Let’s say you have an MVC project. You have a controller with an Index() action. At this point, you can do one of two things:
- You can go to the database to get whatever data you need, create a view model (if necessary), and provide a view name which processes the model to create the final chunk of HTML to send to the browser.
- You bypass the database, simply provide a view name which contains a skeleton of HTML, and send that response. When it’s received by the browser, you have JavaScript that makes an AJAX call to get JSON data from a service (or another controller endpoint), and then you process that JSON data to construct your HTML. Client frameworks like KnockoutJS and Backbone make this exceptionally (and in some cases, magically) easy to do.
So are there benefits to doing one over the other? I haven’t explored that question much and don’t have any insight/answers at this point in time. But I thought it would make for good discussion. I would like to get some feedback. Feel free to leave a comment with your thoughts.
The Life And Times Of Me 
The advantage of approach #2 (client-side rendering) is that a typical JSON payload will be smaller than the corresponding HTML. So if the javascript has already been cached by the client, there is potentially much less data transfer.
However if the javascript has not yet been cached, client-side rendering can perform worse because there are two round-trips to the server: one to get the javascript, then a second one to get the JSON after the JS has been downloaded and executed.
This is definitely a thing I’m doing lately–on WebForms no less 😉 To answer your question: I load data from the client since there’s really no point in doing the initial load from the server when the rest of the conversation takes place between JS client and web service; any infrastructure you create to do an initial server-side load is one-off in a system like that, so why bother? I’m still dropping some configuration and profile information into the view from the server side, so I’m not totally sure if this approach is buying me much (there’s a “model” concept on most of my component views, just not the service data that the client can get by itself).
I do NOT think that entirely client-side HTML generation is a good idea, though. Knockout templates and bindings make JS sooooo much more manageable than the “jQuery everywhere” approach. KO’s binding syntax is opinionated enough to give you an explicit border between model and markup, and that’s a really good thing from a testability standpoint, IMO. The “completely dynamic” approach usually varies so much from dev to dev that it becomes un-maintainable without draconian coding standards.
I’m trying to create KO viewmodels that don’t peform explicit DOM manipulation or use jQuery directly. By encapsulated DOM/jQ logic in injectable JS objects, I end up with viewmodels that can be safely unit tested on a generic VM without any browser dependencies. I have a solid background in server-side unit testing, and I’ve attempted enough UI automation that I know trying to unit test whatever you tell jQuery to do to your DOM is going to cost you more time and sanity than whatever quality it might by you in long run.
@tehinterwebs, I agree with your statements about “entirely client-side HTML generation”. Some of the code I’ve seen do that is just… ugly. It’s basically string concatenation of HTML and it’s just unwieldy and, well, ugly. I mean, it works, and if you keep to a consistent format and process for doing it, then more power to you. But adopting a Knockout style process is much cleaner and a lot easier to debug/read when you have to dig into it..
And the anonymous poster brings up a very good point. A request for a JSON payload can be many times smaller than an entirely rendered HTML page. A great reason to go client-side.
(I’m the anonymous poster)
I actually think the 2nd round-trip for client-side rendering is a worse problem than the increased HTML size. With most wireless networks, latency is a bigger problem than bandwidth. And with most wired networks, everything is super-fast anyway.
This is definitely a very popular approach to web development these days and I think it is really pretty cool in a lot of ways. As with all architecture, there are some trade-offs to consider though. Here are a couple to consider for this strategy:
1. SEO is critically hindered by client side page generation. Most current indexing only takes the initial page load into account and does not deal with subsequent updates of page content. If SEO is important to your site, you should definitely consider at least a two pronged approach where data is loaded server side into the DOM and then updates are handled dynamically. It’s possible the explosion of single page apps will cause search engines to find a way to deal with this, but for now it’s kind of a deal breaker I think.
2. Where do you put your business logic? If your services are purely CRUD, you’re going to end up implementing all of your business smarts in javascript which makes the lines between model and view a bit more hazy. If your server calls are more semantic you can avoid this pollution of client code, but it requires a bit of vigilance (see how I abused the English language there?)
3. Security is a pretty serious consideration as well. If you end up with more and more business code being executed client side, you increase your application’s surface area for attack. Any business rule client side is fair game for manipulation, so you are left with recreating all validation and business rules on the server side as well. Again this is mitigated by semantically correct service calls instead of a purely CRUD approach.
Really 2 & 3 aren’t related to initial load approach as much as just to SPAs in general.
4. Would you rather write more JavaScript or more C#? Just sayin :).
It sure would be nice if they built a convenient way to do the two pronged approach into MVC5. That would give you the best of both worlds I think.
Great topic, thanks!