[kls]

We use HTML / CSS / and JavaScript exclusively for our front ends. We no longer use any intermediary or server bound languages such as PHP or JSP. We have found this to be faster to develop and more portable across back ends. If you decide to go the Java route for your back end I would use JAX-RS and EJB 3. With EJB 3 you can use a tradition DB and not have to worry about all the mapping that generally has to take place with the tradition relational model. Netbeans has pretty good tooling around JAX-RS and EJB 3 in which you can generate your REST service and entity classes from you database structure or generate your database structure and REST services from you entity model. Either way, you can have a working REST service layer up in a matter of hours with Netbeans tooling, it is quite nice.

As for the front end, if you are going to be building a large scale web application I would suggest adding Backbone and a few other libraries to your JavaScript library or going with Dojo. Either way you are going to need something to keep your app organized if it is going to be anything more than a few hundred lines of code.

[keefe]

Overall I agree, preferring a ReST model with JSON. I do use java and i'm not particularly excited about JAX-RS (never used) or EJB3 (have used) . If I recall properly, then EJB3 merges with hibernate which I have used a lot, so it's not a bad choice. I use the gson parser for object<->json mapping. Overall, I think this is a solid style because it enforces MVC and scales nicely for everything but seo.

[hrasm]

I am very interested to know how you gracefully fallback to noscript mode. I am asking because I am in the process of building something that does fallback gracefully in noscript mode. It is extra work no doubt. Is it really worth it? Would love to hear your thoughts on this.

[kls]

No it is not worth it in 90% of our cases, we monitor traffic religiously and you greatly compound your cost to chase what (according to out stats) is less than 5% of the market, when you compound that by the fact that you are not going to convert that entire 5% the numbers are dismal for adding the cost and complexity to a project.

We have found that one average that building in fallback modes adds 15% to 20% of cost and time to a project. We have also found that that money roughly equates to a mobile version of the web front end, which we see a higher market conversion percentage, in other words, that money would be better spent chasing mobile or adding features and revenue streams to an existing web app, than to chase a dwindling market of last gen technology adopters.

When a client of ours absolutely insists on providing a noscript site for that segment, we tend to opt for browser sniffing and segmenting that traffic to a completely separate site built for those clients. We have found that keeping the noscript version and the full version separate greatly reduces the maintenance cost of both.

[hrasm]

Thanks for the informative response. Redirecting clients to separate site is a nifty idea. I might do just that.

[manish_chhabra]

Thanks