Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I come from an ASP.NET forms background and have found server side coding very powerful in the past. More recently, however, I have been wanting to phase out the server side code of the front-end and replace it with pure HTML/JavaScript, which accesses the data through JSON webservices. I have no real experience in this, and so I would like to hear whether this is a tried and tested model. Also, what are the pitfalls surrounding it?

I find ASP.NET user controls very useful, so I would like to keep the theory behind it by storing markup templates in separate HTML files on the server. These will be retrieved and used through jQuery AJAX and the jQuery HTML templates plugin respectively.

Any input will be extremely appreciated.

P.S. Sorry for the noob question, but is this type of Web architecture what is referred to as web-2.0 or am I completely off-track?

share|improve this question
1  
Do you want to replace asp.net controls with HTML/JavaScript or do you want to expose entire business logic (validation, etc.) to the front end? –  šljaker May 5 '12 at 23:15
1  
Good question. I'm thinking of doing the frontend in only html/javascript in order to lighten the page so that it is quicker on mobiles/pads. So probably just replace asp.net controls. All calls to the server through a webservice, so the wcf service should somehow deal with the validation etc. Do you think this is possible? –  hofnarwillie May 5 '12 at 23:22

5 Answers 5

up vote 25 down vote accepted

I have used this technique exclusively for a web application we're working on. My backend is hosted on Google App Engine using the Java SDK, and my frontend uses HTML, CSS, and JavaScript (with jQuery).

The project is a smaller one with just myself and a Web designer, and we both feel that this method has helped us work a lot faster and get something to market much sooner.

Advantage: Working with Web Designers

The major advantage of this technique is that the Web designer, who knows some PHP but does not consider himself a programmer, can work unencumbered in the HTML and CSS without having to wade through countless lines of JSP, taglib tags, and other server-side markup that we've been told for years is supposed to make a front-end developer's life much easier.

Without all of the server-side markup, we've been more agile. The web designer has directly swapped out and revised his original design 3 or 4 times, with very few changes on my part.

His comment to me was that he felt like the HTML was alive in that he could edit it and then immediately see the changes on his machine with dynamic data. We've both benefit by this in that the integration is mostly automatic.

Server-side code and HTML/CSS Handoffs

In past projects, he's had to handoff the HTML and CSS to Java developers who would then take his HTML and CSS and completely rewrite it using JSP technology. This would take lots of time, and would usually result in subtle yet important differences in the actual rendering of the pages as well as it's validation in the W3C validator.

Overall, we're both quite happy with this technique, and I still have zero JSP pages or server-side code in my HTML pages.

Pitfalls of the REST/JSON Technique

Perhaps the biggest pitfalls are ones that we haven't encountered yet. I fully expect to have some disagreements with more experienced Java developers who have been brainwashed by what the Apache foundation and the Spring team have told them regarding how tag libraries make it easier for frontend developers to work with the code. I fully expect there to be a learning curve as this project expands and we take on more developers who might have to unlearn these outdated techniques that, in my experience, have made the Web designers' job more difficult.

Another pitfall is that the JavaScript code has become very massive. This is more of a problem perhaps because I'm using this technique for the first time, and because we've introduced some slight technical debt in working towards a rapid release. Perhaps picking a better framework would have helped alleviate a lot of the bulk of the code. In my opinion, none of this has been a showstopper, and I'm encouraged to continue using this technique and refine my skills in this area.

Advantage: Other Applications Can Be Built On the Platform

Lastly, I should mention a hidden advantage. Because there is a nice degree of separation between my backend RESTful Web services and my frontend, I've also created a platform that I can easily extend.

One of our operations guys wanted to try a proof of concept in another application, and thanks to my RESTful services, we were able to create an entirely different frontend to the application to solve a completely different problem. The rapidly developed proof of concept used it's own HTML, CSS, and JavaScript, but it used the RESTful services as the backend and datasource.

In the end, another project manager saw what I had done, and it became immediately clear that the feature needed to be more than just a proof of concept, so his team implemented it.

