Enterprise Integration Zone is brought to you in partnership with:

I Started programming in high school and then when I was 16 started coding in C, didn't do much C++ but instead hopped on Java ship. It is complex engineering and art of balancing multiple factors that keeps me warmed up and makes me passionate about what I do. If I want to describe engineering, I would say it is an art and an engineer is an artist. Currently I am a Senior Consultant in Cignex Technologies architecting and leading open source Portal and ECM solutions. Ali has posted 2 posts at DZone. View Full User Profile

Why is Web UI Development Slow?

07.19.2008
| 31487 views |
  • submit to reddit
Have you ever been a team member in a web framework or web product development? You may have noticed although UI prototyping is a fast process but UI integration is disappointingly slow. Have you thought why does this happen? Is it because of not using MVC design pattern and templating technologies? Is it because of poor code quality, tight time frame or ever changing requirements?

To answer the above question, I would say it is more because of the sluggish process of inserting the framework components and tags into the UI pages. Especially when you try to see the changes as the UI is being translated inserting MVC tags and components into the view pages. As many of us have experienced UI designers and usability people can freely preview UI pages as they are being built. Well, at the other hand you may have noticed that a developer can only preview the translated UI pages when they are served by an application server. That really slows down the process. Each time you should wait as the application is built and deployed, again wait for the app server to come up and then finally checking your change. That is just a waste of time, sucks, nah?

So let’s talk about a solution to make the UI construction faster and easier? In this post I am going to introduce the first part of new discipline for UI development by smart manipulation of the existing technologies. That is true, no new technology.

I have learned in time that solutions must be simple not complex; complex solutions are always more error prone than the simple ones. To realize the necessity of the change for UI construction let’s answer to the questions below:

  • What if UI designers could develop UI separately from developers and test them with mock data?

  • What if UI designers could still leverage from easy preview features of their IDE’s while constructing the final UI pages using only HTML, CSS and Java Script?

  • What if backend developers could integrate the UI to their code simply by introducing some touch points (Think of touch points as URLs, yes I mean RESTful API here)?

  • What if the developed UI could be interoperable and be easily integrated with any backend technology like Python, .Net, Java, etc. (Relying on XML and Ajax for interfacing)?

Well, we can continue with questions but I think it is better to see how they all could be possible. It is simple just follow the following steps:

  • Avoid using any non HTML tags (JSF, ASP, JSP, Struts, etc.) in the view layer pages; just use plain HTML with Java script. This helps for faster development and easy page previewing during construction. Simply there will be no need to wait for the app server to be restarted or even waiting for hot deployment.

  • During unit development and testing, simply test the UI with some static mock data, whether it is text or XML. I personally recommend using XML for complex data types. It is better for standardization and reusability and extensibility of your code both in the backend and front end.

  • For any Ajax based component follow a consistent RESTful API. It means that in the backend the integration points should provide XML based RESTful APIs. This helps the ultimate view layer abstraction from the backend technology. This would also lead you to become adaptable with future ESB, SDO and Metamodel integrations.

  • Try to package and proxy XML de-serialization and parsing in reusable and reconfigurable Java Script functions. As an example, study Dojo, JSON, JQuery, etc. In fact, there are frameworks like IceFaces or DWR that perform XML to Java Script data serialization and de-serialization out of the box. Eventually, after creating a dozen of such reusable and reconfigurable functions, then most of your new requirements would be satisfied by an already developed function.


Basically, there is always a tendency that opposes any direction or discipline change from the current state to a new and unexplored state. To dumb it down, there is inertia for quitting the View chunk of the MVC technologies, and simply hopping on this UFO. In fact, this discipline is not a new technology. Instead, it is a simple trick for accelerating the development process by abstracting the view layer from the underlying ones and making it more interoperable, cluster-able, cache-able and reusable. The Lego parts have always been there and this time we are not playing based on the given plot, but we want to play it above the age limit.

