desarrollo WEB vs. desarrollo tradicional

[_iceman]

En el ámbito en el cual me desenvuelvo (facultad), todas las personas con las que me contacto tienen la idea de desarrollar cualquier sistema, sea lo que sea, con tecnología WEB (html, php, java, etc.), y dejaron de lado el desarrollo tradicional (Delphi, Visual C, Builder, Visual Fox), ahora recurro a Uds. con el fin de tener una idea más amplia de cual de estos entornos de desarrollo es el mas apropiado para realizar una aplicacion comun, un sistema de consultas, bajas y altas sobre una base de datos que no necesite realizar grandes tareas de programacion (calculos de algun tipo que exijan un esfuerzo de desarrollo) que es el caso en el cual gana la programacion tradicional segun mi entender, y siguiendo con esto cual es la tendencia, si se puede hablar de tendencia en este aspecto, o solo es una moda pasajera que esta implantada en mi entorno.

Saludos.-

[marto]

Wop!

Compañero tu pregunta es la del millón de dolares ;) Recuerdo que cuando empezaba en esto (tampoco hace tanto... parezco un viejo :rolleyes: ) la discusión con los compañeros siempre era cuál era el mejor lenguaje, el mejor entorno. Con el tiempo te das cuenta que no existe ninguna panacea: tienes que saber escojer en función de tus necesidades, ya que cada uno es mejor que otros en alguna cosa (menos VB, que no se me ocurre en qué :D ).

En el tema que tú planteas pasa un poco lo mismo. La web como plataforma de desarrollo de aplicaciones (fin para el que no fue diseñada) tiene grandes ventajas y grandes inconvenientes sobre las aplicaciones de escritorio. Creo que lo mejor que se puede hacer es plantear los pros y los contras y que cada uno llegue a sus conclusiones.

Por un lado, las aplicaciones web pueden ser absolutamente portables en cuanto al cliente. Si necesitas desarrollar para windows, linux,... un mismo programa es mucho más fácil desarrollar un cliente compatible con distintos navegadores que uno de escritorio para distintos SO (a no ser que lo hagas en java, pero entonces necesitarás que a tus clientes les salga la RAM por las orejas).
Otra ventaja de la web es el hecho de no tener que instalar nada en el cliente, excepto el navegador, pero normalmente éste ya está en todos los ordenadores. En relación con este punto tambien hay que destacar que, si se hacen actualizaciones, los usuarios tendrán la última versión al momento mientras que cualquier programador con experiencia te puede explicar los dolores de cabeza que dan estos procesos en las aplicaciones de escritorio.
En mi opinoón la web aun tiene otra ventaja (y seguro que me dejo alguna), se trata de la movilidad. Cualquier persona se puede ir a un cybercafé y acceder al programa... desde Barcelona o desde Cali.

Bien, hasta aquí las bondades de la web. ¿En qué creo que sale victorioso el desarrollo de escritorio? Pues en primer lugar, es mucho más rápido y fácil (de momento) desarrollar una interfaz de escritorio que una web. Además, si ésta requiere cierta complejidad, existen límites a los que es muy complicado llegar en web.

Por último, y esto más que una vetaja es una diferencia crítica, hay cosas que en web no se pueden hacer. Principalmente son limitaciones de seguridad (aunque nuevas tendencias como las aplicaciones HTA las están dejando atrás). Básicamente el tema es que en web no puedes acceder a muchos de los recursos de la máquina cliente que en escritorio sí.

Mi conclusión, en general, es que, si se puede hacer web, así lo hago, ya que para mí sus ventajas pesan más que sus contras. Pero si las exigencias del guión me piden segun que cosas.... entonces hay que ir a lo "tradicional"

[roman]

Para mí la interfaz gráfica es fundamental y ya lo dijo jachguate, hay cosas que en web no se pueden hacer y algunas que sí se pueden cuestan demasiado trabajo y muchas veces sólo en algunos navegadores se pueden realizar. Por dar un ejemplo ínfimo, hay cosas que en este mismísimo editor de mensajes que estoy usando las puedo hacer en un navegador y no en otro y que como usuario me resultan muy cómodas. Pero esto es sólo un pequeñísimo ejemplo ante la infinidad de controles personalizados que muchas veces hacemos o usamos en nuestras aplicaciones para facilitarle la vida al usuario. Esto es algo que muchas veces no tomamos en cuenta; pensamos que una determinada interfaz está muy bien pero nosotros "sólo" la programamos, no la usamos excepto para hacer pruebas y son los usuarios quienes han de "sufrir" nuestras desiciones en el uso cotidiano y constante de la aplicación. Dale, por ejemplo, a un usuario una interfaz que sólo maneje el mouse y te recordará cada día de trabajo ya que quienes diariamente usan la computadora para introducir datos suelen encontar mucho más versatil el teclado.

Lo que comentan las personas en tu facultad no es nuevo, lo he visto varias veces pero sí creo que son modas. Quizá algún día no muy lejano la tecnología para aplicaciones Web sean tan poderosa que se puedean hacer todas las cosas que hoy no es posible, pero mientras eso sucede no veo razón alguna para programar una interfaz gráfica en una plataforma claramente inferior, al menos en el aspecto que estoy mencionando.

Esto no quiere decir de ninguna manera que esté negado a las interfaces Web. Por el contrario, me gustan mucho y tienen todas las ventajas que ya menciona jachguate pero cada cosa a cada cosa.

// Saludos

[kinobi]

Hola,

En el ámbito en el cual me desenvuelvo (facultad), todas las personas con las que me contacto tienen la idea de desarrollar cualquier sistema, sea lo que sea, con tecnología WEB (html, php, java, etc.), y dejaron de lado el desarrollo tradicional (Delphi, Visual C, Builder, Visual Fox), ...

