Aplicaciones de Escritorio vs Aplicaciones Web, ¿hay diferencia en el desarrollo?

Esto post nace como respuesta a las siguientes preguntas o dudas:

  • Estoy desarrollando una aplicación Web, en Windows yo usaba el evento KeyPress pero en asp.net, asp, php, jsp, o xsp no se como hacerlo.
  • De una página A envío información a una página B, quiero que al cerrar la página B el foco regrese a la página A. Esta última es clásica en los foros, además de venir con esta nota la final: el código debe estar con C# 2008 y usando mejores prácticas
  • El diseñador de Visual Studio .Net no funciona, arrastre mis controles pero en el navegador se ve todo feo
  • Voy a desarrollar una página, y no se que lenguaje usar JavaScript, C#, JSP, Php, o ASP.Net, ¿con cuál de estos se ve mejor mi página?
  • Quiero pasar variables usando POST en asp.net, y no se como hacerlo
  • ¿Cuáles son los navegadores más usados? Estoy haciendo una web con Php, y no quiero hacer muchas versiones de mi código, sólo para 3 navegadores como máximo
  • Estoy haciendo una Web 2.0, estoy programando con JavaScript y no puedo conectarme a la base de datos
  • -¿Qué estas usando para desarrollar tu Web html o xhtml?, –No uso html, yo estoy usando lo ultimito uso ASP.NET 3.5, dicen que html ya esta desfasado.
  • -¿Y ya aprendiste Html y Javascript para tu proyecto Web?, –No, con Visual Studio .Net ya no se usa eso, sólo arrastras controles y programas como en Windows

Para responder a las preguntas vamos a ver una arquitectura simple de dos aplicaciones una Windows (o de escritorio) y una Web

Aplicación de Escritorio

http://sergiot2.com/blogimages/2009/01Ene/14-Windows.png

En una aplicación de escritorio normalmente no iniciamos sesión por cada aplicación que usemos, sólo se inicia sesión una vez cuando prendemos el sistema operativo, asumiendo que vamos a abrir una aplicación para ver nuestra lista de tareas:

  1. El usuario carga la aplicación.
  2. La aplicación (el código), se conecta a la base de datos y recupera la información del usuario.
  3. La aplicación muestra al usuario la información solicitada.

Aplicación Web

http://sergiot2.com/blogimages/2009/01Ene/14-Web.png

El usuario desde cualquier parte del mundo y desde cualquier dispositivo (PC, laptop, mobile), desea ver donde será el próximo @BeerTwit.

  1. El usuario tiene que ingresar la URL de la página en su navegador (*1). El navegador por detrás se encargará de hacer un request (solicitud) al servidor Web usando el protocolo de comunicación HTTP (*2) (internet), y en este caso usará el método GET, por que sólo quiere obtener información.
  2. El servidor Web recibe el request y envía un response (sólo html) al navegador. Los navegadores no entienden el código ASP, PHP, o JSP, ellos sólo muestran contenido en html (*3), es por eso que todos los servidores Web después de procesar un request devuelven sólo html (que puede incluir Javascript (*4)), el html generado debe ser un formulario en html, para que el usuario pueda enviar su información. Por otro lado si el usuario ha iniciado sesión con anterioridad es posible que su sesión este activa, y no tenga que iniciar sesión nuevamente.
  3. El usuario llena su información, user y password, y hace clic en el famoso botón “Sign in”. El navegador por detrás recolectará esta información, y en este caso que se desea enviar esa información al servidor debe estar usando el método POST. Todos los lenguajes usan POST para enviar información a una página, ya sea ASP.NET, Php, JSP, etc (*5). En el caso especial de ASP.NET cuando están desarrollando por defecto todos los formularios se envían usando POST, pueden hacer “View Source” de una página en el navegador y verán que el formulario html tiene el método POST. Pueden ver también esto usando la herramienta Fiddler. Con GET también se puede enviar variables, pero no es técnicamente enviar información, es mas bien, un obtener información con estos parámetros.
  4. El request llega al servidor Web, y se ejecutará el código de servidor Php, Jsp, o ASP, que se conectará con la base para verificar si existe el usuario y si el password coincide con el enviado por el usuario.
  5. Si el usuario y el password son validos, el código de servidor (login.php, login.jsp, o login.aspx), redireccionará el request a otra página showUpdates.php, la cual se conecta nuevamente a la base de datos para traer todos los updates de los amigos del usuario, después de procesar la página, el servidor envía el response (sólo html) al usuario.
  6. El usuario ve en una página las últimas actualizaciones de sus amigos, y parece que esta semana no habrá @BeerTwit, así que tendrá que inventar alguna excusa para generar uno nuevo.