Indeed, I have to elaborate this discipline more and describe it by tangible and solid examples. I believe each of the bullets above could be a post for itself. I will definitely expand them with detailed and comparative samples in the coming days.

By the way, I am looking for a name for this discipline, what about MASK?

References
Published at DZone with permission of its author, Ali Loghmani. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Geertjan Wielenga replied on Sat, 2008/07/19 - 9:05am

What about Wicket?

Schalk Neethling replied on Sat, 2008/07/19 - 9:22am

Speaking from a Java and Rails perspective, unless you have made significant changes to the back-end code there is no need to hot deploy or restart your app to see changes to the UI. If you are simply hooking in the UI then making the changes to your UI and refreshing the page will do the trick.

Jacek Furmankiewicz replied on Sat, 2008/07/19 - 9:57am

Have you tried Python's Django? Learning it now, feels fast and great...

Bruce Fancher replied on Sat, 2008/07/19 - 11:56am

Hello?  Wicket?  Tapestry?  WebObjects?

Ron Grimes replied on Sat, 2008/07/19 - 12:38pm

"What if UI designers could develop UI separately from developers and test them with mock data?"

What? You have a UI designer? Lucky guy. I'm expected to do UI design, front-end development, middleware development, and back-end host development. I suspect a lot of us have to develop web apps from front to back as many organizations are cheap.

"Avoid using any non HTML tags (JSF, ASP, JSP, Struts, etc.) in the view layer pages; just use plain HTML with Java script. This helps for faster development and easy page previewing during construction. "

This is the biggest time waster in developing web apps: coding with HTML and JS, trying to accommodate cross browser issues with all its inherent problems. Why choose an environment where you are going to have to test it our in a variety of browsers and versions? That process, in and of itself, is going to create a development model that is going to take longer from the start, and your're going to have to go back and revisit when someone comes out with an update that screws your scripting (think cross-frame scripting after SP2 or IE7 making it so you have to click in the blank area after your menu item instead of on the text itself, etc.).

I gave up on developing in HTML years ago, after a decade of constantly adjusting to new browsers, departures from W3C standards by Microsoft, coming out with updates that suddenly make things that used to work no longer functional. For me, if you want to speed up development, HTML and JS is NOT the way to go, if you need to do anything complex like handling the idiosyncrasies of how different browsers need attachEvent coded. We switched to Flash and Flex on the client side, which, in and of itself, makes me look like I am actuall a fairly decent UI designer, besides completely getting rid of cross-browser pains in the a**. Flex truly delivers "write once, test once, run anywhere". Plus, it has automatic data binding to screen components and hides a lot of how you're communicating to the middleware services.

So, why develop another model based on HTML and JS? I don't get it.

R. Grimes

 

Dean Del Ponte replied on Sat, 2008/07/19 - 3:14pm

Grails will speed up development!

Ali Loghmani replied on Sun, 2008/07/20 - 1:55am in response to: Bruce Fancher

WooHoo,

The Technology Tags and components removal from the UI pages does not mean to get rid of th MC part of the MVCs. Actually, all the Tapestry, Wicket and WebObjects tags bring complexity to the projects. This is really controversial to say that. To describe it better, let me come up with an example. Imagine that you need to have an ajaxified gird with sortable and valitatable columns. This is not what you can do easyily with the said technologies. In fact, once I was involved in a project that we had to develop such a grid on Struts, using DWR, Spring and Velocity for templating. It became such a great struts tag, but so many technologies were wired together to make it possible. Besides it was so much developed into Struts and DWR. Guess what, that tag is only for Struts, not reusable as is, wiht other technologies, say JSF, Wicket , etc. 

Finally, my point is to be able to exploit less expensive UI developers to come up with fancy and ajaxified UI components (Using Javascripts, it is still payable). At the same time you can have your developers to dig in the backend instead of wrestling with micky mouse UI problems (A developer is paid for the right job not HTML gluing). Besides componets developed by the disscussed discipline could be easily wired to any technology, any MVC (better I say MC).

