Это не нужно бизнесу - задача бизнеса, чтобы потребитель покупал. И покупал часто. Вы правильно отметили, что надёжная вещь теперь не требуется; нужно, чтобы она сломалась и потребитель купил снова.
1) пункт наверное разработчики банковских интерфейсов на вооружение взяли. Ну ладно календарь в экран не лезет, можно масштабом спастись, в консоли куча нотисов и ошибок, так ещё и выкладывают токен.
4) не понял - там где уместно использовать ООП, так и с функциональным, иногда не имеет смысла лишние объекты создавать, если функция используется редко и в одном сегменте; в чём то перекликается с п 5)
А вот вопрос - ведь многие в приведённых примерах, используют всякие библиотеки, React, Angular и прочую лабуду. Заметил, что многие клиентские интерфейсы буть то почта, интернет-банк, всякие интернет магазины, в последнее время намного тормознутее стали. А если глянуть консоль, мама дорогая, как правило куча ошибок, предупреждений и т.д.
Если разработчики не утруждаться, чтобы убрать хотя бы ошибки, то уж точно не "надорвутся", оптимизируя вес и быстродействия своих говноподелий
Долго ж рожали... Наконец-то сделали
Это не нужно бизнесу - задача бизнеса, чтобы потребитель покупал. И покупал часто. Вы правильно отметили, что надёжная вещь теперь не требуется; нужно, чтобы она сломалась и потребитель купил снова.
Интересно, кому понадобится выводить в DOM и потом работать с лямом строк?
Кое-как работает, со сбоями. В общем пока не починили
А вот если будет на фронте куча генераторов, таких, как описал автор, насколько ресурсоёмкие такие бесконечные циклы?
Одно дело на байт-коде вертеть опросы портов, а тут высокоуровневый язык...
А почему 100 итераций? Есть какое-то логичное объяснение или просто ткнули в круглую цифру?
А что разработчики вообще разучились в pdo и хотя бы middle уровень sql запросов?
Да уж, скоро no-code во всей красе выплюнется
Согласен с коллегами выше, хранить и пользоваться лучше временной меткой UTC. Только показать в нужном формате.
Разницы поудобнее наверное юзать.
Ооо, это единственный стоящий комментарий.
P.S. почему их кличут фреймворками? Всё-таки это библиотеки больше напоминают
"нужно встроить форму регистрации" и для этого городить?
Неужели на нативном так трудно писать, что надо кучу д...ма к web-приложению тащить.
А забирать ClickHouse быстрее чем из реляционной БД? Тогда уж Redis лучше
Более-менее правдоподобно, за исключением:
1) пункт наверное разработчики банковских интерфейсов на вооружение взяли. Ну ладно календарь в экран не лезет, можно масштабом спастись, в консоли куча нотисов и ошибок, так ещё и выкладывают токен.
4) не понял - там где уместно использовать ООП, так и с функциональным, иногда не имеет смысла лишние объекты создавать, если функция используется редко и в одном сегменте; в чём то перекликается с п 5)
А вот вопрос - ведь многие в приведённых примерах, используют всякие библиотеки, React, Angular и прочую лабуду. Заметил, что многие клиентские интерфейсы буть то почта, интернет-банк, всякие интернет магазины, в последнее время намного тормознутее стали. А если глянуть консоль, мама дорогая, как правило куча ошибок, предупреждений и т.д.
Если разработчики не утруждаться, чтобы убрать хотя бы ошибки, то уж точно не "надорвутся", оптимизируя вес и быстродействия своих говноподелий
Если бы привели примеры, как использовать "улучшения", было бы много эффективнее подача Вашего материала.
Ну и тернарный оператор, + и ~~ точно не улучшают читабельность кода
Снимаю шляпу. Удачи Вам
Я думаю ТС имел ввиду не "человек", а специалиста в области биотехнологии
Ну наконец-то человеческое объяснение, а ни эти мамкины кодеры чушь понаписали. Жаль не могу + поставить.
Почему клик в браузере будет медленнее, чем клик, обработанный через фреймворк?
Пыхом парсить?
тоже не вижу графиков. А есть сравнение с нативным js?