На страже репозитория
Polymer: краткие команды для polymer-cli
Всем привет!
Для тех, кто пишет на фреймворке Polymer
В очередной раз набирая команду polymer analyze > analysis.json для генерации документации компонента я решил, что не располагаю таким большим запасом свободного времени, и было бы замечательно сократить её до нескольких букв. К тому же, писать polymer lint или polymer serve мне тоже казалось долгим. Не найдя подходящего решения, написал небольшой CLI - обёртку над командами polymer-cli. Конечно, есть же история команд и можно переключаться в одном терминале стрелочками вверх-вниз по списку команд, или использовать подсказки bash, но это всё равно дольше, чем ввести po doc или po s. Буду рад отзывам и доработкам.
Пост про современный фронтенд
Пикабушники народ странный. И методы у них странные. Но, что занимательно, эти методы работают. Не так давно я оставил безобидный комментарий про JS, и, по нелепому стечению обстоятельств, неожиданно попал под радары половины сайта и получил что-то около четырехсот подписчиков. Почему? А не знаю. Люди просто подписывались на меня, хотя я ничего им не обещал. Даже не давал намеков. Ты оставил комментарий про JS, я на тебя подписался и теперь ты мне торчишь целый пост про JS. Не знаю, как это работает, но раз вы это читаете, то их план исполняется.
Само собой, я понятия не имел о чем писать. Уроков и без меня хватает на любой вкус и цвет. И серьезных и несерьезных. Но потом я, все таки, задумался. Прям со всей силы. И как итог, додумался до этого поста. Очень надеюсь, что это единственное, что я напишу про JS, только чтобы вас, четырех сотен, не разочаровывать. Я не особо то горю желанием писать целые курсы, да и куда уж мне, скажем прямо
А рассказать я хочу о том, о чем сам бы очень хотел услышать в начале своего обучения, когда робко вступал на территорию бесконечной содомии и анархии под общим названием “Современный фронтэнд”. Некий экскурс, объясняющий общие понятия и положение дел, чтобы было проще разобраться в ситуации. Наверняка этому посту найдутся аналоги, и в свое время я просто плохо их искал. Однако, хуже от еще одного никому не станет, верно? Так что, будем посмотреть.
Я попробую рассказать все как можно проще, не залезая без необходимости в глубокие дебри и не пугая всякими сложными для понимания вещами. Потому что во многом, оно того стоит. Важная деталь состоит в том, что это просто экскурс по основным понятиям, я не буду пытаться обучать вас как пользоваться тем или иным инструментом, вам придется искать это самим. Я просто хочу раскидать все по полкам и только, потому что по себе знаю, что новички просто теряются от всего этого нагромождения.
Node.js
Разумеется, мы начнем именно с node.js, вокруг которого сейчас все и крутится. Если вы никогда с ним до этого не сталкивались, то наверняка задаетесь вопросом, на кой хер он вам вообще нужен и почему его тычут вам в лицо каждый раз, когда вы пытаетесь изучить какую-то современную фронтенд библиотеку или фрэймворк?
И я вас прекрасно в этом понимаю. Когда я пытался в это вникнуть, меня сбивал с толку этот node.js. Я очень хотел изучить какой-нибудь крутой и современный фреймворк по типу React, Angular или Vue. Но каждый раз, когда я пытался это сделать, диктор из видеоуроков упорно начинал с node.js, который я не понимал от слова совсем. Это сильно сбивало с толку, а все из-за одного единственного нюанса.
Почему то, по какой-то совершенно тупой причине, многие продолжают называть Node.js не иначе, как серверный JavaScript. Само собой, от такого определения я начал считать, что все современные технологии для фронтенда работают исключительно с серверами, написанными на JavaScript. Иначе почему Node.js преследует меня повсюду, хотя в сервера я пока лезть не хочу. Ну ладно, думаю я, раз везде нужен этот Node, то изучу Node. Но в каждом уроке по Node мне втирали какую-то совсем уж невразумительную дичь. Очень долго я мучался, пока не нашел то, что описало мне смысл в общих чертах.
И сейчас я постараюсь все расставить по своим местам.
Начнем с того, что JavaScript (только не упадите) — это скриптовый язык. Что это значит? Это значит, что программы для этого языка пишутся в обычном текстовом файле, отличающимся от обычного файла только другим расширением. И все, вот она ваша программа. Открываете блокнот, пишете там console.log(‘Hello World’) и сохраняете в формате .js. Вот и все, ваша программа готова. Вы восхитительны.
Появляется логичный вопрос, раз команды пишутся в обычный текстовый файл, то как нам его запустить? Как заставить эту программу работать? Ответ — скормить этот файл интерпретатору. Это такая программа, которая нужна для исполнения скриптовых файлов. Она их открывает и начинает выполнять строчка за строчкой. Не самый быстрый способ в сравнении с теми же компилируемыми языками, которые просто один раз перегоняются прямо в машинный код и потом запускаются на любом ведре схожим с тем, на котором они были написаны. Но зато, в отличии от них, скриптовый язык запустится на любом ведре, на котором запустится его интерпретатор. Кроссплатформенность!
Каждый скриптовый язык работает так. И Python, и PHP, и, прости господи, Perl. И у каждого свой интерпретатор.
Где же нам, тогда, взять интерпретатор для нашего JS? Ну, самое очевидное — использовать браузер, куда он, само собой, встроен по умолчанию. Браузеры, можно сказать, это естественная среда обитания JS. Вам придется постараться, чтобы найти в сети сайт, работающий без единой строчки этого, позвольте выразиться, кода (DarkWeb не считается!). А заодно, можете попробовать найти в современном мире хоть одно устройство, на котором этого самого браузера нет. Сейчас они везде. Буквально. А раз браузер — это интерпретатор, значит, ваша замечательная программа сработает на любом из этих устройств. Теоретически, само собой.
Но вот проблема, браузеры запускают JS скрипты внутри своей собственной среды, и не дают им никакого доступа во внешний мир. Ваша JS программа, в отличии от любой другой, может действовать только в рамках этого самого браузера, и не может управлять, к примеру, файлами, не может взаимодействовать с операционной системой, с устройствами подключенными компьютеру и так далее. Она изолирована. Для безопасности, само собой. Только представьте, какой был бы ад, если бы любой сайт имел полный доступ к вашему компьютеру. Но с другой стороны, какие безграничные были бы возможности!
А так, не покидает чувство, пардон, стерильности этого языка. И тут на сцену врывается NODE.JS! Платформа (читай как интерпретатор), которая позволяет вам запускать свой ненаглядный JS прямо из под операционной системы, а не из под браузера! Ваш любимый жаваслипт больше не хер собачий, нужный только для написания жалких сайтиков! Теперь, на нем можно писать настоящие взрослые программы! Можете теперь смело подойти к вашему знакомому Python программисту, который всю жизнь смотрел на вас как на говно, расстегнуть ширинку, и вывалить ему на стол ваш огромный мощный движок V8 (Не автомобильный, просто так интерпретатор назвали. Ну круто же! V8!)
И да, само собой, на Node.js можно написать и сервер, кто же вас остановит. Именно написать, потому что, опять таки, из-за того что node все называют серверным JavaScript, многие думают, что можно просто его скачать, установить, и сразу получится нечто вроде PHP в придачу со встроенным в него Nginx. А потом оказывается, что ничего такого там и в помине нет, и чтобы сервер заработал, надо его сначала написать. Доколе!
Но не будем о серверах. Мы уже поняли, что node не только про это. Но по прежнему непонятно, нахрена он нам нужен, ведь приложения для компа мы тоже писать, вроде как, не планировали. Пока.
А нужен он для удобства. На основе node.js мы будем создавать для себя собственную среду разработки. Мы, конечно, будем писать на JavaScript очень многое, ведь мы, все таки, фронтенд разработчики. Вот только этот код, пусть он и написан на JavaScript, исполняться на Node не будет, Node будет работать только с нашими файлами, ведь в отличии от браузерного JS он это умеет!
Более того, он не умеет многое из того, что умеет браузерный JS, так что большую часть кода, даже банальный и всеми любимый alert() вы там не запустите. И это логично. Как вы обратитесь, к примеру, к объекту window, который есть в браузере, если в node.js никакого window не существует?
Знаю, о чем вы думаете. Ты тут столько времени объяснял, что теперь наш JS может работать на компе, но теперь говоришь, что мы этот код даже запускать на Node не будем. Какого хера...
Сейчас все объясню подробнее.
Давайте вернемся в прошлое (для кого-то, впрочем, все еще настоящее, но это мы и пытаемся исправить). Раньше, разработка фронтэнда представляла собой подключение пары библиотек через обычный тег <script>, пару собственных скриптов и, конечно, CSS стили. HTML, CSS, JS. Все прекрасно и лаконично.
Но современный фронтенд намного сложнее. Парой библиотек уже не ограничишься. Приходится подключать их целыми десятками. Это уже само по себе вызывает массу проблем, ведь даже не смотря на то, что все они сжаты и оптимизированы по самая нимагу, их по прежнему много, вес страницы раздувается до неприличных размеров. Неужели нам каким-то образом придется выдергивать из каждой библиотеки только нужное, лишь бы хоть немного уменьшить вес? А ведь порой еще приходится следить за обновлениями этих библиотек, да еще и так, чтобы все остальное к херам не полетело.
И сам JavaScript, будь он неладен, не стоит на месте! Он обновляется, в него добавляют новые возможности, делают его удобнее а иногда даже исправляют в нем старые косяки. И ведь очень хочется писать на самой свежей и красивой версии, со всеми ее возможностями. Но, конечно же, эти современные версии не поддерживаются старыми браузерами. Как быть? Ну, либо писать на старых версиях, либо на новой, но потом перегонять ее в старую. С помощью онлайн утилит, вроде babeljs.io/repl. И так каждый раз. Не очень то удобно. Особенно если вы там накодили на целый вагон.
Да и кому, в общем то, нужен этот идиотский нелогичный JavaScript? Хочу писать на новом, модном, молодежном TypeScript! А вот потом, когда я напишу на нем свою роскошную программу, я перегоню ее уже в JS. А потом этот JS перегоню в JS старой версии, для больше поддержки. А потом то, что получилось, еще прогоню через оптимизатор, для экономии места. Не такая уж и длинная цепочка.
Но и этот HTML уже достал, честно говоря. Шаблонизатор хочу! Буду теперь клепать странички с околосветовой скоростью на pug, потом pug превращать в обычный HTML, и уже туда вставлять свой пережатый перетранслированный JS. Ну и сжимать в конце. Скорость загрузки - наше все! Нам дорог каждый килобайт.
Ах да, забыл, только лохи в 2К20 прописывают стили на лоховском CSS. Все уже давно пересели на Less, SCSS, SASS и тому подобное, с шикарными возможностями, невероятным удобством и мега скоростью! Но да, надо бы сжать да перегнать.
Благодаря всем этим технологиям мы оптимизировали скорость нашей разработки в разы! Да, мы потратили полдня чтобы все это в итоге привести обратно к HTML, CSS и JS, чтобы хоть какой-то браузер нас понял, но мы по прежнему восхитительны и современны!
Вот для чего вам нужен Node.js. Для автоматизации. Только представьте, что у вас есть огромный набор исходных файлов, все разбросанные по своим папочкам, с идеальной архитектурой, на каких угодно технологиях. Современный и большой проект! А потом вы ввели одну единственную команду в консоль и начала происходить настоящая магия! Все это дерьмо превратилось в обычную статику! На выходе вы получаете самые обычные HTML страницы, в каждую из которых подключен всего один общий файл со всеми вашими стилями, сжатый и переведенный в обычный CSS, да еще и с автоматическим добавлением всех этих надоедливых префиксеров и костылей для старых браузеров. И всего один единственный JS файл, в котором объединены все ваши скрипты и весь код из ваших библиотек. Причем, только нужный код! И да, само собой, все сжато и в самом поддерживаемом формате. По итогу, проект, который в исходном виде весил под сотню мегабайт, на выходе превратился в набор страничек общим весом в 5 килобайт! Это ли не чудо?
Я вам больше скажу, вы можете даже не утруждать себя вводом этой единственной команды каждый раз, после любого изменения в файлах! Запустите другую команду, всего единожды, и она запустит вам локальный сервер, куда забросит все ваши файлы в уже готовом виде, и будет обновлять их каждый раз, как только вы что-то поменяете в ваших исходных файлах! Даже открытая страница в браузере перезагрузится сама собой!
О, вам и этого мало? Тогда я подготовил вам напоследок самое сильное колдунство. Истинное мракобесие и самую темную сторону магии! Страница может даже не перезагружаться! Ее части просто будут заменяться динамично! Вы можете разместить на ней текстовую область, напечатать что-то в ней, потом вернуться в редактор и изменить атрибуты тега или внешний вид этой же самой текстовой области. У вас даже текст внутри нее не пропадет! Состояние вашего приложения сохранится неизменным, и это не дешевые фокусы, перезагрузки реально не происходит.
Но я обещал кое что объяснить. Node.js действительно не исполняет наших файлов. Он нужен нам для другого, для запуска всех этих программ и утилит, которые будут позволять нам вытворять такие финты с нашими исходными файлами, написанными на чем угодно и как угодно. И в итоге мы получим сразу готовый сайт для закидывания его на сервер. Или же удобный сервер для разработки прямо на локальной машине, который будет нам все удобно и оперативно обновлять.
Для того, чтобы установить себе node, вам надо тупо его скачать с официального сайта. Ничего сложного в его установке нет.
NPM
Итак, с Node.js мы разобрались. Он крут, офигеннен и V8. Вот только это просто платформа для запуска программ. Самих программ для этой магии еще попусту нет. И не самим же нам их писать! Мы установим готовые модули для Node.js.
Разумеется, это теперь будет осуществляться не так, как мы привыкли. Не надо лезть в интернет, искать библиотеки и скачивать их на комп вручную. Хотя, конечно, и так тоже можно. Кто же вас остановит. Но мы не психи.
После того, как вы установите node.js на свой компьютер, сразу вместе с ним установится програмка npm. Npm - это менеджер пакетов. Именно эта штука будет отвечать за загрузку нужных вам модулей и библиотек из общего репозитория. И не только за загрузку, но и за установку, обновление, удаление и так далее и до бесконечности. На то она и менеджер. И чтобы прикоснуться к ее чарующему миру, нам нужно просто напросто создать новую папку с названием вашего блистательного проекта. Желательное, конечно, называть латиницей, без всяких пробелов и спец знаков, иначе потом будете долго выть.
Тут начинается страшное. Для многих. Консоли! Но какими бы страшными они не казались, к ним придется привыкать, ибо работать через них придется много. Очень скоро вы поймете, что консоль - ваш друг. Ну и будете чувствовать себя мамкиным хакером.
К счастью, там ничего сложного. Разберетесь. Просто заходите через консоль в вашу созданную папку и инициализируете там проект npm. Инициализация будет представлять из себя создание в этой папке служебных файлов npm. И пока он их создает, он будет спрашивать вас кое-какие вещи, чтобы заполнить информацию об авторе. Можете пока все пропустить, это не суть как важно. Важно то, что в конце он создаст важный файлик - package.json.
В этом файле будет прописана информация о проекте, его название, его версия, все это вы можете менять как вам захочется. Информацию о вас, как об авторе проекта, информацию о лицензии проекта, если таковая имеется, а также список всех установленных вами библиотек и их версий. Список будет пополняться, когда вы что-то устанавливаете. А можно пополнять список самостоятельно а потом приказать npm свериться со списком и установить недостающее. Именно поэтому этот файл так важен, потому что вы можете просто перенести его куда угодно, инициализировать установку, и npm сам скачает все прописанные библиотеки, в нужных вам версиях.
Таким нехитрым образом, вам не обязательно повсюду таскать с собой огромную папку node_modules, куда устанавливаются все библиотеки. Они сами установятся, был бы package.json.
У npm есть альтернативы. Самый популярный из которых Yarn. По факту, то же самое, только лучше, быстрее, выше, сильнее. Можете установить его. Само собой, это уже отдельная программа, а не модуль для node. Ее вы просто ищите и скачиваете в интернете с официального сайта.
Также, стоит упомянуть и то, что при установке любой из библиотек в папке node_modules появится не одна единственная папка с нужной вам библиотекой. Все слегка сложнее, но не пугайтесь, вам об этом заморачиваться не придется. Устанавливаемая вами библиотека для своей работы может использовать другие библиотеки. А те — третьи. И так далее, до победного конца.
В этом и прелесть менеджеров, что он сам этим всем занимается, иначе это было бы попусту невозможно для человека. Например, в одном из своих проектов я использую 24 модуля. А в папке node_modules их уже 807. Такая вот арифметика. Кажется страшным, но на самом деле это здорово. Чтобы один и тот же код не повторялся в нескольких библиотеках, они используют какие-то общие библиотеки. В конечном счете, это позволяет значительно уменьшить повторяемость кода а значит и выходной вес объединенного файла. Просто помните, что каким-то мистическим образом из всех этих файлов будет выбрано только все самое нужное и сожмется в считанные килобайты.
Webpack
Самое время поговорить об этом самом мистическом образе. Webpack это как раз то, что и будет упаковывать все ваши файлики в конечный проект. Это уже модуль, который устанавливается через npm прямо в ваш проект.
Сразу предупрежу, что с его настройкой вам будет тяжко. А настраивать его придется. Из коробки он умеет работать только с JavaScript файлами, причем самыми обычными. Сейчас я объясню как именно он это делает.
Вы задаете ему точку входа. Это ваш главный js файл. Вы указываете где он хранится и что с этим файлом надо будет делать. Например, в классическом примере, он находится в папке src и называется index.js. Он его берет и помещает туда, куда вы ему пропишете в настройках. По умолчанию это папка dist, а сам файл будет называться, по умолчанию, bundle.js.
Но не будете же вы весь код хранить в index.js, так ведь? ТАК ВЕДЬ?
Поэтому этот файл и называется точкой входа. Вебпак заглядывает внутрь этого файла и обрабатывает его. И в случае, если вы делили код на несколько файлов (как и нужно делать если кода много), то вы подключаете эти файлы через функцию require (или import, в более новых версиях языка).
Как только он находит эту команду, то он переходит к указанному в ней файлу, и начинает обрабатывать его. Если тот файл тоже подключает какие-то дополнительные файлы, то он продолжает путь дальше. И таким образом, от точки входа он проходит по всему дереву вашего проекта, а на выходе выдает объединенный файл, или, как его принято называть, бандл. О нем мы уже говорили.
И тут есть одно очень важное отличие, которое может сбить с толку тех, кто раньше подключал библиотеки и скрипты только через теги script в HTML файле. Сейчас попробую на пальцах его объяснить.
Если вы в ваш HTML файл подключите два скрипта, то они, как бы, склеятся в единую программу. Как будто это один файл. И если в первом файле вы объявили какую-то переменную, а потом решили вывести его во втором, то это сработает.
Но в случае webpack, вы не просто склеиваете файлы в один. Вы именно импортируете что-то из одного файла в другой. Т.е файл подключился, отработал а на выход отдал то, что получилось. Как функция.
Все остальное в нем — закрыто. Если в вашей точке входа вы сделали импорт двух JS файлов один за другим, то надо помнить, что они независимые модули. Если в одном файле вы объявили переменную, а во втором файле вы попытаетесь ее вывести, то ничего не сработает. Второй файл ничего не знает о переменных, которые находятся в первом файле. И даже главный файл, в который вы импортировали оба этих файла, ничего об этой переменной не знает. Логика каждого отдельного файла инкапсулирована и недоступна для любых других. Это как кокон, у которого есть только вход и выход. Что то импортируется на вход и экспортируется через выход. Что там происходит внутри кокона — секрет)
Откровенно говоря, при попытке импортировать эти два файла в ваш index.js не произойдет вообще ничего. Они просто отработают и все. Разве что второй файл выведет ошибку, так как во время работы он попытается вывести переменную, которой для него не существует. А вот первый файл, по сути, вообще ничего не сделает. Да, он создал переменную. Которая так в нем и осталась.
Но нам не хочется, чтобы они просто работали. Нам хочется получить от этих файлов какие-то данные или какие-то функции, которые мы просто выделили в отдельный файл для удобства. Как же тогда использовать весь этот код и/или данные, если они инкапсулированы внутри файла и доступа к ним нет?
Собственно - экспортировать. Вы можете сделать один общий экспорт в конце файла, тогда у файла будет только один выход для данных. В случае с первым файлом, мы объявляем нашу переменную, и в конце ее экспортируем.
let importantNumber = 42
export default importantNumber
Вот и все, число 5 пошло на экспорт. Именно число, а не сама переменная. В нашем главном файле мы можем задать любую другую переменную для этого числа. Вы можете даже переменную не использовать, просто написать export default 42. И это сработает.
import bukvalnoLubayaPeremennaya from './fileOne.js'
console.log(bukvalnoLubayaPeremennaya) //42
Вот и все. Мы извлекли секретные данные из нашего первого файла. И на месте этих данных может быть все что угодно, функции, обычные переменные, сложные объекты. Можно экспортировать все разом, как сделали мы, используя слово default, а можно все экспортировать по отдельности.
Главное, что нужно уловить из всего этого, это то, что мы не импортируем файл. Мы импортируем что-то из файла.
Точно так же вы подключаете библиотеки и модули. Просто вместо адреса файла вы прописываете название плагина, а он уже автоматически найдется в node_modules. Вы подключаете библиотеку каждый раз заново в тех файлах, где она вам нужна. И не подключаете там, где не нужна. Некоторые библиотеки экспортируют все и сразу, некоторые могут экспортировать функционал по кускам.
const $ = require('jQuery');
Здесь мы назначили jQuery привычную переменную в виде доллара. Но можем любую другую. Как я уже сказал, require это почти то же самое, что и import. Об их различиях (кроме того что одна из них новая а другая - старая) почитаете как нибудь сами.
Ну вот, с JS мы более менее разобрались. Но только лишь с ним.
Вспомним опять import и require. Import более новая и удобная возможность, вот только она не будет работать. Почему? Потому что это возможности новой версии языка JavaScript (на самом деле ECMAScript, но не заморачивайтесь), и они не поддерживаются. Зачем мы тогда написали import, а не require? Вот тут то и начинается самое интересное. Мы будем перегонять написанный нами код из новой и удобной версии - в старую, но поддерживаемую. И рыбку съедим, и пик точеных избежим.
Для этого существуют специальные плагины для вебпака, называемые лоадерами (loaders). Мы прописываем специальные инструкции, согласно которым вызывается тот или иной лоадер. В данном случае, мы хотим, чтобы каждый раз, когда вебпак сталкивался бы с файлом формата .js, он запускал babel-loader. Этот лоадер, в свою очередь, автоматически запустит для файла плагин, который называется просто babel (Если вы помните, сайт для перегонки, который я скидывал, был babeljs.io/repl). Нам надо установить в наш проект и сам babel, и babel-loader который служит перемычкой между babael и webpack, а так же один из пресетов для babel, что то вроде настроек. Порой лоадеры не работают сами по себе.
И вуаля! Наши новомодные import и export прекрасно работают, потому что babel перевел их в старый формат за нас.
И вот это очень важный момент. Вы можете сказать вебпаку, что делать с теми или иными файлами. Просто скопировать их нетронутыми или изменить при помощи какого-нибудь из плагинов. Все эти плагины, конечно же, устанавливаются в ваш проект через npm.
Например, вы можете импортировать в ваши js файлы не только другие js файлы, но и какие только захотите! Хотите импортировать css? Пожалуйста. Так и пишите
import './style.css'
Но как? Да очень просто. Вебпак все так же продолжает гулять по файлам через эти импорты, и каждый раз смотрит на то, что и с каким файлом надо делать. Ага, попался js, значит, надо прогнать его через babel-loader. Ага, а теперь попался css, значит, надо прогнать его сначала через css-loader, а потом еще и через style-loader.
Да, лоадеров может быть несколько для одного и того же типа файлов. Выполняться они, в таком случае, будут поочередно (почему то начиная с последнего. Просто запомните этот факт чтобы меньше ломать голову при настройке)
Например, импортировали мы файл в формате SASS. На этом типе файла у нас в настройках висят сразу 3 лоадера. Первый это sass-loader. Он берет файл и превращает его из sass в обычный и привычный нам css. Потом уже идет css-loader, который добавляет поддержку такого импорта. В конце идет style-loader, он берет весь этот css и вставляет его в шапку нашей будущей страницы. Т.е объединяет все собранные стили и прописывает прямо в HTML.
Вместо style-loader можно использовать, к примеру, mini-css-extract-plugin. Он, в отличии от style-loader, не прописывает стили в шапку страницы, а собирает их в отдельный файл css и просто его подключает. Прямо как bundle.js.
И так вы можете делать для всех типов файлов. Картинки, шрифты, HTML - все что угодно. Главное для каждого прописать свои правила, что с этими файлами делать и куда их складывать.
Отдельного внимания заслуживает HTML, потому что, как правило, не HTML подключают в JS, а наоборот. Для этого есть html-webpack-plugin, он тоже прописывается в настройках вебпака и в нем явно указывается ссылка на HTML. Именно этот плагин скопирует эту HTML страницу куда надо, сделает с ней что надо, и, самое главное, сможет встроить ссылку на получившийся бандл прямо внутрь. Вам не придется прописывать ее самому.
Думаю, главную суть вы уловили. Несмотря на то, что вебпак изначально работает лишь с JS, мы можем с помощью плагинов настроить его под что угодно, прописывая правила отдельно для каждого файла. В начале это будет достаточно муторно и сложно, но с другой стороны, это нужно сделать всего один раз. И вуаля, он будет генерировать нам готовый и собранный проект.
Но что там с локальным сервером разработки? Это плагин webpack-dev-server, который, во многом, использует тот же самый файл с настройками вебпака. Только не создает готовый проект а разворачивает сервер для удобной разработки. Сам следит за обновлениями в файлах, сам обновляет страницу, и именно к нему можно подключить модуль замены содержимого без перезагрузки.
Возможностей у вебпака очень много. Всех их даже не перечислить. Он может даже проверять ваш код на соответствие каким-то стандартам, может проверять совместимость вашего css с поддержкой в браузерах, может даже сам генерировать вам иконки для сайта. Все зависит от того, что вы на него поставите и как настроите. Пусть он и плохо поддается обучению.
Фронтэнд и Бекэнд.
Если вы вдруг хотите начать писать и бенкенд на node.js, то у вас может что-то переклинить в голове, ведь теперь и там и там будет JS, как же его отличить друг от друга?
Ну, код сервера уже будет исполняться самим node.js, и настраивать его нужно так, чтобы он работал уже с готовыми файлами, которые подготовит вам вебпак. Вам придется отказаться от прелестей, которые даст вам webpack-dev-server, потому что заставить их работать синхронно - та еще задача. Но с другой стороны, представить себе ситуацию, где вам нужно прям одновременно работать и с фронтендом и с бенкэндом в одно и то же время — достаточно сложно.
Вы также можете настроить сервер таким образом, чтобы он перезапускался каждый раз, когда вы что-то меняете в его файлах.
Итог
Я надеюсь, что смог для кого-то прояснить общую картинку, что над чем идет и кто под кем работает. Я не уверен, что это кому-то будет нужно, потому что, само собой, сейчас я считаю себя единственным идиотом, кто в свое время не смог в этом разобраться. Но когда только только пытаешься в это вникать, то попусту теряешься от всех этих технологий.
Поисковый клиент Википедии
Всем привет!
В рамках изучения фреймворка Vue.js реализовал небольшой сервис поиска по Википедии.
Приложение представляет собой веб-клиент с визуальным веб-интерфейсом, позволяющий производить поиск по списку статей в Википедии в пространстве имён Википедии "Статьи" и поиск по имени файлов изображений. Реализована маршрутизация между вкладками с сохранением в URL параметров запроса и возможностью подгрузки данных после нативной браузерной перезагрузки страницы (воспроизведение состояния после перезагрузки).
В приложении реализована серверная часть на node.js, позволяющая запустить публичный http-сервер, принимающий запросы от веб-клиента, передающий их программному интерфейсу приложения (ПИП, API), который, в свою очередь, обращается к ПИП Википедии, обрабатывает полученные от Википедии данные, после чего http-сервер возвращает обработанный ответ веб-клиенту.
Однако есть ограничения. Несмотря на то, что ПИП Википедии довольно хорошо описан, не всегда есть возможность сформировать оптимальный запрос, что связано с особенностью архитектуры ПИП Википедии. Например, насколько известно, нет возможности (или я не нашёл способ) получить одновременно название статьи, краткое описание и ссылку на страницу, в связи с чем в текущей реализации для комбинации перечисленных данных на уровне промежуточного ПИП используются 3 вида запросов, что, конечно же, неоптимально.
В связи с этим количество сущностей запросов ограничено 10-ю, то есть, при поиске или показе случайных статей будет выведено не более 10 сущностей.
В реальности для получения основных данных по 10 статьям (название, описание, ссылка) будет сделан 21 запрос к ПИП Википедии:
- запрос случайных статей
- запрос на каждую статью отдельно на основе id
- запрос выдержки (extracts) из каждой статьи
Демо можно посмотреть тут: wikisearch.finecode.ru
В демо-версии есть ограничения на количество запросов с одного ip - не более 20-и запросов в час.
Проект может быть использован как учебный для изучения технологий Vue.js, Redux, Node.js.
Развитие, доработка, оптимизация и улучшения приветствуются.
Nodejs убунту
Добрый день. Установил ubuntu server, apache2, mongodb, nodejs. Собственно несколько вопросов общих. Как я понимаю приложения разрабатываются в Винде на веб шторме, а потом уже копируются на сервер? Для простых заданий (отработка post get запросов) нужно ставить express?
Ищу людей в команду для разработки и обмена опытом
Привет, у меня есть опыт по:
- Linux bash
- Администрирование сервера eNginx и Apache
- Разработка Back-End на PHP и Node.JS (планирую добавить Go, Ruby, Django)
- Front-End на ReactJS, Angular, Vue.JS и др.
- Знания JavaScript и библиотек
- Вёрстка Bootstrap, CSS Grid...
- Рисование графики и анимации в Adobe Illustrator
- Знания по безопасности
- Разработка приложений под Android
- Звуки для меню и саундтрек
- Продвижение в соц.сетях
Кого я ищу:
- Людей, с познаниями в одной из перечисленных тем
- Людей, заинтересованных в этих темах и готовых помочь в поиске информации
Что мы будем делать:
- Обмениваться опытом разработки
- Разрабатывать современные сайты и игры
Спасибо за внимание.
Что в Smart TV тебе моем? Или что можно запихнуть в телевизор?
Вместо предисловия
Добрый день, коллеги! Меня зовут Алексей и я занимаюсь телевизорами, а именно, разработкой Smart TV приложений («давайте похлопаем Алексею»).
Но что такое Smart TV? Какое оно, сферическое Smart TV приложение в вакууме?
Не буду томить вас ожиданием: в основном такого рода приложения предназначены для показа видео-контента. В любых вариациях. Записанное, живое вещание, телепередачи, фильмы, мультфильмы, рекламные ролики, и прочая, и прочая... Тысячи их!
Но разве Smart TV только для этого?
Да, безусловно, телевизор лучше всего показывает именно видео-контент, и с этим он хорошо справляется, но только ли для этого мы можем его использовать?
(Сейчас все счастливые владельцы приставок и HDMI-кабелей кинут в меня свои тухлые помидоры, скажут «Отписка!» и счастливые уйдут, а мы продолжим.)
Действительно, абсолютное большинство приложений, которые нам приходилось разрабатывать, в первую очередь предназначаются для показа видео, но были среди них и замечательные исключения. Кроме того, страдая известным заболеванием «Шило в месте чуть пониже спины», мне хотелось выжать из телевизоров нечто большее, чем все от них ожидают.
О моих (и не только) скромных потугах речь и пойдет ниже.
ТВ — Игра?
Действительно, первое, что приходит на ум — игра! Большой экран, возможность кроссдоменных запросов (так как Smart TV приложение, по сути, локальная HTML страница), и худо-бедно стандартное управление (пульт) позволяют нам реализовать игровой сценарий.
В большинстве своем это казуальные игры типа «1024», либо вариации на тему «Tower Defence». Негусто. К сожалению, накрутить супер 3D с шейдерами, тенями и динамическим освещением, получится разве что только на самых последних моделях... следующего года. Ибо в ТВ обычно размещена не самая совершенная версия браузера и, что хуже всего, она или обновляется крайне редко или не обновляется вовсе. Кроме того, разница между мощностью ТВ даже прошлогодними и текущими может быть кратной.
Поэтому, если вы хотите охватить максимальное количество моделей, готовьтесь к кровавой оптимизации всего и вся. Чистый, нативный Canvas станет вашим лучшим другом. Обертки над ним работают, но крайне прожорливо. Особенно удручает неудовлетворительная работа методов rotate и transform, поэтому анимацию планируйте спрайтовую и повороты спрайтов реализуйте только в самом крайнем случае.
Однажды мы делали игру на Ночь Карьеры. С ней удалось съездить к замечательным коллегам из Web Standarts Days и выступить с докладом.
Визуально игра представляет из себя игровое поле, вмещенное в размер экрана, не скролла, без преград. Задний фон разделен на несколько слоев, чтобы реализовать эффект 3d. На сцене генерируются летающие мишени (утки), по которым пользователь может стрелять.
Рис. 1. Общий вид приложения.
Главная задача состояла в том, чтобы дать возможность играть в игру кому угодно и как угодно, что сразу исключало взаимодействие с пультом. Пульт один, а игроков много. Управление реализовали с помощью телефона, а для максимального охвата мобильных устройств было решено реализовать клиент в виде адаптивного сайта. Реализовали мы его на WebSockets, и добавили фишку — управление через изменение положение телефона.
Тогда всплыло много интересных особенностей, некачественных датчиков ориентации и других глюков. Нам пришлось применить алгоритмы подавления шумов, иначе «прицел» игрока на экране телевизора страдал жутким тремором, Также выяснилось, что в игре «дует ветер»: в расчетах на телефонах накапливалась ошибка и прицелы постепенно «сдувало» в одну сторону, что вынуждало игроков постепенно поворачиваться. Некоторые играли, стоя спиной к ТВ.
Мораль: используйте датчики ориентации в браузерах телефонов как можно реже.
Рис. 2. Убийцы уток за работой
В приложении используется анимация посредством замены спрайтов. Такой способ оказался достаточно производительным. Мы тестировали приложение с сотней и более летающих уток. В реальности в игре их было всего 10. Проблемы с производительностью возникли, когда прибежала дизайнер с возопила: «Хочу, чтобы планета крутилась»!
Закрутить спрайт проблем не составило. Проблема случилась, когда мы запустили приложение на относительно старом ТВ. Оказалось, что поворот спрайта 900×900 пикселей он не вывозит чуть более, чем никак. В итоге, самый глазастый пользователь может заметить, что планета на заднем фоне разрезана на 9 частей, которые вращаются вокруг одного центра. Это решило проблему с производительностью.
Отсюда другая мораль: не вращайте большие спрайты.
Ещё одна фишка проекта заключалась в том, что игровая логика обсчитывается... на ТВ. В этом случае сервер выступает выступает просто в роли передатчика данных между клиентами и ТВ. Сделали мы это для того, чтобы даже в случае потери соединения, утки продолжали летать по экрану, и после восстановления Интернета не требовалось перезапускать приложение. Любопытный кейс, но все же, необязательный.
ТВ — Экран?
Казалось бы, это уже банально, но нет. Как обычно всё скрывается в деталях. Экран для чего? Какую функцию несёт? Для чего предназначен?
Приведу лишь несколько примеров.
Поздравлялка.
Однажды мы решили на день святого Валентина запилить онлайн поздравлялку в компании, и использовать имеющиеся телевизоры в качестве трансляторов поздравлений. Приложение было реализовано в минималистичном варианте с одним запросом к серверу, возвращающим список поздравлений. Главная проблема заключалась в неприятной особенности телевизоров уходить в спящий режим. Если Samsung разрешает отключать эту функцию с помощью метода setScreenSaver, то остальные платформы не особо позволяют это делать. Как вариант, можно запускать в фоновом режиме любое зацикленное видео — ТВ в режиме показа видео выключается намного реже. В итоге приложение свою функцию выполнило: во всех частях офиса на нескольких этажах онлайн транслировались поздравления сотрудников.
Карта.
Если быть совсем точным — карта боевых действий со списком лучших игроков.
Мы снова делали игру на Ночь Карьеры и в этот раз решили совместить телевизоры, телефоны и VR. Суть заключалась в том, что игрок в VR-шлеме летает на драконе и отстреливает принцесс, которыми управляют игроки с телефонов. Кто убил дракона — надевает шлем. И так по кругу. Скромно замечу, что со своей функцией (собрать максимальное количество народа у нашего стенда и удерживать их максимально долго) приложение справилось.
Более подробно о драконах, истребляющих принцесс, можно узнать тут.
Рис. 3. Общий вид стенда.
Приложение для ТВ обеспечивало демонстрацию общей сцены боя для всех желающих .
В этом проекте мы столкнулись с необходимостью оптимизации ранее стабильно и хорошо работающего кода. При увеличении количества игроков заметно ухудшались показатели производительности приложения. Выделили основные пути оптимизации:
— уменьшение объема передаваемой информации с сервера на клиенты и с клиентов на сервер;
— минимизация создания новых объектов в приложении.
Создание каждого нового экземпляра класса заметно глазу, поэтому все экземпляры должны быть созданы заранее и показываться пользователю по мере необходимости.
На ТВ слева — вид из VR-очков, на ТВ по центру — карта сцены.
Рис. 4. Игровой процесс. На ТВ слева - вид из VR-очков, на ТВ по центру - карта сцены.
Интерактивный задний фон.
Вы совершенно справедливо можете спросить: «Ты там вообще работаешь, не?!». На что я с искренним недосыпом на лице отвечу: «Конечно, работаю!». Но об этом чуть позже. А пока нам снова не сиделось и захотелось реализовать интерактивный задний фон для квадрокоптера.
Идея была в том, чтобы показывать в телевизоре саму усадьбу деда Мороза, которая бы реагировала на отлет/прилет квадрокоптера.
Основной интерес был в том, чтобы «растянуть» картинку на три телевизора. Разных производителей.
Сделали мы это путем разбиения всей сцены на «комнаты». Каждый телевизор показывал «комнату» со своим номером. Номера «комнат» можно было менять, таким образом, телевизоры, в принципе, могли показывать одинаковые части одной сцены, но мы показывали всю сцену последовательно. Команды на перемещение окружения сцен (зверушек, движение Луны и дым из труб) передавались с сервера по любимым WebSockets.
Поскольку мы знали время прилета/отлета квадрокоптера, появилась идея сделать «ветер» в телевизорах, который бы «сдувал» дым из труб при близкой работе винтов.
Опять-таки команда на взлет с квадрокоптера через сервер спускалась на клиенты.
И тут тоже у нас возникли сложности с производительностью. «Старый» webOS 2013 года крайне тяжело рендерил большую картинку (5760×1080). Пришлось специально для него нарезать задник в размер экрана и подставлять строго его.
Мораль: не пытайтесь рисовать картинки существенно большего размера, нежели экран телевизора. Он этого не переживет.
Тем не менее, все что относилось к Smart TV и бекенду, мы успешно реализовали.
ТВ — Охранник?
Однако самый интересный проект был совершенно неигровой, а что ни на есть, полезный.
Приложение занималось охраной дома. Да, именно телевизор. Да, именно охранял.
Суть приложения в том, что имеющаяся камера снимает всё, что перед ней происходит, и в случае резкого изменения картинки производит действия на выбор:
— громко орёт;
— посылает пользователю СМС;
— пишет письмо с приложенными фотками инцидента;
— пишет сообщение в FB тоже с фотками;
— делает всё это сразу или в любых вариациях.
Сам ТВ в этот момент усиленно прикидывается валенком и вообще не работающим. В приложении были обработаны случаи выключения ТВ от сети Интернет или просто от питания. Приложение поддерживало мультиязычность.
Установило его себе несколько десятков тысяч человек.
Но и тут было не всё просто.
При подключении камеры и попытке получения в браузере стрима с неё, как известно, вываливается системный попап с подтверждением действия. Особенность в том, что ТВ блокируют все всплывающие окна. Поэтому приложение наше было реализовано только на платформе Samsung с использованием либо встроенной в ТВ камеры, либо специальной камеры, поставляемой тем же самсунгом.
Ещё одним минусом стала, опять же, производительность ТВ. На относительно старых телевизорах (2013 года) можно было м-е-е-е-е-е-е-дленно прокрасться мимо камеры и телевизор бы «прохлопал» этот момент.
Но в целом идея просто блестящая.
Вывод
Телевизоры уже давно переросли свою основную функцию — показывать картинку с канала, показывать видосики или быть вторым монитором.
Их возможности и производительность постоянно растут, а круг применения ограничен только вашей фантазией. Любые задачи можно решить при должной проработке идеи и соответствующей реализации. Дерзайте и достигайте успеха!
Всем телеки!
З.Ы. Может быть у тебя, читатель, были необычные задачи для Smart TV, когда ТВ приходилось использовать в несвойственной для него роли? Поделись! Расскажи!