Ну, у меня в приоритетах веб-приложения, включая SPA/PWA. Поэтому только JS, только хардкор!!1 :)
А по поводу обратной совместимости у меня несколько другое мнение (см. последний пункт в "С лупой на слона"). Так тоже иногда бывает принято, в других сообществах. Например, на программном уровне Magento 2 и Magento 1 - две разные Вселенные, а с точки зрения бизнес-функций - эволюция одной ¯\_(ツ)_/¯
Если что, то и на чистом JS можно написать функцию, устойчивую к изменению сигнатуры метода - с использованием декомпозиции входных-выходных аргументов:
function fn({a = 1, b = 'text', c = true}) {
const res = {};
// do some work
return res;
}
В принципе, годная статья, если абстрагироваться непосредственно от Clojure, а держать в фокусе идею "неразрушающего рефакторинга". Позеленил.
На хабре есть масса ценных комментариев с экспертным мнением
Судя по этой оценке, вы оперируете двоичной логикой - ценный комментарий и не ценный. Можете назвать это качественной оценкой, но в вашем случае я без проблем свёл её к количественной.
О том, что истина в спорах на Хабре не рождается. Что Хабр - это про времяпровождение. Что я могу в разных постах с разными оппонентами аргументированно или не очень отстаивать противоречащие друг другу точки зрения (яйцо нужно разбивать с тупого конца или с острого). Просто потому, что спор - это про ранжирование особей в стае, а не про познание. Про познание - это Web 1.0, вернее даже его предтеча - академическая среда.
Завести "в нейтральном ключе" разговор с чат-ботом "Submissive Schoolgirl", а потом удивляться, что этот бот "описывает действия сексуального характера"?! Ну, это как зайти в помещение под вывеской "Бордель" и громко возмущаться, что ты попал не в булошную.
Думаю, его просто кто-то застукал за общением с "Покорной Школьницей", вот ему и пришлось лепить отмазку - типа, он тут "по работе". Ловкий, чертяка!
Да, занятная штука. Прогнал по своей di-библиотеке - документации по объёму получилось даже в разы больше, чем было кода в библиотеке. Рассматривает взаимосвязи компонентов с различных точек зрения, повторяя по несколько раз одни и те же моменты под разными углами. На первый взгляд даже похоже на правду и довольно пОлно. Впечатлило.
Хотя, с другими библиотеками мне было бы сложно разбираться по такой документации - ощущение, что ходишь по кругу вокруг да около. Но платформа предоставляет возможность задавать вопросы по репозиторию. Думаю, что этот режим будет более востребован, чем просто чтение нагенерённой документации. Если эта штука ещё и фрагменты кода по запросу будет генерировать - вообще мощная вещь. Только цены не нашёл, а это слегка напрягает - стрёмно не быть в курсе своих возможностей, ждать, когда LLM тебе в ответ скажет, что твои лимиты на сегодня исчерпаны.
команда Lufthansa извлекла и осмотрела повреждённый iPad.
Ключевое слово - "повреждённый". Походу, чел или стюарды пытались его достать, что могло привести к повреждениям устройства. После чего и могло быть принято решение "лететь на ближайшую базу". Уверен, что без попыток извлечь застрявший ipad не обошлось.
К сожалению, я не понимаю, что значат эти цифры, но признаю, что выглядит красиво. Поэтому я взял код из вашего теста, немного сократил его и попросил GPT-чат добавить в него измерения времени:
'use strict';
class Bar {
a = 1;
b = 2;
}
class Foo {
a = 1;
b = 2;
constructor() {
return Object.freeze(this);
}
}
const ITERATIONS = 1000000;
console.time('Bar');
for (let i = 0; i < ITERATIONS; i++) new Bar();
console.timeEnd('Bar');
console.time('Foo');
for (let i = 0; i < ITERATIONS; i++) new Foo();
console.timeEnd('Foo');
console.time('Freeze(Bar)');
for (let i = 0; i < ITERATIONS; i++) Object.freeze(new Bar());
console.timeEnd('Freeze(Bar)');
В таком виде код можно гонять в любом окружении (node или браузер). Он даёт некоторое понимание о "стоимости" использования freeze при создании объектов. Я, правда, увеличил кол-во итераций с 10К до 1М, чтобы чуть лучше заметно было различие в числах (на 10К особых различий и не было).
Вот результат, время в миллисекундах на 1 миллион итераций:
По моему очевидно, что создание объекта + его «заморозка», не может быть быстрее, или одинаково по скорости чем просто создание объекта.
Вы абсолютно правы и я не собираюсь спорить с очевидным - создание и "заморозка" объекта однозначно "дороже" по времени, чем просто создание. Примерно на порядок.
Но в абсолютных величинах это составляет меньше 200 миллисекунд на 1 миллион созданных объектов в Firefox'е (самом "тормозном" из трёх).
Может ли проект позволить себе "потерять" 200 миллисекунд на заморозку созданных в нём 1М объектов или нет - зависит от проекта. В моих проектах кол-во функциональных объектов значительно ниже 10К, не говоря уже об 1М. Я могу себе позволить потерять десяток миллисекунд при запуске приложения (хотя на практике деле это число будет ещё меньше - я просто беру с "запасом").
Кстати, а почему ваши тесты на сайте perf.js.hyoo.ru занимают настолько много времени (в секундах!) при кол-ве итераций всего 10К? Что измеряет этот стенд? Я - человек со стороны, мне, например, не понятно, что всё это значит и как настраивается:
Я ж говорю, зависит от проекта. В моём случае с заморозкой даже быстрее сервер стартовал, чем без. Первый запуск из статистики выкидывал, как разогревающий. Брал со второго по четвёртый. Может быть нагрузка на ноуте менялась. Но для моего случая заморозка Контейнером функциональных объектов при старте приложения вообще не существенна:
В общем, пока final внедрят, буду пользоваться freeze'ом, а потом посмотрим...
На всякий случай уточняю, что "морозятся" не все объекты в приложении, а только те, которые создаются Контейнером (функциональные). Например, фабрики DTO. А заморозка самих DTO - на усмотрение фабрик. В принципе, если вы создали DTO при помощи доверенной фабрики, провели его обработку через доверенные функции, а потом сериализовали, чтобы выплюнуть наружу, то нет смысла замораживать "расходники" (данные).
А про временные затраты лучше говорить с цифрами в руках. "Достаточное" и "существенное" - это из области балета.
Вы смотрели деградацию производительности после внедрения этого решения?
Да, разумеется. У меня сервер приложения без "заморозки" в Контейнере поднимался полторы-две секунды. С "заморозкой" - тоже полторы-две секунды. Значимой деградации не замечено.
Если серьёзно, то замораживаются объекты при их создании Контейнером. Я разделяю данные и обработчики. Контейнер создаёт обработчики (в том числе и фабрики DTO). Замораживаются как раз таки объекты-обработчики. Они написаны в функциональном стиле и на всё приложение нужны в одном-единственном экземпляре. Цена вопроса - 100-200-1000-... "заморозок" при старте приложения (зависит от кол-ва функциональных объектов в приложении).
Стоит ли платить эту цену, чтобы кто-то не сделал такой финт?
Если ваше приложение высоконагруженное и каждая микросекунда на учёте - то нет. А если вы работаете в недружественной среде (браузерное приложение - уже недружественная среда, кто его знает, чего в DOM натолкали и чего в globals переопределили), то "морозить" объекты - уже не такая плохая идея.
Я "вырос" из Magento, а там в одном приложении собирались плагины от полутора десятков разрабов. У меня профдеформация :)
А если бы вы в коде сделали так:
const foo = new Foo();
Object.freeze(foo);
то после:
Object.defineProperty(foo, 'bar', {...});
получили это:
Object.defineProperty(foo, 'bar', {
^
TypeError: Cannot define property bar, object is not extensible
at Function.defineProperty (<anonymous>)
...
Заморозка объекта на этапе его создания даёт некоторую гарантию, что вы имеете дело с вашим собственным кодом, а не с кодом других хороших людей.
Насколько это существенно для вашего проекта - зависит от вашего проекта.
"Могут ли машины быть сознательными?" - вопрос из области "Сколько ангелов может танцевать на булавочной головке?" Мы не можем дать определение ни "сознанию", ни "ангелу".
Если LLM обучали на книгах де Сада и Захера-Мазоха, то какое у неё будет "осознание благополучия" - отсутствие наказания или его наличие? Или каждый увидит в модели своё отражение? Будет ли модель вообще рефлексировать без стороннего наблюдателя?
С одной стороны, я согласен с Майком Куком и Стивеном Каспером, но с другой - аплодирую стоя Кайлу Фишу. Чел решительно и амбициозно стремится к финансовому благополучию в этом мире.
Я правильно понимаю, что не все SPA отлично индексируются? Что для успешной индексации в поисковиках им нужно соответствовать некоторым требованиям?
Так-то демка прекрасно работает в режиме SPA. Только не индексируется в Гугле дальше первой страницы.
Да, вы правы когда говорите, что у меня есть возможность сделать sitemap и использовать прочие трюки (типа явного добавления в DOM ссылок навигатора). Но развивая эту мысль дальше, мы можем вдруг обнаружить что при создании SPA мы руководствуемся ценностями SSR.
Электронный магазин есть смысл сразу делать SSR-ориентированным, пусть даже там каждая страница будет SPA и будет генерироваться на серверной стороне "на лету" из данных в базе. А вот банковское приложение можно делать как SPA без оглядки на поисковики.
Я когда-то, примерно в 23-м году, делал PWA (SPA на стероидах) - https://aid.demo.wiredgeese.com/ Там было несколько режимов работы ("страниц"), переход к которым осуществлялся через навигатор в правом верхнем углу:
Вот так выглядит это веб-приложение сейчас в Гугле:
Вы абсолютно правы, что SPA отлично индексируются. Но и моё предположение, что дальше первой страницы поисковики не копают, тоже неплохо подтверждается на практике.
Вы противопоставляете ИИ и ЕИ :(
А что бы вы написали в статье "ChatGPT & Гик. Насколько AI увеличивает производительность опытного верстальщика?"
Ну, это моя точка зрения. Хотя я понимаю, что значит "сломанная обратная совместимость" - тот ещё геморрой.
Ну, у меня в приоритетах веб-приложения, включая SPA/PWA. Поэтому только JS, только хардкор!!1 :)
А по поводу обратной совместимости у меня несколько другое мнение (см. последний пункт в "С лупой на слона"). Так тоже иногда бывает принято, в других сообществах. Например, на программном уровне Magento 2 и Magento 1 - две разные Вселенные, а с точки зрения бизнес-функций - эволюция одной ¯\_(ツ)_/¯
Каждый видит в статье то, что может увидеть - в меру своей "испорченности". Я, например, увидел пересечение с моими публикациями "Отвлеченно о входных/выходных аргументах" и "Так в чём же конечная цель программирования?".
Если что, то и на чистом JS можно написать функцию, устойчивую к изменению сигнатуры метода - с использованием декомпозиции входных-выходных аргументов:
В принципе, годная статья, если абстрагироваться непосредственно от Clojure, а держать в фокусе идею "неразрушающего рефакторинга". Позеленил.
Хотел бы поспорить, но тут сложно. Разве что можно приравнять ценность одного к другому и вспомнить про "аксиому Эскобара".
Не затруднит. Вот:
Судя по этой оценке, вы оперируете двоичной логикой - ценный комментарий и не ценный. Можете назвать это качественной оценкой, но в вашем случае я без проблем свёл её к количественной.
Всеми. На Хабре. На порядок.
Я ж говорю, дискутировать на Хабре - проще пареной репы. И в конце-концов, всегда можно уйти в закат по-английски :)
О том, что истина в спорах на Хабре не рождается. Что Хабр - это про времяпровождение. Что я могу в разных постах с разными оппонентами аргументированно или не очень отстаивать противоречащие друг другу точки зрения (яйцо нужно разбивать с тупого конца или с острого). Просто потому, что спор - это про ранжирование особей в стае, а не про познание. Про познание - это Web 1.0, вернее даже его предтеча - академическая среда.
Завести "в нейтральном ключе" разговор с чат-ботом "Submissive Schoolgirl", а потом удивляться, что этот бот "описывает действия сексуального характера"?! Ну, это как зайти в помещение под вывеской "Бордель" и громко возмущаться, что ты попал не в булошную.
Думаю, его просто кто-то застукал за общением с "Покорной Школьницей", вот ему и пришлось лепить отмазку - типа, он тут "по работе". Ловкий, чертяка!
Да, занятная штука. Прогнал по своей di-библиотеке - документации по объёму получилось даже в разы больше, чем было кода в библиотеке. Рассматривает взаимосвязи компонентов с различных точек зрения, повторяя по несколько раз одни и те же моменты под разными углами. На первый взгляд даже похоже на правду и довольно пОлно. Впечатлило.
Хотя, с другими библиотеками мне было бы сложно разбираться по такой документации - ощущение, что ходишь по кругу вокруг да около. Но платформа предоставляет возможность задавать вопросы по репозиторию. Думаю, что этот режим будет более востребован, чем просто чтение нагенерённой документации. Если эта штука ещё и фрагменты кода по запросу будет генерировать - вообще мощная вещь. Только цены не нашёл, а это слегка напрягает - стрёмно не быть в курсе своих возможностей, ждать, когда LLM тебе в ответ скажет, что твои лимиты на сегодня исчерпаны.
Ключевое слово - "повреждённый". Походу, чел или стюарды пытались его достать, что могло привести к повреждениям устройства. После чего и могло быть принято решение "лететь на ближайшую базу". Уверен, что без попыток извлечь застрявший ipad не обошлось.
К сожалению, я не понимаю, что значат эти цифры, но признаю, что выглядит красиво. Поэтому я взял код из вашего теста, немного сократил его и попросил GPT-чат добавить в него измерения времени:
В таком виде код можно гонять в любом окружении (node или браузер). Он даёт некоторое понимание о "стоимости" использования
freezeпри создании объектов. Я, правда, увеличил кол-во итераций с 10К до 1М, чтобы чуть лучше заметно было различие в числах (на 10К особых различий и не было).Вот результат, время в миллисекундах на 1 миллион итераций:
Вы абсолютно правы и я не собираюсь спорить с очевидным - создание и "заморозка" объекта однозначно "дороже" по времени, чем просто создание. Примерно на порядок.
Но в абсолютных величинах это составляет меньше 200 миллисекунд на 1 миллион созданных объектов в Firefox'е (самом "тормозном" из трёх).
Может ли проект позволить себе "потерять" 200 миллисекунд на заморозку созданных в нём 1М объектов или нет - зависит от проекта. В моих проектах кол-во функциональных объектов значительно ниже 10К, не говоря уже об 1М. Я могу себе позволить потерять десяток миллисекунд при запуске приложения (хотя на практике деле это число будет ещё меньше - я просто беру с "запасом").
Кстати, а почему ваши тесты на сайте perf.js.hyoo.ru занимают настолько много времени (в секундах!) при кол-ве итераций всего 10К? Что измеряет этот стенд? Я - человек со стороны, мне, например, не понятно, что всё это значит и как настраивается:
Я ж говорю, зависит от проекта. В моём случае с заморозкой даже быстрее сервер стартовал, чем без. Первый запуск из статистики выкидывал, как разогревающий. Брал со второго по четвёртый. Может быть нагрузка на ноуте менялась. Но для моего случая заморозка Контейнером функциональных объектов при старте приложения вообще не существенна:
В общем, пока
finalвнедрят, буду пользоватьсяfreeze'ом, а потом посмотрим...На всякий случай уточняю, что "морозятся" не все объекты в приложении, а только те, которые создаются Контейнером (функциональные). Например, фабрики DTO. А заморозка самих DTO - на усмотрение фабрик. В принципе, если вы создали DTO при помощи доверенной фабрики, провели его обработку через доверенные функции, а потом сериализовали, чтобы выплюнуть наружу, то нет смысла замораживать "расходники" (данные).
А про временные затраты лучше говорить с цифрами в руках. "Достаточное" и "существенное" - это из области балета.
Насколько медленная?
Да, разумеется. У меня сервер приложения без "заморозки" в Контейнере поднимался полторы-две секунды. С "заморозкой" - тоже полторы-две секунды. Значимой деградации не замечено.
Если серьёзно, то замораживаются объекты при их создании Контейнером. Я разделяю данные и обработчики. Контейнер создаёт обработчики (в том числе и фабрики DTO). Замораживаются как раз таки объекты-обработчики. Они написаны в функциональном стиле и на всё приложение нужны в одном-единственном экземпляре. Цена вопроса - 100-200-1000-... "заморозок" при старте приложения (зависит от кол-ва функциональных объектов в приложении).
Стоит ли платить эту цену, чтобы кто-то не сделал такой финт?
Если ваше приложение высоконагруженное и каждая микросекунда на учёте - то нет. А если вы работаете в недружественной среде (браузерное приложение - уже недружественная среда, кто его знает, чего в DOM натолкали и чего в globals переопределили), то "морозить" объекты - уже не такая плохая идея.
Я "вырос" из Magento, а там в одном приложении собирались плагины от полутора десятков разрабов. У меня профдеформация :)
А если бы вы в коде сделали так:
то после:
получили это:
Заморозка объекта на этапе его создания даёт некоторую гарантию, что вы имеете дело с вашим собственным кодом, а не с кодом других хороших людей.
Насколько это существенно для вашего проекта - зависит от вашего проекта.
del
"Могут ли машины быть сознательными?" - вопрос из области "Сколько ангелов может танцевать на булавочной головке?" Мы не можем дать определение ни "сознанию", ни "ангелу".
Если LLM обучали на книгах де Сада и Захера-Мазоха, то какое у неё будет "осознание благополучия" - отсутствие наказания или его наличие? Или каждый увидит в модели своё отражение? Будет ли модель вообще рефлексировать без стороннего наблюдателя?
С одной стороны, я согласен с Майком Куком и Стивеном Каспером, но с другой - аплодирую стоя Кайлу Фишу. Чел решительно и амбициозно стремится к финансовому благополучию в этом мире.
Развитие движется по спирали. Не надо откатываться назад, лезьте вперёд и вверх. SPA & SSR вполне могут сосуществовать вместе. И даже в CDN.
Я правильно понимаю, что не все SPA отлично индексируются? Что для успешной индексации в поисковиках им нужно соответствовать некоторым требованиям?
Так-то демка прекрасно работает в режиме SPA. Только не индексируется в Гугле дальше первой страницы.
Да, вы правы когда говорите, что у меня есть возможность сделать sitemap и использовать прочие трюки (типа явного добавления в DOM ссылок навигатора). Но развивая эту мысль дальше, мы можем вдруг обнаружить что при создании SPA мы руководствуемся ценностями SSR.
Электронный магазин есть смысл сразу делать SSR-ориентированным, пусть даже там каждая страница будет SPA и будет генерироваться на серверной стороне "на лету" из данных в базе. А вот банковское приложение можно делать как SPA без оглядки на поисковики.
Именно эту мысль я и пытался донести изначально.
Я когда-то, примерно в 23-м году, делал PWA (SPA на стероидах) - https://aid.demo.wiredgeese.com/ Там было несколько режимов работы ("страниц"), переход к которым осуществлялся через навигатор в правом верхнем углу:
Вот так выглядит это веб-приложение сейчас в Гугле:
Вы абсолютно правы, что SPA отлично индексируются. Но и моё предположение, что дальше первой страницы поисковики не копают, тоже неплохо подтверждается на практике.
Математика умеет в такое: