Explicando la diferencia entre un framework y el código puro

Hay un tema que he visto que sale muy regularmente, y es mucha gente preguntándose cual es la mejor opción para empezar a programar hoy en día.
Precisamente este tema empecé a escribirlo con relación a este otro:
En el cual, el compañero, no tenía muy claros los principios que giran en torno al mundo de la programación hoy en día.

Este artículo que escribo a continuación solo trata de simplificar para poder explicar mejor la diferencia que existe entre un lenguaje de programación (PHP, Java, o Phyton) y un Framework (Laravel, Symfony, Spring, Struts o Django)

En este caso voy a centrarme en PHP dado que es la temática del tema que he cogido de referencia. Pero es posible sustituir donde digo PHP por Java o Python y donde digo Symfony, por Spring o Django)

En primer lugar hay que dejar claro algo: una cosa es el lenguaje de programación y otra forma es la estructura que gira entorno a ese lenguaje

PHP es el lenguaje de programación que da sentido a todo.

Pero una vez empiezas a conocer como funciona PHP en su esencia, dependiendo de a lo que te quieras dedicar te acabarás dando cuenta de dos cosas:

1. Es muy difícil mantener el código (esto pasa en TODOS los lenguajes, no es algo exclusivo de PHP)
2. Es muy difícil compartir el código (igualmente esto pasa en todos los lenguajes

(entre otras tantas)

Entonces, a lo largo de la historia, se propusieron varias soluciones:

Generalmente la solución NUMERO 1, es la "documentación de código". Cuanto más documentación, más fácil será retomar un proyecto que llevas 1 año sin tocar, y más fácil será que otra persona colabore o pueda trabajar con tu código.

Pero también surgieron otras propuestas para resolver estos dos problemas. Una de ellas son los famosos Frameworks Modelo-Vista-Controlador o MVC. Estos frameworks permiten, crear todo un nuevo mundo de métodos y constructos entorno a un lenguaje ya existente y resuelven esos dos problemas anteriormente mencionados básicamente haciendo que todo lo que programes, tenga un orden bastante estricto.

Existen muchos Frameworks, como todos los que mencioné en mensajes anteriores, pero Laravel y Symfony son los más populares. Cuando yo te hablo de aprender Laravel no digo que PHP deba abandonarse. Porque si no se tienen unos amplios conocimientos de PHP, básicamente NO SE PUEDE UTILIZAR Laravel.

Laravel es un framework que se fundamenta en el lenguaje de programación PHP.

El problema es que programar en PHP desde 0, es algo muy arcaico, es de programador de muy bajo nivel. Es decir: coger un fichero en blanco y empezar a programar ahí sin más, es un error a día de hoy muy grande, salvo casos puntuales, como si el objetivo es hacer un microservicio muy sencillo

Siguiendo en la linea de PHP, hay más opciones, pero una muy popular es Wordpress y a la vez muy denostada. La mayoría de los programadores noveles, piensan que Wordpress, es un sistema sencillito para hacerle la vida fácil a los que no saben programar. Pero esto es debido a que la mayoría de la gente no se ha tomado el tiempo para profundizar en la estructura de Wordpress, la cual con el tiempo, acaba pareciendose incluso a la de un Framework como Laravel y Symfony.

En primer lugar es necesario olvidarase del backend y lo tipico cuando uno instala un Wordpress.
Aquí yo me voy a centrar en el Codex: https://codex.wordpress.org

Wordpress como todo en esta vida, tiene varias ventajas y desventajas
Wordpress es PHP 100%, esto lo tenemos claro.
Por tanto si sabes programar en PHP y entiendes el codex de Wordpress, empezarás a crear cosas nuevas en cuestión de días.

Su principal ventaja, es al mismo tiempo su principal desventaja: La comunidad. La comunidad te facilita un millón de soluciones que te simplifican cualquier trabajo. Pero muchas de ellas están muy mal programadas, por tanto, si eliges mal, puedes retrasar tu trabajo. Hay cientos de soluciones increiblemente buenas, y otras tantas miles que son una basura. Con experiencia, uno aprende a seleccionar correctamente y quedarte con lo mejor.

Y esto tiene que ver con uno de los principales problemas que hay en el mundo de la programación: volver a programar lo que ya está programado por otros.

Un ejemplo

Imagínate que quieres hacer una Web que va a ser una casa de apuestas de deportes.

Para este ejemplo voy a tomar tres alternativas:

1. Hacerla en PHP puro, desde 0.
2. Utilizar un Framework como Symfony
3. Utilizar Wordpress

Vamos a plantear una serie de componentes fundamentales que debe tener la casa de apuestas:

1. Un sistema de usuarios
2. Un sistema de pagos
3. El sistema de apuestas en sí
4. Un enlace con algún sistema que recoja los partidos automáticamente de diferentes fuentes via REST
5. Una API para poder ofrecer la información a una App que construiremos en un futuro para Android y para iOS

Y seguramente habran varias cosas más que se me olviden, como lo relativo al frontend.
Pero por simplificar al máximo, vamos a quedarnos con esos 5 componentes de momento.

Si empiezas a programar en PHP puro vas a tener 5 problemas: tener que crear los 5 elementos prácticamente desde 0.

En cambio si decides ir con Symfony o con Wordpress tienes medio camino ya hecho:

1.El sistema de usuarios: Ambas plataformas ofrecen un sistema de usuarios bastante potente, totalmente probado y con muy bajo riesgo de ataque (inyecciones de SQL principalmente). Además incluyen opciones para integración de login social en cuestión de minutos. En cambio si tu esto tienes que programarlo en PHP puro desde 0, vas a tardar un montón de tiempo

2. El sistema de pagos: más de lo mismo: paypal, stripe, etc... todas tienen integraciones ya para ambos sistemas. Ejemplo para Symfony: https://jmspaymentcorebundle.readthedocs.io/en/stable/

Si bien existen librerias para PHP que facilitarían estos dos elementos un poco si decides ir por el camino del PHP puro, el mantenimiento de estas librerias es totalmente odioso. Quizá esto podría resolverse con Composer, pero aún así, con un muy bajo nivel de integración, las largas horas de programación están garantizadas, frente a los apenas minutos con los que puedes conseguir el mismo resultado con Symfony o Wordpress.

Por mi experiencia, apenas puedo contar con los dedos de una mano, las veces que he visto a un programador en PHP puro que use un controlador de repositores tipo Composer. ¿Por qué? Porque empezar con PHP es un claro indicio de novatez. Aquel que ya se toma la molestia en incoporar un repo, automaticamente se va a plantear dar un salto a un Framework por motivos obvios. El paso no es fácil, pero el esfuerzo de aprender a utilizarlo merece la pena.

3. El sistema de apuestas: No existe un sistema de apuestas bueno ni para Wordpress ni para Symfony obviamente. Esto es el elemento más diferenciador de nuestra página por tanto tendremos que currarnoslo desde cero en cualquiera de los casos. Así que en este aspecto, los tres metodos estarían en igualdad de condiciones.

• Pero en el caso de Wordpress, podrías crear un plugin específicamente para esto.
• En Symfony, te crearías un Modulo, es decir, una vista, un modelo y un controlador específico para este elemento, con lo cual, todo quedaría perfectamente estructurado
• Y en PHP Puro, dependiendo lo organizado que seas, con suerte podrás crear algo lo suficientemente estructurado, para que lo sigas entendiendo tu dentro de 1 año o alguien que quiera ayudarte en el proceso.

4. La conexión con API de terceros: Con el tema de las API aquí el claro ganador es Symfony. Los MVC tienen una integración con API brutal que simplifica de sobremanera todo el sistema.
En wordpress no está tan mal, porque tiene bastantes Helper Functions: https://codex.wordpress.org/HTTP_API que también simplifican la historia, aunque no de forma tan potente como un Framework generalmente
En cambio en PHP Puro toca volver a guisárselo desde 0 al 100% casi. Bastante molesto y muchas horas de programación.
En PHP Puro, quizá tendrías que tirar de alguna librería, con los problemas que comentamos anterior (si vas con Composer, lo mismo te salvas de darle mantenimiento a la misma)

5. API propia:
Wordpress, tiene una API pero solo para su estructura interna, así que te tocaría desarrollar una API desde 0
Con PHP Puro te toca desarrollar una API desde 0
Pero aquí Symfony vuelve a ganar: No solo tienes la opción de montarte un microservicio con Sylex espificamente orientado a ofrecer esta API sino que el propio Symfony tambien ofrece una plataforma para crear API en un momento.

¿Como se traduce todo esto en tiempo de programación?

Imaginate que fueras un programador PHP senior, que ya conoce ampliamente Wordpress, Symfony y obviamente sabe programar en PHP puro

Si te pones ahora mismo a programar esta web y dedicas exactamente el mismo tiempo todos los días, el tiempo de ejecución podría ser:

A) Si eliges Wordpress, podrías tardar entre 1 y 2 meses
B) Si eliges Symfony podrías tardar entre 2 y 3 meses
C) Si eliges PHP Puro, tardarías entre 4 y 6 meses

