Why is Web UI Development Slow?
Why is Web UI Development Slow?
Join the DZone community and get the full member experience.Join For Free
FlexNet Code Aware, a free scan tool for developers. Scan Java, NuGet, and NPM packages for open source security and open source license compliance issues.
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?
Published at DZone with permission of Ali Loghmani . See the original article here.
Opinions expressed by DZone contributors are their own.