Why HTML/Web UI response slower than Native UI?

Question

I can\'t understand, Why HTML/Web UI response slower than WinForms/WPF/Android View/Native UI?

The Native UI also have styles, elements nesting, events than the CSS, DOM

Answer 1

If Web UI is completely implemented by JavaScript on the client side, the difference from WinForms/Native UI will be trivial.

However, in most cases, the Web UI triggers some Web request to the Web server, then it has to go through the following steps to achieve the same effect as a WinForms/Native app:

1. Send a HTTP request (GET/POST/...) to the Web server
2. The Web server is an executable (in the format of an external app or a service) listening to one or multiple ports. When it receives the request, parses it, and finds the Web application.
3. Web server executes backend (server-side) logic within application.
   Web application such as ASP.NET is pre-compiled. Time complexity of this step could be very close to a Windows app.
4. Web server renders the result into markup and sends it back to the client
5. Client (Browser) parses the result and updates the UI if necessary. Controls/images/other resources in a Web page normally take a little longer to render within a browser than a Windows app renders its display.

Even the Web server is local, the cost generated the data parsing/formatting/transfer cannot be simply ignored.

On the other hand, an application with WinForms/Native UI typically maintains a message loop, which is active and hosted in machine code. A UI request normally just triggers a lookup in the message table and then execute the backend logic (Step 2 in the above)
When it returns result and updates UI, it can be simply binary data structure (doesn't need to be in markup), and doesn't reply another application(browser) to render to the screen.

Lastly, a WinForms/Native application normally has full control to maintain multiple threads to update UI gradually, while a Web application has no direct control over that type of server-side resources.

UPDATE:
When we compare a Web application and a Windows/WPF (or native) application consuming a same Web service to partially update their UIs

The two UIs should respond and refresh with ignorable speed difference. The implementation difference between binary & scripting execution to respond and refresh UI is almost nothing.
Neither of the UIs needs to reconstruct the control tree and refresh entire appearance. Given same conditions, they could have same CPU priority, memory/virtual memory caching, and same/close number of kernel object & GDI handles at process/thread level.
In this case, as you described, there should be almost no visual difference.

UPDATE 2:
Actually event handling mechanisms in Web and Windows apps are similar. DOM has event bubbling. Similarly, MFC has command routing; Winforms has its event flow; WPF has event bubbling and tunnelling, and so on. The idea is a UI event might not strictly belong to one control and a control has some way to claim an event has been "handled". For standard controls, focus changing, text changing, dropdown, scrolling events should have similar client-side response time for both Web and Windows apps.

Performancewise, rendering is the biggest difference. Web apps have limited control of "device context" because a Web page is hosted by an external application - the Web browser. Windows applications can implement animation effects using GPU resources like WPF and speed up rendering by refreshing the "device context" partially. That's why HTML5 canvas makes Web developers excited while Windows game developers have been using OpenGL/DirectX for over 10 years.

UPDATE 3:
Each Web browser engine (http://en.wikipedia.org/wiki/Layout_engine) has its own implementation of rendering DOM, CSS; and implementation of (CSS) selectors. Moving and resizing elements within a Web page is changing DOM, CSS (tree) setup. The selector and rendering performance highly depends on the Web browser engine.

1. UI operations could make selectors go through unnecessary steps to update UI.
2. A Web page doesn't have control to inform the browser to do partial rendering.

which make fancy JavaScript controls (some jQuery UI, dojo, Ext JS) cannot be real-time fast, usually slower than Flash controls.