Esto descontando que en Wordpress y en Symfony, todo el código quedará, por lo general, decenas de veces más limpio, organizado y cualquiera podrá ayudarte en un futuro. En PHP puro, a no ser que dediques muchisimo tiempo en organizar y estructurar la información y sobre todo una enorme cantidad de tiempo en documentarla, lo más probable es que al cabo del tiempo se acabe convirtiendo más en un problema que en una solución

Así que con esto puedes hacerte una idea de por qué todo el mundo que se dedica al mundo empresarial, ha ido abandonado paulatinamente la programación en PHP pura y decantandose por otras soluciones de trabajo.

Como dije al principio, tanto Wordpress, Symfony y Laravel todo se basa en PHP.

Lo hagas como lo hagas, en todos los casos vas a usar montones de funciones iguales que se podrian reutilizar perfectamente de un sistema a otro.

Pero una de las grandes diferencias está en la comunidad: En Wordpress y en Symfony hay decenas de sistemas que ya funcionan, que ya estan adaptados y que su incorporación es inmediata. En cambio en PHP Puro tienes que empezar por cada paso que des, prácticamente desde 0, lo que se acaba convirtiendo en un auténtico calvario

Conclusión

Si acabas de llegar al mundo de la programación y estás aprendiendo entonces PHP es básico y fundamental para empezar.

Pero si ya se tienen unos conocimientos intermedios de PHP, entonces la recomendación como puedes ver, es que pases a un framework, como Symfony o Laravel

O incluso te plantees leerte a fondo el Codex de Wordpress. Para mi Wordpress es el camino fácil cuando quiero hacer una web eficiente, cuando cuento con pocos recursos (es decir, que no hay un equipo de varios programadores) y cuanto menos se tenga que reinventar la rueda, mejor. Yo simplemente valoro mi tiempo y mi trabajo. Y si puedo dedicar 2 horas en vez de 6, créeme que prefiero dedicar 2. Me da igual como, pero en este caso, el fin, justifica los medios.

Obviamente para hacer este artículo lo más corto posible, he ido por lo fácil, simplificando todo al máximo. Hay cientos de consideraciones a tener en cuenta. Pero a día de hoy, no existe un solo escenario bajo mi punto de vista, en el que merezca la pena desarrollar un proyecto en PHP puro desde 0 (o en ningún lenguaje), salvo una aplicación muy exclusiva, que solo va a hacer una sola función y apenas va a requerir un solo fichero con apenas un centenar de líneas, y se requiera la máxima eficiencia posible. Pero salvo esto, para el resto de los escenarios, lo ideal es empezar con una buena base de trabajo, sea un Microframework como Sylex, o un framework más avanzado como Laravel o incluso, como he comentado, Wordpress.

Espero que haya quedado claro el tema, pero si hay alguna cuestión sobre este tema estaré abierto a darle respuesta.

muy interesante

Me parece un gran aporte para cualquier persona que quiera empezar.

Estos temas son muy interesantes sobre todo para aquellos que queremos iniciar con esto de la programación. Gracias por tu aporte.

Muy bueno, pero falto la recomendación de cursos de PHP.

Muy bueno a favoritos, se agradece tan gran aporte

