Pros and cons of an HTML/JavaScript only web app [closed]

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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?