Desarrollo de aplicaciones web para una larga vida útil (más de 20 años)

160

Actualmente estoy desarrollando una aplicación web para la planificación territorial del gobierno. La aplicación se ejecuta principalmente en el navegador, utilizando ajax para cargar y guardar datos.

Haré el desarrollo inicial y luego me graduaré (es un trabajo de estudiante). Después de esto, el resto del equipo agregará la característica ocasional según sea necesario. Saben codificar, pero en su mayoría son expertos en planificación de tierras.

Teniendo en cuenta el ritmo al que cambian las tecnologías Javascript, ¿cómo puedo escribir código que todavía funcionará dentro de 20 años? Específicamente, ¿qué bibliotecas, tecnologías e ideas de diseño debo usar (o evitar) para proteger mi código en el futuro?

javascript web-development future-proof Dan
fuente
94
Comencé a programar en Fortran a fines de 1966, así que tuve mucho tiempo para pensar exactamente en ese tipo de problema. Si alguna vez encuentra una respuesta confiable de hasta un 50%, hágamelo saber. Mientras tanto, piense en la casi inevitable obsolescencia inevitable como "seguridad laboral" :)
John Forkosh
11
Nada dura para siempre en Software Engineery. Solo HOST en los bancos y porque nadie se atreve a actualizar sistemas tan críticos. Bueno, supongo que el programa que se ejecuta en el Voyager también cuenta.
Laiv
99
@Laiv Hace algún tiempo, trabajé en aplicaciones de transferencia de dinero para Bankers Trust usando la mensajería Swift que se ejecutaba en Vax / VMS. Unos años más tarde, Swift eol'ed (fin de vida) todo el soporte VMS. Chico, eso causó algunos problemas ... y me proporcionó otro contrato en BTCo. Como dije anteriormente, "seguridad laboral" :). De todos modos, mi punto es que incluso las aplicaciones críticas del mercado financiero no son inmunes a la obsolescencia.
John Forkosh el
102
¿Qué tal "Escribir código que el próximo desarrollador pueda entender"? Si el código se vuelve obsoleto y hasta el punto de que necesitarán encontrar un programador para actualizarlo, el mejor escenario es que entenderán lo que está haciendo su código (y tal vez por qué se tomaron ciertas decisiones).
David Starkey
38
Simplemente use HTML antiguo, sin JS, sin complementos, nada sofisticado. Si funciona en Lynx, es bueno para todos los tiempos.
Cayo

Respuestas:

132

Planificar el software para tal vida útil es difícil, porque no sabemos qué depara el futuro. Un poco de contexto: Java se publicó en 1995, hace 21 años. XmlHttpRequest estuvo disponible por primera vez como una extensión patentada para Internet Explorer 5, publicada en 1999, hace 17 años. Pasaron unos 5 años hasta que estuvo disponible en todos los principales navegadores. Los 20 años que está tratando de mirar hacia el futuro son casi el tiempo que incluso han existido aplicaciones web ricas.

Algunas cosas ciertamente han permanecido igual desde entonces. Ha habido un gran esfuerzo de estandarización, y la mayoría de los navegadores se ajustan bien a los diversos estándares involucrados. Un sitio web que funcionó en todos los navegadores hace 15 años seguirá funcionando igual, siempre que funcione porque está dirigido al subconjunto común de todos los navegadores, no porque utiliza soluciones alternativas para cada navegador.

Otras cosas iban y venían, principalmente Flash. Flash tuvo una variedad de problemas que llevaron a su desaparición. Lo más importante, fue controlado por una sola compañía. En lugar de competencia dentro de la plataforma Flash, hubo competencia entre Flash y HTML5, y HTML5 ganó.

De esta historia, podemos reunir un par de pistas:

  • Hágalo simple: haga lo que funciona ahora, sin tener que usar soluciones alternativas. Es probable que este comportamiento permanezca disponible en el futuro por razones de compatibilidad con versiones anteriores.

  • Evite depender de tecnologías patentadas y prefiera estándares abiertos.