El problema se da en la total dependencia de un framework, cuando ese framework no cumple tus expectativas que toca hacer? hacer código desde cero.
Como dices lo ideal es aprender el lenguaje pero sobre todo aprender a programar y luego especializarse en un framework con la intención de saber que es lo que estoy haciendo.

Muy buen aporte (y)

absa dijo:

El problema se da en la total dependencia de un framework, cuando ese framework no cumple tus expectativas que toca hacer?

Hacer clic para expandir...

Así a bote pronto no se me ocurre este escenario.

Ponme un ejemplo de un Framework no cumpliendo las expectativas y la necesidad de hacer el codigo desde 0.

Jiren dijo:

Muy bueno, pero falto la recomendación de cursos de PHP.

Hacer clic para expandir...

Hay millones de cursos en español. Los de Platzi por citar algunos son muy populares.

Pero por mi experiencia no conozco dos personas que aprendan igual. Un amigo mio detestaba los videos, y solo era capaz de aprender leyendo libros. Hay gente que aprende "haciendo", es decir, haciendo microejercicios con cada tema.

En cambio a mi ninguno de estos dos metodos me sirve, yo solo soy capaz de aprender viendo ejemplos.

Si descubres tu mejor forma de aprender encontraras los cursos de PHP que mejor te servirán para aprender.

SirLouen dijo:

Ponme un ejemplo de un Framework no cumpliendo las expectativas y la necesidad de hacer el codigo desde 0.

Hacer clic para expandir...

Cuando debes optimizar el rendimiento. Recordemos que los frameworks luego contienen cosas innecesarias que no se utilizan, para hacer luego escalables los proyectos no solo basta con bajarse la librería del repositorio de composer ya que esto acostumbra a muchos ya no hacer nada, y que pasa cuando el programador o la comunidad ya no le da mantenimiento a la librería y por ende ya no recibe actualizaciones (lo ideal es que si yo se programar cubra ese highlight de tener actualizada la librería), es ahí donde radica el problema la total dependencia a terceros.

Te lo digo como buen usuario de Laravel, es una joya hablaría maravillas de el, pero al mismo tiempo me ha tocado meterme en el núcleo para optimizar ciertas cosas o requerir algún cambio específico.

Eso pasa, obviamente. Pero por mi experiencia hay una cosa que pasa aun más: proyectos a medida que se dejan sin mantenimiento y que al cabo de los años se quedan atrapados en una versión del lenguaje de programación plagada de exploits.

Cuando yo escribo algo, lo miro desde diferentes premisas, pero para mi, a parte del tiempo que ahorras, que es brutal (tiempo que ahorras que luego puedes reinvertir en arreglar esas faltas que encuentras, como la que comentas) y por otro lado, y aún mucho más importante, que si eliges modulos potentes y con una comunidad decente detrás, transcienden a las nuevas versiones

De hecho, hace poco un cliente mio, me paso una web, hecha en 2010, sobre PHP 5.1 a medida, entera, desde 0, la cual se caía constantemente por ataques de diferente índole (principalmente DDoS y consultas masivas a los formularios, que dada la antiguead, no llevaban ni validación y mucho menos, validación captcha).

Al actualizar a PHP 5.3 (que era lo máximo que permitía sin romperse la web despues de varias pruebas), me di cuenta que todavía se utilizaa la sintaxis antigua de <?= con lo cual tuve que lintear y refactorizar todo el código lo que me llevo buenas horas.

En cambio, me pasaron una página asociada, que estaba en Wordpress que estaba en el mismo servidor, en una versión 2.9 y conseguí actualizarla a 5.2.2, apenas se rompió un poco el template (que conseguí arreglar en apenas 1 hora), y conseguí restaurar todo, y todos sus plugins (solo había 1 obsoleto que lo pude sustituir sin problemas), y pase esa web a otro servidor con PHP 7.3 (porque ya no podría convivir en un servidor con PHP 5.3 tan antiguo).

Si hubiera estado hecha en Laravel, seguramente hubiera tenido serios problemas también, pero lo bueno, y es que a diferencia de la versión con PHP Puro, hubiera podido trazar los cambios de funciones mirando el registro de cambios, y haber ido refactorizando todo hasta upgradear hasta la versión 6.

Posiblemente me hubiera llevado al menos 10 veces más tiempo que en Wordpress, pero hubiera sido viable el cambio, con respecto a PHP puro. Por eso, pienso, a ciencia cierta, que es un total error programar en PHP desde 0. Es una mentalidad cortoplacista, que si bien, si es un proyecto de usar y tirar, bien, pero si es algo que queremos darle cierto grado de perpetuidad, lo vamos a lamentar en la mayoría de los casos (salvo que sea nuestro propio proyecto y le demos mucho amor y mimo durante el paso de los años).

Hoy en día, parece que sobra casi todo, menos el tiempo.

Muy interesante, gracias

Me gustaría ver como estaría hecho por ejemplo el sistema de facturación que tenemos ya sea con Wordpress o con Symfony nada más para ver que tan arcaica es la programación desde 0 con PHP. Un punto que no se menciona y que es de los principales por los que no me gustan los Frameworks es que me parece bastante absurdo tener que cargar al servidor miles de archivos (sin exagerar) para un sitio que contiene 5 sencillas secciones y que queda hecho con menos de 20 archivos (contando PHP, CSS, Javascript, etc.) en PHP puro.

Pero bueno cada quien tiene su forma de trabajar.

Programarte dijo:

Un punto que no se menciona y que es de los principales por los que no me gustan los Frameworks es que me parece bastante absurdo tener que cargar al servidor miles de archivos (sin exagerar) para un sitio que contiene 5 sencillas secciones y que queda hecho con menos de 20 archivos (contando PHP, CSS, Javascript, etc.) en PHP puro.

Hacer clic para expandir...

Me alegra que salga alguna alternativa para discusión, pero no demasiado esta alternativa en concreto, la cual me parece demasiado trivial por las razones que voy a ir comentando.

Vamos a desgranar un poco tu planteamiento en 2 partes:

Programarte dijo:

