¿Por qué seguimos usando el DOM en el navegador en lugar de un paradigma de escritorio?


11

Según tengo entendido, la interfaz web se desarrolló para usar HTML porque en ese momento no era posible simular una aplicación de estilo de escritorio en el navegador, como el funcionamiento de Silverlight y Flash, debido a las limitaciones de ancho de banda y posiblemente la potencia de procesamiento.

¿Por qué no ha habido en el pasado, y el presente ha sido una mayor aceptación y empuje para tecnologías como Flash / Silverlight? Según mi experiencia, es más agradable desarrollarlos (por supuesto, mi opinión), y no tiene que lidiar con el cumplimiento cruzado del navegador y los navegadores más antiguos (en su mayor parte).

El manejo de postbacks, AJAX, etc. parece un esfuerzo innecesario adicional en comparación con el paradigma de desarrollo de aplicaciones de escritorio. ¿El DOM y sus tecnologías complementarias continúan prosperando principalmente por el hecho de que Silverlight / Flash requiere una instalación de complemento, y algunos dispositivos móviles no son compatibles con el complemento?


1
Porque el DOM no es un ciudadano de segunda clase. Silverlight y flash son abstracciones con fugas. Puede tener fácilmente aplicaciones de escritorio nativas como el DOM en el usuario del navegador. Simplemente se desempeña e integra mejor que flash o silverlight.
Raynos

Respuestas:


17

Algunas razones que puedo pensar, fuera de mi cabeza:

  • La pila web tradicional es bastante madura en estos días; los navegadores modernos tienen muy pocas peculiaridades, y diseñar sitios web para ellos es relativamente agradable, en comparación con hace solo 5 años
  • Si bien existen diferencias entre los navegadores, son menos relevantes que las diferencias entre el sistema operativo subyacente y el hardware
  • El paradigma de solicitud / respuesta en realidad funciona muy bien para muchas cosas, como presentar contenido de texto pesado
  • Los motores de búsqueda no están exactamente interesados ​​en contenido Flash o Silverlight
  • Flash y Silverlight están controlados por una sola compañía; usarlos significa que el futuro soporte de plataforma para su código está a merced de estas compañías
  • Muchas cosas que puede hacer con HTML no se pueden hacer con complementos: piense en marcadores, copie y pegue, traducción sobre la marcha, hojas de estilo personalizadas
  • Los complementos no funcionan bien con navegadores no estándar: piense en navegadores de texto, navegadores de audio y en la amplia gama de otros dispositivos que pueden mostrar páginas web
  • No puede automatizar fácilmente clientes Flash o Silverlight, mientras que manejar sitios web HTML desde scripts suele ser bastante sencillo.

Una cosa más que se me ocurre: estos complementos no son de código abierto. Y algunas personas simplemente no confían en las cosas, con las que no pueden hacer nada git clone. Por supuesto, puede obtener versiones de código abierto, como Gource o Moonlight, pero en realidad no son totalmente compatibles.
Dr. McKay

2
De hecho, había pensado en el argumento del código abierto, pero no pensé que fuera un problema lo suficientemente grande, en el mundo real (no importa cuán grande sea un fanático de FOSS, yo mismo). El argumento 'a merced de una sola compañía' está relacionado de alguna manera, y es significativo.
tdammers

4

La respuesta simple a "Por qué no hay aplicaciones de escritorio en Flash" es que solo puede escribirlas en Adobe Air, pero aparentemente solo unas pocas lo hacen.

Creo que la respuesta es que las personas quieren aplicaciones web , no aplicaciones Flash llamativas, y quieren que las aplicaciones web tengan el mismo tamaño que todas las demás aplicaciones web que usan. Personalmente, quiero poder usar un Flashblocker y aún tener la funcionalidad completa de la aplicación.


3

Este es un efecto muy común en nuestra industria.
Por ejemplo, personalmente uso haXe e implemento mi código de cliente en Flash Player, porque en mi humilde opinión, es la mejor plataforma web habilitada a la que puedo dirigirme. Una vez que finalice el backend de C #, probablemente verifique si vale la pena usar Silverlight, aunque mi sensación personal es que murió antes de que despegara.

Al estar muy contento con mi elección de idioma, una cosa que me pregunto a menudo es: ¿por qué no más desarrolladores web usan un lenguaje de código abierto, multi-paradigma, expresivo y multiplataforma?

Hay muchas razones, pero siempre son las mismas. Una válida es la preferencia personal. Pero a menudo se trata de ignorancia o renuencia hacia las tecnologías nuevas / nicho.
Cuando se trata de Flash, tuve numerosos argumentos sobre por qué tiene su lugar y por qué usarlo. La mayoría de las personas argumentan que el objetivo de Flash es crear sitios sofisticados que se carguen por años y funcionen horriblemente (y difundan mucha otra información errónea).
De hecho, lo contrario es cierto y aplicaciones como Aviary Phoenix o Sliderocket y juegos como Koyotl y Tanki Online lo demuestran. Flash es una plataforma madura para crear una experiencia de escritorio en el navegador.

