Pure Front end JavaScript with Web API versus MVC views with ajax

Question

This was more a discussion for what peoples thoughts are these days on how to split a web application.

I am used to creating an MVC application with all its views and controllers. I would normally create a full view and pass this back to the browser on a full page request, unless there were specific areas that I did not want to populate straight away and would then use DOM page load events to call the server to load other areas using AJAX.

Also, when it came to partial page refreshing, I would call an MVC action method which would return the HTML fragment which I could then use to populate parts of the page. This would be for areas that I did not want to slow down initial page load, or areas that fitted better with AJAX calls. One example would be for table paging. If you want to move on to the next page, I would prefer it if an AJAX call got that info rather than using a full page refresh. But the AJAX call would still return an HTML fragment.

My question is. Are my thoughts on this archaic because I come from a .net background rather than a pure front end background?

An intelligent front end developer that I work with, prefers to do more or less nothing in the MVC views, and would rather do everything on the front end. Right down to web API calls populating the page. So that rather than calling an MVC action method, which returns HTML, he would prefer to return a standard object and use javascript to create all the elements of the page.

The front end developer way means that any benefits that I normally get with MVC model validation, including client side validation, would be gone. It also means that any benefits that I get with creating the views, with strongly typed html templates etc would be gone.

I believe this would mean I would need to write the same validation for front end and back end validation. The javascript would also need to have lots of methods for creating all the different parts of the DOM. For example, when adding a new row to a table, I would normally use the MVC partial view for creating the row, and then return this as part of the AJAX call, which then gets injected into the table. By using a pure front end way, the javascript would would take in an object (for, say, a product) for the row from the api call, and then create a row from that object. Creating each individual part of the table row.

The website in question will have lots of different areas, from administration, forms, product searching etc. A website that I don't think requires to be architected in a single page application way.

What are everyone's thoughts on this?

I am interested to hear from front end devs and back end devs.

Answer 1

I'm also somewhat skeptical that every new web app needs to be an SPA but one thing I'm 100% sold on as a generalist with the bulk of his experience on the client side is that a service-oriented architecture that hands off raw data rather than HTML to the client is the way to go whether you're loading prebuilt pages/views from the server and doing a lot of dynamic stuff with data after page load or building almost everything 100% with JavaScript.

The reasons this is preferable to a client-side dev are much the same as the reasons nobody wants HTML in the database. What's the client-side dev supposed to do when they want to resort a table for instance when they've been handed HTML? The performance cost of handling all that on the client is trivial compared to making another server request to do that for you. Also, HTML-building is pretty well-covered in JS-land. Sorting data and building new HTML table rows out of it is pretty trivial work for an experienced client-side dev.

And of what use is the back end architecture to a front end for another device that might need to do something exotic like implement widgets that are 100% canvas or a totally different HTML structure? Why should a client-side dev have to load up visual studio or knock on the back end devs door to make a strictly presentational tweak?

As for your concerns about the loss of strongly typed template validation, trust me when I say that if you're dealing with a competent client-side dev, you will find no .NET framework or visual studio tool that is more coal-to-diamond-to-dust-crushingly anal about well-formed, valid HTML than s/he is.

From the full-stack perspective, I like it because it means I'll never have to fish for business or app logic some yutz decided to drop into the templating layer. Not to mention the per-user load it takes off of your servers while in many cases actually improving load experience for the user in modern browsers with modern computers.

I think it's also easier to reason about the back end architecture when you've fully isolated it from all the presentation stuff. You're no longer grabbing data to mash it into some HTML. You're pulling it together to create an implementation-independent data structure that concerns itself more with general use than what's going to be done with it on the other side. IMO, that tends to lead to more consistency in how things are handled since the data is now an end goal rather than the second to last step of a process and there's fewer opportunities for unrelated concerns to get their wires crossed.

Answer 2

I'll offer my highly subjective 2 penny worth (for what it's worth ;)). There isn't a right or wrong answer to this and there are many real world considerations in addition to your points, for example:

• Do you have the relevant experience in house? building a client side driven app is very different to a predominantly server driven one with a completely different skill set.
• How long do you want it to take and which browsers do you need to support? - the more you do on the client the more browser issues you'll face; IE8 is painful and JavaScript performance is quite poor, but there there are a lot of businesses running XP/IE set ups.
• What devices are your users going to be viewing the site on? JavaScript parsing and running may be fast on a recent version of Chrome - but it isn't on an older mobile device, especially not a large amount of JavaScript with a load of business logic in it
• How important is initial load? Server templating is faster than client templating

