jQuery *

Введение

В предыдущей статье мы рассмотрели с Вами вопрос интеграции фреймворка «Webix» в «Electron» и создание на основе этих фреймворков простого GUI приложения. Цель данной статьи является дальнейшую развитие вопроса интеграции в GUI интерфейс, построенный с помощью «Electron» и «Webix» других «JavaScript» фреймворков. Все элементы GUI реализованные в «Webix» характеризуются параметром «view». В зависимости от значения этого параметра будет отображаться тот или иной GUI элемент. Количество типов элементов «view», которые позволяет создавать «Webix» перекрывают порядка 90% задач при реализации интерфейса. Оставшиеся 10% это как раз тот случай, когда необходимо осуществить интеграцию либо ранее написанного кода либо фреймворка (библиотеки), которые в явном виде не поддерживаются в «Webix». Для осуществления интеграции со сторонними фреймворками(библиотеки) создадим вместе с Вами свой «view» элемент «Webix».

Постановка задачи

Создать GUI приложение «Electron+Webix», которое будет строить график функции вида «y=a*sin(b)+c» с возможностью изменения параметров функции «a, b и c» с динамической перерисовкой графика.

Всем привет.

Это отчёт в продолжение статьи "Уйти от jQuery к Svelte, без боли".

Ниже я расскажу о трудностях с которыми столкнулся, их было не много, и только одна была настолько фундаментальной, где без поддержки сообщества я бы не справился.

Введение

Я планировал переписывать фронтэнд по кусочкам, это не то что бы совсем не получилось, получилось не совсем — переписывать пришлось большими кусками.

Во первых потому что подход jQuery — императивный, подход Svelte — декларативный.

Во вторых потому, что с использованием jQuery у нас область видимости всегда глобальная, из любой строчки кода нам доступны все элементы веб-страницы, мы к ним обращаемся по ID или CSS селектору, в то время как Svelte рекомендует использование компонентов и внутри компонента мы видим только сам компонент, ни внешних элементов ни внутренних у нас нет, и мы не имеем возможности обратиться к ним напрямую.

Со Svelte получается настоящее ООП: мы не можем внести изменения сами, мы можем только сообщить компоненту о необходимости изменений. Как эти изменения будут сделаны, знает только код внутри компонента.

И это прекрасно :)

Фото — Maria Teneva, площадка Unsplash

Иногда React, Angular, Vue.js и т. д. — это лишнее

Правда ли, что JavaScript-фреймворков слишком много и выбор становится чересчур сложным? Или, может, мы просто забыли о соображениях производительности и о том, что за лишний трафик в итоге должны платить пользователи?

Вернемся в эпоху jQuery

Помните, было время, когда JQuery использовали для всего! JQuery то, jQuery сё — повсюду легкий аромат jQuery. На любом веб-сайте и в каждом веб-приложении — jQuery.

В чем причина популярности этой библиотеки?

Простой JavaScript казался слишком сложным в применении. К тому, же между браузерами было много отличий.

Но пришло спасение — библиотека jQuery избавила сообщество JavaScript от этой головной боли. Правда, большинство из нас в результате стали лениться, поскольку перестали понимать, что происходит «под капотом».

Я прозрел, когда появился этот сайт.

Чтобы по-настоящему понять колесо, нужно его самостоятельно переизобрести.

На днях я провел собеседование на должность senior javascript разработчика. Мой коллега, который также принимал участие в собеседовании, попросил кандидата написать функцию, которая будет выполнять HTTP-запрос, и повторять его несколько раз в случае сбоя.

Поскольку он писал это на доске, псевдокода было бы достаточно. Если бы он продемонстрировал хорошее понимание вопроса, мы были бы остались довольны. Но, к сожалению, он не смог найти хорошего решения.

Подумав что он нервничает, мы решили сделать задание немного проще и попросили его преобразовать функцию на основе обратного вызова в функцию на основе Promise.

Не повезло.

Я могу сказать, что он видел подобный код раньше. Он более или менее знал, как это работает. Псевдокода, демонстрирующего, что он понимает эту концепцию, было бы достаточно.

Но код, который он написал на доске, не имел никакого смысла. У него было только смутное понимание концепции Promise в JavaScript, и он не смог рассказать про него доходчиво.

Это может быть простительно, если вы начинающий разработчик, но если вы претендуете на руководящую должность, этого недостаточно. Как он отладит сложную цепочку Promise и затем объяснит другим, что он сделал?

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

Содержание статьи:

• Предисловие
• Про phpQuery
• Начало работы
• Практическая часть
• Заключение

jQuery — это самая популярная в мире JavaScript-библиотека. Сообщество веб-разработчиков создало её в конце 2000-х, что привело к возникновению богатой экосистемы сайтов, плагинов и фреймворков, использующих под капотом jQuery.

