Para los proyectos que entran en producción, se desaconseja evitar los marcos porque le cuesta tiempo , cosas equivalentes a tiempo y todos los beneficios del código repetitivo de alta calidad que alguien más ha escrito para usted. Las bibliotecas y los marcos populares (front-and-end) tienen soluciones comprobadas para cosas como manipulación DOM, AJAX, enrutamiento de solicitudes, MVC, filtrado XSS, protección CSRF, acceso a la base de datos independiente del motor, ACL, validación de correo electrónico, etc. Problemas comunes que no siempre son fáciles de resolver. Si el proyecto es por pago, estaría perjudicando a su empleador al tomarse el tiempo para reinventar la rueda.
Editar para agregar: en los comentarios, Mark Simchock señala que tener un marco o dos en su currículum también puede hacerlo más atractivo para los empleadores. No tener esa ventaja podría ser otro costo.
Ahora vamos por la respuesta larga. En este contexto, hay dos razones básicas para comenzar un proyecto de software:
- ¿Qué aplicación es mejor para crear un sitio web?
- Dado que PHP es tan odiado, ¿qué usa la gente como reemplazo? ¿Qué otros idiomas debo aprender en lugar de PHP?
- ¿En qué medida los empleadores pagan completamente los planes de pensiones para los desarrolladores de software en los Países Bajos?
- ¿Cuál es el mejor marco en selenio?
- ¿Los diferentes lenguajes de programación atraen a diferentes tipos de personalidad?
- Para crear un producto útil
- Aprender algo
No son mutuamente excluyentes, pero debe averiguar cuál es más importante lo antes posible y abordar el proyecto en consecuencia. Si su objetivo principal es aprender algo, a veces tiene sentido replicar partes de un marco solo para ver qué tipo de ingeniería requieren. Probar eso una vez también puede ayudarlo a pasar de “Usar este código se siente como hacer trampa” a “Este es un problema no trivial que es tangente a mi objetivo y me alegra que alguien más lo haya resuelto por mí”. Puede ser difícil apreciar una herramienta bien escrita como jQuery o Rails hasta que haya intentado normalizar Javascript con DOM pesado en los navegadores o lidiar con los espaguetis de fondo, pero es más fácil ver cuánto trabajo ahorran si intenta clonarlos .
Trate de no pensar en las herramientas como una muleta. No se trata de si puedes reproducirlos; la pregunta es si vale la pena, y la respuesta es casi siempre no. Una buena ingeniería de software se trata de gestionar la complejidad y obtener un código sólido. Cualquier cosa que le permita cambiar su enfoque de lo que exactamente va a escribir a lo que su aplicación va a hacer es una herramienta que lo hace más efectivo. El truco es descubrir qué detalles no le interesan y ver si algún otro proyecto puede manejarlos por usted.
Por supuesto, habrá momentos en que las soluciones que existen no sean lo suficientemente buenas. Si está haciendo algo que nadie ha hecho antes, puede terminar escribiendo la primera herramienta que resuelve un nuevo problema, y si eso sucede, estaría haciendo un servicio a todos si lo lanzara para que otros puedan beneficiarse de las lecciones que usted aprendido.
