Многие наверно подумаю что это же "просто"! А вот нифига. Написать "просто" - сложнее чем просто написать
Еще у Паскаля было: "Письмо это вышло более длинным только потому, что у меня не было времени написать короче". В общем, это просто проблема оптимизации, которая обычно не решается за 2-3 итерации. За это время можно даже не успеть понять, что конкретно следует оптимизировать и в ущерб чему.
Из примера так и не понял почему одно лучше другого. Для меня выглядят как инструменты для решения немного разных задач. По крайней мере, я обычно разделяю задачи построения лейаута и передачи данных. Иногда эти задачи, конечно, тесно сплетаются, взять например реактивные формы, или таблицы из cdk и прочее. Но такой декларативный подход далеко не всегда уместен, и зачастую сложнее в реализации и поддержке (тут можно обратиться к исходникам тех же форм и таблиц).
В Ваших примерах, количество строк на таком объеме сильно зависит от стиля написания кода, что как бы не совсем объективное сравнение.
Правда одно из существенных отличий в этих примерах я вижу в том как объявляются шаблоны. Метод render в Lit обладает контекстом this и следовательно для него будет работать типизация, подсказки редактора, линтеры и все прочее. Помимо этого, это также снимает сразу множество вопросов по композиции шаблонов.
Для шаблонов в Symbiote без какого-то дополнительного туллинга, как у того же angular, может стать больно. И совсем не очевидно как составлять сложные компоненты, с условиями, списками и т. д. То есть порог входа как-будто становится сильно больше чем у Lit. Но тут вопрос конечно в дизайне, и в том какую проблему этим решали.
Но это так, просто мнение после первого взгляда. В целом спасибо за статью, было интересно ознакомиться.
На сайте Lit, сразу же на главной странице есть пример с декораторами. Что по ощущениям, должно сильно снижать количество бойлерплейта в подобных примерах.
Хотя возможно это особенность V8. Вообще нас еще на первом курсе учили, что довольно опасно проверять на равенство числа с плавающей запятой, независимо от языка.
017 - это 15, так как с префиксом 0 записываются числа в восьмеричной системе. Number("017") - это 17, так как по правилам приведения типов, 0 в начале строки не учитывается. 018 - это 18, так как такая запись не может быть восьмеричной, Number("018") - так же 18, по правилам приведения типов.
В данном примере все конвертируется одинаково. Проблема в том, что используется устаревший синтаксис. То есть дело не том, что авторы языка не видят в этом проблемы, просто ничего не могут с этим сделать, чтобы не сломать разом всю обратную совместимость.
Реализация: Интерфейсы могут быть реализованы классами, в то время как типы не могут быть непосредственно реализованы.
Если речь про implements, то типы могут быть реализованы в виде класса с некоторыми ограничениями.
Объединение типов: Типы могут быть объединены с помощью оператора |, что позволяет создавать объединение типов.
Объединение интерфейсов ничем не отличается от объединения типов, но на выходе, да, получится тип, вместо интерфейса.
Возможности: Интерфейсы обладают некоторыми дополнительными возможностями, такими как объявление методов и наследование интерфейсов.
Ничто не мешает объявить метод внутри типа.
Касательно наследования и расширения, из данного описания как-будто это суть одного и того же:
interface Foo {}
interface Bar extends Foo {}
Foo расширяет Bar
Bar наследует Foo
Но как и в случае с классами, интерфейс может быть расширен типом или унаследован от типа, с некоторыми ограничениями. Примеры.
В основное отличие я бы выделил возможность расширения одного и того же интерфейса, за счет множественного объявления. А дальше уже начинаются различные тонкости.
Люди покупают большие мониторы для того, чтобы на них помещалось больше информации
Не знаю про всех, для себя покупал чтобы видеть приятную картинку на комфортном расстоянии для глаз.
Но если говорить в целом, моя мысль скорее заключалась в том, что нет такой категории людей, как пользователи операционной системы для персональных компьютеров, которая не пересекалась бы с пользователями других систем и других устройств. Чтобы интерфейс подходил как можно большему количеству людей, а особенно новым пользователям, необходимо учитывать опыт других систем и устройств. И так как мир вокруг не стоит на месте, отсюда и процесс изменений в дизайне, а вовсе не из-за тайного заговора дизайнеров. И это не говоря про то, что различные системы сами постоянно меняются, что может требовать адаптации старого интерфейса, под новые возможности.
Меняются размеры экранов, способы ввода, да и в целом персональные устройства. Что является привычным интерфейсом для одних, для других оказывается незнакомым и неудобным.
Понял. В таком случае есть стандартный принтер для печати в файл, но вроде как начиная только с win 10. До этого подобный принтер например появлялся после установки Adobe Reader. Короче в любом случае выглядит как пустяковая проблема.
Для меня лучший вариант, когда можно выполнить необходимое действие нажатием одной или нескольких клавиш. И для себя я вообще не ощутил каких-то изменений в привычных паттернах, после обновления до 11.
Но вот попробуйте объяснить поколению, которое с детства привыкло пользоваться тачскрином и видеть те же настройки чего-угодно в виде вложенных списков, с возможностью поиска по ним, что лучший вариант это оказывается иконки, и многоуровневые окна, в которых ты вряд ли найдешь нужный переключатель без гугла.
сейчас это удобно и быстро, как никогда: Win+R, ввод wt
Слишком сложно как по мне. Я для себя написал небольшой скрипт для Autohotkey, чтобы запускать терминал по F1. Хотя там в какой-то момент добавили и нативную поддержку такого режима открытия.
мы вполне получаем преимущество эвент-лупа, где по сути каждая таска внутри это такой микро-поток в частно случае
Ну и пусть горутина потребляет всего пару килобайт
Что-то я вижу в этом некоторое противоречие.
Если честно, практически незнаком с go, и как там считают потребление горутин, но в event-loop также есть свои накладные расходы на описание структуры задач, хранение их в очереди, на запуск и прочее. При этом libuv может обрабатывать задачи только в одном потоке, а Go этим не ограничен. Что эффективнее в плане накладных расходов: одна задача в очереди event-loop или одна горутина - для меня лично вопрос открытый.
Впрочем я вообще вел к тому, что асинхронный ввод-вывод, не является какой-то особенностью ноды или nginx. Нода является очень простым и удобным инструментом для создания эффективных веб-сервисов, которые не требуют особых вычислений, а например только гоняют данные из базы и обратно. Но нода это не про эффективное распределение нагрузки и параллельные вычисления, так как у нее практически нет для этого инструментов. Так что это просто очевидный ее минус, но опять же в контексте проектов, где это требуется. И тут я согласен с автором треда, что подобный бенчмарк практически бессмысленен.
В этом event-loop и содержится проблема, так как он блокируется на время исполнения JS. А для исполнения JS требуется интерпретатор и вот это все. Хоть сокеты в тредпуле и продолжат считываться и записываться в это время, код на JS все равно остается узким местом в плане производительности и распределения нагрузки.
Касательно спавна потоков, смотри epoll для линукса, или другие реализации неблокирующего ввода-вывода для других систем. Это не изобретение node, или nginx, а то что они просто используют, как и все остальные представленные веб-серверы, на сколько я понимаю.
Как это можно сделать без помощи JS, я не представляю. Не подскажете, как?
Простая форма для этого подойдет.
PS А CORS — это уже дополнительное средство, которое можно использовать неправильно.
Помимо корс заголовков, на сколько я помню сейчас в браузерах по умолчанию выставляется SameSite атрибут у куки. Но сложно спорить с Вашим утверждением, конечно. Однако правильная настройка безопасности, включая шифрование, CORS и CSP, и экранирование пользовательских данных, позволяет обезопасить, на сколько это возможно, всех пользователей сайта для стандартных настроек веб-браузера. И это гораздо важнее с точки зрения бизнеса, чем думать о паре чудиках, которым по каким-то причинам есть дело до отключения JS на странице. Я к тому, что аргумент с безопасностью в пользу выбора этого инструмента очень слабый, по крайней мере в существующей реальности.
JS требует защиты от выполнения вредоносного кода (использования «песочницы») на клиенте, от XSS с CSRF
Для CSRF атак вообще не имеет значение наличие или отсутствие JS, плюс все современные браузеры умеют работать с Access-Control-Allow-* заголовками. Да и ответственность, за возможность проведения таких атак, в любом случае лежит на беке.
По XSS, при рендере документа на беке, точно также, придется специальными средствами санитайзить пользовательские данные. Потому что для 99.9% пользователей веб-браузеров NoScript - это какое ругательство. Помимо этого у бека есть другие возможности, накладывать ограничения, предотвращающие различные сценарии подобных атак, например CSP.
Я могу согласится, с тем что JS, может предоставить дополнительный вектор атак, нацеленных именно на сам веб-браузер и операционку пользователя, но этому также подвержены любые другие технологии. А из того, что перечислено, это просто перекладывание ответственности с одних веб-разработчиков, на других, что никак не влияет на безопасность технологии.
jquery встроить-то, может быть, и можно было, но — уже не встроили.
Думаю в появлении метода querySelector, jQuery сыграл не последнюю роль. Наверняка jQuery также оказал свое влияние и на ряд других элементов стандартного WebAPI. Да даже банально в консоли отладки можно сделать вызов $("my-selector") с ожидаемым результатом и без подключения jQuery. Это конечно не встраивание в чистом виде, но логичное предоставление стандартных инструментов для тех практик, что приживаются в сообществе.
Потому что идеологически jquery чужеродно основному языку страницы — HTML(плюс CSS, естественно), оно — расширение для JS, стороннего для HTML средства, сильно отличающегося по идеологии от HTML.
Если честно, вообще не понимаю этот тезис. Для 90-х годов, возможно, такие рассуждения и имели смысл, то есть когда только формировалось какое-то представление о дальнейшем развитии данных технологий. Но в современном мире ни HTML, ни CSS не развиваются независимо от WebAPI, предоставляемого через JS. Это одна экосистема, где все глубоко интегрировано.
Еще у Паскаля было: "Письмо это вышло более длинным только потому, что у меня не было времени написать короче". В общем, это просто проблема оптимизации, которая обычно не решается за 2-3 итерации. За это время можно даже не успеть понять, что конкретно следует оптимизировать и в ущерб чему.
Полнота по Тьюрингу - это математическое понятие, не более того. Связку HTML+CSS тоже можно считать тьюринг-полной.
Из примера так и не понял почему одно лучше другого. Для меня выглядят как инструменты для решения немного разных задач. По крайней мере, я обычно разделяю задачи построения лейаута и передачи данных. Иногда эти задачи, конечно, тесно сплетаются, взять например реактивные формы, или таблицы из cdk и прочее. Но такой декларативный подход далеко не всегда уместен, и зачастую сложнее в реализации и поддержке (тут можно обратиться к исходникам тех же форм и таблиц).
upd: заглянул в документацию primeng, там для кнопки можно передать и различные виды темплейтов: https://primeng.org/button#template , https://primeng.org/button#api.button.templates , то есть поле label не обязательное.
В Ваших примерах, количество строк на таком объеме сильно зависит от стиля написания кода, что как бы не совсем объективное сравнение.
Правда одно из существенных отличий в этих примерах я вижу в том как объявляются шаблоны. Метод
renderв Lit обладает контекстомthisи следовательно для него будет работать типизация, подсказки редактора, линтеры и все прочее. Помимо этого, это также снимает сразу множество вопросов по композиции шаблонов.Для шаблонов в Symbiote без какого-то дополнительного туллинга, как у того же angular, может стать больно. И совсем не очевидно как составлять сложные компоненты, с условиями, списками и т. д. То есть порог входа как-будто становится сильно больше чем у Lit. Но тут вопрос конечно в дизайне, и в том какую проблему этим решали.
Но это так, просто мнение после первого взгляда. В целом спасибо за статью, было интересно ознакомиться.
На сайте Lit, сразу же на главной странице есть пример с декораторами. Что по ощущениям, должно сильно снижать количество бойлерплейта в подобных примерах.
Это особенность чисел с плавающей запятой.
Касательно равенства этих значений в js
Хотя возможно это особенность V8. Вообще нас еще на первом курсе учили, что довольно опасно проверять на равенство числа с плавающей запятой, независимо от языка.
https://floating-point-gui.de/errors/comparison/
017- это 15, так как с префиксом 0 записываются числа в восьмеричной системе.Number("017")- это 17, так как по правилам приведения типов, 0 в начале строки не учитывается.018- это 18, так как такая запись не может быть восьмеричной,Number("018")- так же 18, по правилам приведения типов.В данном примере все конвертируется одинаково. Проблема в том, что используется устаревший синтаксис. То есть дело не том, что авторы языка не видят в этом проблемы, просто ничего не могут с этим сделать, чтобы не сломать разом всю обратную совместимость.
Достаточно просто ознакомиться с синтаксисом и правилами приведения типов.
Или включить строгий режим и не использовать устаревшие конструкции.
Про пункт отличия типов и интерфейсов
Если речь про
implements, то типы могут быть реализованы в виде класса с некоторыми ограничениями.Объединение интерфейсов ничем не отличается от объединения типов, но на выходе, да, получится тип, вместо интерфейса.
Ничто не мешает объявить метод внутри типа.
Касательно наследования и расширения, из данного описания как-будто это суть одного и того же:
FooрасширяетBarBarнаследуетFooНо как и в случае с классами, интерфейс может быть расширен типом или унаследован от типа, с некоторыми ограничениями. Примеры.
В основное отличие я бы выделил возможность расширения одного и того же интерфейса, за счет множественного объявления. А дальше уже начинаются различные тонкости.
Не знаю про всех, для себя покупал чтобы видеть приятную картинку на комфортном расстоянии для глаз.
Но если говорить в целом, моя мысль скорее заключалась в том, что нет такой категории людей, как пользователи операционной системы для персональных компьютеров, которая не пересекалась бы с пользователями других систем и других устройств. Чтобы интерфейс подходил как можно большему количеству людей, а особенно новым пользователям, необходимо учитывать опыт других систем и устройств. И так как мир вокруг не стоит на месте, отсюда и процесс изменений в дизайне, а вовсе не из-за тайного заговора дизайнеров. И это не говоря про то, что различные системы сами постоянно меняются, что может требовать адаптации старого интерфейса, под новые возможности.
Меняются размеры экранов, способы ввода, да и в целом персональные устройства. Что является привычным интерфейсом для одних, для других оказывается незнакомым и неудобным.
Понял. В таком случае есть стандартный принтер для печати в файл, но вроде как начиная только с win 10. До этого подобный принтер например появлялся после установки Adobe Reader. Короче в любом случае выглядит как пустяковая проблема.
Да любые браузеры уже очень давно умеют открывать и соответственно распечатывать PDF.
Для меня лучший вариант, когда можно выполнить необходимое действие нажатием одной или нескольких клавиш. И для себя я вообще не ощутил каких-то изменений в привычных паттернах, после обновления до 11.
Но вот попробуйте объяснить поколению, которое с детства привыкло пользоваться тачскрином и видеть те же настройки чего-угодно в виде вложенных списков, с возможностью поиска по ним, что лучший вариант это оказывается иконки, и многоуровневые окна, в которых ты вряд ли найдешь нужный переключатель без гугла.
Слишком сложно как по мне. Я для себя написал небольшой скрипт для Autohotkey, чтобы запускать терминал по F1. Хотя там в какой-то момент добавили и нативную поддержку такого режима открытия.
Что-то я вижу в этом некоторое противоречие.
Если честно, практически незнаком с go, и как там считают потребление горутин, но в event-loop также есть свои накладные расходы на описание структуры задач, хранение их в очереди, на запуск и прочее. При этом libuv может обрабатывать задачи только в одном потоке, а Go этим не ограничен. Что эффективнее в плане накладных расходов: одна задача в очереди event-loop или одна горутина - для меня лично вопрос открытый.
Впрочем я вообще вел к тому, что асинхронный ввод-вывод, не является какой-то особенностью ноды или nginx. Нода является очень простым и удобным инструментом для создания эффективных веб-сервисов, которые не требуют особых вычислений, а например только гоняют данные из базы и обратно. Но нода это не про эффективное распределение нагрузки и параллельные вычисления, так как у нее практически нет для этого инструментов. Так что это просто очевидный ее минус, но опять же в контексте проектов, где это требуется. И тут я согласен с автором треда, что подобный бенчмарк практически бессмысленен.
В этом event-loop и содержится проблема, так как он блокируется на время исполнения JS. А для исполнения JS требуется интерпретатор и вот это все. Хоть сокеты в тредпуле и продолжат считываться и записываться в это время, код на JS все равно остается узким местом в плане производительности и распределения нагрузки.
Касательно спавна потоков, смотри epoll для линукса, или другие реализации неблокирующего ввода-вывода для других систем. Это не изобретение node, или nginx, а то что они просто используют, как и все остальные представленные веб-серверы, на сколько я понимаю.
Простая форма для этого подойдет.
Помимо корс заголовков, на сколько я помню сейчас в браузерах по умолчанию выставляется SameSite атрибут у куки. Но сложно спорить с Вашим утверждением, конечно. Однако правильная настройка безопасности, включая шифрование, CORS и CSP, и экранирование пользовательских данных, позволяет обезопасить, на сколько это возможно, всех пользователей сайта для стандартных настроек веб-браузера. И это гораздо важнее с точки зрения бизнеса, чем думать о паре чудиках, которым по каким-то причинам есть дело до отключения JS на странице. Я к тому, что аргумент с безопасностью в пользу выбора этого инструмента очень слабый, по крайней мере в существующей реальности.
upd. Сорри, не заметил сообщение выше
Для CSRF атак вообще не имеет значение наличие или отсутствие JS, плюс все современные браузеры умеют работать с
Access-Control-Allow-*заголовками. Да и ответственность, за возможность проведения таких атак, в любом случае лежит на беке.По XSS, при рендере документа на беке, точно также, придется специальными средствами санитайзить пользовательские данные. Потому что для 99.9% пользователей веб-браузеров NoScript - это какое ругательство. Помимо этого у бека есть другие возможности, накладывать ограничения, предотвращающие различные сценарии подобных атак, например CSP.
Я могу согласится, с тем что JS, может предоставить дополнительный вектор атак, нацеленных именно на сам веб-браузер и операционку пользователя, но этому также подвержены любые другие технологии. А из того, что перечислено, это просто перекладывание ответственности с одних веб-разработчиков, на других, что никак не влияет на безопасность технологии.
Думаю в появлении метода
querySelector, jQuery сыграл не последнюю роль. Наверняка jQuery также оказал свое влияние и на ряд других элементов стандартного WebAPI. Да даже банально в консоли отладки можно сделать вызов$("my-selector")с ожидаемым результатом и без подключения jQuery. Это конечно не встраивание в чистом виде, но логичное предоставление стандартных инструментов для тех практик, что приживаются в сообществе.Если честно, вообще не понимаю этот тезис. Для 90-х годов, возможно, такие рассуждения и имели смысл, то есть когда только формировалось какое-то представление о дальнейшем развитии данных технологий. Но в современном мире ни HTML, ни CSS не развиваются независимо от WebAPI, предоставляемого через JS. Это одна экосистема, где все глубоко интегрировано.