I do not want to unveil the next post of this serie here, but I would elobarete it more.

Ali Loghmani replied on Sat, 2008/07/19 - 10:30pm in response to: Geertjan Wielenga

Although Wicket is a clean one but still you have to use the tags in the UI pages.

Ali Loghmani replied on Sat, 2008/07/19 - 10:38pm in response to: Ron Grimes

Hey,

I love Flex too, I was the lead developer for the new Activion's WCM. Indeed I was responisble for delivering the entire XML data for the flash compoents. But guess what, HTML and java script is ruling the web so dominantly. Besides the entire MVC's and UI technologies with every nitty gritty XSTL, XSL, Velocity or other templating technologies try to generate HTML, CSS and Java Script. 

Browser compatibility has been always there but there is always a solution to that. BTW, if you are a part of 10+ people project then you should have either a UI designer or have it out sourced.

Ali Loghmani replied on Sun, 2008/07/20 - 12:05am in response to: Schalk Neethling

For Simple projects with few people, it is not really a big deal. Just look at your team and the knowledge baseline, choose a technology that they know and hit the ground going. But, if it is a bigger project and you can pay for the learning curve or interviewing and hiring issues then it is time to do some good assessments.

Another aspect of this idea is to let peolpe to generate really reusable and sellable components on the web. There you can find so many payable JSF or Struts custom tags, but what about a really fancy wicket one. With Rails or even Grails you can make phenomenal stuff but they will be wired to the backend platform. The other thing is that not everybody can pay for behemoth tools like Oracle's ADF.

Finally, if you as a company want to have a pool of reusable UI components yet do not want to chain yourself to any of the ever evolving and changing UI technologies, so it is better to MASK them and become MVC agnostic. Interface with the controller part of the MVC but do not use their tags in the UI. Instead glue the pages to the controller following a RESTful API.

Ron Grimes replied on Sun, 2008/07/20 - 12:29am in response to: Ali Loghmani

"But guess what, HTML and java script is ruling the web so dominantly. Besides the entire MVC's and UI technologies with every nitty gritty XSTL, XSL, Velocity or other templating technologies try to generate HTML, CSS and Java Script. 

Agreed. HTML is the lowest common denominator and so it will probably always "rule the web" - if nothing else as wrappers for more complex technologies. Even Flash and Flex are wrapped in HTML with some JS thrown in to accommodate any ExternalInterface calls. But, just because something is the lowest common denominator, doesn't mean it's the best choice. When you have a choice of a technology with a penetration level in the high 90 percentile, and that takes care of cross browser issues in one fell swoop, seems like the choice is clear. Even Microsoft has seen the (Silver) light and decided to jump on board.

But, you have a point that XSLT (which now seems ancient as I used that in my first generation of web applications) eventually renders to HTML - as do many other technologies.

