Cualquiera que siga mi blog, o Access en realidad, sabe que probablemente soy el bloguero más importante en todo lo relacionado con el navegador Access.
Tengo uno de los artículos más completos sobre el Legacy Web Browser Control (LWBC):
Sigue leyendo
y cuando se lanzó el ‘nuevo’ Control de Navegador Web Moderno (MWBC), compilé otro artículo sobre el tema para intentar brindarles a todos los demás una guía rápida para comenzar con el pie derecho:
Recientemente me preguntaron mi opinión sobre LWBC vs MWBC y pensé que expresaría mis pensamientos aquí en lugar de enterrarlos en un comentario en un hilo aleatorio del foro.
El hecho es que no hay un ganador claro.
Sé que esa declaración por sí sola es una triste declaración con respecto a la MWBC. Debería haber superado a la LWBC y ese debería haber sido el final de la discusión.
La realidad es mucho más compleja. Cada una tiene ventajas y desventajas, y debes sopesarlas y elegir la mejor para tus necesidades.
Si tuviera que darle una calificación al MWBC hoy, probablemente sería un 6/10. Es un control que trajo muchas energías renovadas a Access, pero después de probarlo ha sido una decepción. Aún quedan muchas cosas por solucionar, errores y funcionalidades básicas para que esté a la altura de su potencial. En mi opinión, se lanzó probablemente entre 6 meses y un año antes de lo debido y fue un perjuicio para la comunidad de Access. El control mostró una falta total de pruebas adecuadas.
El MWBC evita el hackeo del registro para que funcione correctamente, lo cual fue realmente apreciado. Por otra parte, hay que prefijar las rutas de los archivos locales (incluso dentro del propio HTML, esto debería haberse manejado internamente sin que los usuarios modificaran los archivos HTML), lidiar con el dominio de confianza, lidiar con los errores interminables, el hecho de que no se puede navegar entre el contenido local y el contenido web en el mismo control del navegador y el hecho de que es más lento al manejar archivos locales que el LWBC.
Debido al requisito de prefijo de archivo local (https:\\msaccess\), el MWBC puede ser mucho más difícil de desarrollar y solucionar en comparación con el uso del LWBC y significa que necesita editar archivos HTML para actualizar las URL de las etiquetas SRC de scripts y CSS. En muchos casos, es posible que no pueda renderizar la página sin alterar primero el código fuente HTML/JS/CSS. Peor aún, este requisito ha hecho que sea IMPOSIBLE cargar cierto contenido CSS por completo, lo que significa que ¡hay casos en los que me fue imposible usar archivos locales con el MWBC! Algo que nunca he experimentado con el antiguo LWBC.
Dicho esto, el MWBC incorpora HTML5, CSS moderno y JS a Access, por lo que puede reproducir contenido que simplemente no se reproducía en el LWBC. Sin embargo, sigue habiendo límites, ya que ciertos JS aún no funcionan. La capacidad de abrir la herramienta de inspección del navegador web directamente en la ventana de Microsoft Access es una GRAN ganancia para el desarrollo de Access.
Si recurrimos al LWBC por un segundo, no tuvimos que hacer ningún esfuerzo para renderizar archivos locales y tampoco tuvimos problemas de rendimiento. Pudimos navegar por la estructura de archivos y carpetas locales, algo que no es posible con el MWBC.
Entonces, ¿cuál es el mejor? ¿Cuál debería utilizar en el desarrollo?
Eso depende.
Supongo que si ninguno de los errores del MWBC te afecta y solo necesitas navegar a un solo dominio (sitio), entonces en tal caso usar el MWBC sería la decisión más inteligente.
Si, por otro lado, necesita permitir la navegación libre a sus usuarios, necesita renderizar archivos locales, necesita permitir contenido mixto (archivos locales y contenido web), desea navegar por el sistema de almacenamiento local, … y es compatible con el motor IE11, entonces, en mi humilde opinión, LWBC sigue siendo la mejor opción.
Obviamente, si el contenido que estás intentando ver no es compatible con IE11, entonces no tendrás más opción que usar MWBC.
¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿???
La otra parte de la ecuación que sigue sin estar clara es ¿cuánto tiempo seguirá Access brindando soporte a LWBC? Lamentablemente, no puedo responder esa pregunta, solo el equipo de desarrollo de Access puede hacerlo.
Dicho esto, MSHTML sobre el que se basa LWBC seguirá siendo compatible al menos hasta 2029. Por lo tanto, es muy probable que LWBC también exista y sea compatible hasta 2029, esa sería mi mejor estimación.
Entonces, sabiendo lo anterior, no tengo prisa por salir y convertir cualquiera de mis aplicaciones actuales utilizando el LWBC.
Tampoco tengo ningún problema en utilizar el LWBC en nuevos proyectos. Obviamente, se trata de elegir el mejor control para el trabajo en cuestión, pero debido a los diversos problemas (errores, limitaciones, etc.) con el MWBC, en mi opinión, el LWBC sigue siendo una excelente opción por el momento.
Mirando hacia el futuro
Todavía tengo la esperanza de que el equipo de desarrollo solucione los más de 15 errores pendientes y haga que MWBC sea mucho mejor, más rápido y más estable.
También espero que expongan más capacidades del control nativo WebView2: eventos, métodos y propiedades para que podamos hacer cosas como administrar cookies (que es solo un ejemplo).
También estoy rezando para que despierten y eliminen todas las limitaciones de dominio confiable y contenido mixto.
Si lo hacen, entonces el MWBC finalmente empoderaría a los desarrolladores de Access como lo hemos estado solicitando durante más de 10 años.
Si no lo hacen, simplemente seguirá siendo otra característica a medio hacer que nunca alcanzará su verdadero potencial y otra decepción para los desarrolladores de Access en todo el mundo.
