Why Java Web Application UI lags ?

I've worked on more than 2 Dozen Java Web Applications in different companies and with various teams and every time I felt these applications lagged in UI compare to PHP applications. Don't get me wrong I'm trying to understand and find solution to problems what I'm seeing and I could easily learn from your exposure and experience or may be we all can understand whats happening.

Though most of the teams I've worked with were extremely talented and we wrote huge large scale applications and in fact we also had UI experts on these projects, then why couldn't we write great UI?

I feel there are two reason's for this firstly these teams are dominated by Java guys who mostly like working on server side code and they really don't enjoy working on UI and they spend enormousness time fixing performance, and other server side issues which hardly are issues for some project for an example in one of my project we spend weeks trying to fix application performance which is hardly used by 10 users per day.

Secondly most of the Java Web Applications use MVC frameworks such as (Struts, Spring MVC, JSF) and these framework requires java knowledge so most of the UI is written by Java Developers but most of people would argue that there is no harm in doing this. Though I feel there is a small issue with this practice that is since UI is written by Java Developers and they tend to use Tag Library which makes code unreadable for most of the UI Experts and hence there contribution is restricted.

If my above arguments hold good then this is what I can think of improving the situation

Let UI Experts own and create HTML pages, CSS (rather JSP pages and MVC) and use Javascript framework of their choice or company standard(JQuery, DOJO, YUI etc) and hook them to Server side components using JSON (DWR), REST (RESTFul Services) or POST (MVC Framework without Tag Libraries).

I feel we can take out lot of benefits by doing this.
1. UI Experts can parallel work on UI and that will give then a sense of ownership and we can see the results
2. Server Side guys can spend good amount of time on there domain of choice and be more productive.

JPA 2 new feature @ElementCollection explained

@ElementCollection is new annotation introduced in JPA 2.0, This will help us get rid of One-Many and Many-One shitty syntax. Example 1: Stores list of Strings in an Entity @Entity public class Users implements Serializable { private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @ElementCollection private List<String> certifications = new ArrayList <String> (); public Long getId() { return id; } public void setId(Long id) { this.id = id; } public List <String> getCertifications() { return certifications; } public void setCertifications(List <String> certifications) { this.certifications = certifications; } .. } Users u = new Users(); u.getCertifications().add("Sun Certified Java Programmer"); em.persist(u); Generated Tables Users Co

Validating CSV Files

What is CsvValidator ? A Java framework which validates any CSV files something similar to XML validation using XSD. Why should I use this ? You don't have to use this and in fact its easy to write something your own and also checkout its source code for reference. Why did I write this ? Some of our projects integrate with third party application which exchanges information in CSV files so I thought of writing a generic validator which can be hooked in multiple projects or can be used by QA for integration testing. What is the license clause ? GNU GPL v2 Are there any JUnit test cases for me checkout ? Yes, source How to integrate in my existing project ? Just add the Jar which can be downloaded from here CsvValidator.jar and you are good. Instantiate CsvValidator c onstructor which takes these 3 arguements // filename is the the file to be validated and here is a sample // list - defines all the fields in the above csv file ( a

Reuse JPA Entities as DTO

Note : Major design advantages of JPA Entities are they can detached and used across tiers and networks and later can by merged. Checkout this new way of querying entities in JPA 2.0 String ql = " SELECT new prepclass2.Employee (e.firstname, e.lastname) FROM Employee e "; List<Employee> dtos = em.createQuery(ql).getResultList(); The above query loads all Employee entities but with subset of data i.e. firstname, lastname. Employee entity looks like this. @Entity @Table(name="emp") public class Employee implements Serializable { private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @Column private String firstname; @Column private String lastname; @Column private String username; @Column private String street; @Column private String city; @Column private String state; @Column private String zipc

Unknown said…

I can agree with this. It seems like a framework like Wicket should be able to make everyone happy. You have fairly plain HTML for the UI guys and the server side is "real" Java. It eliminates all of the issues of request/response in a clean way so you can just focus on solving the problem and not working around the web paradigm.

September 6, 2010 at 5:41 PM

Steve Love said…

Having worked as a UI developer on both PHP and Java applications, I can say that your proposal works well in my experience. Still, one of Java's biggest downsides from a UI perspective is that it has to be recompiled every time you make the slightest code change, so it inevitably takes longer to debug UI/design issues.

September 6, 2010 at 7:44 PM

You are right and wrong, right because using others languages and designers would be better in all way, like better UIs and faster, the problem and it's a big one, it's called "Portability and Scalability" that no one of those languages have it, apart from Java, due this is easy use Java to create the client side either, apart that you can have small teams and homogenous, rather than PHP guy that don't understand how the server works and how to send the objects, and all sort of communications gap that might exist. If it's not enough there are that the same guy that is average with UIs might enhance the system in both sides (Client and Server), anyone can say that having development in layers and using one very structured waterfall methodology would work, though with more than 20 year in IT, I'd never saw one work like that, even into the big blue, and the world today is being dominated for Agile methodologies and most recent Craftsmanship that looks like will put on end in the mess that is IT sector today, with PMs that doesn't know anything about technologies those ones that just choose IT because exist plenty job offer and those ones that does not want keep up date with the IT wave.

September 6, 2010 at 8:51 PM

Andy said…

Inversely, doesn't that also mean that PHP suffers from having more UI-type guys working in pages that contain code as well?

While Wicket claims to allow 'readable' html source pages that look like actual html pages, it also advocates re-use and componentization which means that most of the visual elements come from different pages which aren't visible when you look at the source page as HTML.

September 6, 2010 at 9:55 PM

Anonymous said…

@Andy: I disagree with your generalization about Wicket that "most of the visual elements come from different pages". True, you can go for a "single page" web-app approach and swap in and out components and some people like that flexibility. In my experience, "most of the visual elements" are within the source page itself.

That said, nothing stops one from looking at the HTML that backs a given component. You can even choose to extend given component and supply the HTML yourself.

September 6, 2010 at 10:57 PM

Shantanu Kumar said…

For web templates, instead of JSP consider using StringTemplate: http://www.stringtemplate.org/

I would also suggest to take a look at Taimen: http://code.google.com/p/bitumenframework/

Taimen is a micro-framework for Java web development, and has example applications to demonstrate how to use.

September 7, 2010 at 12:28 AM

I meant that when you look at the page.html for a page, if it has different templates and parts and pieces and wicket borders, it will look nothing like the actual page since a html viewer knows nothing about how Wicket replaces wicket markers with html. Ergo, unless you are using simple pages with little or no templating, you still can't view the source page as readable html

September 7, 2010 at 7:29 PM

Wow all I can say is that you are a great writer! Where can I contact you if I want to hire you?

December 5, 2010 at 5:15 AM

hi, new to the site, thanks.

February 26, 2011 at 4:50 PM

Intesar's blog

Search This Blog