I can't emphasize enough how reusable this architecture is, both at the application level as well as the HTML/CSS/JavaScript level, and I would definitely encourage you to try this in your next project.

share|improve this answer
1  
Thank you. This answers my question completely. Appreciate the time you took in giving a clear and concise answer. +1 –  hofnarwillie May 6 '12 at 13:19
2  
I work in a company where the entire internal web applications is html/js only with backend services that serves json encoded data.This works really well and is much faster to create new apps using this model, and because the backend and fronted developers works in parallel. You should really try this. –  nohros May 6 '12 at 20:24

It is certainly a viable strategy, but it's not a silver bullet.

Pros:

  • if done right, applications developed this way are very responsive
  • you have a clear separation of logic (on the server) and presentation (on the client); the server doesn't have to concern itself at all with the presentational aspects of the application
  • potentially more efficient use of network bandwidth (you are only sending raw data, no presentational boilerplate)
  • easier to develop desktop-like GUIs, since you're less dependent on the request/response paradigm

Cons:

  • you have to write your client code in Javascript, or a language that can compile to Javascript, because that's the only thing available in a browser
  • resource usage on the client may be higher, so the application may not work well on substandard devices (think mobile browsers etc.)
  • it won't work at all with javascript disabled; if it is have a public-facing website, you have to think hard whether you are willing to take this risk (especially if you consider SEO and accessibility - a javascript-heavy approach is usually devastating on these two fronts)
  • a lot of logic has to be written twice: once on the client, and once again on the server (because you can never trust the client)
  • concurrency can be a hell, so you need to design your client-side code very carefully and be prepared for all sorts of concurrency issues
share|improve this answer
1  
Thanks. Can you give an example of the concurrency issues that would be caused by this model? –  hofnarwillie May 6 '12 at 15:34
    
+1 for the concurrency awareness. –  Richard Aug 19 '13 at 15:30
3  
Example: If the user clicks Vote Up and then quickly clicks Vote Down before the Vote Up server call has finished, how many votes are there? –  JBRWilkinson Jul 16 at 23:09

Its definitely possible, and probably encouragable as best-practice. What you're proposing is splitting the UI from the business logic so there is a clean separation of concerns. This is really good.

Too often the frameworks we have try to muddle things together and you end up with a monolithic piece of software where the UI, the business logic and the data are all intertwined with each other. That makes it more difficult to maintain and modify.

Once you split the application into 2 pieces, you can replace the UI completely with something else - a desktop program, or another UI for mobile compared to desktop browsers.

The tricky bits you'll find when doing this is that a little bit of code that theoretically should be in the server would be better placed on the client - validation for example, its faster and more responsive for the user to put validation code on a form on the client than it is to hit the server to check, say, a text field only contains alphanumeric characters. The same often applies to data and business layers. You just have to make informed and practical decisions about when to violate the distinction between the layers.

share|improve this answer
    
Thanks for the comments. –  hofnarwillie May 5 '12 at 23:57

If you're still using ASP.NET WebForms and want to speed up your applications, here's what you should do:

  • Design your application with SOLID in mind
  • Disable ViewState on all pages and user controls
  • Don't use server side controls

    <%: VeiwModel.Title %> instead of < asp:Literal id="Title" runat="server">

  • In backend, override OnInit method and do all the initialization there:

    protected override void OnInit(System.EventArgs e) { CreateViewModel(); base.OnInit(e); }

  • Compress all .css and .js files into 1 using SquishIt

  • Lazy load images
  • Cache complex objects

Finally, check out www.porsche.se. Isn't that a damn fast website?

share|improve this answer
    
That really is a speedy website. Thanks very much for the input. Much appreciated. –  hofnarwillie May 6 '12 at 13:14

One downside is needing to duplicate some of the logic in JavaScript and ASP.net. This might not be a big issue for you depending on your application. It often comes up because you don't want to have to ask the server to check every little thing ("Is the user allowed to press this button or select this option in this situation?") but you also don't want to depend on the client as the only one doing validation since the user has control over the client.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.