Tengo algunas confusiones y me gustaría aclararlas haciendo algunas preguntas.
Según esta definición de Ajax:
Ajax es un conjunto de técnicas de desarrollo web que utiliza muchas tecnologías web en el lado del cliente para crear aplicaciones web asíncronas. Con Ajax, las aplicaciones web pueden enviar y recuperar datos de un servidor de forma asincrónica sin interferir con la visualización y el comportamiento de la página existente.
1. ¿No es lo mismo que la función de vistas asíncronas que se ofrece en Django 3.0?
1A. Si Async Django no reemplazará completamente a AJAX, ¿vale la pena aprenderlo?
2. ¿Qué significa esto para los canales?
Channels es un proyecto que toma Django y extiende sus capacidades más allá de HTTP: para manejar WebSockets, protocolos de chat, protocolos IoT y más. Está construido sobre una especificación de Python llamada ASGI.
¿Puede async django reemplazar canales también?
Sugerir cosas relacionadas con estos temas con razonamiento. por ejemplo, use AJAX con JSON (solo un ejemplo)
Sé que convertir Django a asíncrono llevará tiempo, así que ten esto en cuenta al responder
Según la información que tengo (no sé qué es AJAX, pero muchos tutoriales de Django lo mencionan, por lo que estaba en mi lista de deseos de aprendizaje)
AJAX significa Javascript asíncrono y XML. Se reduce a realizar llamadas asincrónicas que permiten que partes de las páginas web se carguen dinámicamente. Esto significa que solo se actualiza una parte de la página cuando se modifican los datos en lugar de toda la página. Le permite hacer que su página obtenga datos de un servidor o API y permitir que el usuario aún vea la página simultáneamente. Una vez que se recupera la información de la API, la vista se puede actualizar para que coincida con los nuevos datos.
¿No es esto lo que también harán las vistas asincrónicas en Django?
Sí, parece que Django te permitirá realizar este tipo de técnicas dentro de las vistas mismas. Puede haber algunos casos de uso en los que se pueda usar AJAX y la función asíncrona de Django no, pero sin investigarlo, no puedo dar una respuesta definitiva.
1A. Si Async Django no reemplazará completamente a AJAX, ¿vale la pena aprenderlo?
¿Todavía vale la pena aprender AJAX? Yo diría que sí. Tengo la mentalidad de un experto en todos los oficios, maestro de nada. Si planeas pasar el resto de tu vida desarrollando con Django, tal vez no valga la pena. Sin embargo, es muy común encontrar AJAX en otras tecnologías, por lo que si planea aventurarse fuera de la pila de Django, valdría la pena aprender. También tendría el beneficio adicional de conocer algunos de los principios subyacentes de cómo funciona la comunicación asíncrona si profundiza en AJAX.
- ¿Qué significa esto para los canales?
Nuevamente, solo especulaciones, pero asumo que Channels proporcionará una funcionalidad adicional que async Django no tendrá desde el principio (en su extracto menciona: manejar WebSockets, protocolos de chat, protocolos IoT y más. Django siendo asíncrono no proporcionan inherentemente estas funcionalidades). Con el tiempo, Django podría adoptar algunas de estas características, pero supongo que Channels seguirá teniendo su nicho.
No soy un desarrollador de Python, pero implementé un par de servidores web desde cero y creo que puedo ayudarlo.
En el desarrollo web, existen dos enfoques para entregar contenido a los usuarios finales, llamados representación del servidor y representación del lado del cliente.
Representación del lado del servidor (SSR) : el método de representación tradicional, básicamente todos los recursos de su página están alojados en el servidor. Luego, cuando se solicita la página (comúnmente desde navegadores web), se descargan el Html, JS y CSS. También los marcos pueden crear dinámicamente el html basado en la lógica de back-end y finalmente descargarlo. En este punto, muchos marcos ofrecen maravillas para crear aplicaciones en muy poco tiempo con funcionalidades "increíbles".
Tecnologías: java, c#, python, nodejs, etc.
Representación del lado del cliente (CSR) : que a veces se denomina "representación de frontend" es un tipo de método de representación más reciente, se basa en JS ejecutado en el lado del cliente (navegador) a través de un marco de JavaScript. Entonces, cuando se solicita la página, se descargan index.html, css y js mínimos, pequeños o vacíos. Aquí, javascript es responsable de enviar o recibir datos y actualizar una sección mínima de la página sin actualizar toda la página. . Finalmente, cuando el usuario haga clic o active algún evento, javascript enviará o recibirá los datos comúnmente a un resto de API (json) usando una llamada asíncrona ( ajax ).
Tecnologías: reaccionar, angular, vue, aurelia, jquery, javascript puro, etc.
Como puede ver en estas publicaciones: el ejemplo CRUD más simple y la aplicación Hello World , necesita Python (lenguaje del servidor) para desarrollar en Django. Django crea internamente sus páginas html y las presenta a su usuario.
Imagine una API proporcionada por OMS. Esta API nos ofrece un punto final para obtener estadísticas de covid por país:
Imagina que eres de la generación z y no sabes nada de java, python, c# y otros lenguajes antiguos. Debe desarrollar un tablero simple que muestre las estadísticas de covid de los primeros países que contrajeron el virus.
Su web tendrá un efecto visual genial: cargue la página de inicio con las casillas vacías y, una por una, mostrará las estadísticas a partir de los diez países principales.
Para lograr este efecto, usará React para mostrar una página de inicio con cuadros vacíos y activará varias solicitudes a la API:
Su página de inicio sigue funcionando, el usuario está navegando, desplazándose y después de unos segundos, los cuadros se llenan de estadísticas.
Entonces, podemos decir que su web realizó llamadas ASINCRONICAS que permitieron que partes de las páginas web se cargaran dinámicamente ... espere, espere Esto es AJAX: D
Uno de los nuevos desafíos para los marcos web de Python es adaptarse a los beneficios potenciales de un modelo asíncrono.
Django tiene soporte para escribir vistas asincrónicas ("asincrónicas"), junto con una pila de solicitudes completamente asincrónica habilitada si está ejecutando bajo ASGI .
La especificación ASGI es un rediseño iterativo pero fundamental, que proporciona una interfaz de servidor/aplicación asíncrona, con soporte para HTTP, HTTP/2 y WebSockets.
Como puedes ver en los siguientes enlaces, Async Views no son páginas html con ajax, ya que usan ASGI, podemos decir que es un intento de Django de desarrollarse de forma asíncrona pero EN EL SERVIDOR con python:
Las vistas asíncronas no son páginas html con ajax, son solo un código python pero se ejecutan de forma asíncrona en el servidor.