El mundo de JavaScript hoy es relativamente volátil con un alto flujo de bibliotecas y marcos. Sin embargo, casi ninguno de ellos importará en 20 años: el único "marco" que estoy seguro de que todavía se utilizará para entonces es Vanilla JS .

Si desea utilizar una biblioteca o herramienta porque realmente hace que el desarrollo sea mucho más fácil, primero asegúrese de que esté basado en los estándares compatibles actuales. Luego debe descargar la biblioteca o herramienta e incluirla con su código fuente. Su repositorio de código debe incluir todo lo necesario para que el sistema sea ejecutable. Cualquier cosa externa es una dependencia que podría romperse en el futuro. Una forma interesante de probar esto es copiar su código en una memoria USB, ir a una computadora nueva con un sistema operativo diferente, desconectarlo de Internet y ver si puede hacer que su interfaz funcione. Siempre y cuando su proyecto consista en HTML + CSS + JavaScript más algunas bibliotecas, es probable que lo apruebe.

amon
fuente
44
Las aplicaciones a gran escala no se pueden mantener en vanilla js, a partir de ahora. ES6 ya soluciona el problema de alguna manera, pero hay una razón por la cual el flujo o TypeScript están ganando popularidad.
Andy
34
@DavidPacker Absolutamente, TypeScript, etc. son geniales y facilitan el desarrollo. Pero tan pronto como introduzco un proceso de compilación, todas las herramientas necesarias para el proceso de compilación se convierten en dependencias: NodeJS, Gulp, NPM, ¿quién dice que NPM seguirá en línea en 20 años? Tendré que ejecutar mi propio registro para estar seguro. Esto no es imposible. Pero en algún momento, es mejor dejar de lado las cosas que hacen que el desarrollo sea más fácil solo de inmediato, pero no a largo plazo.
amon
30
@DavidPacker Hay muchos lenguajes dinámicos, y sorprendentemente, se han construido muchos sistemas exitosos con Smalltalk, Ruby, Perl, Python, incluso con PHP y JS. Si bien los lenguajes tipados estáticamente tienden a ser más fáciles de mantener, mientras que los lenguajes dinámicos tienden a ser mejores para la creación rápida de prototipos, no es imposible escribir JS mantenibles. En ausencia de un compilador, la habilidad mediana alta en el equipo, la artesanía y el énfasis adicional en la organización clara del código se vuelven aún más cruciales. Personalmente, creo que los tipos facilitan todo, pero no son una bala de plata.
amon
44
¿Acabo de leer "tomar usb y probar en una máquina diferente"? ¿Por qué no simplemente activar virtualbox o simplemente usar el modo incógnito (con ethX desactivado)?
Kyslik
55
No estoy seguro de JS vainilla serán ser una cosa segura dentro de 20 años. Su historia fue rocosa y experimental, y ha recogido una gran cantidad de rudo en el camino, incluso a pesar de que se ha convertido en un lenguaje encantador y efectivo (personalmente prefiero JavaScript o TypeScript). No es difícil imaginar que los proveedores pueden querer deshacerse de parte o la totalidad de ese problema, ya sea que esto signifique comenzar a ofrecer un nuevo lenguaje alternativo, ya que Google parecía estar proponiendo con Dart, por mucho que no haya ido a ninguna parte. —O eliminando y luego eliminando porciones de JS.
KRyan
178

