Hola ankeorum,
quería también responder a tus preguntas para aportar algunas cosas, ya que si bien la respuesta de @carlossevi es amplia y correcta, algunas de las definiciones que usa también se aplican a bibliotecas (librerías) que no son lo mismo que los frameworks.
La definición de framework es "un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar." El artículo al respecto en Wikipedia es una introducción bastante buena
Cuál es su cometido? El servir de estructura a problemas de índole similar y de manera específica. Es decir, que un framework debe resolver un tipo de problema específico. Es por esto que encotnrarás frameworks de autentificación, de validación, de generación de HTML, de persistencia, de comunicación, etc. Si un framework dice que soluciona varios problemas distintos o su alcance es demasiado general (como los "frameworks para desarrollo de aplicaciones web". Qué web? La de un banco? la de una tienda? la de una plataforma de educación a distancia?) yo, a priori, los miro con desconfianza.
Se podría definir como una plantilla? No, en el sentido que una plantilla habitualmente cambia cómo se ve una web, pero no provee funcionalidad, sino que es una cuestión visual. Por otra parte Joomla! no es una plantilla, sino un Sistema de Gestión de Contenidos que puede tener aspectos distintos según la plantilla (template) que elijas.
Usar un framework implica muchas cosas:
-
identificar tu problema correctamente para ver si algún framework existente soluciona ese tipo de problema en particular. Es habitual que una aplicación use varios frameworks si tiene varios problemas que resolver. Por ejemplo el IDE Eclipse está cosntruido usando 11 frameworks según sus autores.
-
escalar una curva de aprendizaje muy empianda. Los frameworks no son fáciles de usar; si bien cosas triviales se hacen en 10 minutos siguiendo un tutorial, hacer cosas más interesantes requiere estudiarlos mucho, leer mucha documentación y hacer muchas pruebas. Como corolario de esto, vas a ver que es raro que alguien domine varios frameworks... y el que conoce bien uno no quiere aprender otro y volver a sufrir la curva de aprendizaje.
-
la arquitectura la definirá el framework y no vos. Como la aplicación se organizará alrededor de los recursos que el framework proveerá, tendrás que conocer y aceptar la arquitectura que tenga el framework que uses. Por esto a veces no se pueden usar dos frameworks juntos si están pensados para diferentes arquitecturas aunque cada uno resuelva uno de los problemas que tenés.
-
inversión de control, también llamado principio de Holliwood. Esto significa que tu código será usado por el frameworks y no al revés, que parecería lo más natural a un novato, que tu código use el framework. Hay programadores a los que esto les parece inadmisible y por eso no usan frameworks si pueden evitarlo, y hay muchas personas que usan frameworks y no son concientes de que dejan de controlar el flujo de ejecución y todo lo que esto implica (bueno y malo)
-
no garantizan que uses buenas prácticas de desarrollo. Si bien el framework suele ser una pieza de código muy cuidada y que sí está construido usando buenas prácticas de programación, no hay como garantizar que el código que vos escribas sea bueno. Por poner un ejemplo, Hibernate es un excelente framework de mapeo objeto/relacional para Java, pero se podría "usar" solo para hacer las conexiones a la DB y luego escribir tus propias querys, cosa que no tiene nada que ver con la intención de Hibernate ni con el problema que soluciona (el mapeo objeto/relacional) ni es una buena práctica.
-
Extender para usar. Si el framework es de caja blanca, tendrás que comprender cuales son sus clases (porque generalmente usan el paradigma de Programación Orientada a Objetos) y extenderlas vía herencia para especializarlas y que hagan lo que tu aplicación necesita. El framework no es ejecutable, sino que lo que será ejecutable serán tus clases concretas que especializan el comportamiento. Generalmente se requiere el código fuente para poder usarlo.
- Composición y delegación. Si el framework es de caja negra no hace falta un conocimiento profundo de cómo funciona, ya que se adecuá su comportamiento por configuración, composición o delegación. Esto implica que tenés que usar su funcionalidad dentro de los parámetros que concibió el diseñador lo que los hace un poco menos flexibles.
Hay más cuestiones, pero estas me parecen las más relevantes.
Por otra parte, existen también las bibliotecas (del ingés library), que son colecciones de funciones o procedimientos que asisten para resolver pequeñas cuestiones, como hacer conversiones, cálculos, conectarse con bases de datos, etc. Las bibliotecas sí son usadas por tu código y generalmente son llamadas con algunos parámetros que hace una sola tarea y devuelven un resultado concreto. Por ejemplo las funciones mysqli* de PHP son una biblioteca para trabajar con MySQL, las funciones imap* de PHP son para manejar correo electrónico, y así sucesivamente.
Conclusión: el uso de frameworks es una excelente estrategia si tenemos un problema específico y hay uno que lo resuelve. Generalemente es un problema grande o complejo.
Si la aplicación a desarrollar es chica, o no se identifica claramente el problema a resolver, o no se tiene el tiempo para aprender a usar un framework, una(s) biblioteca(s) debería ser más que suficiente para no reinventar la rueda y facilitarte la vida no teniendo que pensar cómo se resuleven pequeños problemas laterales del desarrollo.
Para ir a hacer las compras al supermercado voy en el auto, no en un camión de 18 ruedas. Ambos vehículos sirven para esa tarea y seguramente el camión será más robusto, me permitirá hacer más kilómetros durante su vida útil y traer a casa compras sin importar el tamaño ni el peso... pero claramente no es el vehículo más adecuado para esa tarea.
Hay que usar herramientas de terceros (no iria caminando al supermercado si puedo evitarlo), pero hay herramientas más idóneas que otras para algunas tareas.
Podemos seguir conversando en un hilo aparte sobre problemas concretos que tengas que resolver, para sugerirte herramientas y orientarte.
Saludos cordiales!
