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

Phil H 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.
Klaus Villaca 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.
ptrthomas 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

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
Column --> ID
    Row             1

Users_CERTIFICATIONS

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 constructor 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 field has index, type, isOptional, rege…

ArrayList vs LinkedList vs HashSet Performance Comparision

ConclusionsInserting & Reading sequentially from Collection prefer LinkedList/ArrayListInserting & Reading/Deleting by Search/equals from Collection prefer HashSetInserting, ArrayList & LinkedList performs best while HashSet takes double the timeReading, HashSet performs best while ArrayList & LinkedList are marginally lessDeleting, HashSet performs 10 times better than ArrayList & ArrayList performs 4 times better than LinkedList. LinkedList is slow because of sequencial search Bottom line : unless you are not going to iterate using for(Integer i : list ) then prefer HashSet
Inserting/Reading/Deleting integer's from zero till countJDK7Collectionactioncounttime msArrayListInsert1000/1LinkedListInsert1000/1HashSetInsert1000/1ArrayListInsert100005LinkedListInsert100004HashSetInsert100007ArrayListInsert10000011LinkedListInsert10000011HashSetInsert10000021ArrayListGet/Read1000LinkedListGet/Read1000HashSetGet/Read1000ArrayListGet/Read100004LinkedListGet/Read100003Has…