Lo que es aún más importante que su código que sobrevive durante 20 años es que sus datos sobrevivan durante 20 años. Lo más probable es que eso sea lo que valga la pena preservar. Si es fácil trabajar con sus datos, será fácil construir un sistema alternativo con tecnología más nueva.

  • Comience con un modelo de datos claro y bien documentado.
  • Utilice un sistema de base de datos establecido y bien compatible, como Oracle [1] o SQL Server.
  • Use las funciones básicas, no intente exprimir las nuevas y llamativas.
  • Prefiero simple sobre inteligente .
  • Acepte que la mantenibilidad futura puede venir a expensas de aspectos como el rendimiento. Por ejemplo, puede sentirse tentado a usar procedimientos almacenados, pero estos pueden limitar el mantenimiento futuro si impiden que alguien migre el sistema a una solución de almacenamiento más simple.

Una vez que tenga eso, preparar la aplicación en el futuro es más simple, ya que es una envoltura alrededor del modelo de datos, y puede reemplazarse si, en 10 años, ya nadie usa Javascript, por ejemplo, y necesita migrar la aplicación a WASM o algo así. Mantener las cosas modulares, menos interdependientes, permite un mantenimiento futuro más fácil.

[1] La mayoría de los comentarios a esta respuesta adoptan una postura firme contra el uso de Oracle para una base de datos, citando muchas razones perfectamente legítimas por las que es difícil trabajar con Oracle, tiene una curva de aprendizaje empinada y una sobrecarga de instalación. Estas son preocupaciones completamente válidas al elegir Oracle como DB, pero en nuestro caso, no estamos buscando una DB de propósito general, sino una en la que la preocupación principal sea la mantenibilidad . Oracle ha existido desde finales de los años 70 y probablemente será compatible durante muchos años, y hay un gran ecosistema de consultores y opciones de soporte que pueden ayudarlo a mantenerlo en funcionamiento. ¿Es esto un desastre caro para muchas empresas? Seguro. ¿Pero mantendrá su base de datos funcionando durante 20 años ? Muy probable.

Avner Shahar-Kashtan
fuente
141
Lo siento, pero tengo que decir esto. Si usa Oracle, está disparando a todos en el pie con respecto a "fácil de trabajar". No es fácil trabajar con Oracle en lo más mínimo. Una gran cantidad de funcionalidades que SQL Server, PostgreSQL y probablemente incluso MySQL hacen simple, Oracle no tiene o hace demasiado difícil. Nunca tengo tantos problemas estúpidos con otros DB como los que tengo con Oracle; incluso solo configurar al cliente es un gran dolor en el trasero. Incluso buscar cosas en Google es difícil. Si desea "trabajar con facilidad", manténgase alejado de Oracle.
jpmc26
44
+1 para mantener los datos lo más simple posible. Use SQL estándar para esto, por ejemplo, use OUTER JOIN en lugar del operador + específico de Oracle. Use diseños de tabla simples. No normalice sus tablas al nivel máximo absoluto. Decida si algunas tablas pueden tener datos redundantes o si realmente debe crear una nueva tabla para que cada valor exista solo una vez. ¿Los procedimientos almacenados son específicos del proveedor ? Si es así, no los use. No utilice la función más actual de su idioma de elección actual: he visto más programas COBOL sin OOP-Features que con ellos. Y eso está totalmente bien.
some_coder
3
@ jpmc26 Estoy de acuerdo con sus sentimientos sobre Oracle, pero como dije, "es fácil trabajar con él" no es necesariamente el requisito principal aquí. Prefiero una plataforma con soporte sólido aquí, incluso si es difícil trabajar con ella. Porque cuando se amortiza en 20 años, no está tan mal.
Avner Shahar-Kashtan
8
De hecho, evite Oracle. El único DB existente en la actualidad que probablemente no se vea como una mala elección en 20 años es Postgresql.
Joshua
3
Me gustaría agregar que los DBMS de código abierto excelentes son preferibles porque hay una buena posibilidad de que no mueran. Si Oracle deja de ganar dinero en 10 años, en 11 desaparecerá. PostreSQL parece ser el mejor caballo para apostar.
Shautieh
36

