#43#114#118#212 algún día escribiré más a fondo sobre ello... pero sería demasiado que contar sobre esos 3 meses perdidos.
Uno de los principales fallos que le vimos es Eloquent, un ORM de juguete que no te permite hacer sentencias con join complejas, y que al final, te da más problemas de los que te resuelve.
Las migraciones, otro chiste malo. Mientras otros ORMs, como es normal, crean las migraciones desde los modelos, aquí pierden casi todo su sentido. No dejas de repetir trabajo ya hecho. Ah, y mejor no hablemos de que cada clase de una tabla tenga que ser un archivo, incluyendo joins, tablas proxy, etc. Hemos llegado a tener 20-30 archivos de modelos por aplicación.
Laravel no deja de estar fuertemente basado en Symfony, pero sin serlo. Una mezcla rara, un frankenstein. Por ejemplo, Laravel tiene su propio sistema de rutas (Symfony ya trae), el cual funciona francamente mal. Te limita muchísimo, porque cosas como tener grupos anidados de rutas no es posible, cosa que sí se puede en otros frameworks.
Laravel debería ser sinónimo de dump-autoload (y no es tanto culpa de Laravel sino de Composer), ya que la creación de nuevas clases requiere estar ejecutando comandos para que el PSR lo tenga registrado (¿de verdad es necesario en desarrollo?), o al menos así era necesario en los workbenchs. A veces fallaba porque se hacen referencias a la clase aún no disponible, tenías que hacer malabares, etc. Un asco para trabajar.
Esto me lleva a hablar de los paquetes. Crear paquetes es incómodo, no se trabaja de la misma forma que sobre el proyecto. Mi conclusión es que afirma ser modulable sin serlo de verdad. Por ejemplo, no tiene nada que ayude al menos en desarrollo a servir los archivos estáticos de tus paquetes.
Otro tema es el de las versiones. Laravel al estar en pañales (aunque aseguren estar ya en su versión 5), de versión en versión mucho código y paquetes pasan a ser incompatibles. Otros frameworks tienen más cuidado en este aspecto, dando alertas de… » ver todo el comentario
#56 --463846-- 
