Боль
Начать проект, если ты новичок в платформе и ещё не освоился в экосистеме, очень трудно. Почему-то Electron выбрал путь комьюнити вместо консолидированного решения.
Во что это выливается? Кривая обучения превращается из прямого, однозначного и понятного пути во множество извилистых дорожек. Так как у нас нет шаблона, предоставленного нам Electron, первое, что мы будем вынуждены сделать — отнюдь не начать разработку приложения. Нам придется потратить часы на сравнение и изучение существующих комьюнити шаблонов, систем сборок и дистрибуции.
После того, как мы, наконец, определимся с выбором шаблона-заготовки, нам нужно будет потратить еще несколько часов в пустую, чтобы понять, зачем же нам нужны три входные точки, какого их предназначение и как же это все-таки связано с безопасностью.
Невероятно, но вот, всего лишь спустя день мы начали разрабатывать приложение. Но не переживайте — так продлится недолго. Как только нам понадобиться установить нашу первую нативную зависимость, тут-то мы и столкнемся с нашей первой проблемой. Потому что в 90% случаев установка проходит исключительно с помощью танцев с бубнами 🥁
Скорее-всего вам придется установить еще кучу инструментов, о которых не было сказано ранее. И приведет это к положительному результату только в том случае, если библиотека поддерживает Electron (неподдерживаемое ABI, проблемы на стороне сборщика и т.д.), в ином случае, нас ждет лишь сообщение об ошибке и горесть о потраченном времени.
Начать проект, если ты новичок в платформе и ещё не освоился в экосистеме, очень трудно. Почему-то Electron выбрал путь комьюнити вместо консолидированного решения.
Во что это выливается? Кривая обучения превращается из прямого, однозначного и понятного пути во множество извилистых дорожек. Так как у нас нет шаблона, предоставленного нам Electron, первое, что мы будем вынуждены сделать — отнюдь не начать разработку приложения. Нам придется потратить часы на сравнение и изучение существующих комьюнити шаблонов, систем сборок и дистрибуции.
О, дивный старый мир библиотек!
После того, как мы, наконец, определимся с выбором шаблона-заготовки, нам нужно будет потратить еще несколько часов в пустую, чтобы понять, зачем же нам нужны три входные точки, какого их предназначение и как же это все-таки связано с безопасностью.
Невероятно, но вот, всего лишь спустя день мы начали разрабатывать приложение. Но не переживайте — так продлится недолго. Как только нам понадобиться установить нашу первую нативную зависимость, тут-то мы и столкнемся с нашей первой проблемой. Потому что в 90% случаев установка проходит исключительно с помощью танцев с бубнами 🥁
Скорее-всего вам придется установить еще кучу инструментов, о которых не было сказано ранее. И приведет это к положительному результату только в том случае, если библиотека поддерживает Electron (неподдерживаемое ABI, проблемы на стороне сборщика и т.д.), в ином случае, нас ждет лишь сообщение об ошибке и горесть о потраченном времени.
👍2😭1
IPC и тайна философского камня
Все вызовы к бэкенду изолированы. Electron собственными руками убивает своё главное превосходство «одно приложение — одна платформа — один язык». Подаваясь нам в обертке моноязыкового решения, нас несознательно вводят в заблуждение. Шаткая надежда на работу в единой кодбазе разбивается о скалы изолированности. Каждый раз, добавляя новую функцию в бэкенд, вам придется расширять интерфейс IPC. Также само разделение между фронтендом и бэкендом довольно неосязаемое. Постоянно приходится следить: «а не занёс ли я бэкенд во фронтенд?».
Все вызовы к бэкенду изолированы. Electron собственными руками убивает своё главное превосходство «одно приложение — одна платформа — один язык». Подаваясь нам в обертке моноязыкового решения, нас несознательно вводят в заблуждение. Шаткая надежда на работу в единой кодбазе разбивается о скалы изолированности. Каждый раз, добавляя новую функцию в бэкенд, вам придется расширять интерфейс IPC. Также само разделение между фронтендом и бэкендом довольно неосязаемое. Постоянно приходится следить: «а не занёс ли я бэкенд во фронтенд?».
Депрессия
В Electron очень трудно, а иногда невозможно создать функционал, который требует более глубокого погружения в нативный мир, в часть, максимально близкую к системе.
Так как мы имеем дело с Node.js, который не очень-то заточен под разработку близкую к системе, то в результате мы получаем недостаток нативных зависимостей, ограниченную поддержку и малое комьюнити в этом направлении.
Вы найдете много хвалебных статей, в которых обязательно будет упомянуто, что Electron полностью покрыл нужды приложения относительно нативной части, но по факту, люди всего лишь использовали API, предоставленный самим Electron (Tray, Menu, Notification). Как только дело доходит до функционала, которого нет в Electron, дела становятся на порядок хуже.
В Electron очень трудно, а иногда невозможно создать функционал, который требует более глубокого погружения в нативный мир, в часть, максимально близкую к системе.
Так как мы имеем дело с Node.js, который не очень-то заточен под разработку близкую к системе, то в результате мы получаем недостаток нативных зависимостей, ограниченную поддержку и малое комьюнити в этом направлении.
Вы найдете много хвалебных статей, в которых обязательно будет упомянуто, что Electron полностью покрыл нужды приложения относительно нативной части, но по факту, люди всего лишь использовали API, предоставленный самим Electron (Tray, Menu, Notification). Как только дело доходит до функционала, которого нет в Electron, дела становятся на порядок хуже.
Разочарование
Electron, несомненно, всё ещё одна из самых используемых технологий в мире десктопной кроссплатформы. Но насколько Electron был прорывным инструментом своих лет, настолько же сильно он редуцировал на фоне новых, более современных решений. Зная, что Electron имеет больше слабых сторон, чем сильных, я бы с опаской смотрел на него в качестве ключевой библиотеки для реализации настольного приложения.
− Большой размер бандла даже для самого крохотного приложения выливается в удорожание инфраструктуры для его распространения.
− Простота реверс-инженеринга делает поиск уязвимостей элементарным процессом, что выливается в ряд ключевых уязвимостей.
− Отсутствие возможности компиляции под мобильные платформы лишает разработчика свободы в выборе продакшн-пайплайна, что вынуждает работать команду над отдельным приложением в отдельной экосистеме, подготавливая индивидуальную инфраструктуру. А в случае, если команда не знакома с выбранным мобильным решением — вынуждает тратить лишнее время на подготовку и изучение.
− Отсутствие возможности максимально использовать ресурсы системы из-за особенностей JS делает Electron неповоротливым, монструозным здоровяком, который может не подойти для решения сложной задачи.
Electron, несомненно, всё ещё одна из самых используемых технологий в мире десктопной кроссплатформы. Но насколько Electron был прорывным инструментом своих лет, настолько же сильно он редуцировал на фоне новых, более современных решений. Зная, что Electron имеет больше слабых сторон, чем сильных, я бы с опаской смотрел на него в качестве ключевой библиотеки для реализации настольного приложения.
− Большой размер бандла даже для самого крохотного приложения выливается в удорожание инфраструктуры для его распространения.
− Простота реверс-инженеринга делает поиск уязвимостей элементарным процессом, что выливается в ряд ключевых уязвимостей.
− Отсутствие возможности компиляции под мобильные платформы лишает разработчика свободы в выборе продакшн-пайплайна, что вынуждает работать команду над отдельным приложением в отдельной экосистеме, подготавливая индивидуальную инфраструктуру. А в случае, если команда не знакома с выбранным мобильным решением — вынуждает тратить лишнее время на подготовку и изучение.
− Отсутствие возможности максимально использовать ресурсы системы из-за особенностей JS делает Electron неповоротливым, монструозным здоровяком, который может не подойти для решения сложной задачи.
👍2
Вишенка на торте
Спустя 9 лет после релиза Electron, на горизонте появился новичок, который однозначно, требует внимания. Tauri — фреймворк, который буквально противопоставляется Electron во всех слабых сторонах последнего.
− В отличие от Electron, Tauri не поставляет движок отрисовки веб-контента, а использует предустановленный системой. Это позволяет сократить размер пакета с сотен мегабайт до всего лишь нескольких единиц.
− Вместо постоянной необходимости расширения интерфейса API бекенда, мы имеем дело со списком разрешенных нативных функций, который достаточно легко и быстро редактируется, а что главное, это не нужно делать абсолютно каждый раз, когда функционал вашего приложения меняется. Это устраняет разрозненность в приложении, возникшую из-за наличия прослойки в виде IPC. Всё наше приложение делится на две логические части: бэкенд на Rust и фронтенд на JavaScript. Нам достаточно вызвать Команду, описанную в Rust через шину. Это очень повышает скорость разработки.
− И наконец, чтобы начать разрабатывать приложение, достаточно одной команды:
Все эти сильные стороны делают Tauri мощным оппонентом и хорошей альтернативой Electron. Рекомендую, если и не мигрировать текущее приложение, то хотя бы попробовать использовать Tauri в следующем.
Спустя 9 лет после релиза Electron, на горизонте появился новичок, который однозначно, требует внимания. Tauri — фреймворк, который буквально противопоставляется Electron во всех слабых сторонах последнего.
− В отличие от Electron, Tauri не поставляет движок отрисовки веб-контента, а использует предустановленный системой. Это позволяет сократить размер пакета с сотен мегабайт до всего лишь нескольких единиц.
Конечно же, это накладывает ряд определенных ограничений, но они несущественны относительно получаемой выгоды. Опять же, например, если ваша сфера опыта - это веб-разработка, то вы, наверняка, уже слышали про необходимость кросс-браузерных префиксов, различий в уровне поддержки браузерного API и необходимости учитывать различия в рендеринге.
− Вместо постоянной необходимости расширения интерфейса API бекенда, мы имеем дело со списком разрешенных нативных функций, который достаточно легко и быстро редактируется, а что главное, это не нужно делать абсолютно каждый раз, когда функционал вашего приложения меняется. Это устраняет разрозненность в приложении, возникшую из-за наличия прослойки в виде IPC. Всё наше приложение делится на две логические части: бэкенд на Rust и фронтенд на JavaScript. Нам достаточно вызвать Команду, описанную в Rust через шину. Это очень повышает скорость разработки.
− И наконец, чтобы начать разрабатывать приложение, достаточно одной команды:
npm create tauri-appВсе эти сильные стороны делают Tauri мощным оппонентом и хорошей альтернативой Electron. Рекомендую, если и не мигрировать текущее приложение, то хотя бы попробовать использовать Tauri в следующем.
👍8❤1
Старый друг НЕ лучше новых двух
В стародавние времена, когда динозавры ходили по земле, а React приложения писали только на классовых компонентах, я начал свой путь, связанный с фронтенд-разработкой.
Мне предстояло написать мобильное приложение. В тонкости нативной разработки, на тот момент мне погружаться не хотелось. Тем более за плечами у меня уже был кое-какой опыт в JS, поэтому выбор был очевиден — кросс-платформа. Сегодняшний день я целиком посвящу рассказу об этих библиотеках и своем опыте работы с ними.
В стародавние времена, когда динозавры ходили по земле, а React приложения писали только на классовых компонентах, я начал свой путь, связанный с фронтенд-разработкой.
Мне предстояло написать мобильное приложение. В тонкости нативной разработки, на тот момент мне погружаться не хотелось. Тем более за плечами у меня уже был кое-какой опыт в JS, поэтому выбор был очевиден — кросс-платформа. Сегодняшний день я целиком посвящу рассказу об этих библиотеках и своем опыте работы с ними.
Дисклеймер: всё написанное проходит через призму моих воспоминаний полученного опыта. Если ваш экспириенс с этими библиотеками разительно отличался, да и если вам просто есть, чем поделиться по теме, пишите всё, что думаете, в комментарии, обязательно всё обсудим.
👍5
Ionic Native (Cordova #1)
В то время состояние Ionic было слишком шатким. Множество изменений за короткий срок. Всё ломалось из-за отсутствия обратной совместимости, каждая новая мажорная версия предлагала новый подход к написанию приложения.
Комьюнити вокруг Ionic только начинало формироваться. То есть, чтобы получить помощь с установкой open-source плагина, нужно было реально постараться. К тому же, хорошие плагины зачастую не были open-source. Они тогда были на вес золота, да и продавались по баснословным ценам. Всё это делали Ionic очень непопулярным выбором для новичка.
В то время состояние Ionic было слишком шатким. Множество изменений за короткий срок. Всё ломалось из-за отсутствия обратной совместимости, каждая новая мажорная версия предлагала новый подход к написанию приложения.
Комьюнити вокруг Ionic только начинало формироваться. То есть, чтобы получить помощь с установкой open-source плагина, нужно было реально постараться. К тому же, хорошие плагины зачастую не были open-source. Они тогда были на вес золота, да и продавались по баснословным ценам. Всё это делали Ionic очень непопулярным выбором для новичка.
Cordova (Cordova #2)
Cordova — нижний слой Ionic того времени. Всё, что нужно было, чтобы начать разрабатывать приложение — знание HTML, CSS и JS. Плагины имели 100% поддержку оболочки. Чем не сказка?
Производительность. Вы получаете довольно медленный, нагруженный дополнительным функционалом браузер, в котором довольно трудно отобразить серьёзный UI с большим количеством FPS. К тому же, Android смартфоны тогда не могли похвастаться ничем внушительным.
Cordova — нижний слой Ionic того времени. Всё, что нужно было, чтобы начать разрабатывать приложение — знание HTML, CSS и JS. Плагины имели 100% поддержку оболочки. Чем не сказка?
Производительность. Вы получаете довольно медленный, нагруженный дополнительным функционалом браузер, в котором довольно трудно отобразить серьёзный UI с большим количеством FPS. К тому же, Android смартфоны тогда не могли похвастаться ничем внушительным.
Tabris (Cordova #3)
Наверное, вряд ли вы что-то слышали про них. Но если это не так, моё уважение 🎩
Использовал их фреймворк в период его активной разработки (~2018 год). Он нравился мне своей простотой: UI было достаточно удобно и быстро писать, хорошая документация, быстрая поддержка, обратная совместимость со всеми не UI-плагинами от Cordova.
Время шло, на некоторое время я переключился с мобильных приложений на написание бэкенда. Спустя немного времени мне пришлось опять подбирать новый инструмент — Tabris уже начинал умирать, и его функционала стало ощутимо не хватать.
Наверное, вряд ли вы что-то слышали про них. Но если это не так, моё уважение 🎩
Использовал их фреймворк в период его активной разработки (~2018 год). Он нравился мне своей простотой: UI было достаточно удобно и быстро писать, хорошая документация, быстрая поддержка, обратная совместимость со всеми не UI-плагинами от Cordova.
Историческая справка: JSX библиотека тогда не поддерживала (да и на тот момент опыта с React у меня ещё не было), приложение писал на голом JS.
Время шло, на некоторое время я переключился с мобильных приложений на написание бэкенда. Спустя немного времени мне пришлось опять подбирать новый инструмент — Tabris уже начинал умирать, и его функционала стало ощутимо не хватать.
👍2
Flutter (впервые, не Cordova)
Главным минусом Flutter был его язык — Dart. Каждую секунду приходилось знакомиться не только с новыми подходами и правилами самого Flutter, но ещё и языка. Самым неудобным, для меня показался концепт разделения на Stateless и Stateful.
Последним гвоздем в крышку гроба стал метод установки плагинов. После Tabris, в котором была функция автоматической установки плагинов с нативным кодом (схоже auto-linking в React Native), копаться в горе Java и Swift кода мне не хотелось.
Главным минусом Flutter был его язык — Dart. Каждую секунду приходилось знакомиться не только с новыми подходами и правилами самого Flutter, но ещё и языка. Самым неудобным, для меня показался концепт разделения на Stateless и Stateful.
Последним гвоздем в крышку гроба стал метод установки плагинов. После Tabris, в котором была функция автоматической установки плагинов с нативным кодом (схоже auto-linking в React Native), копаться в горе Java и Swift кода мне не хотелось.
👀3💩1
React Native
На тот момент, у меня уже появился опыт в React и попробовать React Native казалось чем-то самим собой разумеющимся. О Hermes и auto-linking тогда ещё никто и слыхать не слыхивал, поэтому разговор с React Native у меня был короткий.
Но возможность писать на знакомом мне React, понравилась. И очень хотелось, чтобы когда-нибудь появился тот самый принц на белом коне, благодаря которому, можно было бы писать на React и не мучаться с нативным кодом…
На тот момент, у меня уже появился опыт в React и попробовать React Native казалось чем-то самим собой разумеющимся. О Hermes и auto-linking тогда ещё никто и слыхать не слыхивал, поэтому разговор с React Native у меня был короткий.
Но возможность писать на знакомом мне React, понравилась. И очень хотелось, чтобы когда-нибудь появился тот самый принц на белом коне, благодаря которому, можно было бы писать на React и не мучаться с нативным кодом…
👀3
Наши дни. Expo
История Expo многострадальная. С момента его зарождения, Expo, почему-то, невзлюбили. Очень много плагинов по причинам несовместимости (а точнее, незаинтересованности их разработчиков поддерживать Expo) нельзя было установить, новые фичи из React Native очень долго переносились в релизы, да и общая удовлетворённость продуктом в комьюнити была на удивление низкая.
Но время шло, паровоз Expo шел на полном ходу. За малое количество времени технологию ждало очень много перемен. Из гадкого утенка, на мой взгляд, Expo превратился во флагман для React Native.
Благодаря появлению auto-linking из React Native в Expo множество плагинов стали обратно совместимы. Сторонние разработчики тоже не стояли на месте и предоставляли плагин для установки нативного кода специально для Expo, отражая это в README.
Команда Expo совместно с коммьюнити, в свою очередь, делала очень много высококлассных плагинов. Множество эксклюзивных для Expo плагинов начали использовать в React Native из expo-* благодаря unimodules (в последствие, установка через expo-cli).
История Expo многострадальная. С момента его зарождения, Expo, почему-то, невзлюбили. Очень много плагинов по причинам несовместимости (а точнее, незаинтересованности их разработчиков поддерживать Expo) нельзя было установить, новые фичи из React Native очень долго переносились в релизы, да и общая удовлетворённость продуктом в комьюнити была на удивление низкая.
Но время шло, паровоз Expo шел на полном ходу. За малое количество времени технологию ждало очень много перемен. Из гадкого утенка, на мой взгляд, Expo превратился во флагман для React Native.
Благодаря появлению auto-linking из React Native в Expo множество плагинов стали обратно совместимы. Сторонние разработчики тоже не стояли на месте и предоставляли плагин для установки нативного кода специально для Expo, отражая это в README.
Команда Expo совместно с коммьюнити, в свою очередь, делала очень много высококлассных плагинов. Множество эксклюзивных для Expo плагинов начали использовать в React Native из expo-* благодаря unimodules (в последствие, установка через expo-cli).
❤3
Что в сухом остатке?
Сейчас Expo — сбалансированная платформа с большим набором фич, инструментов, и главное, со своим развивающимся комьюнити.
Пайплайн разработки очень удобен, особенно, для новичка, как в Expo, так и в React Native. Подробная документация, большое количество примеров и отсутствие необходимости конфигурации и сборки на устройстве подарят разработчику приятный опыт, к которому не стремится подойти ни один конкурент.
За последние несколько релизов появились:
Сейчас Expo — сбалансированная платформа с большим набором фич, инструментов, и главное, со своим развивающимся комьюнити.
Пайплайн разработки очень удобен, особенно, для новичка, как в Expo, так и в React Native. Подробная документация, большое количество примеров и отсутствие необходимости конфигурации и сборки на устройстве подарят разработчику приятный опыт, к которому не стремится подойти ни один конкурент.
За последние несколько релизов появились:
❤2
− Expo Updates. Не только плагин, но и целый сервис доставки OTA обновлений
− Expo Notifications. Унифицированный способ слать пуш-уведомления пользователю, не используя сторонний сервис (если не считать Expo Notifications, как SaaS).
Если вы ещё не знаете какую библиотеку для разработки кросс-платформенных решений выбрать, хотите перейти с голого React Native или хотите вернуться в Expo спустя время, сейчас — лучший момент для того, чтобы попробовать написать Hello World на Expo.
Начать своё путешествие в мир Expo можно тут.
− Expo Notifications. Унифицированный способ слать пуш-уведомления пользователю, не используя сторонний сервис (если не считать Expo Notifications, как SaaS).
Если вы ещё не знаете какую библиотеку для разработки кросс-платформенных решений выбрать, хотите перейти с голого React Native или хотите вернуться в Expo спустя время, сейчас — лучший момент для того, чтобы попробовать написать Hello World на Expo.
Начать своё путешествие в мир Expo можно тут.
❤4
Подведем итог.
Сегодняшние посты, в первую очередь о том, что библиотека и язык — всего лишь инструмент в руках разработчика. Не бойтесь экспериментировать и искать 🙌
До завтра!
Сегодняшние посты, в первую очередь о том, что библиотека и язык — всего лишь инструмент в руках разработчика. Не бойтесь экспериментировать и искать 🙌
До завтра!
🔥6
Вливайся!
Группа людей, объединенная одной идеей и философией, со схожими интересами, иногда, даже мечтами. Звучит, как утопия, не так ли? А что если я скажу, что знаю такое место? И даже покажу…
Группа людей, объединенная одной идеей и философией, со схожими интересами, иногда, даже мечтами. Звучит, как утопия, не так ли? А что если я скажу, что знаю такое место? И даже покажу…
👀4
Почему сила местного комьюнити так важна?
Ещё до всех событий, что сначала, разделили нас на «домашних» и «офисных», а после разбросали по всем континентам, программисты очень часто собирались, чтобы устроить офлайн-движ. Почему-то именно этой социальной группе очень важно постоянно участвовать в разных активностях.
О существовании местного комьюнити я узнал случайно, придя на свой первый хакатон. Было очень весело, я познакомился с интересными людьми, профессионалами в своих областях, мы весело провели время. Хоть дух соперничества не покидал площадку, мы не стеснялись помогать друг другу советом и поддерживали морально.
Этот хакатон, как оказалось, был организован местным комьюнити. Так как мне всегда было интересно знакомиться и общаться с новыми людьми, я быстро оказался в тусе, вернее, пока только в чатике, но нужно же с чего-то начинать, не так ли? Путь в IT довольно уникален для каждого. Мой начался именно там.
Ещё до всех событий, что сначала, разделили нас на «домашних» и «офисных», а после разбросали по всем континентам, программисты очень часто собирались, чтобы устроить офлайн-движ. Почему-то именно этой социальной группе очень важно постоянно участвовать в разных активностях.
О существовании местного комьюнити я узнал случайно, придя на свой первый хакатон. Было очень весело, я познакомился с интересными людьми, профессионалами в своих областях, мы весело провели время. Хоть дух соперничества не покидал площадку, мы не стеснялись помогать друг другу советом и поддерживали морально.
Этот хакатон, как оказалось, был организован местным комьюнити. Так как мне всегда было интересно знакомиться и общаться с новыми людьми, я быстро оказался в тусе, вернее, пока только в чатике, но нужно же с чего-то начинать, не так ли? Путь в IT довольно уникален для каждого. Мой начался именно там.
👍3❤2