Но в последние годы её статус главного инструмента для веб-разработки пошатнулся. Давайте посмотрим, почему jQuery стала популярной и почему она вышла из моды, а также в каких случаях её пока ещё целесообразно использовать для создания современных сайтов.

Современная фронтенд-разработка оставляет полярные впечатления: одни её любят, другие презирают.

Я большая поклонница современной веб-разработки, хотя она мне напоминает некую «магию», со своими плюсами и минусами:

• Когда вы поймёте, как использовать волшебные инструменты (babel! бандлеры! вотчеры! и так далее!), ваш рабочий процесс становится быстрым, мощным и восхитительным
  
• Если вы не понимаете волшебные инструменты, всё ужасно запутанно
  
• …и попытки освоить магию слишком часто неудачны, если вам кто-нибудь не поможет продраться через джунгли жаргона, преувеличений и устаревшей информации в интернете

Многие, когда речь заходит о jQuery, говорят так: «Просто пользуйтесь обычным JavaScript. Библиотека jQuery вам не нужна». Что тут сказать? Я не нуждаюсь во многих вещах, но, несмотря на это, хорошо, когда они есть. Так и jQuery. Я в этой библиотеке не нуждаюсь, но её, определённо, приятно иметь под рукой.

Сайты наподобие You might not need jQuery (YMNJQ) продвигают идею, в соответствии с которой от jQuery очень легко избавиться. Но самый первый пример на этом сайте демонстрирует вескую причину jQuery использовать. Там строка простого кода на jQuery заменяется на 10 строк обычного JS!

Представляем вам перевод статьи Aditya Modi, опубликованной на blog.bitsrc.io. Статья посвящена использованию библиотеки jQuery в приложениях на Angular.

Библиотека JQuery была создана в 2006 году для восполнения недостающей функциональности Javascript. С тех пор последний достаточно продвинулся в своем развитии, чтобы разработчики могли обходиться без JQuery, основная проблема которой — производительность.

Сегодня Mislav Marohnić объявил о том, что разработчики Github избавились от jQuery на фронтенде GitHub.com. Казалось бы, в самом этом факте нет ничего примечательного, если бы не один интересный момент.

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

• querySelectorAll (который предположительно был вдохновлен когда-то именно jQuery),
• fetch для работы с AJAX,
• delegated-events для обработки событий,
• полифиллы для работы с DOM,
• пользовательские элементы (Custom Elements), которые сейчас на подъеме.

Помимо Custom Elements, ничего другого из Web Components было решено не использовать. Разработчики присматривались к Shadow DOM и были бы не против прибегнуть к нему — однако, в силу того, что на полифиллах скорость поиска в DOM оставляет желать лучшего, им пришлось пока отложить эту затею.

Зачем разработчикам в принципе потребовалось все это сделать? По их словам, для того, чтобы «отдавать» посетителям меньше килобайт, иметь возможность использовать более явно выраженный синтаксис для выполнения манипуляций с DOM, а также ради возможности использовать библиотеку Flow.JS для статического анализа типов. По словам разработчиков, процесс ухода с jQuery занял годы.

Автор статьи, перевод которой мы публикуем сегодня, полагает, что в мире существует ещё много программистов, которые, когда им нужно разработать простое веб-приложение, обращаются к jQuery. Обычно это случается тогда, когда некую страницу нужно оснастить простыми интерактивными возможностями, но использование для этого какого-нибудь JavaScript-фреймворка кажется явным перебором. Ведь это — килобайты ненужного кода, шаблоны, инструменты для сборки проектов, средства для упаковки модулей… При этом подключить к странице jQuery, воспользовавшись CDN-ресурсом, проще простого.



В этом материале речь пойдёт о том, как перевести проект, созданный с использованием jQuery, на Vue.js. Этот проект будет создан на jQuery, а потом переработан с применением Vue. Автор материала хочет продемонстрировать всем желающим то, что использование Vue, даже в сравнительно небольших проектах, не обязательно означает чрезмерное увеличение размера кода таких проектов и большую дополнительную нагрузку на программиста. Это, наоборот, при практически тех же размерах вспомогательного кода, что и при использовании jQuery, позволяет повысить производительность труда и улучшить качество приложений.

Как известно, сегодня все больше и больше разработчиков предпочитают грузить js-библиотеки из CDN Google (например, jQuery). Более того, это даже считается хорошим тоном — в более чем 50% случаев тот же jQuery находится в кэше браузера пользователя благодаря посещению других сайтов, использующих тот же CDN. И все бы хорошо — к вашему серверу меньше обращений, у пользователя сайт грузится быстрее… Видимых недостатков нет.

А что если вы работаете на глобальном рынке? Использованием googleapis вы сразу отсекаете огромную часть пользователей из Китая!