La respuesta anterior de amon es excelente, pero hay dos puntos adicionales que no se mencionaron:

  • No se trata solo de navegadores; los dispositivos también importan.

    amon menciona el hecho de que un "sitio web que funcionó en los navegadores hace 15 años seguirá funcionando igual" , lo cual es cierto. Sin embargo, mire los sitios web creados no hace quince, sino hace diez años, que, cuando se crearon, funcionaron en la mayoría de los navegadores para la mayoría de los usuarios. Hoy, una gran parte de los usuarios no podrán usar esos sitios web en absoluto, no porque los navegadores hayan cambiado, sino porque los dispositivos sí lo hicieron. Esos sitios web se verían terribles en pantallas pequeñas de dispositivos móviles , y eventualmente no funcionarían si los desarrolladores decidieran confiar en el clickevento JavaScript , sin saber que ese tapevento también es importante.

  • Te estás enfocando en un tema equivocado.

    Los cambios tecnológicos son una cosa, pero uno más importante son los cambios de requisitos . Es posible que sea necesario escalar el producto, o que deba tener características adicionales, o que necesite cambiar sus características actuales.

    No importa lo que suceda con los navegadores, dispositivos, W3C o ... lo que sea.

    Si escribe su código de manera que pueda ser refactorizado , el producto evolucionará con la tecnología.

    Si escribe su código de una manera que nadie pueda entenderlo y mantenerlo, la tecnología no importa: cualquier cambio ambiental hará que su aplicación se caiga de todos modos, como una migración a un sistema operativo diferente, o incluso algo tan simple como el crecimiento de datos naturales .

    Como ejemplo, trabajo en desarrollo de software durante diez años. Entre las docenas y docenas de proyectos, solo hubo dos que decidí cambiar debido a la tecnología , más precisamente porque PHP evolucionó mucho en los últimos diez años. Ni siquiera fue la decisión del cliente: no le importaría menos si el sitio usa espacios de nombres o cierres de PHP. Sin embargo, los cambios relacionados con los nuevos requisitos y la escalabilidad, ¡hubo muchos!

Arseni Mourzenko
fuente
44
La adopción de diferentes tamaños de pantalla es un problema general. En este momento, lo móvil es lo más publicitado, pero si está mirando este sitio web en una ventana de navegador de pantalla completa en una pantalla con suficiente resolución, hay mucho espacio vacío (desperdiciado). Cambiar diseños y cómo se presenta la información para utilizar mejor los píxeles disponibles nunca sucedió realmente de una manera inteligente. El móvil lo hizo obvio. Pero pensar en la otra dirección podría ser más importante para la pregunta en cuestión.
nulo
99
@null: si bien estoy de acuerdo con tu comentario, los sitios web de StackExchange pueden no ser la mejor ilustración de tu punto. Teniendo en cuenta los datos para mostrar, creo que los diseñadores / desarrolladores de StackExchange hicieron un gran trabajo al mostrarlos, ya que deben mostrarse, incluso en monitores grandes. No puede ampliar la columna principal, porque el texto se volvería mucho más difícil de leer, y no puede utilizar varias columnas porque no se verá bien para preguntas y respuestas cortas.
Arseni Mourzenko el
Otro buen ejemplo es el evento 'hover' que a menudo se usaba en los sistemas de menús. Muchos de esos menús fallan miserablemente con los dispositivos táctiles.
Justas
Tiene un 110% (o más) de razón sobre los dispositivos, y puedo proporcionarle ejemplos de décadas más antiguas. A fines de la década de 1980 trabajé en aplicaciones CICS que se ejecutan en mainframes IBM y terminales síncronas 3270. La región CICS es un poco análoga a las aplicaciones del lado del servidor, enviando pantallas llenas de datos a la vez a los terminales síncronos, que son análogos a los navegadores de dispositivos dedicados. Y la programación de CICS fue quizás 80% Cobol, 20% PL / 1. Ambos idiomas son en su mayoría obsoletos hoy en día, y la aparición de estaciones de trabajo Unix (Sun y Apollo) a principios de la década de 1990 prácticamente mató a CICS por completo
John Forkosh el
31