pero esa división, entre lo que tú llamas "tecnología web" o "desarrollo tradicional", en función de los lenguajes/entornos de desarrollo, no acabo de ver que exista realmente, incluso desde el punto de vista de los interfaces de usuario, que parece ser lo que se está discutiendo realmente en el hilo. Acaso no pueden hacerse aplicaciones, con interfaces de usuario orientados exclusivamente a la consola (caracter), con PHP o Java (yo las he hecho), o sistemas orientados a su uso exclusivo con un navegador web con Delphi (también las he hecho). Incluso aplicaciones con interfaces de usuario, de esos que parece que tú denominas "desarrollo tradicional", con lenguajes como PHP, que tú consideras que son "orientados a web", utilizando extensiones que unen una cosa y otra: PHP-Gtk (http://gtk.php.net/).

Por otro lado, imagina que te encargan desarrollar un sistema que tenga un interface de usuario guiado exclusivamente por el sentido del oido (nada de monitores, ni teclados, ni ratones...) ¿En qué categoría metemos a un sistema así?, y, ¿con qué lenguaje/entorno/tipo de cliente lo desarrollarías?.

Saludos.

[marto]

pero esa división, entre lo que tú llamas "tecnología web" o "desarrollo tradicional", en función de los lenguajes/entornos de desarrollo, no acabo de ver que exista realmente

Totalmente de acuerdo, pero creo que si dejas a un lado los entornos sí que existe. Yo casi todo lo que desarrollo lo hago en entorno web, y siempre uso Delphi, por tanto está claro que el entorno de desarrollo poco tiene que ver con que el sistema sea web o no. En cambio si que puedes diferenciar entre las aplicaciones de escritorio y las basadas en web, independientemente de en qué estés desarrollando.


incluso desde el punto de vista de los interfaces de usuario, que parece ser lo que se está discutiendo realmente en el hilo

Creo que la gran diferencia está ahí y en el tema de los permisos en la máquina cliente, ya que el resto de cosas se pueden hacer del mismo modo


Acaso no pueden hacerse aplicaciones, con interfaces de usuario orientados exclusivamente a la consola (caracter), con PHP o Java

Po zi, pero creo que la pregunta original iba más enfocada a aplicaciones "clásicas" de gestion


Respecto a lo que dice Roman, es cierto que el la tecnología web aun está en una clara fase de maduración. Tiene una edad mucho más corta que la tecnología de escritorio y por tanto es normal que no esté tan avanzada. De todas maneras, te puedo asegurar (porque lo he hecho :D ) que para desarrollar una aplicación de gestión "típica" como la que propone _iceman, te llega y te sobra con una interfaz web. Si el diseñador domina lo suficiente, ésta será tan usable como una de escritorio. Lo que pasa es en escritorio, quizá sea más fácil o, quizá su domino esté más extendido.

[kinobi]

Hola,

En cambio si que puedes diferenciar entre las aplicaciones de escritorio y las basadas en web, independientemente de en qué estés desarrollando.
En todo caso, lo que se está debatiendo es una sola de las partes de ese tipo de aplicaciones (entiendo que aplicaciones de red), y es la parte cliente. Por cierto: ¿un navegador web no es una aplicación de escritorio? Yo la considero como tal.

Creo que la gran diferencia está ahí y en el tema de los permisos en la máquina cliente, ya que el resto de cosas se pueden hacer del mismo modo
Pues no sé qué decirte, en el sentido que tu comentario es muy ambiguo. Los permisos en una máquina, sea cliente o servidora, debería controlarlos el sistema operativo y no una aplicación de un tercero.

Po zi, pero creo que la pregunta original iba más enfocada a aplicaciones "clásicas" de gestion
Bueno, sí, es posible, pero imagino que, pongamos por caso, un invidente puede tener también la necesidad de utilizar una aplicación "clásica de gestión" y, por tanto, el interface de usuario dependerá poco (en ese sentido "clásico") de las cuestiones visuales.

Saludos.

[marto]

En todo caso, lo que se está debatiendo es una sola de las partes de ese tipo de aplicaciones (entiendo que aplicaciones de red), y es la parte cliente.
Claro, pero es que si debatimos (que es lo que proponía _iceman) sobre la disjuntiva web-escritorio, que son las dos grandes ramas de la programación de gestion (a parte de entornos host tipo AS/400) y siendo conscientes que existen otras alternativas menos extendidas.... ¿ves muchas diferencias a parte del cliente?


Por cierto: ¿un navegador web no es una aplicación de escritorio? Yo la considero como tal.

¿Esto era para provocar, no?:D El navegador, sí lo que se ejecuta en él...


Los permisos en una máquina, sea cliente o servidora, debería controlarlos el sistema operativo y no una aplicación de un tercero.
Hombre, el navegador controla los permisos es cierto pero teóricamente quien establece esos persmisos es la w3c


un invidente puede tener también la necesidad de utilizar una aplicación "clásica de gestión" y, por tanto, el interface de usuario dependerá poco (en ese sentido "clásico") de las cuestiones visuales.

Esa es una gran observación. En el último número de la revista síntesis aparecia un artículo sobre cómo diseñar interfaces sin olvidar que no todos tenemos la suerte de contar con todos lo sentidos al 100%, era muy interesante. Desgraciadamente, creo que la indústria informática aun no ha decidido invertir en eso... ¿será que no es tan rentable? De todos modos, todo se andará....

[kinobi]

Claro, pero es que si debatimos (que es lo que proponía _iceman) sobre la disjuntiva web-escritorio, que son las dos grandes ramas de la programación de gestion (a parte de entornos host tipo AS/400) y siendo conscientes que existen otras alternativas menos extendidas....
Es que no tengo claro qué estamos debatiendo realmente. Tú sostienes que las dos grandes ramas de la programación de gestion son: programación web y programación escritorio (por cierto, dicho sea de paso, no tengo muy claro a qué te refieres concretamente con lo segundo), pero para el caso es lo mismo, porque todo parece llevar, según tu opinión, a que las dos grandes ramas de la programación de gestión (por cierto, imagino que te refieres a gestión empresarial) se diferencian en el, permíteme la licencia, entorno operativo sobre el que se ejecuta la aplicación en el cliente.

Además, el compañero que inició el hilo no ha especificado que su consulta sea referida sólo a la parte cliente, y mucho menos sólo a la parte del interface de usuario. Le cito:


todas las personas con las que me contacto tienen la idea de desarrollar cualquier sistema, sea lo que sea,


Como se ve, ni siquiera especifica que esté hablando de aplicaciones de gestión, dice "cualquier sistema". Cierto es que más adelante habla de un ABM.

¿ves muchas diferencias a parte del cliente?
Por ejemplo: los protocolos que se utilizan para comunicar las diferentes partes de una aplicación distribuida como las que estamos considerando; el tipo de arquitectura: si se utilizan clientes (en cuanto al balance de carga) pesados o ligeros, capas intermedias, mecanismos de intercambio de datos... A lo mejor estoy equivocado, pero me parece que tiene más importancia que el tipo de cliente (sea un navegador web o un proceso nativo para un determinado sistema operativo).

¿Esto era para provocar, no?:D El navegador, sí lo que se ejecuta en él...
Pues no, no intento provocar. Un navegador, presentando código HTML, no ejecuta nada, salvo su propio código para visualizar correctamente el código HTML.

Hombre, el navegador controla los permisos es cierto
En mi sistema desde luego no.

pero teóricamente quien establece esos persmisos es la w3c
¿El W3C? Creo que estamos hablando de cosas distintas. ¿A qué permisos te refieres?

Desgraciadamente, creo que la indústria informática aun no ha decidido invertir en eso... ¿será que no es tan rentable? De todos modos, todo se andará....
Recomendaciones y estándares sí que existen:

http://www.w3.org/TR/UAAG10/
http://www.w3.org/TR/ATAG10/
http://www.w3.org/TR/WCAG10/
http://www.cettico.fi.upm.es/aenor/presenta.htm
http://www.sidar.org/

Saludos.

[marto]

programación web y programación escritorio (por cierto, dicho sea de paso, no tengo muy claro a qué te refieres concretamente con lo segundo),

¿Programa que no se ejecuta en un browser con interfaz grafica? No me gusta mucho la definición, pero para entedernos igual sirve.


por cierto, imagino que te refieres a gestión empresarial
Sí

permíteme la licencia, entorno operativo sobre el que se ejecuta la aplicación en el cliente.

Eso mismo estaba diciendo, sí


Como se ve, ni siquiera especifica que esté hablando de aplicaciones de gestión, dice "cualquier sistema". Cierto es que más adelante habla de un ABM.


cual de estos entornos de desarrollo es el mas apropiado para realizar una aplicacion comun, un sistema de consultas, bajas y altas sobre una base de datos que no necesite realizar grandes tareas de programacion

De todas maneras quizá tendría que ser él quien especifique mejor cuál es su duda ;)


