Странно, я всегда думал, что такие вещи должны решаться на конкурентной основе, а не по указке из центра. Ну и вы понимаете, что «использование приватных API» и «излишнее потребление системных ресурсов» это все таки разные вещи. О первом говорит Apple, о втором — добрая половина комментаторов.
не очень вас понял, но если эта переменная уровня этого запроса вы можете объявить его на уровне этого запроса. И остальные узлы (кроме, дочернего assertion узла) не увидят эту переменную
Но ведь есть уже достаточно много реализаций material дизайна, которые можно взять за ориентир и обойтись без дизайнера. Даже в сфере десктопных приложений есть весьма симпатичная версия на qt
Ничуть. В конце концов кейс со списками не я предложил) Я лишь пытаюсь доказать (и об этом я уже пишу из сообщения в сообщение), что сделать несинтетические всеобъемлющие тесты фреймворков (что сравнение однооконного приложения, что сравнение списка — это сугубо синтетические тесты, не отражающие реального положения дел) — это очень сложное дело, а тем более на таком количестве инструментов. Но статья и не претендует на всеобъемлющее исследование (о чем кстати там тоже написано).
Я о другом: вы не сравниваете фреймворки, вы сравниваете реализации списков в разных фреймворках. Серьезных выводов о самом фреймворке вы не сделаете. Пример я уже привел выше — virtual scroll есть в electron (точнее в web фреймворках), и память, которую занимают элементы в DOM константна. Но что это вам говорит о фреймворке в целом?
Согласен, данное исследование носит весьма синтетический характер. С другой стороны, написание реального приложения для все перечисленных платформ — труд весьма кропотливый с одной стороны, с другой стороны объем данного приложения должен быть весьма большим, чтобы убрать синтетичность. Даже озвученный вами кейс с виртуализацией «выстреливает» далеко не всегда, да и к тому же на том же electron-е (не уверен, но я надеюсь и в других популярных GUI фреймворках) это легко реализуется.
Ну и в конце концов сам автор предупреждает, что научной ценности данный материал не несет. Так, забавы ради.
На полном серьезе) Вы не поверите, но процентов 50 (если не больше) вопросов идет именно через живосайт. И судя по диалогам там есть те самые IT профессионалы. Его внедрение — одно из лучших наших решений. Вы поймите, люди достаточно ленивы, вот у них возникла проблема, вы думаете все побегут искать форум или штудировать FAQ/доку? К сожалению, нет. Хотя есть и дока, и чат в телеграме, и чат в слаке, и группа в фейсбуке, и группа в контакте, точек контакта — на любой вкус) Не хотят)
Почему именно живосайт? Бесплатно, мобильные приложения под все интересующие платформы, возможность иметь несколько операторов. Не факт конечно, что с этим решением мы будем всегда
Но ведь есть уже достаточно много реализаций material дизайна, которые можно взять за ориентир и обойтись без дизайнера. Даже в сфере десктопных приложений есть весьма симпатичная версия на qt
Ну и в конце концов сам автор предупреждает, что научной ценности данный материал не несет. Так, забавы ради.
В качестве приложения было выбрано обычное пустое окно
Это перевод, судя по всему автор доступен в соответствующем посте на реддите. https://www.reddit.com/r/programming/comments/cr3tqx/comment/ex2f6g4
Ну пример ангуляра доказал свою состоятельность. Развитие его идеи в сторону back напрашивалось само собой
Почему именно живосайт? Бесплатно, мобильные приложения под все интересующие платформы, возможность иметь несколько операторов. Не факт конечно, что с этим решением мы будем всегда