Un punto que no se menciona y que es de los principales por los que no me gustan los Frameworks es que me parece bastante absurdo tener que cargar al servidor miles de archivos (sin exagerar)

Hacer clic para expandir...

No tengo muy claro si estas partiendo por base de que el almacenamiento de "miles de archivos" como tu dices es un problema, o la carga de los mismos en memoria, por el autoloader, es el problema. Pero en ninguno de los casos, esto es un problema salvo para un viejete estancado en el pasado.

Si estuviéramos en 1990 con 200Mb de Disco duro y 8Mb de RAM, te daría 100% la razón.
El tema es que estamos en otra era, 3 décadas despues, donde la carga del autoload no ocupa más de 50Mb de RAM y la suma total de los ficheros, apenas ocupa 200Mb... en una era donde una máquina de 512Mb de RAM es gratis (Amazon AWS) y que Gmail te regala 10GB para tu correo electrónico, no creo que preocuparse por estas cifras sea tremendo y mucho menos eficiente. El tiempo que pierdes sobreoptimizando podría ser el dinero que ganarías simplemente alquilando una máquina superior, con el tiempo se paga sola.

Este es el argumento que han venido esgrimiento los programadores de muy bajo nivel que están estancados en PHP puro y no son capaces de entender como funciona un Framework. Lo gracioso es que los test hoy en día señalan que por defecto Laravel y Codeigniter tienen una velocidad espectacular y Wordpress sin nada, más de lo mismo. Obviamente un Hello World en PHP se ejecuta al menos el doble de rápido que un Hello World en Laravel y al menos 4 veces mas rápido que un Hello World en Wordpress

Pero en el momento que te pones a programar en PHP, empiezas a crear ineficiencias por todas partes. Y lo que hacía que PHP puro fuera hiper-eficiente se acaba volviendo un poco tortugoso. Nada de lo que enorgullecerse.

Con lo cual, ese punto que no se menciona, no se menciona por motivos obvios. El progreso está para que este tipo de historias queden en el pasado. No podemos decir que las espadas son muy eficientes en la guerra porque no consumen pólvora, lo que es un gran ahorro. Quizá cuando salieron las primeras armas de fuego que eran muy poco eficientes, precisas y gastarían mucha polvora, tenía sentido argumentar esto Pero hoy en día, si fueras al ejercito, te tacharían de loco...

Nota: Si buscas en Internet, hay gente que está en contra de los Frameworks, porque te encorsetan, te dan una estructura que tienes que seguir al pie de la letra. No te permiten ser libre a la hora de crear aplicaciones RESTful con modelos CRUD ampliamente consensuados. Esta gente, bajo mi opinion, son, como te comentaré en el punto anterior, egoistas que quieren cerrar su código a toda costa.

Programarte dijo:

Me gustaría ver como estaría hecho por ejemplo el sistema de facturación que tenemos ya sea con Wordpress o con Symfony nada más para ver que tan arcaica es la programación desde 0 con PHP.

Hacer clic para expandir...

Y lo segundo, esto es la mejor parte. Precisamente esta es la magia de Symfony, Laravel o Wordpress.

Con Symfony te simplica el proceso de crear, estructurar, hidratar, filtrar, organizar modelos, etc, etc, etc... precisamente todo lo que necesitas para forjar un sistema de facturación perfectamente hilado, y que el día de mañana, si por algún casual, alguien necesita ayudarte, o tú no puedes seguir programando para él, la empresa que lo use, pueda prescindir de ti y pasárselo a otro profesional.

Y en este punto, tú podrías tener razón, diciendo que al programar en PHP puro, "sellas" mejor tu trabajo con tu cliente, haciendo prácticamente imposible que tu cliente se vaya con otro programador dado que el código sea muy pobre y difícil de entender. Pero en caso que seas un verdadero profesional y no pienses en estas tonterías egoistas, seguramente habrás hecho un gran esfuerzo en estructurar tu código al máximo y documentarlo, ya no tanto para que otro lo entienda, sino para que tú, dentro de 1 año, si tienes que hacer un modificación, te acuerdes de donde están las cosas y porque hiciste aquello en vez de aquello otro.

Con Laravel/Symfony, organizar y documentar es pecata minuta: todo se estructura tan óptimamente bien, que volver a trabajar en el proyecto, será cuestión de minutos con independencia del tamaño del programa
Pero ahora viene lo mejor: las integraciones con modulos de terceros. Con Symfony/Laravel, tienes a una espectacular comunidad, llena de repositorios de extremadamente fácil integración, con los que, en un par de funciones, podrás integrar decenas de funcionalidades a tu programa: Integración con CRMs, integracion con pasarelas de pago como Paypal o Stripe, con servidores MTA y sus respectivas API, etc, etc, etc... todo quedando programado y funcional a una velocidad record.

En cambio en PHP puro, esto es un calvario: probar, probar y probar, integrar código y debuggear. Con suerte hay algun modulo por ahi de alguien que te integra esto, o con mala suerte, tendrás que tirar de los snippets que te dan las compañias para que lo uses en tu plataforma.
Y luego toca modularizar todo esto, otro calvario, y no equivocarte con los includes no vaya a ser que estes incluyendo cuatro veces el mismo fichero y todo esto acabe en un desperdicio de rendimiento por los cuatro costados.
A esto sumémosle el routing, la solidez del sistema de usuarios probado por varios millares de usuarios, la organización de los modelos de datos y la perfecta interconexión entre estos y la base de datos (no teniendo que hacer una sola query en tu vida y crear inconsistencias por doquier), el uso de un sistema heredado en condiciones con factorías, etc, etc, etc...

Y cuando llegas a dominarlo, todo esto es moco de pavo. Algo que haces rápido, veloz y sin dificultad, a una velocidad unas 3 y 4 veces superior a una programación básica en PHP como la que tu planteas.

Tal es la potencia de un Framework, que incluso he visto en algunos plugins de Wordpress, de algunos programadores gordos como OnTheGoSystems (Toolset/WPML), se montan pequeños frameworks para intentar dotar a Wordpress de la misma arquitectura...

Y finalmente, voy a terminar esta respuesta, con la Joya de la Corona: Wordpress