Por ejemplo: los protocolos que se utilizan para comunicar las diferentes partes de una aplicación distribuida como las que estamos considerando; el tipo de arquitectura: si se utilizan clientes (en cuanto al balance de carga) pesados o ligeros, capas intermedias, mecanismos de intercambio de datos... A lo mejor estoy equivocado, pero me parece que tiene más importancia que el tipo de cliente (sea un navegador web o un proceso nativo para un determinado sistema operativo).

En eso tambien estamos de acuerdo, pero todo eso se puede dar tanto si la aplicación es web como si no.


¿El W3C? Creo que estamos hablando de cosas distintas. ¿A qué permisos te refieres?
Pues me refiero, por ejemplo a no poder tocar el sistema de ficheros de la máquina cliente.

[kinobi]

Hola Marto,

¿Programa que no se ejecuta en un browser con interfaz grafica? No me gusta mucho la definición, pero para entedernos igual sirve.
Ahí está el problema, que para entendernos no sirve. Te voy a poner un ejemplo: asumiendo que el mecanismo de publicación en estos foros es una aplicación web (supongo que en eso estaremos de acuerdo), si yo utilizo la misma con un navegador web sin interface gráfica, p. ej. Lynx (aquí tienes un ejemplo de esta misma mañana: http://www.terra.es/personal2/jrodriguezpe/varios/k_lynx.png), la aplicación web se habrá convertido, según tu definición, en una aplicación de esas que tú llamas de "escritorio". En resumen: hay algo que no encaja con esa definición, y lo que no encaja es que la diferencia no está (sólo) en el entorno operativo en el que se ejecute la misma en el cliente (sea un navegador web o una aplicación nativa para un sistema operativo determinado).

En eso tambien estamos de acuerdo, pero todo eso se puede dar tanto si la aplicación es web como si no.
Exacto. Precisamente por eso, considero que las diferencias entre una aplicación web y una aplicación nativa van mucho más allá del entorno de ejecución en el cliente.

Pues me refiero, por ejemplo a no poder tocar el sistema de ficheros de la máquina cliente.
Bueno, el W3C puede dar todas las recomendaciones que considere oportunas sobre como debe comportarse un navegador en esta cuestión, pero no te quepa la menor duda que el entorno sobre el que se ejecutará, el sistema operativo, mantendrá las suyas propias que anularán a las anteriores.

Saludos.

[Iceman]

Pregunto: ¿Alguien ha desarrollado o visto una aplicacion de gestion comercial que tenga, digamos, unas diez terminales en el mostrador facturando al publico sin pausas y otras tantas realizando otras tareas operativas? Seguro que si verdad?
Pues bien cuantos de esos la desarrolló o la vío simplemente, corriendo en un explorador de internet?

Si la respuesta es ninguno, pues bien, ahi tienes amigo Iceman 2, un ejemplo de que TODO no se puede hacer de la NUEVA forma (WEB) y necesitas el VIEJO metodo, por lo demas, creo que hay cosas que si y cosas que no, depende las circunstancias.-

Iceman, el verdadero :)

[marto]

Pregunto: ¿Alguien ha desarrollado o visto una aplicacion de gestion comercial que tenga, digamos, unas diez terminales en el mostrador facturando al publico sin pausas y otras tantas realizando otras tareas operativas? Seguro que si verdad?
Pues bien cuantos de esos la desarrolló o la vío simplemente, corriendo en un explorador de internet?

Yo :cool: , se trataba de la TPV de una gran y conocida cadena de muebles española. Tienen entorno a 100 tiendas por todo el país con una mendia de unas 7-8 cajas por tienda. El cliente quedó más que satisfecho y todo corria en IE. El programa generaba hasta las etiquetas con los códigos de barras de los productos a etiquetar.

Lo que no se puede hacer con un "simple" navegador son cosas bastante reducidads. Tema distinto es que hasta en el colectivo de programadores existan ciertos tópicos sobre lo que se puede y lo que no.

[kinobi]

Si la respuesta es ninguno, pues bien, ahi tienes amigo Iceman 2, un ejemplo de que TODO no se puede hacer de la NUEVA forma (WEB) y necesitas el VIEJO metodo, por lo demas, creo que hay cosas que si y cosas que no, depende las circunstancias.-

Bien, pero ¿qué es eso de el VIEJO metodo? ¿Acaso es desarrollar aplicaciones en ensamblador? ¿Tal vez es sólo una diferencia en el tipo de cliente que ejecuta esas aplicaciones?

Saludos.

[Iceman]

Respuestas x 2:

Para marto: cuando me referia a facturar sin pausas, me referia a algo con mayor volumen de publico que una muebleria, que supongo que no tendran un cliente x min en cada terminal, ya que estimo que en españa seran como aca y para comprar un mueble los clientes se toman su tiempo para decidir :)
Pero, está bien, tampoco quiero generar una polemica por eso, el tema es que bajo esas circunstancias si anda, yo en particular me referia a algo mas rapido. Pero bueno, espero que a Iceman 2 le sirva la respuesta.

Para kinobi: perdon por lo de VIEJO y NUEVO, deberia haber dicho "tradicional" y "web", tal como lo planteo Iceman 2. No tiene connotaciones de asembler ni nada x el estilo.-

[kinobi]

Hola,

Para kinobi: perdon por lo de VIEJO y NUEVO, deberia haber dicho "tradicional" y "web", tal como lo planteo Iceman 2. No tiene connotaciones de asembler ni nada x el estilo.-

Bien, pero sigue siendo el mismo problema.

Imagina una aplicación (cliente/servidor). Ambos se comunican por medio del protocolo HTTP (el utilizado habitualmente en la web), solicitando el cliente servicios (a través de CGI's) en el servidor. Imagina que el cliente (una aplicación, pongamos por ejemplo, construida con Delphi o Kylix) se ejecuta en un sistema empotrado que utilice Windows o Linux.

Pregunta: ¿de qué tipo de aplicación, según vuestra clasificación ("tradicional/web"), estamos hablando?

Saludos.

[marto]

cuando me referia a facturar sin pausas, me referia a algo con mayor volumen de publico que una muebleria, que supongo que no tendran un cliente x min en cada terminal, ya que estimo que en españa seran como aca y para comprar un mueble los clientes se toman su tiempo para decidir :)

No sé de qué país eres.... pero deduzco que nunca has entrado en un Ikea ;)
Te aseguro que el ritmo de ventas es comparable al de un supermercado.


tampoco quiero generar una polemica por eso

¿Y por qué no? Aquí estamos para eso, la polémica es la salsa de la vida :)


yo en particular me referia a algo mas rapido.
Pues no sé a qué te referirás, pero te puedo asegurar que el hecho que el cliente de la aplicación esté basado en web o no no tiene absolutamente nada que ver con la rapidez de la aplicación.
Si crees que no es así.... por qué no nos das algún argumento de lo contrario?
Las diferencias de velocidad son debidas esencialmente a tres factores (si me dejo alguno seguro que kinobi me corrije ;))

-Volumen de datos /volumen de usarios: Afectará del mismo modo si es web o no

