This is reply to Ali Loghmanis post “Why is Web UI Development Slow?” on DZone.

Nice post Ali.

I have to agree with you. HTML and Ajax is the best solution out there right now. Granted, the world would be a better place if we didn’t have HTML and could code everything straight in our language of choice. The fact is however that we’ll be stuck with HTML for years to come. So we’d better figure out a way to be productive with HTML in the mix.

Re: the cross-browser issues. I used to struggle with those issues as well. Did for years. The javascript frameworks such as Dojo, MooTools, JQuery, Prototype and ExtJS that have come out in the last few years have made the cross-browser issue all but non-existant for me.

The problem that the HTML layer introduces is a break from the server-side runtime environment. It’s a problem no matter what language or framework you use. It’s a problem with the underlying web ecosystem.

The best way to work around it, to bring the backend and front-end closer together is to embrace it. Stop trying to put a square peg in a round hole. Do one of two things:

1) Build rich interfaces using something like Flex or Flash (as someone mentioned). However, this just swaps around the pros and cons. RIAs (Rich Internet Applications) have many advantages, slick looking UIs not being the least among them. They don’t solve the basic problem howeer. They make UI construction easier. But you’e still got to integrate with all the backend systems such as XML-RPC and SOAP-based web-services. Plus it’s a whole new syntax and development infrastructure to get accustomed to.

2) Expose data access on the server-side via JSON or XML formatted data feeds via services and construct UIs with using JavaScript for some things. I’ve seen component-oriented JavaScript frameworks, ExtJS comes to mind, tend to suck developers in, encouraging them to build entire UIs with Javascript components. This is a huge learning curve and can result in a real mess. I’e seen it happen. So I recommend using Javascript just to handle whatever needs to be dynamic after the screen has rendered. This leaves the majority of screen functionality to be coded on the server side, while providing the responsiveness and esthetic appeal of a responsive, dynamic, javascript-enabled interface.

My big thing is that I don’t need more tools in order to build better apps in less time. I already have all the tools I need. I don’t need more syntaxes, toolkits, development environments, etc. I have a great deal of success building apps with just the fundamentals of HTML, JavaScript and a server-side scripting language.

I’ve found it’s much more effective for me to stop looking outward to the developer community for a framework that will solve all my problems. I’ve been disappointed by hyped-up solutions too many times. I’m finding that by being more diligent and more clever with the fundamental components of the environment (web, desktop, mobile) and server-side language I’m developing with, I’m able to develop more functionality in much less time. And the resulting application is simpler and easier to understand and maintain (because there are fewer frameworks to understand).

I think it’s great that your readers are suggesting alternative frameworks. But, just like wearing Air Jordans won’t make you play basketball like Michael Jordan, using a better framework won’t make you a better developer. I don’t mean this as a criticism at all. As Donald Knuth said, “Software is Hard”.

We should experiment with different architectures and solutions throughout our careers. We must continue to learn and grow as developers. We shouldn’t forget that it’s our skill that makes us good though. It’s not the framework we use. And to say that using one framework or another is going to solve the problem of apps being hard to use isn’t accurate. The gains from using one framework or another are marginal compared to the gains you get from experience.

So, all things being equal, keep things simple. Complexity begets more complexity, which ultimately slows you down.

Until the fundamentals of building web applications change so that we don’t need to use markup, the simplest, best approach (in my opinion) is to use HTML and javascript for the UI and a scripting language on the backend.

Lastly, if you’re interested in some more of my thoughts on this topic, read a post I recently made title “Why are there so many Java web frameworks?”

Have at it everyone!