We've all been there, your customer is burbling on about some vapourware "paradigm" that's supposed to completely revolutionise business as we know it. If everything switches to use this new technology that "people" are raving about, then there will be better profits, more customers and world peace. Birds will sing, butterflies flit, and every day will be perfect.
Bollocks!
There's no such thing as one size fits all, especially when it comes to technology. Nonetheless, we let barely tech-literate bosses and customers force us into implementing something for a purpose to which it is not suited. We console ourselves that it's not our money, but it is. If the project you're working on turns into a disaster because of misapplied tools, the customer will be furious, even if that's what they asked for. They won't accept that it wasn't intended for the purpose to which it was put. They'll point out all the companies which have had great experiences with UberWidget 2.0, and imply that its failure to deliver is your fault. If you work for the customer directly, you may lose your job, or career prospects. If you work for a consultancy, your company may lose it's lucrative contract with the customer. That means less revenue, and thus less money in the pot for your hoped-for increase. If the customer bad-mouths your company, you may lose potential sales too.
But what can I do about it?
For starters, get your head out of your foxhole and don't blindly accept the idiotic proposals being scattered about by the customer and/or your management. Don't be negative, focus on the positives that alternatives offer. If your customer is burbling on about how they want their internal-only single-branch, massive data capture application to be "web-enabled" (whatever the hell that means), point to the rich UI of non-web based alternatives. Point out the much easier (and therefore cheaper) development cycle. Tell them all the funky things you can do with a decent threading and networking model. Bang on about the lovely little task tray notifications and Outlook integration stuff you can do.
Can I fake it?
Yes, you can. In one case I had, we were integrating with a vendor that supplied a web-only interface. It would pop up your web pages when certain things happened. So, effectively, we were locked into supplying a web application for exactly the internal-only single branch, massive data capture app that I mentioned before. We did try, we got all sorts of nice controls and did funky Ajax stuff to make this huge app as quick and responsive as possible. Luckily I had decided to do a POC first. Our app, without much of the logic and validation code, was a dog. The page took too long to load, there was WAAY too much Javascript, causing the browser to choke. Perhaps I could have hired some sort of JavaScript guru ('cause I sure as hell am not one).
Instead, I created a nice, easy, fast, multi-threaded, rich UI Windows Forms Control. I turned the bloated web page into a simple control host, with a few hooks between the control properties and events and the page. Viola! The app was responsive and easy to use, with easily implemented things like tabs, menus, grids, graphs, etc. The same development in ASPX would have taken me twice as long, at least. If I'd had a good incentive, I would have done it. You know, like the app was to be used by external customers or something.
But, we were writing an internal application, what on Earth was the point of doing that in a browser? I mean, if it had been the simplest of data capture applications, sure, I could see that. And it is possible to provide powerful, rich UI's in the Web (just look at Gmail), but they tend to be prohibitively expensive either in bandwidth or cost.
What's the bottom line?
The fact of the matter is that our underlying job is to deliver the best implementation that will cater for the client's needs and growth, not to be shoehorned into some silly fad the marketing journals are writing about.
Web applications are for lightweight content provision and/or simple data capture to heterogenous environments. Web Services are for communications across either distributed sites (i.e. across firewalls), or heterogenous environments. Remoting is for local communications across local sites. Windows Forms are for rich UI's in homogenous environments. Sockets should be used for stuff Remoting cannot handle easily, such as broadcast/multicast.
Linux is best suited for networking, proxying and firewalls. Windows is best suited for desktop environments, and for server apps in a Windows site. RSS is ideal for streaming fairly simple content to multiple subscribers.
The moment you hear someone burbling on about using things outside their "target" applications, you should beware. I'm not saying it won't work, just have a healthy dose of skepticism. The next killer app will not be some use of RSS to deliver application services to client PC's, nor will it be a Web based disk defragmenting tool.
Responsibility and Integrity
The important thing to remember here is to have integrity in what you do. If you would not implement something in the way being bandied about, then it's your responsibility to say so, and to provide better alternatives. If you're shouted down for whatever reason, well, generally there's not much you can do about that. Nonetheless, despite the fact that the worst-case scenario has come to pass, it was not guaranteed to be this way, as it would have been if you'd just kept quiet. And every once and again, you'll have the exhilarating experience of actually changing minds, and convincing people to go with the more applicable solution. Those kinds of projects are a dream, because if it happens once that your advice is taken, and it's good advice, then generally your advice will be more listened to and heeded thereafter.
You might eventually reach the Nirvana of being the final arbiter of the solutions used. This will (assuming you're competant), result in happier clients, more sales, more revenue, and ultimately more job satisfaction and money for you.