Существует больше комбинаций внешнего интерфейса, чем разработчиков внешнего интерфейса — МЭ

История гласит, что я отвечал за создание Веб-сайта CSM BA Graphic Design 2016 Degree Show, и он будет реализован на основе дизайнов, предоставленных командой брендинга. Я работал в небольшой команде из трех человек, но оказалось, что другие части дипломного шоу нуждаются в их помощи больше (ну, публикация появляется только через два дня после начала шоу, FFS), и поэтому я остался работать один. на веб-сайте полный рабочий день в течение 3–4 недель, где мне нужно создать серверную часть для выпускников, чтобы они могли заполнять свои данные, интерфейсную часть, чтобы брать эти данные и отображать их в соответствии с дизайном и развертывать его, не тратя ни копейки моих деньги, я, технически, все еще был студентом в конце концов.

Прежде всего, мне нужно было сделать что-то быстрое, так как мне нужно было начать собирать данные о студентах как можно скорее, а если веб-сайт задержится, люди (читай: все) могут забеспокоиться, что никто не придет на шоу. Во-вторых, мне нужно что-то максимально настраиваемое, особенно с точки зрения внешнего вида и дизайна, вы не можете просить целый год студентов, изучающих графический дизайн, радоваться тому, что их веб-сайт выглядит как очередной загрузочный сайт.

Если вы разработчик интерфейса, читаете это и хотите что-то предложить, не делайте этого, только не сейчас. То, что я создаю, также потенциально должно быть доступно для тех, кто собирается сделать веб-сайт CSM BA Graphic Design 2017 Degree Show, поэтому ваше предложение Angular 2 с React.js + фанковый API-интерфейс node.js с хранилищем NoSQL не произойдет. Большинство новичков едва ли могут использовать jQuery, если вы не общаетесь с маглами.

Я должен признаться: я использовал backbone.js в своем внешнем стеке, но пока не нападайте на меня с вилами! Я сделал несколько умных вещей, чтобы скрыть этот факт, чтобы новички не беспокоились об этом. Что они? Это для другой статьи, потому что мне действительно нужно написать о моем стеке.

Чтобы быстро пройтись по всем компонентам, прежде чем я перейду к их объяснению: на задней панели есть только сайт Wordpress, на котором запущены такие плагины, как Advance Custom Fields, WP REST API, Maintenence и другие с некоторыми PHP-скрипты для управления настраиваемыми полями и ответом API, поскольку по умолчанию возвращается слишком много вещей, которые мне не нужны, и формат недостаточно удобен для использования. Во внешнем интерфейсе, где я стремлюсь выполнять большую часть работы (я ненавижу PHP, хорошо?), jQuery, backbone.js, smark.js и любую другую служебную библиотеку, которая мне нужна.

Бэкэнд

Задняя часть демонстрирует быстрый и простой (относительно). Я размещаю сайт Wordpress на сервере (в случае с BAGD, на сервере колледжа, бесплатно) и позволяю студентам зарегистрироваться и создать сообщение для заполнения своих данных, никому не нужно вводить данные, гениально! Кроме того, мне не нужно самому создавать серверную часть, я очень нервничаю из-за таких вещей, я не являюсь серверной частью или полноценным разработчиком полного стека, я могу сделать что-то ужасно неправильное…

Вы можете задаться вопросом, почему бы мне просто не создать все это в Wordpress? Зачем создавать сервер API и вместо этого иметь внешний интерфейс? Как я уже упоминал ранее, я ненавижу PHP, я не хочу смотреть на него ни на секунду дольше, чем это необходимо, я надеюсь, что он умрет в ужасном пожаре, который разожжен вовсе не мной. Кроме того, Wordpress считает, что всегда ожидает что-то в виде постов, что не всегда является правильной идеей для всего.

Передняя часть

Что касается внешнего интерфейса, jQuery на самом деле является данностью, получить минимизированную версию v2 совсем не сложно, особенно если вы используете CDN, что вам следует. Backbone.js — это мой выбранный интерфейсный фреймворк, прежде всего потому, что он позволяет вам делать все, что вы хотите, и так, как вы хотите, гибкость имеет решающее значение, как упоминалось ранее. Кроме того, underscore/lodash — очень полезная библиотека (о чем свидетельствует то, что она является наиболее зависимым пакетом NPM с давних пор). Еще одна js-библиотека, которую я регулярно использую, — это smark.js, вы не слышали о ней раньше, потому что я написал ее. Он просто анализирует строки в действительный HTML, используя синтаксис, подобный уценке (уценка без новых строк) и сопоставление URL. Это помогает ускорить вставку общих ссылок, видео и изображений.