Como montar un sistema de facturación TOP en tres sencillos pasos:

A) Instalas Wordpress
B) Instalas este plugin: Sprout Invoices https://sproutinvoices.com/features/
C) Te metes aquí: https://sproutinvoices.com/features/invoices-for-developers/
Para entender como funciona su API y sus snippets

Y si aún así, te falta algo, lo programas con un plugin adjunto!! Vamos que tienes un sistema de facturación hiper-completo que seguramente satisfaga el 80% sino el 90% de lo que satisfaceria un programa hecho por tí, pero puesto en bandeja en apenas unos segundos.

Y todo esto, por un total de $40 al año!! $40 es lo que vale un programador senior en una hora. Y una hora es el tiempo que gasta para abrir su IDE y tomarse el café de la mañana y charlar un rato con su compañero de mesa. Vamos, que un sistema de facturación, sin lugar a dudas, es el peor ejemplo que me podrías poner para comparar un framework o Wordpress, con un desarrollo en PHP puro

Pero en tu caso, es diferente, porque lo que tu ofreces es un servicio de facturación a terceros. En este caso, quizá incluso podrías perfeccionar el plugin con la versión más top ($149 al año) y a posteriori introduciendo los elementos necesarios para proveer esa usabilidad a tus clientes. Wordpress te provee de un sistema de usuarios perfecto, y con algo de código podrás generar una plataforma totalmente multiusuario basándose en este plugin casi seguro

O en el peor de los casos, simplemente podrias tirar de Wordpress desde 0, y montarte bajo un template muy básico uno o varios plugins a medida creados por ti, que cumplan este cometido. Al igual que el Laravel/Symfony, Wordpress te provee de esta estructura. Incluso para no usar Custom Post Types que quizá son un poco ineficientes para segun que tareas (por ejemplo, para almacenar los registros de las facturas), podrías plantearte usar tus propias tablas. Puedes crear un front-end y back-end a medida y todo quedaría orquestado perfectamente, invirtiendo con total seguridad más de la mitad del tiempo que invertiste en crear dicha plataforma.

Pero después de todo este rollo, tengo que decirte que en el fondo te entiendo perfectamente. Si solo sabes programar en PHP, crees que se te da bien, y quieres conservar tu status quo obviamente tienes todo el derecho del mundo para defender esta postura.

Pero te voy a ser sincero, si yo fuera tu, haría un pequeño esfuerzo y me pondría a estudiar un Framework en profundidad urgentemente.
Si no poco a poco, te vas a ir quedando atrás. Aunque si tienes 60 años, ya para lo que te queda para jubilarte tampoco te preocupes. En 5 años no va a cambiar demasiado la cosa, sigue haciendo tus programitas en PHP a pelo y vive la vida loca.

👏👏👏👏👏 ¡Excelente aporte, compañero! Gracias por compartir, así da gusto pertenecer a este foro.

Interesante pero incompleto a mi parecer.

No es necesario saber mucho de PHP para aprender un framework, sencillamente lo correcto es saber manejarlo para no ser un esclavo del framework y el copy+paste de stackoverflow, como termina siendo la mayoría. No pocas veces me ha tocado ver cosas como "No se como hacerlo en javascript, pero siempre copio y pego este jquery y funciona" hasta el punto de que no diferencian entre lo que es del lenguaje y lo que es del framework, por lo que hacen cosas que podrían hacer mejor haciéndolas "vanilla" y no son capaces de usar otra cosa que no sea ese framework o les revienta la cabeza. Resumido: Aprender directamente un framework, te causará problemas.

Es cierto que el paso posterior a un lenguaje desde 0, sería el usar librerías y frameworks, pero no pare reemplazar a la programación desde 0, sino para hacer ciertos trabajos que entren en el nicho específico: Hacerlo rápido para hacerlo barato y que sea redituable y luego de entregarlo ya no será tu problema si la librería o el framework deja de ser viable para el proyecto en unos años (porque lo abandonan, por ej.), sino del siguiente que lo tendrá que mantener y probablemente solo lo haga desde 0 con otro framework y migre las bases de datos.

Hay muchos casos en los que un framework no es lo recomendable:

- Si vas a hacer un sistema sencillo, un framework es matar una mosca cañonazos, ahí hacerlo desde 0 es mejor.
- Si vas a hacer un proyecto grande y hay buen presupuesto para tomarte tu tiempo haciéndolo bien, actualizándolo, etc.
- Si vas a hacer algo cuyas licencias no sean compatibles con las que suelen usar los frameworks.
- Si quieres aprender de lo que haces y mejorar tus bases (proyectos personales, por ej.).
- Si requieres algo bien optimizado.
- Etc.

Igual, si nunca ordenaste tu mismo tus proyectos (siguen siendo un desorden), consideraría aún no tocar los frameworks. El MVC y demás, no son exclusivos de los frameworks, son de hecho anteriores y siempre puedes usarlos desde 0 o con librerías.

Algo en lo que estoy muy en desacuerdo con lo que has dicho como que "mejor usar el sistema de usuarios del framework, que es más seguro", ese es un error bastante común que de hecho suele procurar otros bugs peores: Del mismo modo que se debe aprender PHP desde 0, igual se debe aprender sobre seguridad, de modo que puedas prever si ciertos códigos pueden generar bugs, sean vanilla, con librería o con framework y no solo tenerle fe ciega y creer que el framework hará toda la magia o acabarán creando bugs ellos mismos, más si luego te toca arreglar a la rápida algo que en el framework dejaron mal hecho.

PD: Documentar no toma tanto tiempo, incluso hay herramientas para hacerlo mas rápido y aún con las mismas sigue siendo tedioso hacerlo. Los trabajos que hagas con frameworks igual se deberían documentar, a menos que no programes nada realmente y solo sea una suerte de configuración, por decirlo de alguna manera y por ello la documentación sea tan pequeña o nula que no sea necesaria hacerla.

PD2: Platzi :S

kj2 dijo:

Del mismo modo que se debe aprender PHP desde 0, igual se debe aprender sobre seguridad, lo más a fondo posible, de modo que puedas prever si ciertos códigos, sean vanilla, con librería o con framework y no solo tenerle fe ciega y creer que él hará toda la magia o acabarán creando bugs ellos mismos.

