Como dijeron los demás, todo “depende”.
Pero también depende de su definición de eficiencia. En cuanto al rendimiento, WP y Drupal están lejos, lejos de ser eficientes. A nivel de entrada en cuanto al tiempo, seguro, WP es muy eficiente: cada no codificador de su personal sabrá cómo usarlo en muy poco tiempo. En cuanto al código, una vez más, depende de si tiene personas con experiencia previa en WP / Drupal a bordo, porque desarrollar para esos CMS puede ser increíblemente torpe (debido a su código y arquitectura torpes) y requiere acostumbrarse.
En cuanto a los marcos, sí. Absolutamente. Absolutamente debería usar un marco, para que no se encuentre reinventando demasiadas ruedas. Bueno, tal vez no tanto marcos como componentes populares, probados en batalla, desde los cuales puedes construir tu propio “marco”, así: Construye tu propio Marco PHP con Componentes Symfony
- ¿Publicar la aplicación de servicio web de Facebook?
- ¿Cómo crearía una aplicación web para que la gente pueda enumerar los autos que están a la venta?
- ¿Puedo construir una aplicación web seria con PrimeFaces como front-end? ¿Cuáles son los contras y los pros?
- ¿Es una mala idea hacer una aplicación web donde la autenticación del usuario se sirve de una manera y todo lo demás está separado?
- ¿Por qué ya no está de moda poner una captura de pantalla de su aplicación en la página de inicio de su sitio web de promoción?
Es importante usar bibliotecas y paquetes de alta calidad (como estos: The League of Extraordinary Packages) porque tienen una base de usuarios muy alta y son mantenidos por una multitud constante de muchos, muchos ojos, lo que hace que los errores y las infracciones de seguridad sean difíciles. El problema con los CMS de la vieja escuela establecidos como Drupal y WP es que la comunidad que jura por ellos suele ser también de la vieja escuela, no familiarizada con los avances recientes, las mejores prácticas y las medidas de seguridad, y cosas como estas suceden: Drupal reconoce la vulnerabilidad de inyección SQL importante
En resumen: mi recomendación es no pensar demasiado en el aspecto técnico si no tiene experiencia con él. El truco para un proyecto a gran escala rápido, estable y seguro es encontrar un buen desarrollador / arquitecto senior que pueda planificar la aplicación adecuadamente de tal manera que requiera reescrituras mínimas más adelante y sea máximamente compatible con los avances futuros, utilizando principios SOLID:
S: PHP Master | El principio de responsabilidad única
O: PHP Master | El principio abierto / cerrado
L: El principio de sustitución de Liskov
I: Desacoplamiento de interfaces de la implementación: uso de interfaces separadas
D: Gestión de dependencias de clase: una introducción a la inyección de dependencias, localizadores de servicios y fábricas, Parte 1 y Principio de inversión de dependencias
eso significa usar interfaces para asegurarse de que los componentes se puedan cambiar más adelante, manteniendo los componentes pequeños para que puedan probarse y actualizarse fácilmente, y por último, pero no menos importante, adoptando un enfoque API primero. De esa manera, puede tener un equipo separado trabajando en la aplicación de back-end y front-end, que divide la carga de trabajo, asegura la separación de las preocupaciones (le permite externalizar la creación de varios clientes para su aplicación de back-end: una compañía puede hacer su aplicación móvil, uno puede hacer su aplicación de escritorio, uno puede hacer su tablero web, todo conectado a la API de la que se ocupa su equipo de back-end), y muchos otros beneficios.
