— "Це правда! Я маю фреймворк, який може відобразити CRUD за допомогою однієї стрічки коду. Він може рендерити веб-сторінки, використовуючи MVC паттерн з найменшими зусиллями, і немає значення як ви накапарите з HTML в своїх темплатах і з CSS в своїх стилях, з нашою технологією "зроби-красіво" ваш сайт завжди матиме достойний вигляд. По суті фреймворк навіть вибере лей-аут сторінки, який буде найкраще підходити для відвідувача, при тому ще й з самими оптимальними показниками виконання, з якими вам коли-небудь приходилось стикатись".
Якщо ви шукаєте ссилку «Скачати», будь ласка, облиште це зайняття: такого фреймворка не існує. Незважаючи на те, що абзац вище очевидний, я завжди наголошую людям, які серйозно займаються пошуком фреймворка на всі випадки життя. Я навіть спілкувався з розробниками, які використовували Zend Framework для кожного проекта, який вони робили, бо їхньому боссу сказали, що це найкращий фреймворк. Zend дійсно хороший фреймворк, який ви зможете використати в більшості випадків, але є задачі, з якими інший вибраний фреймворк міг би справитись краще.
Фреймворк, який би допомагав вирішити будь-яку проблему, яку ви можете уявити просто не існує і не може бути створений з декількох причинам.
По-перше, якщо фреймворк хоче забезпечити готове рішення для великої кількості ситуацій, то все менше часу залишається на розробку вирішення для конкретної ситуації. Тому фреймворки, які націлені на вузьке коло проблем, що вони вирішують, буде кращим рішенням. З іншої сторони ви не хочете використовувати 20 різних фреймворків в одному проекті, бо вам займе багато часу знайомство з кожним з них і підтримувати фреймворки в актуальному стані буде основною вашою болячкою.
По-друге, фреймворк повинен бути великим і малим одночасно. Якщо ви побудуєте фреймворк, який буде робити масу речей, він у вас получиться великим. Якщо вам потрібно буде застосувати тільки один аспект, то у вас можуть виникнути накладки з цим. Користі від здорового фреймворка не буде, якого для того щоб розвернути, потрібно інсталювати і настроїти, якщо все, що ви хотіли зробити, — це маленький скрипт на 5 стрічок, який запускається по crontab. Звісно фреймворк може бути більш захищеним в цьому випадку, але подумайте про кількість include-ів і перевірок, які повинен виконати фреймворк перед тим, як добереться до виконання власне вашого коду! В конкретному випадку краще буде використати компонентний фреймворк, або частину великого фреймворка.
Є багато інших причин, щоб ви не покладались тільки на один фреймворк. Інколи ви хочете швидко шось "приготувати" і те, як це працює і виглядає є менш важливе, чим власне задачу, яку код виконує. На іншому проекті вам буде потрібно тюнінгувати кожного компонента, наприклад настроїти вигляд кожної кнопки. Ці два різних проекти потребують абсолютно різних фреймворків, і, очевидно, другий потребую потужнішого і функціональнішого. Це речі, про які ви не повинні забувати при виборі фреймворка.
Один з аргументів в користь використання єдиного інструмента є можливість спеціалізації розробників на виконанні одного (одноманітного) завдання. Використання правильного інструменту зробить розробника набагато ефективнішим загалом. Розділити кусок дерева молотком буде важко, і результат, що ми отримаємо, не буде одним з кращих, не залежно від того яким б "майстром молотка" ви не були. Набагато корисніше знати, що є такий пристрій як пила і яке його застосування. Якщо ви не знаєте яким боком пила повинна бути повернена вверх, — не хвилюйтесь, — це можна дізнатись із документації до пили або запитати в людей, які користувались пилою раніше, на форумах підтримки.
Тому необхідно знати, які фреймворки вже існують і яким краще скористатись в конкретній ситуації. Вам не обов’язково бути гуру в кожному з цим фреймворків. Хоча знання фреймворків і ситуацій, коли їх варто застосовувати може надати вам велику перевагу над розробниками, які користуютья тільки одним інструментом.