¡Mi madre! Tengo que armarme de valor y leer este hilo por completo, todavía no lo he hecho.

Yo también he hecho "programación web", y he de decir que para ciertas cosas es mucho mejor la programación cliente/servidor de toda la vida. De hecho, en mi último trabajo solté unos cuantos "Te lo dije" por no haberme hecho caso cuando lo propuse y empeñarse él en que era mejor la "programación web".

Es verdad, muchas veces las empresas que no conocen de esto, mencionan hay que hacer una "aplicación web" porque está de moda y todo el mundo lo usa, pero no necesariamente sea la solución más idónea. Otras opciones que hay si se da el caso de su necesidad es hacer sistemas distribuídos.

El factor determinante es el mercado/cliente al que se piensa servir. Como programadores, muchas veces se piensa desde la tecnologia "hacia afuera". Se define la tecnologia *primero* y luego se trata de ajustar esas decisiones a todo lo demas (incluyendo, al final, al usuario).

Ese es un error garrafal. Como dice fer21unmsm los clientes hacen en parte lo mismo, por la "moda". Al final, escojen la tecnologia, y luego tratan de que esta se ajuste a las necesidades (evidentemente, los implicados normalmente NO se dan cuenta de que están haciendo eso).

Volviendo a los programadores, la verdad uno tiende a usar lo que a uno le gusta. No lo que necesariamente es mejor para el cliente y/o el usuario (que pueden ser 2 personas diferentes!) y eso termina notandose mucho.

He hecho apps de muchos tipos, monousuarios, multiusuarios, 2 niveles, 3 niveles, web tipo LAMP, servicios windows, utilerias, escritorio, moviles, etc... y siempre he descubierto que cuando la tecnologia se escoje previamente termina uno repudiando luego el problema.

Lo correcto y mejor, es preguntarse cuales son las TOP N (máximo 5) actividades MAS cruciales para el usuario (no el cliente), y cual es el usuario a quien hay que satisfacer realmente. Ej: En un programa de facturación, el usuario a satisfacer no es el gerente, es el digitador de las facturas. En un sitio web, no es el gerente, es el visitante que desconoce la empresa -o el partner, o el usuario registrado, o el comprador casual, o el comprador recurrente-. En general, el gerente es el usuario que MENOS hay que satisfacer!.

Ahora viene la parte interesante, y es ver cuales son los parámetros de satisfacción del servicio, y cuales son las integraciones, y las tareas MAS DIFICILES. Digamos, que por ejemplo, un programa de facturación debe procesarse en menos de 1sec por factura (es algo que casi nunca se pregunta!) o que esta debe imprimir en un impresora termica. Que hay un proceso, muy importante, cada mes, que no puede frenar a la empresa.

De pronto, *un solo* requerimiento puede empujar la tarea en una dirección u otra. Y lo tenaz es que normalmente, es algo que se ve venir desde el principio, no de la clase de cosas que salen a la mitad del camino, sino de las que se aprenden al principio del proyecto. Pero la terquedad, el orgullo o el optimismo ciega a la realidad de la avalancha que se viene.

P.D: Y no necesariamente tiene que ser Web vs. Desktop. HTTP es un protocolo de comunicacion, que no esta amarrado a HTML, ni a PHP, ni a MySql. Se puede usar libremente de cualquier app a cualquier app (al igual que otros protocolos y formatos estandar como TCP, UDP, JSON, XML, etc).