¿Se nota la diferencia por qué es distinto para programar para Windows, que programar para Web? ¿Todavía no?. Vayamos resumiendo:

*1. El front-end de toda aplicación Web, siempre acabará en un “navegador” y si queremos que se vea bien la mayoría de navegadores debemos desarrollar usando estándares, eso evitará tener que hacer una versión de Html o Css por cada navegador. Ahora también esta de moda tener una versión móvil de las aplicaciones: http://m.elcomercio.com.pe, http://m.hi5.com/, http://m.facebook.com, http://m.twitter.com, http://m.tuWebAqui.com.

*2. El protocolo usado para comunicarse con un servidor web es: “HTTP”, y normalmente usamos HTTP GET o HTTP POST, para cualquier tecnología de servidor. Revisar este Screencast del genial David Salgado: Trabajando con HTTP GET y HTTP POST, acá muestra por ejemplo simular un browser desde .Net haciendo request GET o POST usando la clase HttpWebRequest, aunque también pueden usar la clase WebClient. Por otro lado existen otros métodos de request además del GET o POST, el uso de estos métodos los verán con REST.

*3. Ya hemos mencionado que todo servidor Web devuelve al cliente sólo “HTML”, por eso importante trabajar con estándares para que nuestro diseño se pueda ver bien en todos los navegadores. ¿Por qué el código de mi página (php, jps, asp.net) no se ve bien? Pues posiblemente sea por que no sabemos HTML o no sabemos CSS o el diseño no es nuestro tu tema, si vamos a desarrollar una Web tampoco vamos a centrarnos en aprender html a nivel experto, pero si debemos conocer lo básico sobretodo si nosotros estamos encargados de integrar el diseño con la funcionalidad. ¿Si soy developer como diseño mi página Web?, revisar los comentarios en el siguiente artículo.

*4. Un gran aliado para hacer más dinámica la interacción de nuestra aplicación web con el usuario es usar “Javascript. Recuerden que una aplicación Web, tiene dos ámbitos: cuando esta en el cliente (1), y cuando se hace un request y se va al servidor (2) para procesar el request y generar el response. Entonces, o está en el navegador del usuario o está en el servidor Web, entonces JavaScript es un lenguaje script del lado del cliente, y con el voy poder cambiar elementos dentro de la versión html que este en el cliente. Por ejemplo, puedo con un botón (input: type-button) hacer el llamado a una función en javascript que cambia el color o contenido a un caja de texto (input: type-text), y para hacer esto en la página, no es necesario que la página vaya al servidor, con JavaScript podemos hacer estos cambios del lado del cliente. Si yo hago el cambio de color o contenido de una caja de texto desde un lenguaje de servidor asp o php, la página tendrá que viajar al servidor sólo para cambiar el color. JavaScript da una mejor interacción con el usuario, pero no todo se puede hacer del lado cliente, por que la data, información, el valor, la carnecita, esta en el servidor y hay que viajar para traer esta información. Cada vez que se hace un request al servidor Web (sea GET o POST) se refresca toda la página, lo que da una percepción de lentitud a comparación de Windows, si quieres mejorar esto una de las opciones es usar Ajax. Siempre es bueno conocer lo básico de JavaScript, sobre todo para cuando estemos trabajando con popUps o cualquier interacción del lado del cliente.

*5. Y por último el “lenguaje de servidor, que puede ser Php, Asp, Jsp, y todos los demás. Obviamente si tu labor es desarrollar páginas web con acceso a datos, debes dominar el lenguaje de programación, pero como vimos anteriormente también es útil conocer lo básico de JavaScript, Html, Css, y cuando lo vayas necesitando aprendes más de cada uno de ellos.

Espero que las preguntas propuestas al inicio, hayan quedado resueltas.

P.D.: Y recuerden, programar una aplicación Web no es lo mismo que programar una aplicación de escritorio, pero si va servir nuestros conocimientos de programación. En .Net por ejemplo todas las librerías, a excepción de las propias de Windows, que hayas aprendido programando Windows, te van servir cuando programas en Web, ejemplo: System.IO, System.Xml, System.Data.SqlClient, System.XYZ.

Saludos,