Hacer clic para expandir...

Yo no me fio de programaciones de un solo programador en una sola web no porque el programdor sea malo, sino porque es incapaz de contemplar millones de variantes que se dan en el día a día. Por mucho que sepas de seguridad y de buenas practicas el conocimiento colectivo va tapando todos los fallos paulatinamente y robusteciendo el sistema progresivamente.

Obviamente cuando en tu web entra +1 millon de personas al dia y puedes pagar a un equipo de buenos programadores en plantilla, quizá merezca la pena transcender alguno de estos sistemas de seguridad un poco más y hacer algunos retoques adicionales para reforzar la historia (incluso con un experto en seguridad adhoc). Aun así la facilidad con la que se integran medidas adicionales de seguridad en algunos sistemas y frameworks, para proyectos pequeños con pocos empleados, es, en cambio, una autentica complejidad cuando hablamos de un sistema hecho a mano.

kj2 dijo:

No pocas veces me ha tocado ver cosas como "No se como hacerlo en javascript, pero siempre copio y pego este jquery y funciona" hasta el punto de que no diferencian entre lo que es del lenguaje

Hacer clic para expandir...

En cierto punto, sabía que alguien iba a sacar jQuery, que es una condena de los frameworks porque en algun momento alguien decidió llamar a jQuery "framework". El 100% de las criticas serias contra los frameworks siempre sacan jQuery y tiene toda su logica

Estoy de acuerdo contigo, pero jQuery no es un framework en realidad. JQuery es una libreria y creo que son bastante importantes las diferencias. Un framework contiene librerias, pero una libreria no contiene frameworks. Por ejemplo, si hablamos de Javascript, tendriamos que hablar de BackboneJS no de jQuery. También podriamos hablar de Angular o de React que serian MVVM más que MVC pero sirven al uso.

El objetivo de un framework es estructurar la programación, en cambio el objetivo de una libreria, es simplificar el proceso y crear mayor abstracción. De hecho esta ha sido la tendencia desde que se inició la programación: pasamos de un sistema ensamblador, a una serie de lenguajes de programación muy primarios como COBOL los cuales abstraían este sistema ensamblador. Por el medio, pasamos de ensambladores a traductores y de traductores a lenguajes de programación muchisimo más abstractos. De C pasamos a C++ que abstraía aún más todo, y de C++ pasamos a Java y a Ruby que ya eran el culmén de la abstracción. Hoy en día existen BPMO en Java que permiten programar un sistema sin escribir una línea de código.

Pero aún así, sigo estando de acuerdo contigo, como te decía hace un momento, porque Jquery al simplificar el proceso, también engaña a los sentidos, haciendo que la gente no tenga porqué saber como funcionan los procesos internamente y puedan darse lugar a falsas interpretaciones.

Pero esto se ha dado siempre históricamente. Recuerdo cuando estudiaba algoritmia, me parecía una broma tener que aprenderme los malditos algoritmos casi de memoria, para entender que era viable alcanzar una complejidad de (n log n) para ordenar un array con quicksort, cuando al uso, ya existían librerías que te hacían el quicksort con un include y simplemente usando quicksort(variable_array); ya conseguía el mismo efecto que tener que aprenderme tal morralla.

Gente con tu forma de pensar, venía a replicarme regularmente: "Pero si no entiendes como usas el quicksort, nunca sabrás programar". De todos los programadores que he tenido en mi empresa, el mejor, sin lugar a dudas, con una diferencia abismal sobre el resto, no sabía programar el quicksort. Y creeme que era una verdadera máquina.

Así que creo que esa opinión de que hay que saber como funcionan las cosas para poder usarlas, creo que es como le dije al anterior compañero, es la clásica opinión del viejo académico que suele apoyarse en sus comparaciones entre un programador novato que lleva 2 meses y solo se ha aprendido 20 metodos de jquery, frente a un programador con 10 años de experiencia que domina muy bien javascript en su íntegra extensión.

Pero si hacemos una comparación en condiciones también podemos tener a un programador decente, con 5 años de experiencia, que domina ampliamente Angular y React, con conocimientos suficientes de Javascript, que se come con patatas al programador puro de javascript con el doble de experiencia, que en el fondo, es un viejete anclado en el pasado (o un joven que está al límite 🤣). Ponme a ambos a trabajar en el mismo proyecto, y te aseguro, con 100% de garantía, que el programador con 5 años que domina varios frameworks, te termina el trabajo en la mitad de tiempo.

Y esto lo sé con certeza, porque en mi vida, he tenido que hacer cientos de entrevistas y pruebas a programadores de diferente índole.

Como le dije al otro compañero, hazme caso, y aprende el MEAN stack. No te faltarán oportunidades en los próximos 10 años y ya no tanto por los frameworks en sí, sino porque al aprender esto, amplías tu cerebro y no te estancas en prácticas arcaícas, creando nuevas conexiones sinápticas en el cerebro que seguramente faciliten de sobremanera entender nuevas propuestas que vayan surgiendo en los próximos años. En cambio si no das ese paso, te vas a estancar, y luego te va a costar salir de ahí una verdadera locura.

Mi intención no es ser purista, es sencillamente que estás recomendando a novatos saltar a frameworks y de una manera tipo "confía ciegamente".

Las miles de variantes, sobre todo en lo que a seguridad respecta, realmente se dan al uso muchas veces, en código con saber lo básico de seguridad incluso ya te es suficiente para no meter la pata o al menos meterlo lo mismo que lo haría cualquier framework.

Cualquier programador aprende frameworks, porque se suele exigir velocidad. Yendo a tu ejemplo: Pones al "vejete" con javascript vanilla y al que lleva 5 años a base de javascript, el de frameworks desde luego que te lo hará mas rápido, la diferencia quizá sería que el vanilla te entregaría una web que hará tendrá 100KB de javascript, mientras que el de frameworks te dará uno que tenga 800KB y aún así en lo que respecta a tiempo, si es un trabajo que solo hay que entregar rápido (como suele ser para la mayoría de sistemas contables y webs sencillas que se encargan a empresas), barato y que no hay necesidad de mantenerlo realmente (el cliente no querrá actualizarlo sino hasta que ya no le funcione ni con mañas), pues el de frameworks en esa gran mayoría de casos será la mejor opción.

