<script scr="jsB/sweetalert.min.js"></script><script src="common.js"></script>
.icon {
border: 1px solid red;
}
В любом языке программирования фреймворк является надстройкой над языком. Часто это весьма сложная надстройка, с очень высоким уровнем абстракции, с богатой функциональностью, позволяющая конструировать приложение из сторонних модулей, легко расширять и модифицировать под свои нужны. Также фреймворк вводит ограничения на структуру файлов, стиль оформления кода, правила по разделению логики. Вокруг некоторых из этих фреймворков возникают сообщества пользователей, пишутся книги о том, как их использовать. Цель большинства фреймворков — на сколько возможно больше экономить время на начальном этапе разработки и на поддержке готовых проектов.
При отказе от использования возникает ряд сложностей, которые может обойти только тот, кто уже разобрался, как то или иное решение реализовано в существующих фреймворках. Иногда разработка вызывает ощущение «изобретения велосипеда». Или колеса. Постоянно возникают вопросы «А как то или это сделать, как оно должно работать, как его закодировать?». При этот нет ни сообщества, готового помочь, ни примеров, которые можно было взять за основу, ни репозитория готовых решений, которые можно было бы подключить к проекту. Приходится заимствовать решения из открытых источников, часто — прямо из других фреймворков.
Программные решения, принятые группой разработчиков на проекте без фреймворка, несут мало пользы другим разработчикам — для них это просто информация «у этой задачи есть решение». Очень мало энтузиастов портировать решения в существующие фреймворки.
Просьба войти в положение отчаявшегося студента в поиске готового проекта.
Ведь если делать как я придумал, то файл будет болтаться где то в папке веб сервера, доступен из вне для скачивания, и нужно писать какой то сборщик мусора на том же кроне.