Lo que no me gusta de Laravel
He estado leyendo, probando y viendo un poco de cerca Laravel, buscando agilizar los desarrollos que hacemos en Nodos.
Estas son algunas cosas que no me han gustado de Laravel. Quizás en algunas esté equivocado, dado que sólo he construido algo pequeño con el framework para tener un hands-on experience y no tengo un conocimiento a profundidad de éste. Corríjanme si me equivoco.
NOTA: Al momento que escribo esto, la versión más reciente de Laravel es 5.6.
La magia
Este es un código de ejemplo copiado del manual de Laravel acerca de validación:
/**
* Store a new blog post.
*
* @param Request $request
* @return Response
*/
public function store(Request $request)
{
$validatedData = $request->validate([
'title' => 'required|unique:posts|max:255',
'body' => 'required',
]);
// The blog post is valid...
}Lo que se puede ver es que hay una llamada a $request->validate().
Lo que no se ve es que si validate() encuentra contenido inválido, arroja una Excepción y se redirige automáticamente a la página anterior (con toda otra funcionalidad detrás de cámaras para preparar los errores y la persistencia de los valores antiguos).
Este comportamiento “mágico” no es visible ni intuitivo en el código, violando el Principle of Least Surprise. Solamente alguien con conocimientos de Laravel sabe lo que va a suceder.
Por otro lado, los Exceptions están siendo usados para controlar el flujo de la aplicación, lo cual es una mala práctica. Citando a Philip Brown:
An exception is basically an exceptional circumstance that is often unrecoverable from. This means something went wrong and we can’t proceed with running the application because the program is unable to carry on executing.
For example, I see a lot of code where the developer is using exceptions to control the flow of logic.
Exceptions should only be used in exceptional circumstances and therefore should be used sparingly.
Los famosos “Façades”
Mathias Verraes lo sabe decir mejor:
Laravel’s Facades have global state, which is precisely the thing you *shouldn’t* do. It is bad design and should be deprecated. They are nothing more than an elaborate $_GLOBALS.
(And they are a misnomer, as they are not Facades in the OOP meaning.)
Los formularios
Zend Framework 2 y 3 tienen Forms, que son colecciones de Form Elements con validación. Puedes crear nuevas clases de Form Elements como por ejemplo, “DNI” que incluye validadores, filtros, atributos, etc.
Laravel no tiene un concepto similar, estas funcionalidades están dispersas. Menos que eso, los helpers para renderizar los elementos de formulario fueron retirados del framework. No hay una base sobre la cual crear elementos reutilizables.
Service Container y PSR-11
Debido a requerimientos de clientes, en Nodos seguiremos usando tanto Zend Framework como Laravel. Revisando la interoperabilidad de Laravel en relación a su Service Container, veo que no se ajusta al PSR-11 — tampoco al ahora obsoleto container-interop.
Quizás tengamos que usar zend-servicemanager o algún otro Container PSR-11 para los Layers framework-agnostic.
Coda
Sobre el tema de la magia, cabe mencionar lo obvio: todo framework, por definición, trae consigo cierta medida de magia. Desde Rails, esto viene siendo un debate; y como ex-Rails developer, tengo tolerancia a cierta medida de magia pero ahora estoy gravitando más hacia lo explícito.
Hay “magia buena” (e.g. convention-over-configuration) y “magia mala” (e.g. leaky abstractions). La primera es aceptable, la segunda no.
Es mi sentir (y meramente mi opinión personal) que Laravel sacrifica mucho por darle prioridad al aspecto “beautiful code” y el “developer as an Web Artisan.” Para que Laravel pueda ser más interoperativo y desacoplado tendría que cambiar mucho estructuralmente, pero dudo que formen parte de las metas de Taylor Otwell. Mientras no pretenda convertirse en omakase, estamos bien.
Para equilibrar la balanza, en un próximo post haré una lista de las cosas que me gustan de Laravel.