Al final, demasiadas decisiones estratégicas son tomadas por personas incompetentes, que prefieren seguir las tendencias y prefieren confiar en algún blogger sofisticado que sus desarrolladores. Y quién realmente tiene muchas ideas equivocadas en su cabeza.

Las tecnologías nuevas / de nicho siempre lucharán por la aceptación, a menos que realmente hagan un gran avance. Ruby, por ejemplo, tuvo éxito en esto a través de Rails y la gran exageración a su alrededor. Flash tuvo un gran avance para los diseñadores, porque en la década de los 90 la gente pensaba que la estridencia era buena y era la primera plataforma ampliamente extendida que permitía implementar precisamente eso.
A pesar de Flex, Flash nunca tuvo un avance tan grande para los desarrolladores. Posiblemente porque GWT , qooxdoo y muchos otros frameworks de implementación en HTML son lo suficientemente buenos como para simplemente no usar Flex o Flash, y hay significativamente más desarrolladores de Java y JavaScript (aparentemente las compañías prefieren elegir tecnologías donde hay una gran cantidad de empleados potenciales )

No necesita escribir su sitio web AJAX desde cero hoy en día. En realidad, no puede comprender HTML y hacerlo de todos modos, en el idioma que elija.

En este momento, HTML5 es muy publicitado y promovido y muchas personas deducen la muerte de Flash a partir de eso. Se dan muchas razones excelentes por las que HTML5 es mejor que Flash. Lo más probable es que tenga más y más sitios web hambrientos de recursos creados con HTML5. La basura estándar no es mejor que la basura de terceros.

En este momento, están sucediendo muchas cosas. El iPhone y otros dispositivos similares han creado un mercado gigante que no existía hace solo 4 años. Y los estándares web finalmente están siendo impulsados ​​por todas las principales empresas en la misma dirección (vagamente).

Personalmente, solo espero que toda la agitación se estabilice en un año o dos, que HTML5 se estabilice, madure y se extienda hasta entonces, mientras que Apple tendrá una postura menos despótica y Flash Player se volverá más rápido en las plataformas móviles. Y que una vez que se haya completado este gran paso, la gente volverá a elegir la herramienta adecuada para el trabajo, tal como sucedió después de que las guerras del navegador se detuvieran. A partir de ahora, hay demasiado ruido para que la gente piense con claridad.


3
Encienda un lector de pantalla, apague la pantalla y pruébelo. ¿Todavía funciona?
BillThor

1
"¿Por qué no hay más desarrolladores web que utilicen un lenguaje de código abierto, multi-paradigma, expresivo y multiplataforma?" - ¿Quieres decir, como Javascript?
André Paramés

1
@BillThor: De hecho, esto depende de la implementación. Flash Player puede interactuar con lectores de pantalla . No muchas personas optan por aprovechar estas posibilidades. Ya sea porque no les importa o porque no tiene sentido. Por mucho que lamento las personas con discapacidad visual, no veo mucho valor en hacer que cualquiera de las aplicaciones / juegos que vinculé sea accesible para los lectores de pantalla. También estoy bastante seguro de que tendrá dificultades para usar Photoshop con la pantalla apagada.
back2dos

1
@BillThor: Aparentemente, no pudo obtener el punto central de mi mensaje: la gente debería volver a usar la herramienta adecuada para el trabajo en lugar de usar lo que es popular. HTML es una gran herramienta para aplicaciones con mucho contenido que se puede capturar con su semántica. Más allá de eso, no es canónicamente la mejor herramienta.
back2dos

1
@ back2dos: No me lo perdí en lo más mínimo. Si usara la mejor herramienta para el trabajo para todo, entonces estaría usando una docena de herramientas, algunas de ellas oscuras. Entonces el mantenimiento se vuelve extremadamente difícil. En cambio, uso herramientas con las que otros miembros del equipo tienen experiencia. La herramienta adecuada para un proyecto no siempre es una herramienta especializada.
BillThor

1

Las tecnologías son todas bastante inmaduras. Solo mire cuánto cambio ha ocurrido en cualquier bloque de 5 años. Con las tecnologías móviles / tabletas, va a cambiar nuevamente.

Lo veo como una fusión más. No se trata solo de HTML / DOM o complementos. He visto extensiones HTML para acceder a las funciones del dispositivo. Los complementos admiten conceptos de escritorio y web junto con aportar sus propias ideas.

Dependiendo de su perspectiva, esto es bueno o malo. Por el momento, mi equipo está trabajando en SilverLight (no para la web). No es una mala tecnología. Puede crear algunas aplicaciones muy potentes y muy atractivas. Sin embargo, viene con mucha complejidad sobre sus predecesores (.Net y quizás Win32) porque no podía hacer tanto con esas tecnologías y las expectativas eran más bajas. Hoy en día, la mayoría de los desarrolladores que escriben cualquier aplicación a menudo compiten (expectativas, no competencia real) con la mejor combinación de tecnologías de escritorio, web y móviles (velocidad, características, atractivo, usabilidad, ...)

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.