Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
Да про каждый фреймворк пишут: «У нас Virtual DOM! У нас ленивые вычисления! У нас обновление только изменившегося! У нас всё супергипер эффективно!». А бенчмарков никаких не приводят. А я вот приведу:
Не умаляю остальных его достоинств, но производительность — не его конёк.
Не умаляю остальных его достоинств, но производительность — не его конёк.
Лео сейчас переписывает реализацию виртуального дома, там будут использоваться почти все оптимизации, которые можно встретить в самых быстрых вдом либах.
Только вот лидеры не используют vdom, ибо это куча работы впустую.
Лидеры в этом корявом бэнчмарке? Не вижу ни одной быстрой вдом либы в этом списке.
Что же в нём корявого?
Видимо на быстрых вдом либах слишком сложно написать todomvc :-D
Видимо на быстрых вдом либах слишком сложно написать todomvc :-D
Интересно, какие вы делаете выводы, глядя на эту цифру в бэнчмарке? :) Хоть немного представляете о том на каких кэйсах kvo сосёт, а на каких vdom? Почему вообще все эти идиоты вокруг начали придумывать dirty checking или virtual dom в то время как уже более десяти лет люди разрабатывали интерфейсы с использованием kvo, видимо эти идиоты просто так и не осилили всей красоты kvo :)
Когда я выложил vdom-benchmark, куча людей так же начало делать выводы что одна либа быстрее другой в N раз, глядя на цифру «Overall time», пришлось постоянно объяснять что единственное предназначение этой цифры — это чтобы разработчикам либ было проще отслеживать регрессии, и что какие-то выводы можно делать только глядя на конкретные тесткэйсы. И вообще лучше не делать никаких выводов, если нет глубокого понимания того как работают все современные библиотеки и почему они используют одно решение или другое.
Когда я выложил vdom-benchmark, куча людей так же начало делать выводы что одна либа быстрее другой в N раз, глядя на цифру «Overall time», пришлось постоянно объяснять что единственное предназначение этой цифры — это чтобы разработчикам либ было проще отслеживать регрессии, и что какие-то выводы можно делать только глядя на конкретные тесткэйсы. И вообще лучше не делать никаких выводов, если нет глубокого понимания того как работают все современные библиотеки и почему они используют одно решение или другое.
Интересно, какие вы делаете выводы, глядя на эту цифру в бэнчмарке?Очевидно, что одно и то же приложение на одном фреймворке быстрее приложения на другом. А вы делаете какие-то иные выводы? Расскажите о них по подробнее.
Хоть немного представляете о том на каких кэйсах kvo сосёт, а на каких vdom?Что такое «вдом» я уж догадался. Что такое «кво» — ума не приложу. Вы когда употребляете аббревиатуры, хотя бы раз их расшифровывайте, пожалуйста.
Почему вообще все эти идиоты вокруг начали придумывать dirty checking или virtual dom в то время как уже более десяти лет люди разрабатывали интерфейсы с использованием kvo, видимо эти идиоты просто так и не осилили всей красоты kvo :)Аргументация к авторитету, как мило.
И вообще лучше не делать никаких выводов, если нет глубокого понимания того как работают все современные библиотеки и почему они используют одно решение или другое.Ну, раз у вас есть глубокое понимание как работают эти библиотеки, значит вам не составит труда объяснить почему приложения на фреймворках, разрабытывающихся кучей высококлассных специалистов с более чем десятилетним стажем, и позиционирующихся как самые быстрые, проигрывают более чем в 2 раза на этом конкретном тесткейсе?
>Очевидно, что одно и то же приложение на одном фреймворке быстрее приложения на другом. А вы делаете какие-то иные выводы? Расскажите о них по подробнее.
Я не делаю никаких выводов, потомучто есть куча способов как можно реализовать TodoMVC с одной и той же либой для отображения UI, и результаты будут очень сильно отличаться. Какие-то реализации в этом бэнче вообще используют батчинг, а какие-то нет. Пихать всё в одну кучу и думать что одна либа быстрее другой потомучто она тупо не делала той же работы из-за батчинга, что и другие либы — это конечно отличный показатель производительности.
>Что такое «вдом» я уж догадался. Что такое «кво» — ума не приложу. Вы когда употребляете аббревиатуры, хотя бы раз их расшифровывайте, пожалуйста.
Key-Value Observing.
>и позиционирующихся как самые быстрые, проигрывают более чем в 2 раза на этом конкретном тесткейсе?
Например потомучто у фб приоритет на скорость изначального рендера и рендера большого куска дома при переходе между страницами, поэтому они готовы пожертвовать скоростью мелких точечных апдейтов, но сделать более быстрый рендер.
Или просто потомучто vuejs использует батчинг.
Я не делаю никаких выводов, потомучто есть куча способов как можно реализовать TodoMVC с одной и той же либой для отображения UI, и результаты будут очень сильно отличаться. Какие-то реализации в этом бэнче вообще используют батчинг, а какие-то нет. Пихать всё в одну кучу и думать что одна либа быстрее другой потомучто она тупо не делала той же работы из-за батчинга, что и другие либы — это конечно отличный показатель производительности.
>Что такое «вдом» я уж догадался. Что такое «кво» — ума не приложу. Вы когда употребляете аббревиатуры, хотя бы раз их расшифровывайте, пожалуйста.
Key-Value Observing.
>и позиционирующихся как самые быстрые, проигрывают более чем в 2 раза на этом конкретном тесткейсе?
Например потомучто у фб приоритет на скорость изначального рендера и рендера большого куска дома при переходе между страницами, поэтому они готовы пожертвовать скоростью мелких точечных апдейтов, но сделать более быстрый рендер.
Или просто потомучто vuejs использует батчинг.
Последнее время ещё разработчики фрэймворков начали добавлять DOM node recycling, ну чтобы выигрывать подобные бэнчмарки, ведь оно же там не догадается что после первой итерации фрэймворк вместо создания дом элементов, будет вынимать готовые из пула и вставлять(эффективная техника немного сложнее, но суть примерно такая). В реальной ситуации такая оптимизация помогает в редких ситуациях, зато на многих подобных бэнчмарках либа начинает показывать потрясающую производительность, и неважно что на реальных кэйсах она может значительно отставать, главное ведь выиграть в бэнчмарке :)
1. В данном бенчмарке такая техника не прокатит (тут сначала создаётся куча задач, а потом они по одной удаляются), так что сохранение нод только замедлит. Хотя, замеры потребляемой памяти бы не помешали, да.
2. При реализации рендеринга только видимых узлов (в ситуациях, когда нужно отображать список на многие тысячи элементов), переиспользование узлов просто необходимо. Более того, их нельзя перемещать, иначе в ИЕ плавный скроллинг перестаёт быть плавным.
2. При реализации рендеринга только видимых узлов (в ситуациях, когда нужно отображать список на многие тысячи элементов), переиспользование узлов просто необходимо. Более того, их нельзя перемещать, иначе в ИЕ плавный скроллинг перестаёт быть плавным.
>При реализации рендеринга только видимых узлов (в ситуациях, когда нужно отображать список на многие тысячи элементов), переиспользование узлов просто необходимо. Более того, их нельзя перемещать, иначе в ИЕ плавный скроллинг перестаёт быть плавным.
Под переиспользованием я подразумеваю что вместо удаления нода, он помещается в пул. И когда на второй итерации вашего бенчмарка происходит опять создание кучи задач, то вместо кучи DOM операций на создание новой деревяшки, вынимается нод с похожим шэйпом и обновляет все динамические части. Никакого отношения к виртуальному рендерингу(или как там в вебе его щас называют) он не имеет.
Под переиспользованием я подразумеваю что вместо удаления нода, он помещается в пул. И когда на второй итерации вашего бенчмарка происходит опять создание кучи задач, то вместо кучи DOM операций на создание новой деревяшки, вынимается нод с похожим шэйпом и обновляет все динамические части. Никакого отношения к виртуальному рендерингу(или как там в вебе его щас называют) он не имеет.
на многих подобных бэнчмарках либа начинает показывать потрясающую производительностьAngular 2 не удаляет элементы (в директиве *for) и вставляет их на следующей итерации. Но по моим экспериментам, эта техника дает 5-10% (ничего потрясающего). Насоздавать элементы не так «дорого» как их отрендерить.
Я не делаю никаких выводов, потомучто есть куча способов как можно реализовать TodoMVC с одной и той же либой для отображения UI, и результаты будут очень сильно отличаться.Именно, тем и хорошо проект ToDoMVC, что это не бенчмарк, а демонстрация читаемости кода на разных фреймворках. Именно поэтому реализация на VanillaJS получилась не самой быстрой. Если вы считаете, что решение на каком-то фреймворке можно ускорить без вреда для читаемости и поддерживаемости, и наоборот, что можно существенно улучшить читаемость и поддерживаемость ценой скорости, то пулреквесты приветствуются. Я не в состоянии в одиночку проверить идиоматичность всех 80 решений. Но основная миссия проекта — именно идиоматичный, а не быстрый код. И именно поэтому он хорош в качестве интегральной оценки скорости фреймворков. В отличие от многочисленных бенчмарков, где в код вставляют кучу костылей ради скорости, которые в реальном приложении никто не напишет кроме крайней нужды, когда фреймворк начинает жутко тупить на казалось бы простых задачах. Например, пользователи knockout вставляют throttl-инги, чтобы он не перерисовывал дом на каждый чих.
Какие-то реализации в этом бэнче вообще используют батчинг, а какие-то нет. Пихать всё в одну кучу и думать что одна либа быстрее другой потомучто она тупо не делала той же работы из-за батчинга, что и другие либы — это конечно отличный показатель производительности.В рамках одного фрейма группировать пересчёты допустимо и даже желательно. Типичная ситуация — сделали несколько запросов, они потупили секунду и скопом все прилетели — нужно отрендерить актуальное состояние, а не рендерить подряд все промежуточные. Тем не менее, тест занимает много фреймов — итерации исполняются по setTimeout (что, кстати, несколько сглаживает результаты, так что разница в скорости решений на самом деле даже больше, чем представлена на графике). Если какое-то решение рендерило только один раз в самом конце, то оно дисквалифицировалось. Не помню, были ли такие случаи, но многие решения пришлось исключить, так как они не проходили весь положенный цикл (создание задач через инпут, завершение всех задач, удаление задач по кнопке удаления). Если почините какое-либо из исключённых решений — пулреквесты приветствуются.
Key-Value Observing.
Кроме KVO и грязных проверок других способов реакции на изменения нет?
Например потомучто у фб приоритет на скорость изначального рендера и рендера большого куска дома при переходе между страницами, поэтому они готовы пожертвовать скоростью мелких точечных апдейтов, но сделать более быстрый рендер.Тогда при чём тут вообще VDOM? Для рендеринга больших кусков дома нет ничего быстрее, чем тупо сгенерить весь хтмл и отдать его браузеру, как в старые добрые времена jquery-templates, и не надо грузить мегабайтную библиотеку.
Или просто потомучто vuejs использует батчинг.Как я уже сказал, использует не больше необходимого. Но я сейчас проверил, у многих решений есть косяк — задачи не комплитятся. Буду сейчас разбираться что там не так, но погоды сильной этот этап не делает.
>Но основная миссия проекта — именно идиоматичный, а не быстрый код.
Не знаю какие у вас там TodoMVC реализации, последний раз когда я смотрел реализацию реактового TodoMVC, она была сделана как можно проще. Для примеров может и сойдёт, но на больших проектах никто так не пишет, подозреваю что большинство других реализаций такие же. Так что не знаю о какой идиоматичности речь.
>В рамках одного фрейма группировать пересчёты допустимо и даже желательно. Типичная ситуация — сделали несколько запросов, они потупили секунду и скопом все прилетели — нужно отрендерить актуальное состояние, а не рендерить подряд все промежуточные.
Что замеряем то? Зачем всё это в бэнчмарке, вы знаете какое начальное состояние, и какое должно быть после апдэйта, вот и замеряйте синхронный апдэйт из состояния A в состояние B, а не то сколько у вас там фрэймворк сможет успеть проскочить апдэйтов. Хочется сделать симуляцию множества изменений, ну так и делайте одинаковый синхронный апдэйт для состояния B в котором будет множество изменений.
>(создание задач через инпут, завершение всех задач, удаление задач по кнопке удаления)
Ну так и пишите три результата, зачем всё в одну кучу пихать? Три совершенно разные задачи, на одной задаче один фрэймворк может сильно проигрывать, на другой выигрывать. Например deku начнёт жестоко сливать только потомучто у него медленное удаление компонентов.
>Кроме KVO и грязных проверок других способов реакции на изменения нет?
Все вариации на kvo имеют одни и те же недостатки, так что их обычно просто называют kvo последнее время, когда обсуждают эту тему. Конечная суть ведь в обновлении отображения, можно тупо перерисовывать каждый фрэйм, можно перерисовывать каждый фрэйм с использования чего-то вроде virtual dom'а, можно перерисовывать когда происходит какой-либо input, а можно выстраивать граф зависимостей на обсёрвэблы и не делать «никакой» работы впустую. Ни о чём другом вроде и не слышал.
>Тогда при чём тут вообще VDOM? Для рендеринга больших кусков дома нет ничего быстрее, чем тупо сгенерить весь хтмл и отдать его браузеру, как в старые добрые времена jquery-templates, и не надо грузить мегабайтную библиотеку.
Не всё так просто и всё очень браузерозависимо, например реакт создавался во времена когда в большинстве браузеров была эффективна одна техника для создания деревяшки, сейчас же всё совсем изменилось, тк большинство начало оптимизировать под тормозные андроиды и в след релизе реакта будет использоваться другая техника.
>Буду сейчас разбираться что там не так, но погоды сильной этот этап не делает.
Не знаю что у вас там за бэнчмарк с TodoMVC, но если это что-то похожее на оригинал, который народ использовал год назад, то батчинг имел ключевую роль в том чтобы выиграть этот бэнчмарк, никакая другая оптимизация не была настолько значительна как использование батчинга.
Не знаю какие у вас там TodoMVC реализации, последний раз когда я смотрел реализацию реактового TodoMVC, она была сделана как можно проще. Для примеров может и сойдёт, но на больших проектах никто так не пишет, подозреваю что большинство других реализаций такие же. Так что не знаю о какой идиоматичности речь.
>В рамках одного фрейма группировать пересчёты допустимо и даже желательно. Типичная ситуация — сделали несколько запросов, они потупили секунду и скопом все прилетели — нужно отрендерить актуальное состояние, а не рендерить подряд все промежуточные.
Что замеряем то? Зачем всё это в бэнчмарке, вы знаете какое начальное состояние, и какое должно быть после апдэйта, вот и замеряйте синхронный апдэйт из состояния A в состояние B, а не то сколько у вас там фрэймворк сможет успеть проскочить апдэйтов. Хочется сделать симуляцию множества изменений, ну так и делайте одинаковый синхронный апдэйт для состояния B в котором будет множество изменений.
>(создание задач через инпут, завершение всех задач, удаление задач по кнопке удаления)
Ну так и пишите три результата, зачем всё в одну кучу пихать? Три совершенно разные задачи, на одной задаче один фрэймворк может сильно проигрывать, на другой выигрывать. Например deku начнёт жестоко сливать только потомучто у него медленное удаление компонентов.
>Кроме KVO и грязных проверок других способов реакции на изменения нет?
Все вариации на kvo имеют одни и те же недостатки, так что их обычно просто называют kvo последнее время, когда обсуждают эту тему. Конечная суть ведь в обновлении отображения, можно тупо перерисовывать каждый фрэйм, можно перерисовывать каждый фрэйм с использования чего-то вроде virtual dom'а, можно перерисовывать когда происходит какой-либо input, а можно выстраивать граф зависимостей на обсёрвэблы и не делать «никакой» работы впустую. Ни о чём другом вроде и не слышал.
>Тогда при чём тут вообще VDOM? Для рендеринга больших кусков дома нет ничего быстрее, чем тупо сгенерить весь хтмл и отдать его браузеру, как в старые добрые времена jquery-templates, и не надо грузить мегабайтную библиотеку.
Не всё так просто и всё очень браузерозависимо, например реакт создавался во времена когда в большинстве браузеров была эффективна одна техника для создания деревяшки, сейчас же всё совсем изменилось, тк большинство начало оптимизировать под тормозные андроиды и в след релизе реакта будет использоваться другая техника.
>Буду сейчас разбираться что там не так, но погоды сильной этот этап не делает.
Не знаю что у вас там за бэнчмарк с TodoMVC, но если это что-то похожее на оригинал, который народ использовал год назад, то батчинг имел ключевую роль в том чтобы выиграть этот бэнчмарк, никакая другая оптимизация не была настолько значительна как использование батчинга.
Простота — это всё же ближе к идиоматичности, чем переусложнение ради попугаев. Но да, хотелось бы более реалистичного кода, но имеем то, что имеем. Всяко улчше синтетических бенчмарков.
Бенчмарк замеряет полный цикл работы фреймворка, от пеерехвата события до рендеринга. Например, если фреймворк использует jQuery, то при возникновении события происходит его нормализация, что бывает даёт значительное пенальти. Асинхронизация используется в частности и для предотвращения «батчинга». Кстати, я посмотрел код бенчмарка, по ходу дела батчинг бы сломал удаление задач (кликается первая попавшаяся кнопка удаления), так что все представленные фреймворки не «батчатся».
Три результата пишутся в консоль, если очень надо. Это же интегральный тест. Фреймворк который быстро создаёт узлы, но медленно удаляет, и фреймворк, который медленно создаёт и быстро удаляет — одинаково плохи, так как при переключении экранов всё равно нужно кучу узлов удалить и кучу узлов добавить. Можно добавить ещё изменение названий задач для полного набора.
Почему «никакой» в кавычках? Есть ещё автотрекинг зависимостей с автоматическим же точечным изменением DOM. В чём тут недостаток?
Я думаю всё проще — реакт заложник своей архитектуры. Нельзя добиться существенного увеличения производительности без изменения архитектуры. Например, наиболее преспективным мне видится рендеринг только видимых элементов. Сейчас это в основном решается вручную, а хотелось бы на уровне фреймворка.
Это сильно кастомизированный бенчмарк — при добавлении нового приложения, оно автоматом подхватывается бенчмарком, предотвращается «батчинг», рисуется график, сохраняются состояния чекбоксов.
Бенчмарк замеряет полный цикл работы фреймворка, от пеерехвата события до рендеринга. Например, если фреймворк использует jQuery, то при возникновении события происходит его нормализация, что бывает даёт значительное пенальти. Асинхронизация используется в частности и для предотвращения «батчинга». Кстати, я посмотрел код бенчмарка, по ходу дела батчинг бы сломал удаление задач (кликается первая попавшаяся кнопка удаления), так что все представленные фреймворки не «батчатся».
Три результата пишутся в консоль, если очень надо. Это же интегральный тест. Фреймворк который быстро создаёт узлы, но медленно удаляет, и фреймворк, который медленно создаёт и быстро удаляет — одинаково плохи, так как при переключении экранов всё равно нужно кучу узлов удалить и кучу узлов добавить. Можно добавить ещё изменение названий задач для полного набора.
Почему «никакой» в кавычках? Есть ещё автотрекинг зависимостей с автоматическим же точечным изменением DOM. В чём тут недостаток?
Я думаю всё проще — реакт заложник своей архитектуры. Нельзя добиться существенного увеличения производительности без изменения архитектуры. Например, наиболее преспективным мне видится рендеринг только видимых элементов. Сейчас это в основном решается вручную, а хотелось бы на уровне фреймворка.
Это сильно кастомизированный бенчмарк — при добавлении нового приложения, оно автоматом подхватывается бенчмарком, предотвращается «батчинг», рисуется график, сохраняются состояния чекбоксов.
>Например, если фреймворк использует jQuery, то при возникновении события происходит его нормализация, что бывает даёт значительное пенальти.
И если вдруг какие-то синтетические евенты реализованы очень-очень тормозно для кликов, ну кроме спец кэйсов вроде маусмува и скролла(не используется делегирование для фаст рендера), то конечный результат для этого фрэймворка будет плохим, ведь это так важно оптимизировать клик, ведь пользователи успевают прокликать 100 раз втечении одного кадра. Отличный бэнчмарк!
>Почему «никакой» в кавычках? Есть ещё автотрекинг зависимостей с автоматическим же точечным изменением DOM. В чём тут недостаток?
Явно или неявно вешаем слушателей, никакой разницы, суть не в апи. А с неявными слушателями вообще весело, когда рендерим список с отсортироваными и фильтроваными(10 из 10000) итемами, сколько слушателей повешаете? :)
>Я думаю всё проще — реакт заложник своей архитектуры. Нельзя добиться существенного увеличения производительности без изменения архитектуры.
Под архитектурой вы подразумеваете идею виртуального дома? Или конкретную его реализацию в реакте? Просто я не вижу никакой проблемы с виртуальным домом, зато вижу как на кэйсах с тяжёлыми дом апдэйтами, реализации с kvo стабильно показывают худший результат, а когда точечный апдэйт, оверхэд от диффа не такой значительный(у быстрых вдом либ) и у нас есть гораздо больше времени на исполнение жаваскрипта.
>Например, наиболее преспективным мне видится рендеринг только видимых элементов. Сейчас это в основном решается вручную, а хотелось бы на уровне фреймворка.
Автоматическое убивание поиска и a11y на уровне фрэймворка, ну может только в Aurelia на это способны :)
И если вдруг какие-то синтетические евенты реализованы очень-очень тормозно для кликов, ну кроме спец кэйсов вроде маусмува и скролла(не используется делегирование для фаст рендера), то конечный результат для этого фрэймворка будет плохим, ведь это так важно оптимизировать клик, ведь пользователи успевают прокликать 100 раз втечении одного кадра. Отличный бэнчмарк!
>Почему «никакой» в кавычках? Есть ещё автотрекинг зависимостей с автоматическим же точечным изменением DOM. В чём тут недостаток?
Явно или неявно вешаем слушателей, никакой разницы, суть не в апи. А с неявными слушателями вообще весело, когда рендерим список с отсортироваными и фильтроваными(10 из 10000) итемами, сколько слушателей повешаете? :)
>Я думаю всё проще — реакт заложник своей архитектуры. Нельзя добиться существенного увеличения производительности без изменения архитектуры.
Под архитектурой вы подразумеваете идею виртуального дома? Или конкретную его реализацию в реакте? Просто я не вижу никакой проблемы с виртуальным домом, зато вижу как на кэйсах с тяжёлыми дом апдэйтами, реализации с kvo стабильно показывают худший результат, а когда точечный апдэйт, оверхэд от диффа не такой значительный(у быстрых вдом либ) и у нас есть гораздо больше времени на исполнение жаваскрипта.
>Например, наиболее преспективным мне видится рендеринг только видимых элементов. Сейчас это в основном решается вручную, а хотелось бы на уровне фреймворка.
Автоматическое убивание поиска и a11y на уровне фрэймворка, ну может только в Aurelia на это способны :)
Не раз наблюдал, как нормализация ивента приводила к полусекундным затыкам из-за рефлоу дерева на несколько тысяч узлов.
Очевидно это будет порядка 20000 ссылок на связанные объекты. Вы думаете это много?
Вы забываете, что этот VDOM нужно сначала сгенерировать, при этом приходится вам это делать на каждый чих, а потом ещё бежать по нему вычилять разницу. Либо не на каждый, обвешавшись обсерверами.
Браузерного поиска по странице? Ну ничего страшного, интегрированный в интерфейс поиск всяко лучше будет искать. Что такое a11у?
Очевидно это будет порядка 20000 ссылок на связанные объекты. Вы думаете это много?
Вы забываете, что этот VDOM нужно сначала сгенерировать, при этом приходится вам это делать на каждый чих, а потом ещё бежать по нему вычилять разницу. Либо не на каждый, обвешавшись обсерверами.
Браузерного поиска по странице? Ну ничего страшного, интегрированный в интерфейс поиск всяко лучше будет искать. Что такое a11у?
vintage, поделитесь ссылкой откуда бенчмарк и картинка ?
Только мне показалось, что к Mithril приложил руку Mithgol? )
Для каждой задачи свой инструмент и у меня был опыт небольшого SPA с локализацией на xml-ках (требование заказчика). Mithril мне очень понравился и именно для небольших задач он подходит очень и очень хорошо, так как из коробки есть все что нужно.
Но сейчас React во всех возможных вариациях и как-то уже позабыл про проект 8-месячной давности. Пришла пора вспомнить.
Но сейчас React во всех возможных вариациях и как-то уже позабыл про проект 8-месячной давности. Пришла пора вспомнить.
Если хочется лайтового реакта, то есть riotjs.com
Да, он не такой продвинутый, но он сильно приятнее в обращении, чем остальные монстрофреймворке. И размер приятно удивит вас и ваших посетителей. С джейдом и кофе внутри будет совсем милота.
Да, он не такой продвинутый, но он сильно приятнее в обращении, чем остальные монстрофреймворке. И размер приятно удивит вас и ваших посетителей. С джейдом и кофе внутри будет совсем милота.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка Mithril. Практика, опыт и подводные камни