No planeas durar 20 años. Llano y simple. En cambio, cambias tus objetivos a la compartimentación.

¿Su base de datos de aplicaciones es independiente? Si tuviera que cambiar las bases de datos en este momento, ¿podría? ¿Es su lenguaje lógico agnóstico? Si tuviera que volver a escribir la aplicación en un idioma totalmente nuevo en este momento, ¿podría? ¿Sigue buenas pautas de diseño como SRP y DRY?

He tenido proyectos en vivo durante más de 20 años, y puedo decirles que las cosas cambian. Al igual que las ventanas emergentes. Hace 20 años podía confiar en una ventana emergente, hoy no puede. XSS no era una cosa hace 20 años, ahora tienes que dar cuenta de CORS.

Entonces, lo que debe hacer es asegurarse de que su lógica esté bien separada, y que evite usar CUALQUIER tecnología que lo encierre en un proveedor específico.

Esto puede ser muy complicado a veces. .NET, por ejemplo, es excelente para exponer la lógica y el método para su adaptador de base de datos MSSQL que no tiene equivalentes en otros adaptadores. MSSQL puede parecer un buen plan hoy, pero ¿seguirá siéndolo durante 20 años? Quién sabe. Un ejemplo de cómo solucionar esto para tener una capa de datos totalmente separada de las otras partes de la aplicación. Luego, en el peor de los casos, solo tiene que volver a escribir toda la capa de datos, el resto de su aplicación no se ve afectada.

En otras palabras, piense en ello como un automóvil. Su automóvil no va a cumplir 20 años. Pero, con neumáticos nuevos, motor nuevo, transmisión nueva, ventanas nuevas, electrónica nueva, etc. Ese mismo automóvil puede estar en la carretera durante mucho tiempo.

coteyr
fuente
2
"Si tuviera que cambiar las bases de datos en este momento, podría" Esto es casi imposible de lograr si hace algo más que CRUD en una fila a la vez.
jpmc26
1
Muchos ORM son independientes de la base de datos. Podría dar cualquiera de los proyectos en los que estoy trabajando para garantizar que podría cambiar de SQLLite a MySql y Postgre sin ningún esfuerzo.
coteyr el
55
Y los ORM dejan de ser herramientas muy buenas para el trabajo cuando haces más que CRUD simple en un solo registro a la vez. Por eso lo califiqué. He intentado. A medida que crece la complejidad de las consultas, incluso los mejores ORM se vuelven más problemáticos que simplemente escribir la consulta, e incluso si fuerza su consulta en ellos, se encuentra rápidamente utilizando características u optimizaciones específicas de la base de datos.
jpmc26
1
Definir "complejo". ¿Fue esta una operación masiva? ¿Incluyó consultas de ventana? Subconsultas? CTE? Sindicatos? ¿Condiciones de agrupamiento complejas? Matemáticas complejas en cada fila y los agregados? ¿Cuántas combinaciones en una sola consulta? ¿Qué tipo de uniones? ¿Cuántas filas se procesaron a la vez? Es cierto que decir algo sobre CRUD de una sola fila (eso sí, esto significa que una fila por consulta, no por solicitud web o lo que sea) es un poco exagerado, pero el camino hacia cuando el ORM se vuelve más problemático de lo que vale es mucho más corto que Crees. Y los pasos para hacer que una consulta funcione bien con frecuencia son específicos de la base de datos.
jpmc26
44
"¿Es agnóstica la base de datos de su aplicación? Si tuviera que cambiar las bases de datos en este momento, ¿podría? Es su lenguaje lógico agnóstico. Si tuviera que reescribir la aplicación en un idioma totalmente nuevo en este momento, ¿podría?" - Este es un consejo ABSOLUTAMENTE TERRIBLE! No te limites artificialmente a lo que creas que es el denominador común más grande de lenguajes de programación o bases de datos; esto te obligará a reinventar la rueda constantemente. En su lugar, trate de encontrar la forma NATURAL de expresar el comportamiento deseado en su lenguaje de programación y base de datos de su elección.
fgp
12

