Код Меркури – Telegram
Код Меркури
2.15K subscribers
3.45K photos
488 videos
2 files
3.6K links
Микромедиа об IT для айтишников-релокантов и удаленщиков по всему миру 🪐

Познакомиться поближе: https://mercdev.com
Download Telegram
Депрессия

В Electron очень трудно, а иногда невозможно создать функционал, который требует более глубокого погружения в нативный мир, в часть, максимально близкую к системе.

Так как мы имеем дело с Node.js, который не очень-то заточен под разработку близкую к системе, то в результате мы получаем недостаток нативных зависимостей, ограниченную поддержку и малое комьюнити в этом направлении.

Вы найдете много хвалебных статей, в которых обязательно будет упомянуто, что Electron полностью покрыл нужды приложения относительно нативной части, но по факту, люди всего лишь использовали API, предоставленный самим Electron (Tray, Menu, Notification). Как только дело доходит до функционала, которого нет в Electron, дела становятся на порядок хуже.
Разочарование

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

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

− Простота реверс-инженеринга делает поиск уязвимостей элементарным процессом, что выливается в ряд ключевых уязвимостей.

− Отсутствие возможности компиляции под мобильные платформы лишает разработчика свободы в выборе продакшн-пайплайна, что вынуждает работать команду над отдельным приложением в отдельной экосистеме, подготавливая индивидуальную инфраструктуру. А в случае, если команда не знакома с выбранным мобильным решением — вынуждает тратить лишнее время на подготовку и изучение.

− Отсутствие возможности максимально использовать ресурсы системы из-за особенностей JS делает Electron неповоротливым, монструозным здоровяком, который может не подойти для решения сложной задачи.
👍2
Вишенка на торте

Спустя 9 лет после релиза Electron, на горизонте появился новичок, который однозначно, требует внимания. Tauri — фреймворк, который буквально противопоставляется Electron во всех слабых сторонах последнего.

− В отличие от Electron, Tauri не поставляет движок отрисовки веб-контента, а использует предустановленный системой. Это позволяет сократить размер пакета с сотен мегабайт до всего лишь нескольких единиц.

Конечно же, это накладывает ряд определенных ограничений, но они несущественны относительно получаемой выгоды. Опять же, например, если ваша сфера опыта - это веб-разработка, то вы, наверняка, уже слышали про необходимость кросс-браузерных префиксов, различий в уровне поддержки браузерного API и необходимости учитывать различия в рендеринге.


− Вместо постоянной необходимости расширения интерфейса API бекенда, мы имеем дело со списком разрешенных нативных функций, который достаточно легко и быстро редактируется, а что главное, это не нужно делать абсолютно каждый раз, когда функционал вашего приложения меняется. Это устраняет разрозненность в приложении, возникшую из-за наличия прослойки в виде IPC. Всё наше приложение делится на две логические части: бэкенд на Rust и фронтенд на JavaScript. Нам достаточно вызвать Команду, описанную в Rust через шину. Это очень повышает скорость разработки.

− И наконец, чтобы начать разрабатывать приложение, достаточно одной команды: npm create tauri-app

Все эти сильные стороны делают Tauri мощным оппонентом и хорошей альтернативой Electron. Рекомендую, если и не мигрировать текущее приложение, то хотя бы попробовать использовать Tauri в следующем.
👍81
Старый друг НЕ лучше новых двух

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

Мне предстояло написать мобильное приложение. В тонкости нативной разработки, на тот момент мне погружаться не хотелось. Тем более за плечами у меня уже был кое-какой опыт в JS, поэтому выбор был очевиден — кросс-платформа. Сегодняшний день я целиком посвящу рассказу об этих библиотеках и своем опыте работы с ними.

