Это редакционная статья моего последнего JavaScript-бюллетеня, вы можете подписаться здесь .
Я пришел с хорошими новостями! Для тех из вас, кто еще не слышал (где вы были?), SitePoint недавно запустил новый подкаст: The Versioning Show . Его возглавляют постоянные участники SitePoint М. Дэвид Грин и Тим Эвко, которые каждую неделю садятся обсуждать индустрию Интернета, от разработки до дизайна, с некоторыми людьми, которые делают это сегодня.
Лично я люблю шоу. Я был заядлым слушателем предыдущего подкаста SitePoint (кто-нибудь помнит это?), И я думаю, что подкасты в целом — отличный способ идти в ногу со стремительно развивающейся и постоянно меняющейся отраслью. Тим и Дэвид уже разговаривали с рядом высоких гостей, одним из которых был Крис Койер. Они спросили Криса (который также написал для канала JavaScript ), какие технологии он будет использовать, если ему придется завтра создавать новый веб-сайт. Я нашел его ответ интересным (поскольку он дал мне пищу для размышлений), и именно на это я хотел бы взглянуть сегодня.
Позиция Криса заключается в том, что в основном «это зависит». Для небольшого (ish) веб-сайта он начинал с простого с HTML и CSS, посыпал jQuery для интерактивности и (при необходимости) использовал WordPress в качестве бэкэнда. Для приложения, которое требует большей интерактивности и состояния, он, вероятно, достигнет решения React и Redux. Другими словами, он пошел бы прямо к знакомым инструментам, которые делают его быстро продуктивным.
Теперь, живя на земле JavaScript, где каждые несколько дней появляются новые и причудливые рамки, я как бы наоборот. Всякий раз, когда я решаю новую проблему, я сразу же думаю: «Какую из этих двух дюжин фреймворков или библиотек, которые я хотел бы попробовать, лучше всего подходит для работы?» О технологии можно узнать очень много, прочитав об этом и реальной мировой практике неоценимо, когда сталкиваешься с чем-то новым.
Этот подход, безусловно, имеет свои недостатки. Например, вам нужно убедиться, что вы не ставите ферму на проект, который будет заброшен автором так же быстро, как и появился. И, конечно же, необходимо учитывать ограничения проекта (такие как время, рабочая сила и бюджет). Сколько человек будет работать над проектом и как долго вы будете его поддерживать, также являются важными соображениями. Тем не менее, этот подход работает для меня и дает ценную информацию о том, как разные проекты подходят к одной и той же проблеме.
Еще одна интересная точка зрения на обсуждение подкаста — это тема Тима Эвко. Тим предпочитает видеть, что он может сделать с «просто» ванильным JavaScript. Опять же, я думаю, это зависит от того, чего вы пытаетесь достичь, но я считаю, что большинство этих фреймворков и библиотек существуют для решения конкретной проблемы, и что вам нужно укусить эту проблему, прежде чем вы сможете цените то, что данная технология делает для вас. Для меня писать все на vanilla JS было бы слишком болезненно — первое, что я делаю при запуске нового проекта, это включаю jQuery (из общего принципа, если ничего больше).
Это не обесценивает важность понимания ванильного JavaScript. Если вы используете что-то вроде Angular, но не имеете понятия о языке, на котором оно написано, у вас будут плохие времена . Однако, как только вы освоите ванильный JavaScript, фреймворки и библиотеки станут вашими друзьями. Они, как правило, проходят боевые испытания и помогут вам еще до того, как вы об этом узнаете.
Но что вы думаете? Чего вы достигаете, когда начинаете новый проект? Используете ли вы проверенные и испытанные технологии, которые делают вас продуктивным? Вы катаетесь с ванильным JavaScript? Или ты идешь на последнее сияющее совершенство?
Дайте мне знать в комментариях ниже, и не забудьте проверить подкаст .