Наверно, можно преисполниться и написать напрямую на WASM-овских S-выражениях, как вот этот уважаемый человек: https://habr.com/ru/articles/901976/, но я пока не готов :)
Да, тут приходится сравнивать размер декодера против размера сэкономленного места. Если игнорировать кроссбраузерность, то DecompressionStream умеет brotli.
Ну и можно ещё сам алгоритм распаковки в WASM скомпилировать, но вряд ли оно побьёт gzip, который браузер даёт практически бесплатно.
Не уверен что следует вам ответить. Пример зависимых валидаторов сделаю во второй статье. Про валидацию на бэке — первый абзац этой статьи. Что выбранный мной подход не прост, не очевиден и не является "первым выбором" — да, именно по этому я его взял и исследую.
Можно и разумно использовать json schema или решения с аналогичным подходм, согласен. Я, просто, решил подойти к вопросу чуть шире и с чуть менее серьёзным лицом.
Если нужно сходить в БД — это в любом случае не фронтовый валидатор, "не наш случай". "Одно поле зависит от другого" — это задача валидации, "появляются доп поля" — задача уже вне валидации. Я начал вторую часть статьи, реализация того же, но на wasm, попробую проанализировать в процессе случай с зависимыми полями, как он соотносится с идеей "один код валидации на фронте и бэке".
А вот это хороший вопрос. Не думал, что делать для 3+ участников. Подумаю. Что касается схемы, это понятно, что в 95% случаев использование библиотек с единой конфигурацией наиболее разумно. Я исследую вопрос с другого угла, хочу чтобы валидатор был не декларативными правилами, а исполнимым кодом. Так гибкость выше чем у любого конструктора правил.
А я, видимо, попробую так сделать и оформить статьёй. Алаверды от бэка, так сказать. Ну и надо, кажется, проговорить явно, что это болше забавный эксперимент, чем HOWTO.
Да, безусловно. Приминимость разных подходв зависит от размера проекта и сложности валидаторов. Мой эксперимент, как правилнее сказать, - "на максималочках" - на JS-то точно любой валидатор можно написать. Ну и так веселее :)
Согласен. Без вопросов. Есть и другие заходы на проблему, в том числе и два конструктора валидаторов из единого конфига. И использование третьего языа, который можно скомпилировать в язык и фронта и бэка. Можно посравнивать эти подходы на практике, но это уже будет другая статья.
Т.е. тачпад для меня не очень — долго целюсь и часто мажу (случайные клики).
(Интересных результатов мне накликали за эти три дня, надо бы их обобщить и выложить...)
Да, если не заморачиваться и пройтись теми же инструментами, то выходит ± так же как JS-версия:
Наверно, можно преисполниться и написать напрямую на WASM-овских S-выражениях, как вот этот уважаемый человек: https://habr.com/ru/articles/901976/, но я пока не готов :)
Это после wasm-opt и gzip? Где посмотреть исходный код?
Да, тут приходится сравнивать размер декодера против размера сэкономленного места. Если игнорировать кроссбраузерность, то DecompressionStream умеет brotli.
Ну и можно ещё сам алгоритм распаковки в WASM скомпилировать, но вряд ли оно побьёт gzip, который браузер даёт практически бесплатно.
Напоминает phpBB версий 1-2.
Рельсы не моя тема, но посмотреть подход будет интересно. Спасибо за ссылку.
Не уверен что следует вам ответить. Пример зависимых валидаторов сделаю во второй статье. Про валидацию на бэке — первый абзац этой статьи. Что выбранный мной подход не прост, не очевиден и не является "первым выбором" — да, именно по этому я его взял и исследую.
Можно и разумно использовать json schema или решения с аналогичным подходм, согласен. Я, просто, решил подойти к вопросу чуть шире и с чуть менее серьёзным лицом.
Спасибо за ссылку. Интересная штука, поизучаю.
Если нужно сходить в БД — это в любом случае не фронтовый валидатор, "не наш случай". "Одно поле зависит от другого" — это задача валидации, "появляются доп поля" — задача уже вне валидации. Я начал вторую часть статьи, реализация того же, но на wasm, попробую проанализировать в процессе случай с зависимыми полями, как он соотносится с идеей "один код валидации на фронте и бэке".
А вот это хороший вопрос. Не думал, что делать для 3+ участников. Подумаю.
Что касается схемы, это понятно, что в 95% случаев использование библиотек с единой конфигурацией наиболее разумно. Я исследую вопрос с другого угла, хочу чтобы валидатор был не декларативными правилами, а исполнимым кодом. Так гибкость выше чем у любого конструктора правил.
А я, видимо, попробую так сделать и оформить статьёй. Алаверды от бэка, так сказать. Ну и надо, кажется, проговорить явно, что это болше забавный эксперимент, чем HOWTO.
Спасибо за ссылочку. Для того и общаемся, чтобы в комментариях насыпали того, на что сам не сразу наскочишь.
Да, безусловно. Приминимость разных подходв зависит от размера проекта и сложности валидаторов. Мой эксперимент, как правилнее сказать, - "на максималочках" - на JS-то точно любой валидатор можно написать. Ну и так веселее :)
Согласен. Без вопросов. Есть и другие заходы на проблему, в том числе и два конструктора валидаторов из единого конфига. И использование третьего языа, который можно скомпилировать в язык и фронта и бэка. Можно посравнивать эти подходы на практике, но это уже будет другая статья.
среднее время клика: 882.5 — 1080.98
точность клика: 1.00
Trackball (x3 прогона)
среднее время клика: 960.16 — 969.5
точность клика: 0.92
Mouse (x3 прогона)
среднее время клика: 695.7 — 818.48
точность клика: 0.96
Touchpad (x4 прогона)
среднее время клика: 1104.18 — 1326.08
точность клика: 0.76
Т.е. тачпад для меня не очень — долго целюсь и часто мажу (случайные клики).
(Интересных результатов мне накликали за эти три дня, надо бы их обобщить и выложить...)
Попробуйте поискать на сайте производителя, в техподдержку ещё можно написать.