One of the advantages (and there aren't many) of working for a billion dollar plus company that feels only 2 web application developers are needed, is that you are forced to adopt the technologies that give you the greatest level of productivity with the highest level of quality, security, and functionality. When you're faced with that choice, you eliminate anything that's unnecessary. And, testing across multiple browsers and versions is one time consuming task that can be eliminated with technologies like Flash, Flex, or Silverlight.

If you look at articles, such as this one http://www.cmswatch.com/trends/1165-sun-to-pursue-java-less-java , it's easy to see that we are in the early to intermediate stages of turning to technologies that can run inside either a JVM or AVM. It's a more powerful solution that's gaining traction. Inventing further HTML-based solutions is sort of like investing in buggy whips after the car had been invented. There still may be a use for them, but the demand can only wane over time as more powerful solutions come into prominence.

R. Grimes

 

Gabor Farkas replied on Sun, 2008/07/20 - 1:34pm

UI development in my company turns slow when existing UI framework facilities become insufficient. The team can develop quite fast using existing patterns, creating standardized types of UI elements. But when in need of something different, we always have to face limitations of the UI framework. In case of JSF, even richfaces and facelets, you'll probably end up hacking JS. The time we've spent hacking html, js, and the faces model is enormous. I faced similar problems earlier using the Delphi VCL, I often had to turn to win32 GDI API docs.

Creating a HTML based UI is a complex task, you can only keep the development simple if you keep your UI desing simple.

If you are tied to use a web based architecture, you can possibly get the ease of desktop UI development using frameworks like millstone, thinwire, echo, or something alike.

Sandeep Chandra replied on Sun, 2008/07/20 - 4:27pm

Has anyone tried Intraweb(components for Delphi and C++Builder)? Although not as popular as ASP.NET, PHP, etc but I think it is the fastest way to develop UI for WebApplications. I have not done very complex UI with it but whatever I have done has worked perfectly so far.

Jose Maria Arranz replied on Sun, 2008/07/20 - 5:12pm

What about a framework with *absolute pure* HTML (or SVG) based templates?

For instance... ItsNat, Natural AJAX

 

Ali Loghmani replied on Mon, 2008/07/21 - 5:01pm in response to: Ron Grimes

Agreed, the HTML era shoud be ended. But I am trying to say is to decouple the view layer, the UI pages, from the underlying layers. Using ASP, JSP, JSF of any kind, Struts, Wicket, etc. tags in the UI pages just makes the UI pages dependtant to those technologies. Especially, when the backend logic is complex and session management, validation checks and i18n translations are mixed with comet Ajax calls within the page. Then, that UI would only be usable for the underlying technology. 

So, if instead of massive HTML and Java script implementation you use Flash and action script, there is no problem. The point is that there should be no server side technology dependency in the View layer and besides the communication discipline should be XML RESTful based. Imagine that you have a set of complex components that can interface with any server side technology. 

At the other hand, I do believe that in coming years browser have to come up with a new scripting language that supports mega rich user interface needs. There should be some out of the box plugins in the browsers for XML marshaling to client side objects and vice versa based on the standardized metadata types. 

Ultimately, I would like to bold the View layer abstraction of this discipline by client side scripting (HTML and JavaSript or Flex) and XML RESTful API intefacing.

Ali Loghmani replied on Sun, 2008/07/20 - 7:21pm in response to: Jose Maria Arranz

IsNat looks nice, gotta play with it.

Dean Del Ponte replied on Sun, 2008/07/20 - 8:56pm

With Grails you can create plugins that will work within any Grails app.  Plugins are portable and reusable.

Aaron Digulla replied on Mon, 2008/07/21 - 4:21am

The reason why this is so slow is that no one tests web apps with JUnit because the code (JSPs and the whole lot) take ages to set up - if you can set the environment up outside of the appserver at all.

My solution was to cut the crap to pieces which are all testable (using MockRunner and env.js with Rhino) without deploying.

With these tools, I can create working webapps just as fast as I can write library code and the final result will work the first time it is deployed anywhere. I can test whether the JSPs create the correct HTML, I can test JavaScript in the HTML, I can test events triggered by the user, all from within JUnit.

Ritesh Chitlangi replied on Mon, 2008/07/21 - 6:34am

because it is soul-sucking.

Despite the bazillion ajax-y frameworks, "easy-to-use" templating etc. I still haven't found anything easier than PHP for fast-as-fuck UI development.

Yeah I know there'll be uproar about how PHP is unmaintainable etc. etc., but huge and complicated sites on the web are served by PHP, and it is probably the most natural fit to developing Web UIs.

I've been using the Google Web Toolkit on a project, and goodness, it needs so much boilerplate and complicated tools for testing if your UI output is exactly how you want it.

 

About Flash etc., I suppose they'd be the way to go for this whole "web application" thing. I'm personally not too fond of them as they don't really support many platforms apart from MS Windows, but then I am not in the target market for web-sites developed with those.

Laran Evans replied on Mon, 2008/07/21 - 12:14pm

Nice post Ali. Good discussion as well.

 I posted a reply on my blog. Check it out.

Happy developing :)

