Подкаст SitePoint # 166: Разработка интерфейса с Мэйсоном Стюартом

Кевин: Точно. Определенно мы прошли дни делать это с нуля. Раньше это было своего рода, когда jQuery все еще находился в зачаточном состоянии. У вас был прототип и все эти другие вещи, но люди все еще как бы катали свои собственные наборы с нуля.

Мейсон: Конечно.

Кевин: Главным образом, чтобы иметь дело с совместимостью браузера. Но мы отошли от тех дней, и мы находимся в каком-то веке или десятилетии фреймворков и фреймворков Javascript в частности. Я бы определенно сказал и согласился с тобой, просто возьми и попробуй, потому что тебе нечего терять. Если вам не нравится это, попробуйте другой. Попробуйте шаблонизировать некоторые фреймворки, Подчеркните Усы, как вы можете выбрать подчеркивание, которое вам не нравится Подчеркните, правильно используйте Усы. Если вам не нравится Backbone, используйте ember.

Мейсон: Точно, да. Вы очень быстро узнаете, подходит ли он для вашей ситуации, или это просто мусор. Просто отбросьте это, особенно потому, что у нас такой модульный подход к веб-дизайну. Если вы создаете что-то с помощью rails, просто включите Gem, и если вам это не нравится, удалите gem, и если вы создаете что-то с Node, принесите его с помощью менеджера пакетов, если вам не нравится, избавьтесь от него. , Очевидно, я не сторонник легкомысленного добавления всего этого барахла в ваш проект. Вам не нужно все, вам не нужно использовать 60 различных шаблонных систем в вашем Javascript, но если вы чувствуете, что можете что-то получить или даже чему-то научиться, определенно попробуйте.

Кевин: Да. Я думаю, что это действительно хороший совет, когда вы говорите об экспериментах. Это своего рода экспериментальное телосложение или фасад о тебе, верно. Вы просто хотите выйти отсюда и поиграть с тестом и посмотреть, что получится.

Мейсон: Конечно.

Кевин: Это немного о каркасных работах, и я хотел бы, чтобы мы могли больше погрузиться в них, но они такие уникальные и такие разные. Это действительно сводится к их использованию. Вы действительно много намекали на такие вещи, как coffeescript Sass, и я знаю, что LESS — это еще один, и были некоторые люди, которые были против этого, и я не обязательно хочу делать что-то, что отнимает у них контроль чтобы использовать эти инструменты. В некотором контексте это правда, верно, потому что вы не всегда хотите использовать эти препроцессоры в некоторых случаях, особенно в небольших проектах, таких как плагин для jQuery. Вы не хотите интегрировать кучу фреймворков в плагин, который должен быть небольшим или, как скрипт, которым вы хотите просто поделиться. Откуда эти вещи вступают в игру и являются ли они хорошими или плохими, или это отчасти косвенно?

Мейсон: С Sass, Compass, SCSS я могу с уверенностью сказать, что со временем я смог написать только четыре строки CSS, и я действительно предпочел бы использовать препроцессор Sass для всего, что связано с таблицами стилей, потому что это в конечном итоге CSS. Это CSS просто с отсутствующим материалом. Некоторые вещи, которые действительно сделали бы, сделали наш CSS великолепным пять лет назад. На самом деле, на мой взгляд, до тех пор, пока у вас есть настройка, позволяющая выполнять эту предварительную обработку, независимо от того, выполняете ли вы предварительную обработку локально, а затем отправляете ее на сервер, поскольку она уже обработана в CSS или у вас ». В любом случае, делаю это на лету, я бы определенно сказал «да». Что касается coffeescript, я бы сказал, что порог немного больше. Если вы собираетесь написать 100 строк какого-нибудь действительно простого Javascript, возможно, не стоит беспокоиться о coffeescript. Coffeescript великолепен и отлично подходит даже для нескольких строк, но не усложняйте его. Как будто я перестраиваю свой сайт с закрытием и Noir в качестве фреймворка, и у меня будет только 30 строк Javascript на нем, а не на Closurescript, который является нормальным языком Javascript в этой среде, я наверное просто собираюсь делать обычный Javascript. Мне не нужно быть таким крутым, как Closurescript, я просто не нуждаюсь в такой маленькой ситуации. Итак, на самом деле все это сводится к тому, собираетесь ли вы использовать его и как будет выглядеть процесс разработки, если вы его не используете. Потому что нет ничего постыдного в использовании необработанного HTML или необработанного CSS и необработанного Javascript. В некоторых случаях это предпочтительнее.