20 comentarios en “Aplicaciones de Escritorio vs Aplicaciones Web, ¿hay diferencia en el desarrollo?”

  1. Sí que son diferentes, pero con Silverlight, JavaFX, Adobe AIR… (RIA) se acerca un poco más a lo que es el desarrollo Windows, si lo que queremos es crear una aplicación para ambos mundos. Corrígeme si estoy equivocado.

  2. Parece una preogrullada todo esto que dices, pero ya van 3 veces las que me he encontrado en empresas con desarrollos hechos en ASP.NET el mostrar alertas con MessageBox.Show.

    Y encima te dicen “Cuando desarrollo en mi máquina el mensaje se muestra bien, pero al subirlo al servidor Web el mensaje no sale”…

    Y entonces es cuando no sabes si tirarte al metro o a la revisora..

  3. @unodetantos: pues no entiendo como un MessageBox.Show() puede funcionar en Web en una maquina si y en otra no :|, de acuerdo a lo poquito que entiendo yo de aplicaciones web eso no debería funciona nunca !!!

    y no me parece mal el post, siempre es bueno reflexionar un poco sobre la forma en que trabajamos y las tecnologías disponibles, es la mejor forma de aprender.

    Saludos

  4. @Oscar Montesinos, así es, no quería tocar el tema aún para no complicar, pero dentro de nuestra gráfica las RIA estarían del lado del cliente y estas funcionan gracias a un motor instlado del lado del cliente, ya lo continuaremos con otro post.

    @Bruno, @unodetantos se refiere a que se agrega la referencia a System.Windows.Forms dentro de una aplicación Web, y se usa la siguiente línea para mostrar un mensaje:

    System.Windows.Forms.MessageBox.Show(“hola mundo”);

    Y localmente si funciona, ves el mensaje. Pero cuando lo ejecutas desde el cliente, el mensaje se ve en el servidor y el cliente no ve nada, además de quedarse colgada.

    Y la idea de la entrada, es para que aquellas personas que recién se están iniciando en el mundo de desarrollo web, para resaltarles: no es lo mismo desarrollar una aplicación web que una Windows, por las infraestructuras de las mismas.

    Saludos,

  5. Sergio, ahi le has dado !!!

    por eso mismo lo comentaba, yo creo que a cualquier persona con un poco de sentido común no se le ocurrirá agregar una referencia System.Windows.* a un proyecto Web, ¿no?

    Saludos

  6. Jejejeje, Buen post Sergio.
    La verdad que la gente que empieza con proyectos web y solo han tocado aplicaciones windows llegan a hacer verdaderas locuras.

    Haré Pingback con la web del grupo LonetCamp si te parece bien.

    Saludos.

  7. @Bruno, a veces mucha gente olvida usar el sentido común. Había un post de Juan Irigoyen, que hablaba de la arquitectura y el sentido común, y bueno, sólo la experiencia hace que nuestro sentido común suba su KI.

    Claro @Marc, la idea de la entrada es que estas locuras cada vez sean menores.

    Saludos @Fabricio.

  8. Y además de todo eso es imprescindible conocer los tipos de vulnerabilidades basadas en web (XSS, SQL injection, CSRF y un largo etcétera) y cómo mitigar esas amenazas.

    Por cierto, no sé si le habéis echado un vistazo a la investigación que acaba de publicarse sobre los 25 errores de seguridad más peligrosos. Va a haber que tenerlos muy en cuenta, tanto en aplicaciones web como en el escritorio.

  9. @Sergio
    No siempre es sentido común… a veces el puro desconocimiento 🙂
    Y si uno programa con un web server en local (lo normal, vamos) y usa un MessageBox porque es lo que ha hecho toda su vida, y en SU máquina le aparece… como va a imaginarse que esto en producción no sólo no saldrá en las máquinas de los clientes, sino que dejará la aplicación cogada?

    Vale… debería saberlo si se dedica a esto, pero hay gente que NO lo sabe…

    @Marc
    Totalmente cierto, y además la arquitectura de ASP.NET no ayuda a evitarlas… “programa en web como si fuese windows” es muy bonito, hasta que aparecen los viewstates descomunales, p.ej 🙂

    Saludos!

  10. @Ramón, tienes razón la seguridad es todo un tema, pero lo básico debe ser conocer los ataques más comunes y como evitarlos. Un buen libro (que puede ser un guideline) es: Write Secure Code, v2.

    @Eduar, claro pero el conocimiento ya te va dando sentido común, el conocimiento te va enseñando a resolver problemas semejandolo a problemas ya resueltos.

    Y en cuanto a la frase: “programa en web como en windows”, no es por la arquitectura de Windows, es por el equipo de marketing y ventas de MS. Aunque ese mensaje es válido para todos aquellos desarrolladores del classic ASP, a ellos el mensaje si se aplica. ¿Pero quá con los desarrolladores Windows?, ahí si el mensaje sólo es “marketing” por que no es aplicable.

    Y si debería saberlo o no, espero que con este post ayude un poco en el conocimiento de saber y no saber :).

    Saludos,

  11. Perdonad mi falta de respuesta, pero no he podido entrar a ver nada de este grupo en un tiempecito. Vamos que lanzé la pieda y escondí la mano.

    Eso de que un programador no mete un

    using System.Windows.Form

    en una aplicación Web es más común de lo que pensais. Ya lo he visto 3 veces. Una de ellas en una persona de mi equipo de programación que llegó nueva. Venía de la programación en C++ y la fiché para mi equipo porque la veía muy válida (yo no valoro tanto los conocimientos que pueda tener una persona, sino las ganas que tenga de aprender y de que le sea fácil aquirir conocimiento puesto que nadie nace sabiendo y en este mundillo el no saber una tecnología y tener que enfrertarte a ella es MUY común).

    La formamos, en la parte Web HTML, Javascript, C#, ASP.NET y la verdad que no me equivoqué puesto que a la semana ya estaba haciendo sus pinitos en ASP.NET y en 2 semanas ya estaba en el proyecto haciendo cositas incluso con AJAX (supervisada, pero el código que tiraba era válido).

    Pasó el tiempo y un día me llamó diciendo que no localizaba un error que le daba al subir una aplicación a preproducción. ¡Y fuí cuando lo ví! Un using System.Window.Forms y un MessageBox.Show como una catedral. En este caso me reí un montón y cuando se lo expliqué (y entendió el chiste) se partió de risa conmigo de su torpeza. Fuimos al servidor y le enseñé el mensaje de alerta que había salido allí. Sin más importancia.

    No obstante, las 2 veces restantes eran en empresas externas que tienen alojados servidores en nuestras instalaciones. Se suponía que eran expertos en desarrollo Web (o al menos así me lo vendían). Pero vamos, tuve que echarles una mano desde cómo crear un ADO.NET con MySQL y usarlo, el MessageBox.Show, luego otro problema que dejaban colgado al servidor puesto que no hacían un puñetero rs.Close() en todo el código (debieron pensar que eso de liberar recursos es para nenazas) y el driver de conexión .NET de MySQL parece que no liberaba la conexión a no ser que le hagas un rs.Close()… Cuando pasaba el tiempo el servidor MySQL alcanzaba el número máximo de conexiones disponibles y decía “hasta aquí hemos llegado, vaquero”.

    Como decía Einstein “el sentido común es el menos común de los sentidos”. Y no le faltaba razón.

    Por eso veo muy bien este tipo de posts. No todo debe ser SilverLight o SharePoint. Existen tecnologías que aunque a nosotros nos parezcan normales hay gente que por distintos motivos no está familiarizado con ellas.

    Imaginad a un consultor de SAP que algún día decida reciclarse y meterse en Web o en un Unviersitario recién salidito de la Universidad (que levante la mano a quién en la Universidad no es que no sólo le hayan enseñado tecnologías Web de servidor (JSP, Servlets, ASP, ASP.NET, CGI, …) sino ya únicamente HTML).

    Es más, incluso hay gente que usa ASP.NET y no sabe nada del transfondo que eso conlleva y de la evolución que ha llevado (antes era un CGI con un .exe, pero eso hacía que se perdiese mucho tiempo creando y destruyendo contextos de aplicación.

    Luego se pasó a ISAPI y NSAPI (la N del NSAPI es del Netscape) para que fuese una DLL y se cargase en el mismo contexto que el servidor Web (con lo que no había que crear contextos de aplicación nuevos), pero un “NULL pointer exception” hacía que el sistema operativo invalidase tu dll y por tanto todo el contexto de aplicación asociado a ella (es decir, todo el servidor Web se iba a la mierda). Y de ahí se pasó a los lenguajes interpretados ASP, PHP, Servlets donde expertos te hacían las dlls ISAPI ó NSAPI y ya era mucho más difícil un “NULL pointer exception” porque esas dlls te las desarrollaban expertos. Tú únicamente te dedicabas a programar en un lenguaje que se interpretaba de un fichero de texto sin acceso a punteros y demás “armas de destrucción masiva”.

    Y de ahí se pasó al ASP.NET para mejorar el rendimiento de los ASP clásico con caché de compilación y demás facilidades que en Java ya llevaban mucho tiempo usándose (JSP). Además de que para hacer cualquier cosa que se saliese un poco del estándar ya tenías que contar con objetos COM que hacían peligrosísimo el meter una aplicación ASP en producción.

    ¡Bien por el Post!

  12. Complex essays writing can be not a problem for up-to-date students. In fact formatting service can be able to soleve all papers writing complications.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *