Bradley Holt

I just read Neil McAllister’s post: The case against Web apps. I couldn’t resist sharing my thoughts on what he had to say (and I wonder now if his article was intended as a troll).

“1. It’s client-server all over again… Scaling small server farms to meet demand can be a real challenge — just ask Twitter.”

Twitter is a bad example, Neil. By its nature Twitter requires a client-server architecture. Unless, of course, he’s suggesting re-architecting Twitter as peer-to-peer application. Interesting idea, but probably more complicated than scaling server farms.

“Furthermore, security vulnerabilities abound in networked applications, and the complexity of the browser itself seemingly makes bugs inevitable. Why saddle your apps with that much baggage?”

The first part of that statement is mostly meaningless. Sure, unplug most applications from the network and you’ll instantly have less security vulnerabilities! Is Neil suggesting that developers will have less bugs if they build the whole stack themselves? Doubtful. Having a large part of the stack maintained separately is a nice benefit of web applications. Developers can focus on getting their part right, and let other people worry about getting the other parts right.

“2. Web UIs are a mess… Buttons, controls, and widgets vary from app to app. Sometimes the menus are along the top, other times they’re off to the side. Sometimes they pop down when you roll over them, and sometimes you have to click. That inconsistency hurts your development budget, but it hurts usability more.”

Desktop applications are just as guilty of having inconsitent UIs. Programmers break the rules all the time regardless of the platform. We need more UI experts and we need to stop making programmers responsible for the UI.

“3. Browser technologies are too limiting.”

So? The web has its own advantages that I will not enumerate here as they are (mostly) well known. It’s a different platform. People need to stop trying to build web applications as if they were desktop applications (hint: REST).

“4. The big vendors call the shots… Increasingly, the evolution of Web standards is being driven by major browser vendors — new features are implemented first and standardized later. Independent developers have little genuine input into the future direction of the Web. And that’s to say nothing of the ongoing bickering between the various vendors. Does it make sense to rely on client-side software that’s such a moving target?”

No one’s claiming the standardization process is perfect. But, at least it happens mostly in the open. All it takes to solve this problem is for more people to step up and get involved in promoting web standards. Stop complaining and get involved!

“5. Should every employee have a browser? … You could make a case that it’s unwise to allow employees unfettered access to the Web if your company values productivity, particularly in high-turnover environments such as help desks and call centers. But if your internal applications are Web-based, you’ll need to either host them onsite or maintain careful router or firewall rules to prevent abuse of your Internet services.”

I’m not even sure what Neil’s point is here. This is a company-by-company decision. If it’s important for a company to block web access, then surely they can figure out how to write the appropriate firewall rules to allow their own web apps to work? Overall I thought this piece was not very well researched and had some major logic gaps. If its goal was to be flamebait then it did a good job.