Кевин: Большая проблема, о которой я действительно хотел бы поговорить с вами, это интеграция этих препроцессоров в такие вещи, как IE и, например, например, Fire bug, если вы используете Sass или LESS, вы не можете просто проверить им и говорят, что эта строка является кодом и получить это точно. Есть много инструментов, которые были построены вокруг статического плоского файла, и, кроме того, вы должны иметь возможность скомпилировать эти препроцессоры. Итак, вы должны быть в состоянии скомпилировать Sass, LESS скомпилировать Coffeescript, и для тех людей я хочу отметить, что существуют подобные приложения специально для Mac. Я не слишком знаком с аспектами Windows, но вы можете получить такие вещи, как набор кода или я думаю, что есть и другие. Так что не пугайтесь компиляции этого материала, очень просто найти приложение, загрузить его, оно стоит денег. Обычно там около 20 долларов, так что бойтесь этого. Но я хочу больше сосредоточиться на том, как прикладная сторона правой IDE не затрагивает подобные вещи, или вы знаете. Что вы думаете о том, что достаточно большой недостаток, чтобы не использовать эти вещи?

Мейсон: Нет. Честно говоря, я совсем не чувствую боли. Причина в том, что в Zarlee мы используем SCSS, и в режиме разработки я пишу несколько стилей для чего-то, а затем нажимаю «проверить элемент». Я вижу сгенерированный CSS, но если я нажму, в строке 500 файла main.css будет указано, что если я щелкну прямо там, то в комментариях прямо над этим блоком будет показано, откуда именно он пришел в Sass.

Кевин: Это круто.

Мейсон: Для меня это может звучать или даже вводить в заблуждение, но когда ты это видишь, это имеет смысл. Это в основном дает вам очень четкое место, куда можно вернуться. Многие люди действительно начинают смотреть на исходные карты сейчас. Исходные карты позволяют вам при проверке элементов видеть, где это действительно было в исходном предварительно обработанном coffeescript или SCSS или сценарии закрытия. По сути, все, что вы пытаетесь использовать, если вы посмотрите на доступность исходной карты, там могут быть действительно большие ресурсы. Но в конечном счете, я думаю, что это сводится к этому. Если я пишу что-то в coffeescript и получаю сообщение об ошибке в сгенерированном Javascript, это никогда не будет настолько отличным от того, что я написал изначально, и не смогу сказать, где это было. Coffeescript собирается добавить несколько дополнительных кусочков синтаксиса, возможно, он сделает немного магии, чтобы исправить проблемы с областями видимости, но в конечном итоге я все равно буду знать, где он находится. Если вы знакомы с вашим кодом, и вы пишете свой собственный код, а не просто копируете и вставляете несколько плагинов, это будет довольно очевидно, даже если скомпилированный исходный код сильно отличается от вашего предварительно скомпилированного исходного кода.

Кевин: Мне нравится, что этот разговор больше склоняется к Sass, потому что я использовал LESS в прошлом, и чем больше и больше я использую Sass, тем больше и больше я понимаю, почему он немного превосходит LESS. МЕНЬШЕ уместно, не поймите меня неправильно, но больше подходит для небольших проектов. Когда вы используете Sass, как будто вы встраиваете, на самом деле не становитесь классом, который просто пуст в вашей таблице стилей и тому подобное. Из-за этого случается много маленьких кусочков. Как будто вы говорили о компиляции и как комментарии, как и все эти вещи, если бы вы заявили о различиях между LESS и Sass, LESS легче написать и приятно начать с него, но в конце концов вы захотите перейти к Sass I думать.