Что касается таблиц стилей, я пробовал SCSS, Less и postcss с плагинами. То, что я пишу, в основном одно и то же, postcss с плагинами потенциально медленнее компилируется, а различные плагины иногда плохо работают вместе, поэтому я, вероятно, не буду использовать это снова. SCSS и Less различаются только по второстепенным вопросам, поэтому я рассматриваю их как эквивалентные, я использую Less больше просто по привычке. Используется Normalize.css, но никакие другие сторонние таблицы стилей не использовались, если только это не требуется какой-либо библиотеке, такой как fontawesome.

HTML сам по себе является более новым дополнением к моему интерфейсному стеку. Раньше у меня был только один файл HTML (index.html), но по мере того, как приложения становятся все более сложными, а заголовки более полными, один файл HTML просто неуправляем, мне нужно что-то для статической компиляции шаблонов в один файл index.html, который я на самом деле развертывать. Сначала я использовал Jade (это был еще Jade, когда я его использовал, сейчас это Pug), который статически компилирует шаблоны в собственном синтаксисе в HTML. Однако я нахожу синтаксис слишком минималистичным, он использует только пробелы для определения структуры и, в отличие, скажем, от Python или Ruby, управляющие структуры не имеют ничего, что сигнализировало бы об окончании. Это означает, что мне трудно читать это, потому что я не могу легко найти, где что-то начинается или заканчивается, мне нужно отслеживать пробелы, чтобы определить это. Я хотел использовать рули, но сами рули не предоставляют статический компилятор. В конце концов я все равно выбрал руль со статическим компилятором, предоставляемым плагинами Gulp.

И последнее, но не менее важное: инструменты для сборки. В этом случае у меня есть два предпочтения: NPM и Gulp.

Используете NPM в качестве инструмента сборки? Какой хипстер.

Да, спасибо, но хотите верьте, хотите нет, но для небольших проектов NPM настраивается намного быстрее, чем любой другой инструмент сборки. Единственное, что вам нужно для NPM, — это знание bash, а инструменты, которые вы используете, предоставляют интерфейс командной строки (что и должно быть). Часто вы можете сделать ставку на инструменты с интерфейсом командной строки, а не на плагины для Grunt или Gulp (часто не оба, что раздражает). Я не занимаюсь написанием плагинов для Grunt или Gulp, но я занимаюсь написанием приложений командной строки node.js, поэтому, если у меня есть выбор, я пишу сценарий командной строки для запуска непонятного мне инструмента. Сказав это, когда проект становится все больше и больше, NPM будет показывать свои трещины, становится сложнее писать шаги сборки, и выполнение одного шага за другим довольно медленно (может быть, я делаю что-то не так, я не знаю). Использование Grunt или Gulp делает написание сложных шагов сборки более понятным, а их последовательное выполнение — более быстрым. Почему тогда я предпочитаю Gulp Grunt? В основном из-за файла конфигурации. Gruntfile — это просто файлы конфигурации, тогда как Gulpfile на самом деле является файлом js для всех целей и задач. Я могу интегрировать собственный материал node.js или другие собственные пакеты NPM непосредственно в свой Gulpfile и ожидать, что он будет работать так, как я его определил, что для меня является огромным плюсом.

Что я хочу улучшить

Я очень доволен своим интерфейсным стеком, мне просто нужно объединить его в шаблон, чтобы я мог быстро приступить к работе. У меня больше проблем с моим внутренним стеком, я упоминал, что ненавижу PHP? Да? Я еще раз упомяну:

Я НЕНАВИЖУ PHP!

Так что да, то, что я хочу улучшить для своей серверной части, — это не столько улучшение, сколько полное изменение. Мне еще предстоит найти API-фреймворк на основе node.js, который является достаточно зрелым, активно поддерживается и существует. Если ничего не помогает и у меня есть много свободного времени, у меня может возникнуть соблазн написать его самому. Я все еще надеюсь, что мне не придется.

О, ты все еще здесь

Поскольку вы не заскучали и не бросили ярость, читая о моем заблуждении, я благодарю вас. Также я хотел бы перенаправить вас обратно к верхней цитате. Да, это мой стек, только я им сейчас пользуюсь. Конечно, вы можете копировать меня, но вы также можете придерживаться своего, если он вам подходит. Я могу многое делать не так, вежливо дайте мне знать в комментариях, и я либо скажу вам, почему я этого не сделал, либо отвечу

Интересный…