-Trafico de red: Contra lo que mucha gente piensa, si se programa bien será el mismo en los dos casos

-Infraestructura de hardware: aquí incluyo el hardware del cliente, el del servidor/es y las redes que haya por medio. En este tema, y en función de las distintas especificaciones, beneficiará a un tipo de cliente o a otro. Pero en ningún caso se puede decir que de forma general penalice más a las aplicaciones web.

Sé que me estoy dejando otros factores, pero creo que llegaríamos a conclusiones similares. Si a alguien se le ocurre alguno en el que no, pues ya sabe.

[Emilio]

En mi caso y por exigencias del guión me ha tocado desarrollar junto a mi compañero toda la aplicación de gestión de una empresa con delegaciones en toda España. La aplicación consta de Gestión de Obras, Pedidos, Contabilidad, Mano de Obra, Almacén así como de un sin fin de pormenores como listados, tablas auxialiares etc...

La aplicación está desarrollada íntegramente en PHP atacando una base de datos DB2 de un AS/400, y es usada simultaneamente por unos 200 PC's

Es cierto que muchas cosas se hacen con muchísima más facilidad con Delphi, no obstante para una aplicación de gestión poco tienes que atacar los recursos del sistema, al lado del cliente usamos JavaScript, aunque bastante pejilguero para mi gusto se pueden hacer con él cosas realmente sorprendentes.

El único tema que no tenemos realmente solucionado es el de los listados, todavía no hemos encontrado una solución tipo Report Builder y que además corra en Linux, los de Digital Metamor... tiene algo pero él servidor sólo corre en Windows.

Por supuesto para hacer programas de gestión de fotos, música y video, sigo usando Delphi, también para otras cosas que ni PHP ni el explorer son capaces todavía de llegar :)

Con esto creo responder a la pregunta de ¿alguno ha visto una aplicación.....?

[marto]

Ah! una nota, los factores que comentaba son suponiendo qua la única diferencia sea la interfaz. Como bien a dicho kinobi, existen muchas otras diferenciias (protocolos, arquitectura, nº capas,...). Pero suponiendo que el resto siga igual, creo que los tiros van sobre lo que decía.

[marto]

Imagina una aplicación (cliente/servidor). Ambos se comunican por medio del protocolo HTTP (el utilizado habitualmente en la web), solicitando el cliente servicios (a través de CGI's) en el servidor. Imagina que el cliente (una aplicación, pongamos por ejemplo, construida con Delphi o Kylix) se ejecuta en un sistema empotrado que utilice Windows o Linux.

Pregunta: ¿de qué tipo de aplicación, según vuestra clasificación ("tradicional/web"), estamos hablando?

Tienes toda la razón. Lo que sucede es que lo que planteó el amigo _iceman (que por cierto no ha vuelto a dar señales de vida) era mucho más sencillo que todo eso. Actualmente muchas de las aplicaciones que tengo que desarrollar con clientes Delphi las hago exactamente con el diseño que tú has explicado y creo que se consiguen muchas de las ventajas de ambos mundos.
Siempre que se hacen simplificaciones se cometen errores, pero es mucho más fácil manejarse en un mundo simplificado que hacerlo con todas las variantes ;)

[marto]

El único tema que no tenemos realmente solucionado es el de los listados, todavía no hemos encontrado una solución tipo Report Builder y que además corra en Linux, los de Digital Metamor... tiene algo pero él servidor sólo corre en Windows.

Pues nosotros sí lo tenemos solucionado, pero con los cgi en delphi, claro. De todas maneras te lo comento porqué igual la idea te "inspira". Generamos los informes con FastReport como si fuese un cliente Delphi, despues los exportamos a pdf y los guardamos en un fichero temporal. llegados a ese munto solamente falta redireccionar al navegador hacia el fichero creado. Con una tarea programada se borran los ficheros cada noche y listos.

[Iceman]

En el ámbito en el cual me desenvuelvo (facultad), todas las personas con las que me contacto tienen la idea de desarrollar cualquier sistema, sea lo que sea, con tecnología WEB (html, php, java, etc.), y dejaron de lado el desarrollo tradicional (Delphi, Visual C, Builder, Visual Fox),


Segun Iceman 2:
Tecnologia Web: html, php, java, etc
Desarrollo Tradicional: Delphi, Visual C, Builder, Visual Fox.

Segun esta division, quiero suponer que cuando se referia a tecnologia Web, imaginaba una aplicacion que se ejecuta en un explorador de internet desarrollada basicamente con las herramientas descriptas, y cuando se referia a desarrollo tradicional se imaginaba un EXE para Win32 hecho con las otras herramientas.

Al menos a mi me sonó asi. No dudo de que lo que han planteado precedentemente es asi, y las aplicaciones funcionan, pero les digo algo que los que no son argentinos desconocen seguramente: "Uds. no saben lo que son programar un sistema de facturacion con nuestras benditas impresoras fiscales " :)

Mas allá de todo, creo que cuando uno tiene que hacer un sistema, que generalmente es para AYER, si es un especialista en Delphi, aun si es un sistema perfecto para hacerlo en php, lo exprime al pobre Delphi y lo termina haciendo con el "desarrollo tradicional" como lo define Iceman 2, y por el contrario si es un avezado desarrollador Web, aunque el sistema conste de un menu y tres ABM que se pueden hacer con el asistente de Delphi, buscará hacerlo con PHP. Simplemente por una cuestion de que pone sobre la mesa la seguridad que dá hacer las cosas con las herramientas que mas se domina. Ahora, si se dominan ambos mundos, pues preguntenle, no es mi caso :)

Iceman, el verdadero

[marto]

Mas allá de todo, creo que cuando uno tiene que hacer un sistema, que generalmente es para AYER....
Pues llevas parte de razón todos vamos fatal con las fechas de entregas. No obstante, creo que con esa filosofía aun estaíamos "exprimeindo" al pobre clipper. Nadie es experto en nada hasta que se pone a investigarlo y pasa un tiempo de pinche, pero esto sería fuente de otro debate.

[jachguate]

y pasa un tiempo de piche
Y esto que quiere decir???? me he matao de la risa... pues en mi pueblo, piche = coño!!!

no creo que te la pases de la manera que me he imaginao... :eek: :D :D

[marto]

Y esto que quiere decir???? me he matao de la risa... pues en mi pueblo, piche = coño!!!

no creo que te la pases de la manera que me he imaginao... :eek: :D :D
jajajaajajaja

no... ojalá!:D :D quería decir pinche!!!!

[perrogrun]

Hola a todos, vereis yo soy "programador web" bueno si eso significa algo, a lo que me refiero es que programo más en asp y lenguajes de páginas activas que en delphi o en otros entornos parecidos.

En cuanto a la capacidad del desarrollo Web, como lo denomina iceman en el inicio del debate, estoy de acuerdo en que está limitada, tanto por la velocidad de línea del cliente, como de la fiabilidad que te de el servidor donde tienes alojada la aplicación (dile a un cliente que su sistema no va porque hay una cosa que se llama servidor que no depende de ti y que no puedes hacer nada para solucionarlo hasta que a los del servidor les de por solucionar tu problema).