Большой китайский фаервол блокирует не только поисковик от Google, но и все его сервисы, в числе которых и CDN. Таким образом, в Китае Ваш сайт становится либо недоступен (если Вы подключаете jQuery до body), либо работает не совсем так, как вы ожидаете (если jQuery подключается в конце кода). То же самое касается шрифтов от Google, графиков от Google, reCaptcha от Google и всего остального «от Google».

Вывод: Если Вам интересны пользователи из Китая — следует пересмотреть свое мнение на предмет загрузки библиотек или шрифтов с гугловских CDN.

Забьем еще один гвоздь в крышку гроба Роскомнадзора.

Напрямую получить доступ сообщениям своего канала для вывода их в веб страницу нельзя. Но можно написать bot, который будет поступающие к нему сообщения отправлять куда нужно, чтобы их обработать и вывести на сайт. А можно воспользоваться готовым.

Странно, что на Хабре еще не упоминался этот замечательный бот — Journalist (@JournalistBot). На сайте указано, что beta, но работает более чем стабильно.

Всем привет,

Приглашаем на первый открытый Front-end MeetUp 28 марта, организованный внутренним сообществом разработчиков Райффайзенбанка.

Фреймворк Bootstrap — это свободный набор инструментов для создания интерфейсов сайтов и веб-приложений. Его возможности ориентированы исключительно на фронтенд-разработку. Bootstrap — проект весьма популярный, о чём, например, говорит то, что он занимает (по состоянию на начало марта 2018-го года) второе место по количеству звёзд на GitHub.

Если вы хотите освоить Bootstrap, в частности, его самую свежую, четвёртую версию, значит, этот материал подготовлен специально для вас. Здесь, на небольшом сквозном примере, который реально освоить за полчаса, будут продемонстрированы основы Bootstrap, разобравшись с которыми вы вполне сможете сделать что-то своё, использовав этот фреймворк.

В Первой части мы подготовили нашу страницу.

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

Имитация базы, как мне уже писали в комментариях, это json файлы с содержанием нужного текста. Вопрос: "Зачем тут Vue? Если это можно написать и на скриптах?". Если честно — для красоты html верстки. Ну и изучения новых технологий.

Передо мной встала задача по обновлению текущего сайта одной компании, и в соответствии тренду выбор пал на landing page с поддержкой мультиязычности.

Посмотрев на реализации представленные в интернете я ужаснулась. В теле страницы куча текста! С такой разметкой же невозможно работать. А если надо поменять информацию? Это надо лезть в html, искать нужное, и менять в нескольких местах. Короче ужас! И я подумала что хорошо бы использовать базу данных, но это же обычная страница, и разворачивать ради нее целый сервер? и базу? как то перебор! Работая с Angular2 я подумала что было бы классно с его помощью создать страницу, но он очень тяжелый, и не подходит… И тут я вспомнила о его аналоге Vue.js. Легкая библиотека, для создания приложений. Я подумала: "А почему бы не создать сайт с помощью vue и добавить имитацию базы?".

Обдумав все за и против, посмотрев на другие подходы, мне захотелось внести немного "красоты" в html верстку.

Для объяснения подхода я решила сделать небольшую страничку, потому что выкладывание полного кода существующей страницы считаю слишком "тяжелым".

Но пришлось все равно разбивать статью на 2ве части, тут описывается только подготовка небольшой страницы и добавление меню для смены языка.

Недавно мне довелось выполнить один маленький и интересный заказ Его суть заключалась в том, чтобы по нажатию кнопки с удалённого сервера БД скопировать БД (её приблизительный размер составляет почти 800Mb) на тестовый сервер и после выполнить ряд изменений в структурах таблиц.

Казалось бы, что нет ничего проще берём выполняем на удалённом сервере запрос вида:

mysqldump -uLogin -pPassword db_name > db_name.sql

и забрать потом файл, но в моём случае это оказался сервер БД без возможности выкачать оттуда файл, поэтому мне пришлось изловчиться и написать свой механизм экспорта из этой удалённой БД средствами YII2, с которым я был на тот момент не так сильно знаком.

Привет, Хабр! Представляю вашему вниманию перевод статьи Vue.js Tutorial: From jQuery to Vue.js автора Paul Redmond.

Что касается библиотек JavaScript, то никогда не было более популярной библиотеки, чем jQuery. Она создавалась для обхода DOM элементов с использованием CSS селекторов в то время, когда совместимость браузеров была важной проблемой для разработчиков.

Фактически jQuery настолько универсален, что я подумал что он отлично передаст то, почему я люблю писать UI с Vue, используя компонентный JavaScript. В этом руководстве мы сначала рассмотрим создание пользовательского интерфейса с jQuery, а затем перепишем его с помощью Vue.