Skip to main content

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.

Comments

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.
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.
Unknown said…
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.
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.
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.
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.
Andy said…
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
Anonymous said…
Wow all I can say is that you are a great writer! Where can I contact you if I want to hire you?
Anonymous said…
hi, new to the site, thanks.

Popular posts from this blog

Access multiple Databases in JPA

According to JPA specification we can define multiple "persistence-unit" elements (i.e. like below) in persistence.xml file and can easily refer them inside Dao layers as this. public class PolarDaoImpl {     @PersistenceContext(unitName="PolarPU")     protected EntityManager entityManager; -- } public class BearDaoImpl {     @PersistenceContext(unitName="BearPU")     protected EntityManager entityManager; -- } Checkout sample persistence.xml <?xml version="1.0" encoding="UTF-8"?> <persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">     <!-- Database 1 -->     <persistence-unit name="PolarPU" transaction-type="RESOURCE_LOCAL">         <

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

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