En mi empresa he desarrollado una aplicación inmobiliaria el la que más de un ciento de inmobiliarias meten, sacan, actualizan, hacen carteles, cofiguran su web, configuran sus paneles de control, comparten propiedades, controlan a sus agentes, comparten clientes, acceden al servicio de mensajería... y además todos los usuarios de las webs acceden al mismo sistema para ver las webs de cada cliente en particular. Todo esto con imágenes en bases de datos (mas de 5.000 de 60Kb), panorámicas, etc. Por lo tanto, la potencia de estas aplicaciones está probada, pero el gran problema no esta del lado digamos del servidor, sino de las capacidades del cliente. Imagina que se le corta la conexión a internet. Una empresa no se puede paralizar porque se les corte la conexión, esto no es fiable. Por eso la solución (por lo menos la que yo veo) es combinar ambar técnicas. Crear una aplicació web (siempre que se pueda por las carencias que antes habeis comentado) y tener una "aplicación de escritorio" a modo local de "urgencia" para cuando no funcione la conexión o exista algún problema a modo de "salvavidas".

En cuanto a lo de los listado en las aplicaciones webs también se pueden hacer (y yo creo que de manera sencilla, depende del lenguaje que utilices) yo personalmente para hacer listados siempre utilizo el Word. ¿Por qué? Porque desde, por ejemplo asp, puedes presentar una web en el navegador o abriendo el word y presentándola en él, así para el cliente es una forma más familiar de visualizar los listados, los puede modificar, guardar en su disco duro, etc. Ahora si ya me sacais de windows no tengo idea como se vería esto que os digo en linux u otro sistema operativo diferente de windows.

En lo que sí estoy de acuerdo es en que una aplicación de "escritorio" es mucho más segura que una aplicación web, pero mucho más, aunque las aplicaciones web si que tienen otra ventaja que no habeis comentado y es que el cliente se OLVIDA de las copias de seguridad de sus datos, ya que la mayoría de los servidores, y cuando digo servidores me refiero a empresas de hosting serias, hacen copias de seguridad de todo tu sitio día a día y las puedes recuperar hasta con un mes plazo.

[kinobi]

Hola,

En cuanto a la capacidad del desarrollo Web, como lo denomina iceman en el inicio del debate, estoy de acuerdo en que está limitada, tanto por la velocidad de línea del cliente,
No veo la relación entre la línea del cliente y la "limitación" de una "aplicación web" frente a eso que llamáis "aplicaciones de escritorio". Me temo que distinguís las "aplicaciones web" como aplicaciones de "conexión remota" (un cliente y un servidor en máquinas diferentes) frente a "aplicaciones de escritorio" que se ejecutan en una "conexión local" (sólo hay una máquina). Pero esto no es realmente así, puedo tener un servidor web y un cliente (pongamos un navegador web) ejecutándose ambos en la misma máquina, y una "aplicación de escritorio" conectándose a un servidor (p. ej. de base de datos) a miles de kilómetros de distancia. De hecho no es una situación tan extraña.

Nota: entrecomillo "aplicación web" y "aplicación de escritorio" por seguir usando vuestra terminología.

como de la fiabilidad que te de el servidor donde tienes alojada la aplicación (dile a un cliente que su sistema no va porque hay una cosa que se llama servidor que no depende de ti y que no puedes hacer nada para solucionarlo hasta que a los del servidor les de por solucionar tu problema).
¿Acaso eso que llamáis "aplicaciones de escritorio" no se conectan a servidores (de bases de datos, de transferencia de archivos, de autenticación, ...) que no dependen de vosotros?

Imagina que se le corta la conexión a internet. Una empresa no se puede paralizar porque se les corte la conexión, esto no es fiable. Por eso la solución (por lo menos la que yo veo) es combinar ambar técnicas. Crear una aplicació web (siempre que se pueda por las carencias que antes habeis comentado) y tener una "aplicación de escritorio" a modo local de "urgencia" para cuando no funcione la conexión o exista algún problema a modo de "salvavidas".
¿Acaso no es posible ejecutar el servidor web y el servidor de base de datos en el cliente para cuando suceda tal contigencia? De hecho es una situación habitual en muchas LAN's.

yo personalmente para hacer listados siempre utilizo el Word. ¿Por qué? Porque desde, por ejemplo asp, puedes presentar una web en el navegador o abriendo el word y presentándola en él, así para el cliente es una forma más familiar de visualizar los listados, los puede modificar, guardar en su disco duro, etc. Ahora si ya me sacais de windows no tengo idea como se vería esto que os digo en linux u otro sistema operativo diferente de windows.
Bien, tú has optado por una solución "propietaria" (el uso de Word) para la presentación de tus listados, frente a otro tipo de soluciones "abiertas" y de caracters "universal". Desde luego no hay nada que criticar en ello. La única premisa es que tus clientes tendrán que adquirir, si no lo han hecho ya, sus correspondientes licencias de Word, además de trabajar en un sistema operativo que permita ejecutar dicho software. Esto último sí que choca con uno de los objetivos de diseño de la web: la neutralidad de la plataforma en la que se presentan los documentos (esto incluye el sistema operativo y la no obligatoriedad de utilizar clientes gráficos).

En lo que sí estoy de acuerdo es en que una aplicación de "escritorio" es mucho más segura que una aplicación web, pero mucho más,
Aquí sí que estoy perdido. No logro intuir siquiera en qué sentido y cómo puede ser más segura una "aplicación de escritorio" frente a una "aplicación web". Juraría que una "aplicación web" puede utilizar cualquier mecanismo de seguridad que pueda utilizar una "aplicación de escritorio": autenticación, cifrado, respaldo de datos, ...

Saludos.

[perrogrun]

Hola kinobi, veo que eres una persona a la que le gusta el cambio de ideas, me alegro.

Kinobi;
Me temo que distinguís las "aplicaciones web" como aplicaciones de "conexión remota" (un cliente y un servidor en máquinas diferentes) frente a "aplicaciones de escritorio" que se ejecutan en una "conexión local" (sólo hay una máquina)
Yo creo que el debate está en aplicaciones creadas para trabajar con ellas en una "página web" mediante un navegador (Asp, php, coldfusion,... ), no aplicaciones cliente-servidor.Sinceramente creo que ese es el debate.

Kinobi
¿Acaso eso que llamáis "aplicaciones de escritorio" no se conectan a servidores (de bases de datos, de transferencia de archivos, de autenticación, ...) que no dependen de vosotros?
Totalmente de acuerdo pero yo creo, como digo arriba, que no estamos discutiendo las aplicaciones cliente-servidor, sino las "aplicaciones web" (asp,php,...)


Kinobi
¿Acaso no es posible ejecutar el servidor web y el servidor de base de datos en el cliente para cuando suceda tal contigencia? De hecho es una situación habitual en muchas LAN's.
¿Y como haces para tener actualizada la aplicación del lado del servidor local del cliente?

Kinobi
La única premisa es que tus clientes tendrán que adquirir, si no lo han hecho ya, sus correspondientes licencias de Word
¿Y quién no tiene word hoy en día en su empresa?¿Tú no tienes word (perdona que te tutee)?

Kinobi
Esto último sí que choca con uno de los objetivos de diseño de la web: la neutralidad de la plataforma en la que se presentan los documentos (esto incluye el sistema operativo y la no obligatoriedad de utilizar clientes gráficos).