Stephen Harding replied on Tue, 2008/07/22 - 11:24am

Ali

Myself and a few colleagues are working on an open source project called AjaxToaster that you might find ties in with your ideas of separating the view logic from the model using RESTful services.

Have a look and see what you think.

Steve 

replied on Wed, 2008/07/23 - 6:03am

check this introduction on Linux.com:

http://www.linux.com/feature/141601

Jose Beas replied on Tue, 2008/07/29 - 10:38am in response to: Stephen Harding

Sorry, but I thought the idea was to decouple the view from the data but with AjaxToaster you are tightly coupling (and exposing) your database to the view. But the idea of having generic UI components that render any XML/JSON coming from the backend is very good. It can be as decoupled that we can easily unit test the components, unit test the RESTful services and test the integration of both.

 

My main concern is how to manage the user conversation as services (in a canonical SOA) should be stateless.

 

Best regards,

JMB

 

Ron Grimes replied on Tue, 2008/07/29 - 11:14am

Another piece of the equation in this whole discussion, and why I'm against developing the front-end primarily in HTML and JS, is that I see these HTML-based web applications as far more vulnerable to XSS and CSRF, which in turn exposes your database to SQL injection attacks. 

There is an old joke:

Two guys are being chased by a bear, when one stops to put on his sneakers.
The other guy yells, 'You idiot, you can't outrun a bear.'
The first guy gasps, 'I don't have to outrun a bear - I just have to outrun you.'

In web terms, the moral of the story is, please keep developing in HTML and JS. You become easier prey for the hacker, since you expose so much to them. Given a choice, as a hacker, between exploiting a website developed in HTML/JS or a website developed in Flex, which would you choose?

R. Grimes

 

Ali Loghmani replied on Wed, 2008/07/30 - 12:28am in response to: Ron Grimes

Hey,

I have been so busy last week preparing a proposal for a customer for using FLEX on top a XML based RESTful ECM. Actually, the notion of this idea is to make the View layer technology agnostic, make it independent and reusable but not at any cost.

What I have tried to explain was not to eliminate the whole MVC and exposing your database to people. it is like striping the fat lady. In fact, it is ridiculous to lose Context and Session Management, I18N functionalities, Security and so many other inherent services provided by the MVC, in order to be technology agnostic. Indeed nobody will buy that.

FYI, in my new project FLEX will be only used to consume the XML output of the RESTful services and will have no access to the underlying layers directly. The same thing could happen using HTML instead of FLEX. Anyway, I am cooking a new post and in that I am elaborating these details.

Ali Loghmani replied on Wed, 2008/07/30 - 12:40am in response to: Stephen Harding

Steve,

The idea looks great. FYI, my ideal architecture is having King's SEAM providing RESTful services, performing context management, etc. and having a technology independent view framework on top of that. basically as I have mentioned in one of my replies here, the view layer should not see the database for so many reasons. Please follow the next posts of this series. 

 

ivo mägi replied on Tue, 2008/12/09 - 4:53am

The turnaround time author is complainging about can be completely removed from your development using the tools like JavaRebel and JSP Weaver. Check from http://www.zeroturnaround.com

 

 

Carla Brian replied on Mon, 2012/07/30 - 10:24am

The mapping of widget states to program states is not always straightforward. To the contrary, the possible permutations are more often than not incalculable.  - Mercy Ministries

Passion Lab replied on Fri, 2012/08/31 - 2:55pm

In this post I am read to introduce the first part of new discipline for UI development by smart manipulation of the existing technologies Bridesmaid jewelry sets

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.