Las respuestas de @amon y algunas otras son geniales, pero quería sugerirte que mires esto desde otra perspectiva.

He trabajado con grandes fabricantes y agencias gubernamentales que confiaban en programas o bases de código que se habían utilizado durante más de 20 años, y todos tenían una cosa en común: la compañía controlaba el hardware. Tener algo funcionando y extensible por más de 20 años no es difícil cuando controlas lo que funciona. Los empleados de estos grupos desarrollaron código en máquinas modernas que eran cientos de veces más rápido que las máquinas de implementación ... pero las máquinas de implementación se congelaron a tiempo.

Su situación es complicada, porque un sitio web significa que necesita planificar dos entornos: el servidor y el navegador.

Cuando se trata del servidor, tiene dos opciones generales:

  • Confíe en el sistema operativo para varias funciones de soporte que pueden ser mucho más rápidas, pero significa que el sistema operativo puede necesitar "congelarse a tiempo". Si ese es el caso, querrá preparar algunas copias de seguridad de la instalación del sistema operativo para el servidor. Si algo falla en 10 años, no querrá volver loco a alguien tratando de reinstalar el sistema operativo o reescribir el código para que funcione en un entorno diferente.

  • Use bibliotecas versionadas dentro de un lenguaje / marco de trabajo dado, que son más lentos, pero se pueden empaquetar en un entorno virtual y probablemente se ejecuten en diferentes sistemas operativos o arquitecturas.

Cuando se trata del navegador, necesitará alojar todo en el servidor (es decir, no puede usar una CDN global para alojar archivos). Podemos suponer que los futuros navegadores seguirán ejecutando HTML y Javascript (al menos por compatibilidad), pero eso es realmente una suposición / suposición y no se puede controlar eso.

Jonathan Vanasco
fuente
11
También debes considerar la seguridad. Un sistema operativo no compatible de 20 años probablemente esté lleno de agujeros de seguridad. Trabajé para una empresa y heredé este problema. Agencia gubernamental, sistemas operativos antiguos (todos virtualizados durante mucho tiempo, afortunadamente), pero este era un gran problema, y ​​la actualización era casi imposible debido a tener que reescribir completamente el software (cientos de scripts PHP de código de espagueti individuales, cada uno de los cuales tenía las llamadas a la base de datos codificado, utilizando funciones obsoletas que el nuevo controlador no admitía / estremecía).
Si sigue la ruta del sistema operativo, en el mejor de los casos, puede esperar que se hayan aplicado parches de seguridad y que los futuros mantenedores puedan proteger cosas en la capa de red. Para planear que las cosas funcionen de esta manera a largo plazo (especialmente en ausencia de un gran presupuesto, ya que el OP es un estudiante), básicamente debe aceptar que su aplicación y servidor eventualmente se volverán inseguros. Por ejemplo, en 20 años eventualmente existirán exploits conocidos para la versión SSL en el servidor ... pero ese sistema operativo puede no ser compatible con las versiones de OpenSL en 10 años. Esto se trata de minimizar las compensaciones.
Jonathan Vanasco
@FighterJet, siempre puede ejecutar un firewall en un sistema operativo compatible, luego tiene pocos riesgos, aparte de las inyecciones de SQL, etc., que de todos modos debería haber codificado.
Ian
@ Ian: lo deseo. Había un cortafuegos. Pero no escribí el código, lo heredé. Y sí, había miles de vulnerabilidades de SQL que desearía haber solucionado, pero el verdadero problema era que el código dependía de una versión particular de PHP4 (que ha quedado en desuso para siempre y está llena de agujeros de seguridad) y un versión particular del controlador de la base de datos (que no funcionaba en sistemas operativos más nuevos), lo que nos impedía actualizar a una versión más nueva de la base de datos ... el punto es que confiar en que algo permanezca igual no siempre funciona. Digamos que me alegro de no trabajar más allí.
1
@FighterJet Ese es realmente un muy buen ejemplo de lo que quise hablar. Terminó heredando código que solo funciona en una versión particular de PHP4 y un controlador que solo se ejecuta en un sistema operativo particular ... por lo que no puede actualizar el servidor. No recomendaría a nadie que haga eso, pero sucede. -- mucho. FWIW, estoy de acuerdo con usted, pero quería mi respuesta para fomentar el pensamiento en torno a ese tipo de escenarios, no hacer una recomendación.
Jonathan Vanasco
6