El objetivo real que tiene cualquier aplicación es la rentabilidad tanto para el cliente como para la empresa que lo desarrolla, si me ahorro tiempo de trabajo y el cliente se ahorra tiempo de aprendizaje, es dinero ahorrado por ambas partes.

Kinobi
Aquí sí que estoy perdido. No logro intuir siquiera en qué sentido y cómo puede ser más segura una "aplicación de escritorio" frente a una "aplicación web".
Seguro que no estás tan perdido, imáginate una aplicación que corre en una Lan o en una máquina a modo local, los usuarios que pueden acceder a ella son "pocos" o por lo menos conocidos y todos pertenecientes a la Lan (además si la Lan no tiene acceso a Internet mucho más segura será), sin embargo, las "aplicaciones web" están diseñadas para trabajar en Internet, con lo que eso significa. En mi aplicación, tengo un registro en la página de login, ¿sabes cuantos intentos de sql injection que he sufrido en la última semana desde ips muy diferentes? Muchísimas. ¿Sabes cuantos correos engañosos reciben mis clientes pidiendo claves? Muchísimos. Cuando me refiero a seguridad me refiero también a estos aspectos, ahora, que le puedas poner mecanismos de seguridad como a las "aplicaciones de escritorio" y muchos más, estoy de acuerdo.Esto, si mi aplicación corre en una Lan sin acceso a Internet no ocurre.

[marto]

Yo creo que el debate está en aplicaciones creadas para trabajar con ellas en una "página web" mediante un navegador (Asp, php, coldfusion,... ), no aplicaciones cliente-servidor.Sinceramente creo que ese es el debate.
....
Totalmente de acuerdo pero yo creo, como digo arriba, que no estamos discutiendo las aplicaciones cliente-servidor, sino las "aplicaciones web" (asp,php,...)
El debate es sobr lo que queramos interpretar del mensage de _iceman, que no ha vuelto a aparecer. En cualquier caso, él hablaba de dos tipos de aplicaciones: las que como tu dices se ejecuntan en un navegador y las cliente-servidor o "clásicas" como decía él, pero se trataba de compararlas, no entiendo por qué tú dices que solo trata sobre las primeras


¿Y como haces para tener actualizada la aplicación del lado del servidor local del cliente?
¿Y cómo lo haces si el cliente está hecho en Delphi?

¿Y quién no tiene word hoy en día en su empresa?¿Tú no tienes word (perdona que te tutee)?
Lamentablemente, ese es uno de los argumentos más usados para justificar los abusos de M$.... ¿alguna vez has oído la frase "la democracia se basa en el respeto a las minorías"?

El objetivo real que tiene cualquier aplicación es la rentabilidad tanto para el cliente como para la empresa que lo desarrolla
Bueno, eso sería otro debate, pero normalmente, si generalizas tanto, te equivocas.

, si me ahorro tiempo de trabajo y el cliente se ahorra tiempo de aprendizaje, es dinero ahorrado por ambas partes.
Si seguimos con analisis tan simplistas, al final, volveremos al trueque


Seguro que no estás tan perdido
¿Kinobi?... seguro que no ;)

, imáginate una aplicación que corre en una Lan o en una máquina a modo local, los usuarios que pueden acceder a ella son "pocos" o por lo menos conocidos y todos pertenecientes a la Lan
Si los argumentos que justifican la seguridad o no de una aplicación se basan en quien tiene acceso físico a la misma, volvamos todos a ms-dos, dormiremos más tranquilos.

(además si la Lan no tiene acceso a Internet mucho más segura será), sin embargo, las "aplicaciones web" están diseñadas para trabajar en Internet,
Lo siento, pero eso no es cierto. Confundes la arquitectura del soft (web o no) con la red en la que se ejecuta (LAN, WAN...). El cliente de una aplicación web está "diseñado" para ejecutarse en un navegador, eso poco tiene que ver con si las peticiones las hace via internet, a un servidor de su LAN o a localhost.

¿sabes cuantos intentos de sql injection que he sufrido en la última semana desde ips muy diferentes? Muchísimas. ¿Sabes cuantos correos engañosos reciben mis clientes pidiendo claves? Muchísimos.
Eso no tiene nada que ver con que tu aplicación sea web o no, si no con que esté "colgada" de internet.

[perrogrun]

Mira que os gusta sacarle punta a todo, hay que escribir un un lápiz de punta fina. La cuestión es que comprendais lo que yo quiero decir, lo único que quiero es transmitir mis experiencias a las personas que se planteen si hacer una aplicación de una manera u otra, no hacer alardes de sabiduría porque entre otras cosas seguro que vosotros sabeis más que yo.

marto
¿Y cómo lo haces si el cliente está hecho en Delphi?

La aplicación delphi a modo local es sólo de urgencia y sólo (en mi caso) muestra propiedades para que la inmobiliaria no se quede parada, naturalmente han de bajarse la base de datos todos los días para estar actualizados, el resto de funciones de la aplicación han de hacerse en web.

marto
Lamentablemente, ese es uno de los argumentos más usados para justificar los abusos de M$.... ¿alguna vez has oído la frase "la democracia se basa en el respeto a las minorías"?

Estoy totalmente de acuerdo contigo, pero ¿quién le dice eso a mi jefe?¿o mejor dicho, quién le hace comprender que tiene que perder dinero y tiempo? Si por mí fuese no utilizaría casi nada de M$ pero ya se sabe. Yo no mando, a mi me mandan. La empresa no es mía y hay que acatar la filosofía de la empresa ( más que nada por mi hipoteca y esas cosas ).

marto
Si los argumentos que justifican la seguridad o no de una aplicación se basan en quien tiene acceso físico a la misma, volvamos todos a ms-dos, dormiremos más tranquilos.

Como tú dices no seas simplista, entiende lo que quiero decir.


marto
Lo siento, pero eso no es cierto. Confundes la arquitectura del soft (web o no) con la red en la que se ejecuta (LAN, WAN...). El cliente de una aplicación web está "diseñado" para ejecutarse en un navegador, eso poco tiene que ver con si las peticiones las hace via internet, a un servidor de su LAN o a localhost.

No has entendido lo que quiero decir. O no me quieres entender o seguramente me habré expresado mal. Estoy de acuerdo con lo que dices, es obvio, pero no es lo mismo tener x potenciales ataques que tener x elevado a 100 potenciales ataques. ¿No se si me entiendes?


marto
¿Kinobi?... seguro que no

Eres un cachondo, no quería faltarle el respeto a nadie y menos a los moderadores como tú o kinobi, ya que gracias a vosotros todos aprendemos muchísimo, la verdad es que debemos daros las gracias.
Pues eso, gracias.

[marto]

Mira que os gusta sacarle punta a todo,
Po zi ;)

La cuestión es que comprendais lo que yo quiero decir, lo único que quiero es transmitir mis experiencias a las personas que se planteen si hacer una aplicación de una manera u otra,
Y se agradece, pero entiende que tú has reducido el tema las aplicaciones web colgadas de internet, y eso es reducir mucho.

no hacer alardes de sabiduría porque entre otras cosas seguro que vosotros sabeis más que yo.
Aquí nadie hace alardes, cada uno pone lo que sabe o lo que cree para intentar ayudar a enriquecer el debate, y todas las opiniones son beienvenidas