Tanto para a lo que respecta de seguridad, como a aprender de verdad, primero requieres bases. De lo contrario luego ves barbaridades de "programadores" los cuales en lo que a calidad de trabajo respecta, es equivalente o incluso inferior al de uno que no terminó la secundaria y está aprendiendo directamente a "configurar" con frameworks porque buscaba trabajo y encontró eso de oportunidad (este es un caso real, por cierto). Desde luego todos los trabajos de esta empresa, de cara al cliente se van a ver bien y funcionarán, aunque detrás tenga cosas que luego sea mejor hacerlas otra vez.

Al final, que la gente se apure con frameworks y solo con eso, es lo que más conviene al jefe, pero no lo que más le convine al programador, que tendrá que estar acostumbrándose a los nuevos frameworks y al no tener bases, tendrá que aprenderlo a las malas cada cierto tiempo y sin posibilidad de juzgar si X o Y framework es o no mejor para su proyecto: Mientras el programador con 5 años que de base comenzó solo por frameworks y es un experto en los mismos, se verá limitado por esos frameworks, sin poder pivotar a otros empleos o puestos ya que no tiene bases. El programador vanilla (dudo que de 5 años, en eso ya has aprendido algún framework y usado mil librerías por obligación de algún trabajo, ya que eso es parte de aprender el oficio) podrá pivotar fácilmente, podrá (y debería) aprender cualquier frameworks con facilidad, juzgarlo y arreglarlo en caso de que sea necesario (porque siempre hay bugs y no es plan de esperar que "la comunidad" lo arregle).

Desde luego, nuevamente desde la perspectiva del "jefe" igual y le renta más contratar a un full-frameworks novato y sin bases (el típico mal ejemplo de "programador" con frameworks), porque el vanilla que lo hará mejor y sabe de frameworks, tiene un perfil bien calificado que, si no es tonto, le permitiría exigir un mejor sueldo o convertirse él en el jefe, cosa que también he visto.

Por cierto, JQuery si es una libería, pero eso solo fue un ejemplo que bien aplica para cualquier framework o librería.

En resumen: El perfil completo de verdad de un programador es saber las bases, manejar lo que a seguridad respecta y luego, como añadido, ya que solo es una rama de su trabajo: Saber frameworks y puede que ni mucho, si es que a lo que se dedica no lo requiere (igual y programa los sistemas de los bancos, sistemas de vuelo, firmwares, ing. forence, inteligencia artificial, etc.).

Si le dedicas mucho a solo una rama, sobre todo dejando descuidadas las bases, te quedará la obsolescencia y mediocridad... y a tu jefe el dinero que le hiciste ganar por sacrificar tu tiempo solo en frameworks y no en mejorar todo el árbol de habilidades que tenías disponible.

Para hacer eso, mejor abandonas la universidad y agarras un taller intensivo de 2 semanas y así te ahorras el tiempo de estudio, que luego lo necesitarás en cuanto tus frameworks pierdan fuelle.

PD: Quicksort no es algo que haya que "programar" es un algoritmo resuelto (aquí el programador ya no tiene nada que hacer), que te lo lees en wikipedia, cualquiera que sepa recursividad lo puede escribir (ojo, escribir, no programar) en cualquier lenguaje.

kj2 dijo:

Mi intención no es ser purista, es sencillamente que estás recomendando a novatos saltar a frameworks y de una manera tipo "confía ciegamente".

Hacer clic para expandir...

En realidad, creo que no has seguido la conversación desde el principio.
De hecho precisamente recapitulé así en el primer mensaje (al final, en la conclusión), para evitar estos malentendidos para aquellos que no había leído el otro tema:

SirLouen dijo:

Si acabas de llegar al mundo de la programación y estás aprendiendo entonces PHP es básico y fundamental para empezar.

Pero si ya se tienen unos conocimientos intermedios de PHP, entonces la recomendación como puedes ver, es que pases a un framework, como Symfony o Laravel

Hacer clic para expandir...

Por otro lado:

kj2 dijo:

El programador vanilla (dudo que de 5 años, en eso ya has aprendido algún framework y usado mil librerías por obligación de algún trabajo, ya que eso es parte de aprender el oficio) podrá pivotar fácilmente,

Hacer clic para expandir...

Supongo que esto lo cuentas por experiencia propia. En el mundo real, esto nunca se da. Si ya tienes a alguien programando cómodamente con frameworks, rara vez te va a dar un paso atrás.

Generalmente, los que no te hablan de frameworks, y ensalzan exclusivamente las bondades del lenguaje puro, es que ya se quedaron estancados hace años y tienen una habilidad pesima en el uso de frameworks. Precisamente uno de mis programadores, ya ha pasado por tres frameworks en un suspiro (Laravel, Symfony y ZF2) y por cada salto, tarda menos de un cuarto de tiempo de lo que tardo en el framework anterior: se obseva en el perfectamente una progresión geométrica de aprendizaje. Lo paradójico, es que en su primer empleo me comentó que empezo a desarrollar páginas en Wordpress para una empresa muy famosa de bebidas en España.

kj2 dijo:

Por cierto, JQuery si es una libería, pero eso solo fue un ejemplo que bien aplica para cualquier framework o librería.

Hacer clic para expandir...

Usar jQuery, es un ejemplo que NO aplica a cualquier framework y que como te dije, siempre usa para "atacar" a los frameworks.
Por eso es importante diferenciar

kj2 dijo:

PD: Quicksort no es algo que haya que "programar" es un algoritmo resuelto (aquí el programador ya no tiene nada que hacer), que te lo lees en wikipedia, cualquiera que sepa recursividad lo puede escribir (ojo, escribir, no programar) en cualquier lenguaje.

Hacer clic para expandir...

