Вот почему Clojure нужны веб-фреймворки.
Я не знаю, на каком уровне находятся мои способности к программированию, я хотел бы сказать, что я эксперт, но я также могу быть одним из тех, кто имеет 1 год опыта в 10 раз больше 😬, как знать. Я знаю одно: после того, как я отправился в путешествие по написанию 12 веб-приложений / нативных приложений за 12 месяцев на основе моей собственной платформы clojure, веб-разработчикам нужны фреймворки, а не библиотеки.
В зоне
Я знаю, что это называется потоком, но знаете, что еще называется потоком? Женский период. Я называю это зоной, потому что я не сексист и думаю, что все программисты могут наслаждаться этим состоянием продуктивности. Когда вы пишете веб-приложение или, честно говоря, веб-сайт, вы хотите достичь этого состояния непрерывной концентрации. Вы делаете больше за гораздо более короткий период времени, чем обычно, и это очень весело! Какой самый хороший способ достичь этого возвышенного состояния? Веб-фреймворки. Я сказал это. Веб-разработчики Clojure придерживаются этого странного мировоззрения, отрицая, насколько хороши веб-фреймворки. Было бы здорово выбрать библиотеки, если бы вам не приходилось переключать контекст и пытаться искать нужную библиотеку. Я, честно говоря, не понимаю, почему выбор между разными переносчиками базы данных или разными парсерами параметров URL - это хорошо. Это подводит меня к следующей проблеме, связанной с библиотечным подходом.
Парадокс выбора
Похоже, было бы здорово, может быть, иметь несколько вариантов, для какой библиотеки auth, какой парсер параметров URL, какой маршрутизатор или какой html-рендерер выбрать, но на практике это увеличивает когнитивную нагрузку на создание веб-сайта. Я действительно не знаю, сколько разработчиков Rails, Laravel или Phoenix подумали про себя, о, мне не нравится, как разбираются параметры URL, я должен их поменять. Нет, они слишком заняты созданием веб-сайтов и не увязнут в кучу ненужных решений. Совершенство - враг достаточно хорошего, и думаю, что такой упор на библиотеки - это отход от корней шепелявых корней clojure, где мы все стремимся к совершенству кода, а не просто создавать вещи и выкладывать их там. Вы можете распространить это на сами фреймворки, но я не утверждаю, что должен быть только настоящий фреймворк, я утверждаю, что принятие решения о том, какой фреймворк выбрать, а не отдельные его части, является гораздо более целесообразным решением. Наличие различных целых фреймворков на выбор - определенно отличная вещь. В Clojure должно быть множество фреймворков, но, к сожалению, его нет. Люди указывают либо на luminus (который представляет собой просто набор библиотек), либо на GTFO. Я имею в виду, что было бы в блоге о веб-фреймворках с мастерски рассчитанным по времени плагином какого-то фреймворка с открытым исходным кодом, над которым работает автор?
Примите рамку, станьте рамкой
Побег на clojure, великое имя, еще большие участники. Почему вы должны выбрать побережье в качестве следующего веб-фреймворка? Я скажу вам почему: clojure. Нет, но, честно говоря, я думаю, что это дает некоторые новые концепции, которые вы не часто видите в веб-фреймворках на языках, созданных на основе алгоритмов. Относительная нехватка кода, который вы будете писать, действительно заслуживает внимания. Clojure действительно отличный язык для быстрого, безопасного создания веб-сайтов с наименьшим количеством ошибок, которые вы можете выявить. В 2019 году я буду все больше и больше углубляться в побережье, но пока мне нужно сделать резервную копию и привести аргументы в пользу фреймворков в целом.
