Комментарии 49
♥️
Код для клиентов (iOS, Android, Web) лучше бы по отдельным репозиториям разложили
Планируете расширять кол-во ЯП, на которые будет приходить ответ?
Серьезно? Простите, что не читал статью полностью... Это из-за того, что меня приследует дежавю в том, что рендерить html и вешать скриптовый язык для оживления тоже-самой по идее...
Наше первое решение — добавить в ленту карточку на основе WebView для показа кастомизированных сообщений. Но, потратив где-то полгода на разбор странных крешей WebView, мы решили искать другой путь.
Спустя 5 лет:
Наше первое решение — добавить в ленту карточку на основе DivKit для показа кастомизированных сообщений. Но, потратив где-то полгода на разбор странных крешей DivKit, мы решили искать другой путь.
Не думаю, что переизобретение HTML/CSS/JS что-то принципиально решает. Ну кроме "Это сделано не нами"...
Пока, на старте - да, наверное, удобно. Тем более что сами и разработали решение. А что будет потом? Внешние библиотеки, вопросы безопасности, вопросы доверия к серверу, появление своей песочницы, тормоза, глюки и т.д... И получаем еще один WebView со всеми его заморочками...
Технологии всегда сменяют одни другие. Сейчас DivKit лучше, чем HTML подходит для наших задач, что будет дальше - посмотрим.
Как минимум
еще один WebView
- легче дебажить так как присутствует типизация в отличии от html + js
- нативный код упрощает работу с api системы
- это быстрее работает
Так что технология точно имеет право на жизнь по моему мнению.
Право на жизнь имеет, не спорю. Но это достаточно нишевое решение. А если дальше развивать - то получим все тот же веб со, всеми его нюансами/заморочками.
Легче дебажить? Не уверен - для HTML/CSS/JS инструментов больше и они будут более развитыми. Про типизацию - аналогично, TypeScript появился достаточно давно (хотя он далек от идеального решения - в первую очередь своей переусложненной экосистемой).
Нативный код - чем отличается про проброса нативных методов в тот же WebView? Не говоря уже про "безопасность" вызова нативного кода с удаленного сервера.
Быстрее работает - да, самый главный аргумент. Но опять же - а если верстать как в начале 2000х было принято? С минимумом CSS/JS и прочих "плюшек"? Тоже будет медленно? А если какой упрощенный WebView сделать, заточенный под скорость, упростив поддерживаемые стандарты?
А если какой упрощенный WebView сделать, заточенный под скорость, упростив поддерживаемые стандарты?
То получите свой собственный веб-вью, который сложнее дебажить чем обычный, писать на нем не каждый захочет и поддерживать и развивать его не каждый сможет
И возвращаемся к тому от чего хотели уйти...
А что будет потом? Внешние библиотеки, вопросы безопасности, вопросы доверия к серверу, появление своей песочницы, тормоза, глюки и т.д… И получаем еще один WebView со всеми его заморочками...
Концептуально да, но вопросы же как всегда в практической плоскости. Если нужен server driven ui - Яндекс в таком подходе не одинок. Альфа-Банк рассказывает на мобиусе о своих "много-шагах", что по сути тоже самое, что сабж.
Мне кажется, что это решения для бизнеса по месту требования, которые и не станут полноценной заменой webview, но и от его косяков избавляют
Очень похожую идею реализует jasonette. Рассматривали ли вы эту технологию и чем она вам не подошла?
Как там дела с БЭМ?
а потом заметили что для отрисовки списков элементов нужно одни и теже стили навешивать на каждый элемент, json получается громоздким, долго передавать по сети. и придумали вешать стили на классы...
или gzip сжатия достаточно?
Не, для этого придумали шаблоны (aka templates), в песочнице можно увидеть пример https://divkit.tech/ru/playground
Именно так, спасибо :)
Всё это уже было в симпсонах:
$myTutorialCard $yaContainer
items /$yaDiv
<= Head $yaText
text <= title \
style *
font *
size 21
weight \bold
margin *
bottom 16
<= Body $yaText
text <= body \
style *
font * size 16
margin * bottom 16
<= Links $yaContainer
items <= links /$myLink
style *
margin * bottom 6
orientation \vertical
paddings *
top 10
bottom 0
left 30
right 3
$myLink $yaText
action * url <= link \
style *
font * size 14
margin * bottom 2
text * color \#0000ff
underline \single
$mySampleCard $yaCard
states *
default <= Default $yaContainer
items /$yaDiv
<= Logo $yaImage
image_url \https://yastatic.net/s3/home/divkit/logo.png
style * margin *
top 10
right 60
bottom 10
left 6
<= Main $myTutorialCard,
title \DivKit
body \What is DivKit and why did I get here?\n\nDivKit is a new Yandex open source framework that helps speed up mobile development.\n\niOS, Android, Web — update the interface of any applications directly from the server, without publishing updates.\n\nFor 5 years we have been using Devkit in the Yandex search app, Alice, Edadeal, Market, and now we are sharing it with you.\n\nThe source code is published on GitHub under the Apache 2.0 license.",
links /$myLink
<= Landing $myLink
text \More about DivKit
link \https://divkit.tech/
<= Docs $myLink
text \Documentation
link \https://divkit.tech/doc/
log \docs
<= TgNews $myLink
text \News channel
link \https://t.me/divkit_news
<= TgEnChat $myLink
text \EN Community chat
link \https://t.me/divkit_community_en
<= TgRuChat $myLink
text \RU Community chat
link \https://t.me/divkit_community_ru
При этом строчек в 2 раза меньше, меньше визуального шума, синтаксическая гарантия уникальности имён, статическая типизация.
а как вы навешиваете события на эту верстку?
2. Я так понял, это очередной WebView под капотом, а не мапинг json'а на нативные контролы?
Это был в своё время такой Wicket для веб-приложений на Java, что-то похожее по концепции.
Когда-то был такой фреймворк, назывался ExtJS. Он и сейчас условно есть, но условно. Там тоже программировали по сути джейсонами, только задача была рендерить во всем зоопарке браузеров, включая мобильные, включая режим когда юи мимикрировал под нативный, в том числе если это сайт и под разные ОС. В том числе со сборщиком в приложение, а также в десктопное, до появления электрона и прочего. Ну И прикольно было иметь флексы ещё на IE6 ещё до того как их изобрели в CSS. И всё как раз такими конфигами. Проблемы копирования свойств и прочего не было из-за возможности конфигов итемов, наследуемых свойств и прочего, ну а если очень хотелось, то можно было и стили дописать, с автогенерацией неймспейсов для защиты от коллизий и уменьшения бойлерплейта. К последним версиям шли бонусом MVC, MVVM, модели, домены эвентов, самопильные промисы, коннекторы к апи, полифилы на любой чих и просто миллиард утилит и возможностей - от высокоуровневых компонентов-панелей, до возможности играться напрямую в теги, с оптимизациями привязки ссылок в памяти на элементы и ещё целый сундук фич на любого эстета. Ну и главное - уже рабочий набор компонентов, от кнопок до мультифункциональных гридов с экспортами, графиками прям в ячейках и сводными данными. И ты просто мог сесть и делать юи, не долбаться, не писать свой очередной юи-кит, не смотреть и плакать на тот минимум что дают всякие материал юи, даже на бутстрап и подобное - там был смешной минимум, а тут у тебя звездолёт и ты его архитектор со световым мечом - где надо просто взял и сделал юи, где захотелось поиграть в джедая - держи низкоуровневые функции и вперёд властвовать над всеми.
Классный был фреймворк, был его ярым фанатом. А потом он умер. Потому что нельзя продвигать нормально то что стоит 5к баксов в год за право писать, а свободную версию прятали и ограничивали, в какой-то момент чтобы скачать надо было через гугл искать ссылку и потом ещё по почте получать персональную ссылку. В итоге развитие замедлилось и сейчас оно по факту мертво, полностью растеряв былое величие и отстав от современности в плане инструментов и версий самого языка, эдак года с 2014. А ведь этот дедушка умел больше чем некоторое сейчас, значительно больше, безапелляционно больше, титан своего времени.
Использовал его вплоть до версии 3.4, фреймворк действительно был отличный. И тогда он стоил намного меньше 5к. Хотя, в целом, довольно тяжеловат.
В свое время купили версию 3.4 за пару тысяч (баксов), до сих пор используем. Был забавный случай, когда вечно меняющиеся перекупщики этой библиотеки звонили нашим клиентам и выпытывали инфу как используется система с дальнейшими разного рода наездами. В остальном идеальная библиотека. Что касается подхода Яндекса в статье - то он как раз очень хорошо работает в ExtJS уже лет 10 (?).
Я занимался его кастомизацией - это была та ещё боль. Захардкоженные в огромных методах куски HTML В каждом - сложная, усеянная костылями, логика. Тем не менее, при разработке $mol один момент я позаимствовал как раз из ExtJS - кастомизация любого поля при инстанцировании. Только в реактивной среде со статической типизацией это безопасно, а вот в ExtJS можно было легко что-нибудь поломать и сутки потом дебажить.
Сейчас у них на кнопке Buy уже опять появилась community edition (правда как раньше, ссылка через почту). Ну и цены начинаются "всего" с $1.3к
Прошелся по документации, периодически вылетает 404 Page not found. Будут ли какие-то плагины для Figma, Wordpress и прочего ? Без готового шаблонизатора, и большой библиотеки компонентов кажется игра не стоит свеч...
Sorry за саморекламу, но у меня есть концепция по развитию этой идеи :)
Суть в том, чтобы отказаться от JSON вообще, а передавать на устройство прямо код, который оно будет исполнять (в моем случае -- это JS, передаваемый в браузер через вебсокет). Код может не просто отрисовывать элементы, но и определять новые функции, так что можно просто передать клиенту функцию для отрисовки сложного элемента (включая всю внутреннюю логику его работы и всякие анимации/переходы), а потом просто вызывать ее. Или пусть он сам ее вызывает по событию. У меня это реализовано на Common Lisp (извините :), который компилируется в JS, но можно и для других языков это сделать.
Очень похоже на HTML с подключением JavaScript из отдельных источников. Возвращение к истокам :)
примерно. Но этот JS можно обновлять в любой момент, он может учитывать параметры устройства клиента, его историю, локальные данные, что угодно. Фактически, я вообще вернулся к самым истокам истоков -- я могу написать функцию, которая будет получать размеры экрана и рисовать все элементы на нужных местах, как в олдскульных библиотеках интерфейсов)
Удачи с производительностью на мобилах. Весь цирк ради них затеян.
производительность, кстати, нормальная. Когда в первый раз подгружается весь код, может немного подфризить, но не критично. Зато потом этот код вызывается и отрабатывает мгновенно. При этом не обязательно передавать весь контент каждый раз, можно вызывать функцию с параметром для перерисовки виджета, можно вообще сделать ее автономной, чтобы она сама подгружала что нужно через асинхронные вызовы.
звучит не оч безопасно)
Так вот почему в едадиле тормознутый интерфейс)
Есть какие-нибудь инсайты, на сколько backend driven ui повысил скорость разработки? с учетом того, что компания тратит время на разработку и поддержку DivKit?
Яндекс выпускает DivKit — фреймворк для server-driven UI с открытым кодом