This list is by no means exhaustive and sounds like a client side bashing which isn't my intention, I've made sites with a heavy emphasis on the front end end.

For me it really comes down to user experience and API re-usability. To address each of these.

If you are going to be making an app or offering an API, there's a lot of sense in using a .Net API project, this then forms the logic, checking and implementation cross platform. In this scenario a complete client side approach may be favourable, the API can be maintained separately and just provides an interface to your application. You can amend the logic and refactor comfortably and just have to keep the interface the same. You can easily write different applications for different media all using the same background code.

The strongest argument for a pure front end solution (in my opinion) is that of user experience.

Does (when considering all the downsides) a pure JavaScript browser application offer a substantial improvement on usability and user experience on a traditional website?

When creating sites that work like native applications; I'd argue the answer is an obvious yes. Most sites however aren't this clean cut though, so it's a matter of assessing whether individual user workflows benefit from a highly dynamic interface.

I take a fairly pragmatic view of this, it isn't an either or matter; JavaScript will obviously play quite happily along with Server technologies and you don't have to choose one or the other - every site isn't a single page web app - but there's nothing stopping you using Knockout, backbone and the suchlike on individual pages to improve things where it's deemed necessary.

Answer 3

I have a love-hate relationship with front end heavy applications.

On one hand, I love writing JavaScript and I love the browser as an execution environment.

On the other hand, both feel like a Formula 1 race car with holes in the engine. It really boils down to this: Can you prevent duplication of business logic between C# and JavaScript? If so, use whatever method for generating the view you deem worthy. If you are duplicating business logic in two languages, you may have a front end developer who just wants to write JavaScript, and doesn't quite see the big picture.

As for technical differences:

Rendering a partial and delivering it to the client:

• Easy and fast to implement
• Prevents backend business logic from being duplicated on the front end
• Can result in a much larger HTTP payload to the browser. Not a bad thing on a desktop with a high bandwidth connection. Very bad on a weak mobile phone whilst you are sitting on a rush hour train speeding down the track at 60mph and 1,000 other mobile phones are simultaneously disconnecting from one cell tower and trying to reconnect to the next cell tower.

Delivering JSON and rendering a client side template:

• Can result in a smaller HTTP payload than HTML, which can make the application seem more responsive over unreliable or slow network connections
• Many JavaScript templating languages are fully featured, meaning we don't need a backend just to generate some HTML

Sometimes I think the newer JavaScript frameworks are throwing the baby out with the bath water --- man I hope I'm not becoming a grumpy curmudgeon programmer...

Answer 4

In my last application I combined REST api and JavaScript front-end.

What I did was :

• I created a REST API for CRUD operations.
• I created a Javascript application that loads pre-defined HTML templates and populates with data returned from the REST API.

Basically the JS front-end communicates with REST API for CRUD operations and populates the HTML's with the returned data or created data, or removes the deleted data or updates changed data.

Thus we have pure HTML, we have the processing done on the client, we have less bandwidth usage by not having to load all the HTML and can give an experience truly Web 2.0 to the users.

I do not do business validations on the front end for safety and code duplication, since anyone can change the data before sending them to the server and we have to validate the data on the server again. Therefore, this would be easily hacked. All validations are done on the back-end. Validations on client-side are made ​​only for types of input.

Pros:

• Facility to make changes in HTML due to the fact it is not generated by JS;
• Lower consumption of bandwidth by using ajax and JSON;
• Lower consumption of server processing, since HTML is populated on the client side;
• Improved user experience by using JS to change the screen, allowing use of effects and increasing the rendering speed.
• Better use of the HTTP protocol, by using REST.

Cons:

• 2 applications to be maintained;
• Depends on the client processing, which can be bad due to poor hardware.

Hope this helps.

Regards,

Answer 5

Regarding the validation aspect in Web Api - It is possible to do "model validation" and respond with a 400 bad request http response.

Refer https://stackoverflow.com/questions/11686690/handle-modelstate-validation-in-asp-net-web-api/25050285#25050285