El núcleo de la mayoría de las aplicaciones son los datos. Los datos son para siempre. El código es más prescindible , cambiante, maleable. Sin embargo, los datos deben conservarse. Así que concéntrate en crear un modelo de datos realmente sólido. Mantenga el esquema y los datos limpios. Anticípese, que una nueva aplicación podría construirse sobre la misma base de datos.

Elija una base de datos que sea capaz de imponer restricciones de integridad. Las restricciones no forzadas tienden a violarse a medida que pasa el tiempo. Nadie se da cuenta. Aproveche al máximo las instalaciones, como claves foráneas, restricciones únicas, verifique las restricciones y posiblemente los activadores para la validación. Hay algunos trucos para abusar de las vistas indexadas para imponer restricciones de unicidad entre tablas.

Entonces quizás deba aceptar que la aplicación se reescribirá en algún momento. Si la base de datos está limpia, habrá poco trabajo de migración. Las migraciones son extremadamente caras en términos de mano de obra y defectos causados.

Desde una perspectiva tecnológica, podría ser una buena idea colocar la mayor parte de la aplicación en el servidor y no en un formulario JavaScript en el cliente. Probablemente podrá ejecutar la misma aplicación en la misma instancia del sistema operativo durante mucho tiempo gracias a la virtualización . Eso no es realmente agradable, pero es una garantía de que la aplicación funcionará dentro de 20 años sin costos de mantenimiento y hardware costosos. Al hacer esto, al menos tiene la alternativa segura y económica de continuar ejecutando código antiguo y funcional.

Además, encuentro que algunas pilas de tecnología son más estables que otras . Yo diría que .NET tiene la mejor historia de compatibilidad con versiones anteriores posible actualmente. Microsoft es muy serio al respecto. Java y C / C ++ también son realmente estables. Python ha demostrado que es muy inestable con los cambios de última hora de Python 3. JavaScript en realidad me parece bastante estable porque romper la web no es una opción para ningún proveedor de navegadores. Sin embargo, probablemente no deberías confiar en nada experimental o funky. ("Funky" se define como "Lo sé cuando lo veo").

usr
fuente
sobre la historia de compatibilidad con versiones anteriores de .net : no creo haber visto una aplicación de Java que solicite una versión anterior de Java, por el contrario. Eso podría cambiar con Java 9 o posterior, pero aún no lo he visto suceder.
Eis
Es increíblemente compatible en la práctica, y la instalación de una versión anterior no es un problema. También tenga en cuenta que, en mi opinión, el .NET BCL es 10-100x más grande que las clases integradas de Java.
usr
la compatibilidad con versiones anteriores significa que no debería haber necesidad de instalar también una versión anterior. Pero nos estamos desviando de la pregunta original, esto no es realmente relevante para OP.
Eis
0

Las otras respuestas tienen sentido. Sin embargo, creo que los comentarios sobre la tecnología del cliente han terminado de complicar las cosas. He trabajado como desarrollador durante los últimos 16 años. En mi experiencia, siempre y cuando mantenga su código de cliente intuitivo, debería estar bien. Así que no hay "hacks" con marcos / iframes, etc. Solo use funciones bien definidas en los navegadores.