La aplicación delphi a modo local es sólo de urgencia y sólo (en mi caso) muestra propiedades para que la inmobiliaria no se quede parada, naturalmente han de bajarse la base de datos todos los días para estar actualizados, el resto de funciones de la aplicación han de hacerse en web.
No me refería a eso. Lo que quería decir es que el problema de las actualizaciones viene de siempre. Evidentemente, si tu montas, por ejemplo, el servidor web de la aplicación dentro de la LAN del cliente, actualizarlo posiblemente te será más costoso que si lo tienes en internet. Pero sigue siendo menos tedioso que actualizar un cliente hecho en Delphi que ataque a un servidor en la propia LAN.


Estoy totalmente de acuerdo contigo, pero ¿quién le dice eso a mi jefe?
Yo no, desde luego ;)... no, en serio, eso lo tenemos que sufrir muchos y sé que no todos tenemos las mismas armas de luchas. Sin ir más lejos, yo desarrollo en Delphi, sobre windows, y la intranet, para IE :mad: :mad:

¿o mejor dicho, quién le hace comprender que tiene que perder dinero y tiempo?
bueno, eso también es bastante discutible, depende de lo que se considere "perder tiempo y dinero" (¿o crees que las empresas que se basan en soft open source son todas tontas?)

No has entendido lo que quiero decir. O no me quieres entender o seguramente me habré expresado mal. Estoy de acuerdo con lo que dices, es obvio, pero no es lo mismo tener x potenciales ataques que tener x elevado a 100 potenciales ataques. ¿No se si me entiendes?
Sí, si que te entiendo, pero el número de ataques potenciales depende más de dónde se ejecute la aplicación que de si ésta es web o no.... ¿o solamente se puede trabajar con internet en aplicaciones de interfaz web?


Eres un cachondo,
gracias ;)

no quería faltarle el respeto a nadie y menos a los moderadores como tú o kinobi, ya que gracias a vosotros todos aprendemos muchísimo, la verdad es que debemos daros las gracias.
tranquilo, solamente era un guiño, nunca lo entendí como una falta de respeto.:)

[kinobi]

Hola,

Totalmente de acuerdo pero yo creo, como digo arriba, que no estamos discutiendo las aplicaciones cliente-servidor, sino las "aplicaciones web" (asp,php,...)
Y qué es una aplicación web sino una aplicación cliente/servidor.

aplicación web <-> servidor http <-> // red (wan/lan/*) // <-> cliente (p.ej. navegador)

(*) No necesariamente tiene que existir una red física, puede estar dentro de la misma máquina todos los procesos (servidores y clientes).

Juraría que el esquema anterior corresponde a una aplicación cliente/servidor

¿Y como haces para tener actualizada la aplicación del lado del servidor local del cliente?
Siento tener que responder con otra pregunta:

¿Y cómo haces para tener actualizada la aplicación ("de escritorio") en tu cliente?

¿Y quién no tiene word hoy en día en su empresa?¿Tú no tienes word (perdona que te tutee)?
No hay problema por el tuteo, al contrario.

Pues no, no tengo Word. Y aunque lo tuviera no podría ejecutarlo, ya que no tengo Windows, uso Linux.

Esto último sí que choca con uno de los objetivos de diseño de la web: la neutralidad de la plataforma en la que se presentan los documentos (esto incluye el sistema operativo y la no obligatoriedad de utilizar cliente

El objetivo real que tiene cualquier aplicación es la rentabilidad tanto para el cliente como para la empresa que lo desarrolla, si me ahorro tiempo de trabajo y el cliente se ahorra tiempo de aprendizaje, es dinero ahorrado por ambas partes.
Pues no, ese es el objetivo real tuyo. No todo el mundo desarrolla software para cumplir los mismos objetivos. E insisto: uno de los objetivos de diseño de la web: la neutralidad de la plataforma en la que se presentan los documentos (esto incluye el sistema operativo y la no obligatoriedad de utilizar cliente gráfico). Otro asunto es que a tí no te interese, por la razón que sea, mantener esa neutralidad.

Seguro que no estás tan perdido, imáginate una aplicación que corre en una Lan o en una máquina a modo local, los usuarios que pueden acceder a ella son "pocos" o por lo menos conocidos y todos pertenecientes a la Lan (además si la Lan no tiene acceso a Internet mucho más segura será), sin embargo, las "aplicaciones web" están diseñadas para trabajar en Internet, ...
Sí, "las "aplicaciones web" están diseñadas para trabajar en Internet", y también hay "aplicaciones que no son para web" que están diseñadas para trabajar también en internet, y "aplicaciones web" diseñadas para trabajar en redes de área local... En fin, que sigo sin ver la relación entre una cosa y otra.

Saludos.

[perrogrun]

Hola kinobi.

Kinobi
Pues no, ese es el objetivo real tuyo.
El mío no el de mi empresa, no olvides que yo hago lo que me oredenan. (Subdito, esclavo o programador sin decisión)

]Kinobi
No todo el mundo desarrolla software para cumplir los mismos objetivos. E insisto: uno de los objetivos de diseño de la web: la neutralidad de la plataforma en la que se presentan los documentos (esto incluye el sistema operativo y la no obligatoriedad de utilizar cliente gráfico). Otro asunto es que a tí no te interese, por la razón que sea, mantener esa neutralidad.

Te vuelvo a repetir, a mi personalmete sí me interesaría mantener esa neutralidad y tener tiempo para poder trabajar sobre otros sistemas como tú pero la verdad es que trabajo 11 horas al día entre los dos trabajo que tengo para pagar al banco, por eso, pero si me dicen que debo diseñar para uno clientes que todos tienen windows, word y explorer, pues lo tengo que hacer sin rechistar (lo que te digo: hay veces que te sientes un mero traductor entre lo que te mandan y lo que desarrollas, no hay opción a opinar).

Ya me imaginaba que no funcionabas en windows porque he leido el foro entero, pero date cuenta de que la gente (por lo menos la que yo conozco) utilizan en un 99.8% sistemas de M$. Es duro pero lo que te voy a decir es cierto: me imagino yendo a uno de esos clientes que tengo, que no saben casi nada de informática ( ni tienen porqué ) y diciéndoles: Hola señor xxxxx que tal, le voy a instalar linux y ahora póngase a aprender como funciona, olvídese de todos los programas que manejaba hasta ahora y esas bases de datos access hágalas de nuevo en otro sistema de bases de datos. Sólo de imaginarme su cara me dan temblores. Seguro que hay alguno que me echararía a partadas de su empresa ;) con lo "apretaos" que somos en el sur no me extrañaría nada. :D

Marto
depende de lo que se considere "perder tiempo y dinero" (¿o crees que las empresas que se basan en soft open source son todas tontas?)
Obviamente no creo que todas las empresas de open source sean tontas, no seas simplista. Lo que para mi empresa es "perder tiempo y dinero" es que si se puede hacer en menos tiempo y eso es trabajar con productos M$, se trabaja con productos M$ que son los que tiene todo el mundo.
Y quiero dejaros claro que es la filosofía de mi empresa no la mía, y que cuando digo "mi empresa" significa la empresa donde yo trabajo, no es que sea mía, ya me gustaría a mi :D

[kinobi]

Hola,