Дисклеймер: всё написанное проходит через призму моих воспоминаний полученного опыта. Если ваш экспириенс с этими библиотеками разительно отличался, да и если вам просто есть, чем поделиться по теме, пишите всё, что думаете, в комментарии, обязательно всё обсудим.
👍5
Ionic Native (Cordova #1)

В то время состояние Ionic было слишком шатким. Множество изменений за короткий срок. Всё ломалось из-за отсутствия обратной совместимости, каждая новая мажорная версия предлагала новый подход к написанию приложения.

Комьюнити вокруг Ionic только начинало формироваться. То есть, чтобы получить помощь с установкой open-source плагина, нужно было реально постараться. К тому же, хорошие плагины зачастую не были open-source. Они тогда были на вес золота, да и продавались по баснословным ценам. Всё это делали Ionic очень непопулярным выбором для новичка.
Cordova (Cordova #2)

Cordova — нижний слой Ionic того времени. Всё, что нужно было, чтобы начать разрабатывать приложение — знание HTML, CSS и JS. Плагины имели 100% поддержку оболочки. Чем не сказка?

Производительность. Вы получаете довольно медленный, нагруженный дополнительным функционалом браузер, в котором довольно трудно отобразить серьёзный UI с большим количеством FPS. К тому же, Android смартфоны тогда не могли похвастаться ничем внушительным.
Tabris (Cordova #3)

Наверное, вряд ли вы что-то слышали про них. Но если это не так, моё уважение 🎩

Использовал их фреймворк в период его активной разработки (~2018 год). Он нравился мне своей простотой: UI было достаточно удобно и быстро писать, хорошая документация, быстрая поддержка, обратная совместимость со всеми не UI-плагинами от Cordova.

Историческая справка: JSX библиотека тогда не поддерживала (да и на тот момент опыта с React у меня ещё не было), приложение писал на голом JS.


Время шло, на некоторое время я переключился с мобильных приложений на написание бэкенда. Спустя немного времени мне пришлось опять подбирать новый инструмент — Tabris уже начинал умирать, и его функционала стало ощутимо не хватать.
👍2
Flutter (впервые, не Cordova)

Главным минусом 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 и не мучаться с нативным кодом…
👀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).
3
Что в сухом остатке?

Сейчас Expo — сбалансированная платформа с большим набором фич, инструментов, и главное, со своим развивающимся комьюнити.

Пайплайн разработки очень удобен, особенно, для новичка, как в Expo, так и в React Native. Подробная документация, большое количество примеров и отсутствие необходимости конфигурации и сборки на устройстве подарят разработчику приятный опыт, к которому не стремится подойти ни один конкурент.

За последние несколько релизов появились:
2
− Expo Router — новый удобный способ управления экранами (что-то похожее на Next App Router).
👍1
− Expo Updates. Не только плагин, но и целый сервис доставки OTA обновлений

− Expo Notifications. Унифицированный способ слать пуш-уведомления пользователю, не используя сторонний сервис (если не считать Expo Notifications, как SaaS).

Если вы ещё не знаете какую библиотеку для разработки кросс-платформенных решений выбрать, хотите перейти с голого React Native или хотите вернуться в Expo спустя время, сейчас — лучший момент для того, чтобы попробовать написать Hello World на Expo.

Начать своё путешествие в мир Expo можно тут.
4
Подведем итог.

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

До завтра!
🔥6
Вливайся!

Группа людей, объединенная одной идеей и философией, со схожими интересами, иногда, даже мечтами. Звучит, как утопия, не так ли? А что если я скажу, что знаю такое место? И даже покажу…
👀4
Почему сила местного комьюнити так важна?

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

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

Этот хакатон, как оказалось, был организован местным комьюнити. Так как мне всегда было интересно знакомиться и общаться с новыми людьми, я быстро оказался в тусе, вернее, пока только в чатике, но нужно же с чего-то начинать, не так ли? Путь в IT довольно уникален для каждого. Мой начался именно там.
👍32
В чатике мы делимся чем-то, что нас волнует в жизни в данный момент, рассказываем о новых покупках, да и просто, кидаем мемы с котами.

Конечно же, мы не забываем и о важном, об IT. Мы делимся текущими вакансиями, проходящими мероприятиями, помогаем решить проблему с пет- или рабочим проектом.
😁12
Пивной четверг

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

Даже, если вы главный завсегдатай чата, и все знают вас как vasya_pupkin1, то никогда не поздно превратить асинхронное общение в виртуальном пространстве в интересный вечер в кругу единомышленников. Обязательно приходите на ближайшую встречу интересующего вас комьюнити. Если вы новичок, вы сможете больше узнать о выбранном вами направлении, проникнуться вайбом окружающих, конечно же, просто поболтать с профессионалами. А если вы далеко не первый день на корабле, то вас ждет увлекательный вечер, полный холиваров, мемов и ТОП-10 самых вкусных печенек в офисе.

На фото, например, одни из моих любимых, орешки 🙂
3🔥2🤮1