Chrome Audit на 500: Часть 1. Лендинг

Да, чужие сайты к сожалению с оптимизировать нельзя.

Chrome Audit на 500: Часть 1. Лендинг

Судя по рейтингу интернет тотально сломан, и вместо html с анимашками надо возвращать epub =)

Chrome Audit на 500: Часть 1. Лендинг

Здесь рядом должен быть комментарий. «Зачем мне ждать загрузку подвала, если мне нужен только телефон в шапке» =)
И ленивая отрисовка на js не выдает белых блоков, белые блоки выдают ленивая подгрузка.

Chrome Audit на 500: Часть 1. Лендинг

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

Chrome Audit на 500: Часть 1. Лендинг

Ничего страшного, всё то вы описали имеет отношение к кривым рукам, и никак не связано с использованием js вместо html. Просто на js гораздо проще бездумнее выжрать всю память, чем на html =)

Chrome Audit на 500: Часть 1. Лендинг

Серверный рендеринг увеличивает время до Time to Interact. С начало сервер тратит время на рендеринг, потом нарендереное передается клиенту (клиенты любуются белым экраном), потом клиенту передается SPA (что бы у пользователей не мелькал экран между переходами), потом происходит расчет нового дома и гидрация…
В случае отсутствия серверного рендеринга время до окончания запуска программы сильно меньше, а при повторном заходе вся программа уже будет на клиенте.

Время жизни кеша тоже полезная фича, хоть и не привычная. Lighthouse рекомендует выставить год. По хорошему для сброса такого кеша надо использовать хеш файла (как делает ангуляр), но я просто использую версии /scripts/main.min.js?v={version} которые расставляются при компиляции статики.

Chrome Audit на 500: Часть 1. Лендинг

Боюсь что вы не входите в большинство пользователей. Большинство более требовательно и хотят что бы не только работало, но и было красиво, эффектно, удобно.

Вот для примера два сайта вики и промо. И как вы думаете какой из них выберет пользователь? Там где скучный текст, или там где можно трейлеры посмотреть, музыку послушать, но все на скриптах…

Chrome Audit на 500: Часть 1. Лендинг

Только это не конфигурируется, а программируется. А что бы повторить функционал nginx надо много попотеть.
Производительность в том что С++ программы работают быстрее C# программ, а nginx годами затачивался на производительность отдачи статики.

Chrome Audit на 500: Часть 1. Лендинг

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

Chrome Audit на 500: Часть 1. Лендинг

Я сам шарпист и пишу уже на .net core 3. Да, шарп действительно быстр, но реальная жизнь не ограничивается отдачей строки из программы. Нужно еще установить соединение, считать файлы с диска, сжать их, закешировать, навесить правильные заголовки и только потом отдать клиенту. На шарпе мало того что из коробки этого функционала нет, так и производительность будет все же поменьше.

Веб-компоненты в реальном мире

Да именно такая конструкция. Дроп даун очень простой на самом деле. Вот календарь это да.

Больших компонентов всего три, и да, это больно делать без шаблонизатора.
Поэтому посмотрим как будут развиваться события и когда будем писать более серьезные вещи выберем какой нибудь микро шаблонизатор.

Веб-компоненты в реальном мире

API выглядит не так, как вы описываете

Я описал абстрактный сервис который будет заниматься регистрацией веб компонентов и возвращать готовый React компонент для его использования =). А у себя решили просто корпоративным префиксом, что то типо <prefix-button/> и ближайшие пару лет проблем точно не будет.

Обновили компонент, поменяли свойства, но забыли обновить Intrinsic. Typescript молчит, а в рантайме все ломается.

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

В случае нативного тэга input браузер сам позаботится об оптимизации и перерендерит input только после обновления всех свойств.

Нет, он пересчитывает поштучно, именно поэтому виртуальный дом бывает много выгоднее:

var elem = document.querySelector(".post__title_link");
elem.textContent += "1";
console.log(elem.getClientRects()[0].width); // 419.203125
elem.textContent += "2";
console.log(elem.getClientRects()[0].width); // 433.40625

А как вы будете оптимизировать свой собственный компонент?

Я не использую lit-element, у меня своя микро-надстройка. Просто на сеттере свойства я меняю только то что мне нужно, поэтому поведение полностью наследуется от нативного =)

Веб-компоненты в реальном мире

На самом деле проблемы совсем не страшные.

• Tree-shaking и Глобальные имена компонентов — не обязательно регистрировать отдельно и глобально, можно сделать также как сделано в styled components
  
  

  import {ButtonElement} from "wclibs/button-element"
  
  const Button = wc.register(ButtonElement);
  ...
  render (<Button/>);
  

  
  Тогда много проблем сразу отваливается.
  
• Проблемы с типизацией — Intrinsic описанный в статье решает проблему.
• Групповое обновление свойств — это не проблема веб компонентов, это стандартное поведение DOM, а если писать без прослойки с VDOM то и не проблема вовсе.

На самом деле тема очень полезная, у нас большая компания, пишем на разных шаблонизаторах и веб компоненты помогают реюзать компоненты между ними. Но без какой то прослойки типа lit-element крупные вещи действительно лучше не писать.

Rollup: уже можно собирать приложения

По сравнению с webpack 2, на 30% эффективнее, но если собирать в webpack 4 в es2015+, то разница стремится к 0.

Rollup: уже можно собирать приложения

Спасибо, поправил.

Rollup: уже можно собирать приложения

Показан не результат сборки, а сама возможность сборки в iife. В Commonjs ситуация следующая:

• Относительно Browserify и Webpack2 размер бандла iife меньше на 30%
• Относительно Webpack 4 при сборке es5 из esnext бандл iife на 10% меньше
• Относительно Webpack 4 при сборке es2015+ разница стремится к 0
• Если оба бандлера собрать в commonjs и es2015, то они соберут одно и тоже, за той разницей что rollup поэффективнее мертвый код удалит, но commonjs придется отдельно подключать, тогда как webpack сам включит его в бандл.

Rollup: уже можно собирать приложения

Это на самом деле палка на двух концах. С одной стороны Rollup быстрее собирает продакшен сборку, с другой в девелоперском режиме нельзя отключить treeshaking.

Но облегчить ситуацию всё таки можно, дело в том что webpack в девелоперском режиме отключает все оптимизации, из-за чего в angular можно наблюдать бандлы по 14мб. Конфиг Rollup тоже можно настроить на отключение всех минификаций в плагинах в режиме девелоп, что сильно ускорит сборку.

TypeScript: Десериализация JSON в классы с валидацией типов у свойств

Интересный прием. Спасибо!

TypeScript: Десериализация JSON в классы с валидацией типов у свойств

А вы правы, в комментарии выше уже всплывала эта проблема. И в Newtonsoft десериализация тоже реализована через статический метод. Реализую как Serializable.toClass(User, json): User

TypeScript: Десериализация JSON в классы с валидацией типов у свойств

Мне не нравится подход со схемами, кроме того в моделях у меня бывают методы.