Te vuelvo a repetir, a mi personalmete sí me interesaría mantener esa neutralidad y tener tiempo para poder trabajar sobre otros sistemas como tú pero la verdad es que trabajo 11 horas al día entre los dos trabajo que tengo para pagar al banco, por eso, pero si me dicen que debo diseñar para uno clientes que todos tienen windows, word y explorer, pues lo tengo que hacer sin rechistar (lo que te digo: hay veces que te sientes un mero traductor entre lo que te mandan y lo que desarrollas, no hay opción a opinar).

Yo no critico que desarrolles software teniendo en mente a Windows, o aplicaciones de Microsoft, faltaría más. Lo único que estoy diciendo, y supongo que estaremos de acuerdo, es que la web (y genéricamente Internet) no presupone que debas tener (obligatoriamente) software de determinada compañía para poder visualizar un documento. Precisamente uno de los objetivos de diseño de la Red es la interconexión de sistemas heterogéneos.

Que para una solución particular tuya decidas apoyarte en MS-Word no me parece ni bien ni mal, es tu opción (tuya o de tus jefes). Ahora bien, siendo una opción personal y particular para un caso concreto, no puede considerarse una solución genérica.

De todas formas, esto no forma parte del debate de este hilo.

Saludos.

[perrogrun]

Estamos de acuerdo, esto no forma parte de este debate, me he desviado un poco.

[cmena]

hola:

podrias extenderte un poco en las cosas que no se pueden hacer en web

incluyendo el tema de seguridad

Wop!

Compañero tu pregunta es la del millón de dolares ;) Recuerdo que cuando empezaba en esto (tampoco hace tanto... parezco un viejo :rolleyes: ) la discusión con los compañeros siempre era cuál era el mejor lenguaje, el mejor entorno. Con el tiempo te das cuenta que no existe ninguna panacea: tienes que saber escojer en función de tus necesidades, ya que cada uno es mejor que otros en alguna cosa (menos VB, que no se me ocurre en qué :D ).

En el tema que tú planteas pasa un poco lo mismo. La web como plataforma de desarrollo de aplicaciones (fin para el que no fue diseñada) tiene grandes ventajas y grandes inconvenientes sobre las aplicaciones de escritorio. Creo que lo mejor que se puede hacer es plantear los pros y los contras y que cada uno llegue a sus conclusiones.

Por un lado, las aplicaciones web pueden ser absolutamente portables en cuanto al cliente. Si necesitas desarrollar para windows, linux,... un mismo programa es mucho más fácil desarrollar un cliente compatible con distintos navegadores que uno de escritorio para distintos SO (a no ser que lo hagas en java, pero entonces necesitarás que a tus clientes les salga la RAM por las orejas).
Otra ventaja de la web es el hecho de no tener que instalar nada en el cliente, excepto el navegador, pero normalmente éste ya está en todos los ordenadores. En relación con este punto tambien hay que destacar que, si se hacen actualizaciones, los usuarios tendrán la última versión al momento mientras que cualquier programador con experiencia te puede explicar los dolores de cabeza que dan estos procesos en las aplicaciones de escritorio.
En mi opinoón la web aun tiene otra ventaja (y seguro que me dejo alguna), se trata de la movilidad. Cualquier persona se puede ir a un cybercafé y acceder al programa... desde Barcelona o desde Cali.

Bien, hasta aquí las bondades de la web. ¿En qué creo que sale victorioso el desarrollo de escritorio? Pues en primer lugar, es mucho más rápido y fácil (de momento) desarrollar una interfaz de escritorio que una web. Además, si ésta requiere cierta complejidad, existen límites a los que es muy complicado llegar en web.

Por último, y esto más que una vetaja es una diferencia crítica, hay cosas que en web no se pueden hacer. Principalmente son limitaciones de seguridad (aunque nuevas tendencias como las aplicaciones HTA las están dejando atrás). Básicamente el tema es que en web no puedes acceder a muchos de los recursos de la máquina cliente que en escritorio sí.

Mi conclusión, en general, es que, si se puede hacer web, así lo hago, ya que para mí sus ventajas pesan más que sus contras. Pero si las exigencias del guión me piden segun que cosas.... entonces hay que ir a lo "tradicional"

[marto]

hola:

podrias extenderte un poco en las cosas que no se pueden hacer en web

incluyendo el tema de seguridad
Wop!

Bueno, existen dos tipos de limitaciones cuando se desarrolla un cliente web: las referentes a la propia interfaz y las relacionadas con las restricciones del entorno en el que se ejecuta.

Limitaciones en la interfaz hay muchas, por ejemplo, ¿has probado hacer una ventana modal?. Existen dos opciones, o lo haces mediante capas (y eso supone un trabajo considerable) o tiras de la funcion ShowModalDialog, pero resulta que esta función tiene dos problemas: actualmente solamente está disponible para IE y consume una cantidad de memoria incomprensible. Otro caso pareceido es el de las aplicaciones MDI. Existen frameworks como el Bindows de webfx (http://webfx.eae.net) que te permiten hacer este tipo de aplicaciones pero aun no tienen toda la potencia a la que estmos acostumbrados en GUI y además consumen muchos recursos. Como estos. existen otras limitaciones.

El otro tipo de limitación, el de las restricciones del entorno, (a esto me refería cuando hablaba de seguridad) se refiere a qué recursos del sistema local están a nuestra disposición. Algunos ejemplos són: la escritura de ficheros en local, el acceso al registro en Windows o el acceso a los procesos que están corriendo.

En mi caso particular, como el 90% de mis aplicaciones son de gestión, las restricciones de seguridad prácticamente no me afectan. Respecto a las la interfaz, sencillamente me pesan más los pros que los contras.

[haron]

lo unico que hecho de menos al hacer aplicaciones webs, son el diseño de las interfaces rapidas que se hacian con Delphi.

como no puedo usar el DrimGüevo en Linux, tengo que ensuciarme las manos con el hml para hacer las jodidas interfaces.

con lo facil que era, pinchar y soltar.

ahora le estoy dando vueltas a una herramienta de Sun, Visual Creator, que utiliza la tecnica de pinchar y soltar para desarrollar interfaces.
parece una herramienta muy prometedora.

si alguien conoce una herramienta para linux que te permita crear interfaces de forma muy rapida y sin tener que pringarte con el html, por favor me lo diga.

[perrogrun]

Me encanta ver este hilo casi 8 años después. Finalmente sigo siendo programador web y sigo haciendo aplicaciones web.

Un saludo a todos los participantes!!!

[Al González]

Me encanta ver este hilo casi 8 años después. Finalmente sigo siendo programador web y sigo haciendo aplicaciones web.

Un saludo a todos los participantes!!!
Ya casi nueve años y todavía la gran mayoría de las aplicaciones de software que le dan vida a las empresas e instituciones de todo el mundo siguen siendo de escritorio. Debe haber alguna razón detrás de ello. ;)

Como dicen por ahí, el desarrollo Web va ocupando cada vez más y mejor su nicho, pero mal hace el que se cierra a una sola tecnología y quiere resolverlo todo con su lenguaje favorito. :)

[Chris]

Que nostalgia encontrarse con un hilo tan viejo... :)

[Ñuño Martínez]

¡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".

[fer21unmsm]

¡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.

[mamcx]

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).