django vs flask vs node
Flask y Django son marcos de desarrollo web basados en Python. Este tutorial compara Django vs Flask en detalle. Flask vs Node también se cubre brevemente:
Siempre ha sido un dilema generalizado cuando se trata de seleccionar un marco para su próximo proyecto. Cada pocos meses, ves nueva tecnología y un marco que supera la debilidad del anterior que usaste.
Un marco es más como una cultura silenciosa y un conjunto de convenciones que debe seguir para ser más relevante y productivo en este mundo tecnológico en constante cambio. Comparativamente, el desarrollo web se mueve mucho más rápido que el desarrollo de escritorio.
=> Lea la serie de capacitación sobre frascos
Lo que vas a aprender:
Frasco de django vs
En este tutorial, trazamos una comparación entre Django y Flask en detalle. Flask y Django son marcos de desarrollo web basados en Python. Muchos se están moviendo hacia microframeworks ligeros. Estos marcos son ágiles, flexibles, pequeños y ayudan a desarrollar microservicios y aplicaciones sin servidor.
Teniendo en cuenta la popularidad de NodeJS, también hemos proporcionado una comparación prodigiosa entre Flask y Node en la sección Flask vs.Node. Evaluar Django y Flask en las siguientes funciones le ayudará a seleccionar una sobre la otra.
Administrador predeterminado
Ambos marcos proporcionan una aplicación de administración de arranque. En Django, está integrado y viene con la instalación predeterminada. Sin embargo, en el caso de Flask, debe instalar Flask-Appbuilder para tener una interfaz de administración.
Mientras tanto, recuerde crear un superusuario en Django y administrador en el caso de Flask para que pueda iniciar sesión en el backend de administración usando el navegador.
Bases de datos y ORMS
Django se envía con un ORM incorporado predeterminado que admite directamente la interacción con RDBMS como Oracle, MySQL, PostgreSQL, SQLite, etc. Este ORM también admite la generación y gestión de migraciones. Es relativamente más cómodo crear modelos de base de datos con validaciones incorporadas.
Flask tampoco impone ningún método en particular y está disponible para usarse con varias extensiones que admiten funciones similares como se describe en el caso de Django. Hemos dado ejemplos de Flask-SQLAlchemy, Flask-Migrate, Flask-MongoEngine, en uno de los tutoriales de la serie.
Vistas y rutas
Ambos marcos tienen mecanismos para declarar vistas basadas en métodos y basadas en clases. En el caso de Django, las rutas y vistas se mencionan en archivos separados. Además, siempre debemos pasar el objeto de solicitud de forma explícita.
Por otro lado, en Flask, podemos usar un decorador para mencionar las rutas de los manejadores correspondientes. El objeto de solicitud en Flask es global y solo está disponible sin ningún paso explícito. Hemos detallado los conceptos de uso de vistas y rutas en uno de nuestros tutoriales.
Formularios y plantillas
Los formularios Django están integrados en el marco y no requieren instalación. Los formularios son bastante esenciales para las aplicaciones, y en Django, los formularios se pueden pasar a etiquetas de plantilla y están disponibles para renderizarse en plantillas. Sin embargo, en el caso de Flask, necesitamos usar Flask-WTF.
También utilizamos Flask-Appbuilder para crear formularios. Además, WTF-Alembic se puede utilizar para generar formularios HTML basados en modelos de bases de datos.
Ambos marcos admiten la creación de plantillas Jinja2 y ambos admiten el servicio de archivos estáticos con funciones incorporadas para generar las URL de los recursos y es un patrón bastante común en todos los marcos en estos días.
Aunque hay diferentes formas de pasar las variables y de representar las plantillas en sus métodos de vista particulares, ambos marcos tienen la misma sintaxis para acceder a las variables en las plantillas.
Flexibilidad
Django, debido a su gran tamaño y complejidad, es menos flexible que Flask. Flask se puede extender fácilmente con la ayuda de una gran cantidad de extensiones que admite. Por lo tanto, se necesita más tiempo y esfuerzo para configurar Flask porque necesitamos evaluar más extensiones.
La libertad otorgada a los desarrolladores de alguna manera resulta en un desarrollo y entrega más lentos. Por otro lado, Django sigue un conjunto de convenciones ya establecidas y sigue los arquetipos que requieren menos desviaciones de las metas y objetivos del proyecto.
Curva de aprendizaje
Casi requiere la misma cantidad de tiempo para aprender tanto Django como Flask. Flask tiene una API más pequeña; por lo tanto, las personas podrían terminarlo más rápido en lo que respecta al marco principal. Se vuelve igualmente desafiante cuando se trata de usar sus extensiones. Pronto podría volverse engorroso.
Sin embargo, solo porque no todo está empaquetado en un paquete, es más fácil practicar la separación de preocupaciones en el caso del marco Flask.
Le recomendamos que aprenda los patrones y no la sintaxis que se sigue. Tanto Django como Flask tienen una excelente documentación. Puede seguirlo fácilmente mientras desarrolla una función.
Tamaño y duración del proyecto
Cuando trabajas en un proyecto más grande con equipos más grandes, es mejor aprovechar la madurez de Django y el amplio soporte de contribuyentes que tiene. Si su proyecto es más pequeño y requiere un número menor de desarrolladores, es mejor optar por Flask.
Además, si su proyecto va a durar mucho, Django es la elección correcta; de lo contrario, puede seleccionar Frasco.
tipo de aplicacion
Anteriormente, se consideraba que Django era la opción correcta cuando existía el requisito de aplicaciones web completas a escala empresarial. Pero, hoy en día, Flask está igualmente maduro y puede funcionar bien para las mismas condiciones.
Sin embargo, los desarrolladores tienden a elegir Flask más para desarrollar sitios web pequeños o estáticos, o mientras implementan servicios web de API RESTful rápidos para entregar.
Reclutamiento de desarrolladores
Tener recursos capacitados en la convención del marco que utiliza vale la pena. Puede esperar un desarrollo más rápido, pruebas más rápidas, entrega más rápida y soluciones de problemas más rápidas.
Es bastante fácil encontrar nuevos desarrolladores en el caso de Flask. Sin embargo, es un desafío encontrar recursos capacitados en Django. No hay muchos listos para ser contratados por desarrolladores de Django. Además, el marco de Django es bastante antiguo y, por lo tanto, la mayoría de los nuevos empleados son costosos de contratar en comparación con los que tienen experiencia en el marco de Flask.
Los nuevos graduados técnicos también están eligiendo marcos livianos como Flask porque las tendencias de la industria apuntan a la creación de aplicaciones con microservicios desacoplados o la tecnología que respalda la creación de la implementación sin servidor. Javascript se usa ampliamente junto con los marcos que son más fáciles de usar y más populares.
Fuente abierta
Tanto Flask como Django son proyectos de código abierto. Puede encontrar Django en https://github.com/django/django y Flask en https://github.com/pallets/flask. En cuanto a estos proyectos, el número de colaboradores de Django es bastante mayor que el de los que contribuyen a Flask.
Por lo tanto, podemos esperar un soporte más rápido y más rápido si tenemos algunos problemas y consultas que necesitan resolución. Contrariamente a las suposiciones típicas, el número de usuarios del proyecto Flask es mayor que el de Django.
Un hecho preocupante sobre Flask es que podría no haber una extensión estable para una tarea en particular. Por lo tanto, el trabajo de filtrar el mejor queda en manos del usuario de la extensión.
Por ejemplo, Usamos Flask-Twitter-oembedder para trabajar con la API de Twitter en el último tutorial, pero esta extensión tuvo algunos problemas debido a los cuales tuvimos que cambiar de Flask-Cache a Flask-Caching.
Incluso tuvimos que incluir una declaración de instalación personalizada para instalar Flask-twitter-oembedder desde nuestro repositorio de Github actualizado en lugar de mencionarlo en nuestro archivo requrements.txt del proyecto.
El mantenimiento frecuente es un desafío típico al que se enfrentará con un proyecto de código abierto. El soporte y la gestión del proyecto de código abierto suelen estar vinculados a los servicios de pago. Es posible que tenga que esperar mucho tiempo para solucionar algunos problemas de los contribuyentes al proyecto.
Rendimiento
El marco de Flask es más ligero que Django y funciona mejor con diferencias insignificantes, especialmente al considerar las operaciones de E / S.
Eche un vistazo a las comparaciones que se dan a continuación. Con el aumento de solicitudes, el rendimiento de Flask sigue siendo casi el mismo. Sin embargo, Django tarda más en renderizar plantillas después de obtener datos usando el ORM.
Python Flask Vs Django: una comparación tabular
| # | Características | Django | Matraz |
|---|---|---|---|
| 7 | Interpolación variable en plantillas | En templates / demo.html {{tempvar}} | En templates / demo.html {{tempvar}} |
| 1 | Administrador predeterminado | Backend de administración integrado | Instalar Flask-Appbuilder |
| 2 | Habilitar administrador predeterminado | En settings.py, asegúrese de descomentar la aplicación instalada por el administrador. ... # Definición de la aplicación INSTALLED_APPS = ( 'sitio web', 'django.contrib.admin', # otro código ) ... | Importe AppBuilder y SQLA desde flask_appbuilder, inicialice la base de datos primero y luego Appbuilder desde el matraz de importación Matraz desde flask_appbuilder importar AppBuilder, SQLA app = Frasco (__ nombre__) db = SQLA (aplicación) appbuilder = AppBuilder (aplicación, db.session) |
| 3 | Crear usuario administrador | python manage.py crea superusuario | matraz fab create-admin |
| 4 | Bases de datos y ORMS | ORM incorporado para RDBMS Utilice Django-nonrel para backends NoSQL | Instalar Flask-SQLAlchemy Una extensión de Flask específica de NoSQL como Flask-MongoEngine |
| 5 | Vistas y rutas | URLConf en urls.py desde la ruta de importación django.urls desde vistas de importación urlpatterns = ( ruta ('/ ruta', views.handler_method), # otras URL y controladores ) | Utilice el decorador @ app.route (“/ ruta”) en Vistas para mapear una ruta con una función. @ app.route ('/ ruta') def handler_method (): # otro código con más lógica |
| 6 | Plantillas de renderizado | En vistas de django.shortcuts import render def vista_ejemplo (solicitud): tempvar = 'value_for_template' return render petición, 'Demo.html', {'Tempvar': tempvar} ) | En vistas desde . importar aplicación de solicitud de importación de matraces desde la importación de matraces render_template @ app.route ('/ ruta') def demo (): tempvar = 'value_for_template' return render_template ( 'Demo.html', temp_var = temp_var ) |
| 8 | Flexibilidad | Menos flexible | Mas flexible |
| 9 | Decisiones de diseño | Menos decisiones de diseño con desarrolladores. | Más libertad para los desarrolladores. |
| 10 | Desviación del proyecto | Menor desviación de los objetivos del proyecto. | Más desviación debido a la libertad dada a los desarrolladores. |
| 11 | Tamaño de la base de código | Base de código más grande | Base de código más pequeña |
| 12 | No de API | Más API | Menos API |
| 13 | tipo de aplicacion | Aplicaciones web completas | Aplicaciones / microservicios más pequeños |
| 14 | Aplicaciones RESTful | Marco Django REST para aplicaciones RESTful. | Utilice las siguientes extensiones para aplicaciones RESTful. Frasco-REPOSO Matraz-RESTX Acceso |
| 15 | Rendimiento | Rendimiento lento cuando la cantidad de solicitudes es grande. | Rendimiento constante en todas partes. |
| 16 | Contribuciones de código abierto | Más cantidad de bifurcaciones, relojes y confirmaciones. | Menor número de bifurcaciones, relojes y confirmaciones. |
| 17 | Desarrolladores | Requiere desarrolladores experimentados y no están fácilmente disponibles para la contratación. | La mayoría de los desarrolladores tienen menos experiencia y se encuentran en cantidades adecuadas. |
Frasco Vs Nodo
Con respecto a la pila de desarrollo web, resulta que desarrollar para la web requiere una combinación de varias tecnologías. Necesitamos dividir una aplicación web en frontend y backend. La parte frontal de la aplicación se desarrolla mejor en las tecnologías que se ejecutan en el navegador, como JavaScript, HTML y CSS.
Generalmente, el backend se desarrolla en lenguajes que son adecuados para el lado del servidor y pueden interactuar con el sistema operativo subyacente, las bases de datos conectadas o la red cuando sea necesario.
Sin embargo, un marco basado en JavaScript llamado NodeJS cambió la vista anterior y permitió a los Desarrolladores tener consistencia y uniformidad en el desarrollo de aplicaciones web de front-end y back-end. Los desarrolladores podrían desarrollar para el back-end utilizando JavaScript.
En esta sección Flask vs Node, comparamos Flask, que es un marco de trabajo basado en el lenguaje de programación Python, con Node, que se basa en el tiempo de ejecución de JavaScript de Chrome en varios criterios como arquitectura, velocidad, soporte de la comunidad, etc.
| # | Criterios | Matraz | Nodo |
|---|---|---|---|
| 7 | Depuración | Más fácil de depurar con el depurador de Python sin dependencias. | Requiere más esfuerzo. Más fácil con un IDE de desarrollo con Bluebird / Promise Library. |
| 1 | Tiempo de ejecución del idioma | Pitón | Motor JavaScript V8 de Chrome |
| 2 | Arquitectura | La E / S sin bloqueo requiere el uso de servidores web sin bloqueo como gunicorn. Categoría Microframework (back end). | Proporciona de forma inherente E / S sin bloqueo. Categoría fullstack |
| 3 | Gerente de empaquetación | pepita | sobre el nivel del mar |
| 4 | Velocidad | Más lento debido a un intérprete de Python independiente. | Más rápido gracias al compilador Just-In-Time. |
| 5 | Fuente abierta | sí | sí |
| 6 | Soporte comunitario | En Github 2.3 K relojes 51,4 K estrellas Horquillas 13,7 K | En Github 2.9 K Relojes 71,9 K estrellas Horquillas 17,6 K |
| 8 | Mantenimiento | Bajo mantenimiento | Mayor mantenimiento |
| 9 | Aplicaciones en tiempo real | Inherentemente no adecuado. Sin embargo, puede funcionar junto con socket.io para casos de uso en tiempo real. Utilice la extensión Flask-socketio. | Adecuado debido a la arquitectura impulsada por eventos y los módulos de transmisión. Inherentemente asincrónico. |
| 10 | Bibliotecas | Más maduro y estable. | Menos maduro y estable, pero en desarrollo activo y lanzamientos fijos. |
| 11 | Calidad del código | Está creado exclusivamente para el back-end. | A veces se ve comprometido debido a que los nuevos desarrolladores de front-end cambian al back-end. |
| 12 | Composición del equipo de desarrolladores | Los equipos suelen estar compuestos por desarrolladores de back-end y desarrolladores de front-end. Las preocupaciones están separadas. | Los desarrolladores pueden intercambiar roles y trabajar tanto para el front end como para el back end. |
| 13 | Integración con el sistema y las aplicaciones existentes | Más fácil de integrar con otras aplicaciones de backend heredadas existentes mediante el ecosistema de Python para aplicaciones de Big Data y aprendizaje automático. | Bastante nuevo y requiere la creación de bibliotecas nuevas o personalizadas para la integración con otras aplicaciones existentes. |
Preguntas frecuentes
P # 1) ¿Qué debo aprender primero, Django o Flask?
Responder: Es mejor ir primero con Flask. Una vez que adquiera un poco de experiencia en desarrollo web, puede comenzar con Django. Django asume que ya sabe cómo funcionan las aplicaciones web y se encarga de la mayor parte de la funcionalidad por sí mismo.
P # 2) ¿Flask o Django son mejores?
Responder: Tanto Flask como Django son excelentes y se ajustan a su propósito. Django se utiliza para crear aplicaciones a escala empresarial más destacadas. El matraz se utiliza para crear aplicaciones estáticas y más pequeñas. Matraz también es adecuado para la creación de prototipos. Sin embargo, con el uso de extensiones de Flask, también podemos crear aplicaciones grandes.
P # 3) ¿Qué empresas utilizan Flask?
Uy concepto en c # con ejemplo
Responder: Algunas de las empresas que utilizan Flask son Reddit, Mailgun, Netflix, Airbnb, etc.
P # 4) ¿Qué sitios usan Django?
Responder: Algunos de los sitios que usan Django son Instagram, Spotify, YouTube, Dropbox, Bitbucket, Eventbrite, etc.
Conclusión
Realmente no deberíamos obsesionarnos con un marco por mucho tiempo. Deberíamos estar preparados para aprender nuevos conjuntos de tecnología y adoptar las tendencias que existen. Algunos de nosotros queremos, comparativamente, enfoques con batería incluida con ciclos de liberación rígidos, manteniendo una compatibilidad con versiones anteriores más estricta, etc.
Si cree que pertenece más a este grupo, debe elegir Django. Sin embargo, es increíble caminar junto con las nuevas características y la flexibilidad del marco Flask también. Cuando desee mantener la coherencia entre el front-end y el backend, puede elegir un marco de pila completa como NodeJS.
Ir con un marco es más una elección que depende del contexto y los problemas que intentamos resolver. Seleccionar un marco siempre es difícil. Esperamos haber presentado los puntos de revisión esenciales en este tutorial y le ayudará a finalizar un marco. Sin embargo, recomendamos aprender ambos marcos.
Es más fácil comenzar con Flask y luego pasar a Django después de adquirir algo de experiencia en Desarrollo Web. Si por alguna razón sus esfuerzos de desarrollo requieren el uso de JavaScript, puede continuar con NodeJS.
=> Consulte TODOS los tutoriales de matraces aquí
Lectura recomendada
- Tutorial de Python Django - Introducción a Django
- Patrones de diseño de matraces y mejores prácticas para aplicaciones web
- Plantilla de matraz, formulario, vista y redireccionamiento con ejemplos
- Las 31 preguntas más populares de la entrevista con Python Flask con respuestas
- Cómo configurar el marco de prueba de Node.js: Tutorial de Node.js
- Tutorial de TestNG: Introducción al marco de TestNG
- Marco basado en palabras clave en selenio con ejemplos
- Tutorial de Robot Framework: características e instalación del software