Siempre puede usar los modos de compatibilidad en los navegadores para que sigan funcionando.

Para probar mi punto, hace solo unos meses arreglé un error de milenio en el código javascript para un cliente, que ha estado ejecutando su aplicación web durante 17 años. Todavía funciona en máquinas recientes, base de datos reciente, sistema operativo reciente.

Conclusión: manténgalo simple y limpio y debería estar bien.

Jonathan van de Veen
fuente
1
Los marcos y los iframes están muy bien definidos en la especificación HTML. ¿Qué los hace inadecuados?
curiousdannii
3
@curiousdannii: No es tanto el uso de iframes (los marcos ya no son compatibles con HTML5), como el uso de marcos e iframes para cargar contenido de forma asincrónica a través de secuencias de comandos, etc. Puede funcionar muy bien en este momento, pero siempre lo hará. estar sujeto a cambios de seguridad.
Jonathan van de Veen
-2

Algunos axiomas:

  • La verdad sobrevive. En este contexto, serían algoritmos y modelos de datos, lo que representa verdaderamente el "qué" y el "cómo" de su espacio problemático. Aunque, siempre existe el potencial de refinamiento y mejora, o una evolución del problema en sí.
  • Las lenguas evolucionan. Esto es tan cierto para los lenguajes de computadora como para los lenguajes naturales.
  • Toda tecnología es vulnerable a la obsolescencia. Puede tomar más tiempo para algunas tecnologías que otras

Las tecnologías y estándares más estables (los menos vulnerables a la obsolescencia) tienden a ser los que no son propietarios y se han adoptado más ampliamente. Cuanto más amplia es la adopción, mayor es la inercia contra casi cualquier forma de cambio. Los "estándares" propietarios son siempre vulnerables a las fortunas y caprichos de sus dueños y fuerzas competitivas.

Veinte años es mucho tiempo en la industria informática. Cinco años es un objetivo más realista. Dentro de cinco años, todo el problema que su aplicación debe resolver podría redefinirse por completo.

Algunos ejemplos para ilustrar:

C y C ++ han existido por mucho tiempo. Tienen implementaciones en casi todas las plataformas. C ++ continúa evolucionando, pero las características "universales" (las disponibles en todas las plataformas) están prácticamente garantizadas de que nunca serán desaprobadas.

Flash casi se convirtió en un estándar universal, pero es propietario. Las decisiones corporativas de no admitirlo en plataformas móviles populares básicamente lo han condenado a todas partes: si está creando para la web, quiere que su contenido esté disponible en todas las plataformas; no te quieres perder el principal mercado móvil se ha convertido.

WinTel (Windows / x86) a pesar de ser propiedad de Microsoft e Intel, habiendo comenzado en una plataforma menos que óptima (16 bits internos / 8 bits externos 8088 frente a Apple Macintosh contemporáneo 32 bits internos / 16 bits externos 68000), y erosión para Apple en el mercado de consumo sigue siendo una opción de facto para las plataformas comerciales. En todo ese tiempo (25 años), un compromiso con la compatibilidad con versiones anteriores ha obstaculizado el desarrollo futuro y ha inspirado una confianza considerable en que lo que funcionó en la caja anterior seguirá funcionando en la nueva.

Pensamientos finales

JavaScript podría no ser la mejor opción para implementar la lógica empresarial. Por razones de integridad y seguridad de los datos, la lógica empresarial debe realizarse en el servidor, por lo que JavaScript del lado del cliente debe limitarse al comportamiento de la interfaz de usuario. Incluso en el servidor, JavaScript podría no ser la mejor opción. Aunque es más fácil trabajar con él que otras pilas (Java o C #) para proyectos pequeños, carece de la formalidad que puede ayudarlo a escribir soluciones mejores y más organizadas cuando las cosas se vuelven más complejas.

Zenilogix
fuente