En cambio, esta diferenciación que haces, sí que aplica a cualquier escenario, sea una función como quicksort, que no tienes que olvidar que pertenece a una librería (a la Standard Library que no deja de ser una libreria igual que jQuery). Pero es que hacer una diferencia explicita entre escribir y programar, solo se da en alto nivel, en una conversación que estamos discutiendo sobre la base de los frameworks.
Sería como resaltar la diferencia entre cocinar (poner la comida al fuego) y cocinar (todo el acto completo desde la preparación de los ingredientes hasta la presentación del plato).
Lo mismo como si usas una función para enviar email. Aquí estas hablando con gente que te va a hacer la función paso por paso, teniendo que leer toda la documentación relativa a todos los elementos de un mail relevantes.
En vez de simplemente usar PHPMailer que es la librería más popular del mundo, que sabes que nunca te va a dejar tirado, y que tiene un soporte detrás continuado adaptandose a todas las novedades del estándar de los e-mail (y por ende, no se te va a quedar obsoleta nunca).
Cuando implementan la función paso a paso, ¿están programando o escribiendo? Están programando, porque posiblemente no tengan la definición por delante. Pues igual que si alguien conoce el quicksort de memoria: puede saber el algoritmo, pero al final puede decidir hacerlo iterando o recurriendo. En el fondo, programando en cualquiera de sus formas

El concepto, sigue siendo el mismo: ¿para qué necesitas "escribir" una llamada AJAX en javascript si tienes la llamada perfectamente formulada en una llamada jQuery?

Pero a lo mejor tú te sientes muy fresa, chocolate o vainilla cuando programas en javascript la llamada AJAX con todos sus componentes, desde 0. Práctico, eficaz y para todos los públicos. Yo soy más de Straciatella: y ojo, yo soy el primero que programa en PHP bastante holgado y que me cuesta subirme al carro de los frameworks constantemente. Soy el primero que debería defender esta postura vainillera. Pero como tu dices, desde la perspectiva del "jefe", o del que orquestra la producción y el avance, el tren pasa 1 vez, y ya no para. Y cuanto estas dentro, como te dije, la evolución es geométrica. Pero si no te subes, al final ocurre lo contrario: el trabajo que cuesta subirse, conforme pasan los años, se multiplica más que sumarse.

Y finalmente una reflexión: ¿Para qué se necesita estar constantemente, reinventando la rueda?

Dentro de los comentarios que haces veo que das por hecho ciertas cosas que si bien a ti te han pasado como jefe no quiere decir que el resto de las situaciones sea 100% igual. En primera das a entender que el código de los Frameworks está mucho más estructurado que uno hecho desde 0 lo cual creo que es una de esas afirmaciones que no puede ser 100% real, aunque he de decir que efectivamente la mayoría (de los que yo he conocido) de los programadores que según son profesionistas son realmente un asco para programar y realmente crean código ineficiente, redundante, mal estructurado, etc.

Incluso yo en proyectos que no tienen mayor complejidad, trascendencia o importancia no me esfuerzo al máximo por dejar todo impecable y ni siquiera documentado pues termina siendo una sencilla página informativa que tendrá cierto periodo de vida y que además el nivel de complejidad es tan bajo que aunque lo tomes 3 años después no tendrías problema alguno en entender lo que se hizo o cualquier otro programador con conocimientos medios e incluso básicos.

Por otro lado por ejemplo en un proyecto que estamos trabajando que es un Web Service para un programa de lealtad de una cadena de tiendas nacional donde hay que programar lo necesario para recibir las peticiones de los POS, hacer procesos con la información y finalmente almacenar datos en la base todo tiene que estar perfectamente estructurado y la documentación no es opcional (estuviera hecho en lo que estuviera). No sé si piensas que en este tipo de ejemplos, donde por ejemplo no existe una interfaz gráfica, también es más práctico un Framework.

He mencionado, o dado a entender que no me gusta usar los Frameworks, esto habiendo trabajado con PHP desde 0 y con WordPress. Y entiendo perfectamente que a unos les guste más una cosa que la otra. Desde tu punto de vista usar PHP desde 0 es para viejitos estancados y es respetable, desde mi punto de vista esa afirmación sería parecida a decir que los que usan WordPress es porque no saben programar, pero repito es mi punto de vista.

El argumento que más repites y que me parece el más válido porque no está sujeto a la subjetividad es que el uso de Frameworks reduce el número de horas de trabajo y eso en la mayoría de los casos aplica perfectamente, aunque como decía al principio no en todos pues aunque los sistemas o simples páginas se desarrollen desde 0 realmente es muy común reutilizar buena parte de unos proyectos u otros en nuevos proyectos y de cierta manera termina siendo más o menos la misma idea y que tiene que ver con tu reflexión: no es necesario estar reinventando la rueda una y otra vez.

Programarte dijo:

Por otro lado por ejemplo en un proyecto que estamos trabajando que es un Web Service para un programa de lealtad de una cadena de tiendas nacional donde hay que programar lo necesario para recibir las peticiones de los POS, hacer procesos con la información y finalmente almacenar datos en la base todo tiene que estar perfectamente estructurado y la documentación no es opcional (estuviera hecho en lo que estuviera). No sé si piensas que en este tipo de ejemplos, donde por ejemplo no existe una interfaz gráfica, también es más práctico un Framework.

Hacer clic para expandir...

En este escenario puedes montar un Lumen o un Symlex (dependiendo si manejas mas Laravel o Symfony)

Yo creo que es de necesidad usar un framework porque en cierto grado estandarizas tus procesos. Hasta podrias optar por Codeigniter que tiene un footprint muy bajo, con un rendimiento de la mitad de PHP puro que es verdaderamente espectacular. Yo no soy muy fan de Codeigniter porque no tiene una gran comunidad detrás.

Y si eres fanático del rendimiento, tienes Ubiquity https://github.com/phpMv/ubiquity
Que parecido a BackboneJS para JS simplemente está ahi para estructurar la información pero aportando lo mínimo de lo mínimo. Sería casi como usar un boilerplate con lo básico de un framework.

Todas estas opciones optimas para un servidor headless. Pero como digo, lo importante es la estructura. Más incluso que la velocidad de desarrollo. Es cierto que se puede usar mal la estructura, pero poco a poco se le va pillando el truco si se insiste.