Основные плюсы React это: Virtual DOM... Такой подход работает быстрее, потому как не включает в себя все тяжеловесные части реального DOM
Я бы не записывал в плюсы, это просто реализация поиска изменений для оптимизации вызова DOM API. Например, в Angular его нет и там реактивные алгоритмы справляются в некоторых кейсах даже быстрее.
Классовые компоненты медленнее, из-за большого количества встроенных методов
Это самое большое заблуждение, классовые компоненты не могут быть медленнее функциональных априори, кроме одного случая, о нём в конце. Функциональный компонент по сути является render функцией, которая будет выполнятся на каждом рендере, а значит и всё внутри будет заново аллоцироваться. Для избежания этого мы используем хуки - useState, useMemo, useCallback, а точнее для кэширования значений. Какие подводные камни на примере useCallback. Появляется оверхед в виде массива, который используется для кэширования функций - индекс (порядок вызова хука, из-за чего и нельзя загонять под условные операторы), сама функция, массив зависимостей. На каждом рендере появляется оверхед для сравнения массивов зависимостей, а самое главное, сама функция в любом случае аллоцируется, а значит занимает память и деаллоцируется с помощью GC (хоть и в первом поколении). В классовом компоненте вместо того, чтобы создавать стрелочные функции в render методе, мы можем сделать их методами класса, а значит у нас пропадает надобность их пересоздавать, так как мы имеем доступ к актуальному полю state, и соответственно у нас пропадает надобность их кэшировать, так как они не пересоздаются. В принципе любой бенчмарк покажет вам, что классовые компоненты более производительны, чем функциональные компоненты. Единственное исключение - если в функциональном компоненте не используются хуки.
Странно, там, где я сейчас работаю, компания сама предлагала на время испыталки поработать в формате ГПХ, а потом уже если всё хорошо, то заключить трудовой договор.
Интересный факт, атаке подвергся буквально спустя 30 минут после деплоя
Это вообще классика, IP популярных VPS-провайдеров в автоматическом режиме пробиваются ботами на популярные уязвимости, и понятное дело, что злоумышленниками.
Но отмывание денег это легализация средств, полученных преступным путём. То есть по сути это способ СОКРЫТИЯ преступления - кражи, продажи запрещённых веществ, предпринимательства без государственной регистрации и т.д. И дальше мы приходим к тому, а какими средствами собственно происходит легализация средств. Этому способствуют обычно другие преступления, например, подделка чеков, документов. Но если говорить в контексте криптовалюты, то тут нет преступления, в ходе которого произошёл отмыв денег, потому что переводить крипту никто не запрещает. В большинстве юрисдикций, нет ответственности за сокрытия преступления, как и нет ответственности за пользование краденных средств. Поэтому законы об отмывании денег - это лишь инструмент репрессий от государства, когда они не могут доказать преступления, из-за которых совершили отмыв и с помощью которых отмыли деньги. Само по себе отмывание денег не является преступлением против населения. Да и легализованные средства идут дальше в налоговый оборот, что в идеальной картине мира улучшает качество жизни населения, чем если б эти деньги просто где-то лежали или были в чёрном обороте.
Если государство так хочет следить за происхождением криптовалютных средств, пусть делает очередной реестр (человек -> кошелёк) и делает закон об обязательной регистрации в нём при создании кошелька. Иначе это маразм в виде - раз 100% киберприступлений производиться с помощью ПК, давайте посадим всех производителей ПК, ведь они не обеспечили идентификацию и проверку действий пользователя на законность. С приведённым вами примером оружия, государство регулирует эту сферу в виде лицензий на создание, распространение и тд. И что-то таких производителей не сажают за то, что их клиенты продают оружие на чёрном рынке. И старый добрый пример с ножами, производители ножей не сажают за то, что большинство бытовых убийств совершенно их продукцией.
А какой вывод? Если государство хочет регулировать, пусть создаёт регуляцию, а сейчас пусть доказывает преступный умысел (привет, презумпция невиновности) и не сажает за то, что люди как-то не предусмотрели, что их продукция может использоваться для совершения преступления. Именно поэтому тут (и не только тут) в комментах у многих и полыхает. Этот прецедент даёт государству право посадить любого производителя, если его продуктом совершится преступление.
Да, это по сути клон GitHub/Gitlab, сделанный на их движке Forgejo. Якобы свободная альтернатива. Но проектов там мало, в основном порты/форки/зеркала и "серые" проекты (читы, хаки античитов и прочая муть).
MV, MVVM, MVC и прочее относятся только к Presentation слою в чистой архитектуре. Можете взять любую схему, которая на ваш взгляд удобнее, но сам по себе MV не является clean architecture
Идея неплоха, даже напоминает чем-то Slint, но на вряд ли сыщет большой популярности, так как не очень понятно, а какую проблему существующих HTML/CSS/JS ваш транспилятор решает.
Так в мире JavaScript тоже. Опять же если не брать фронтенд, то это в подавляющем большинстве - Node.js. Остальное, как я и писал - сырое или что-то специально для cloud решений, там в общем всё кастомное, в том числе и рантаймы Java попадаются.
Увы, но вы для красного словца довольно сильно передёргиваете несложные и известные факты в свою пользу. Это не есть хорошо. ))
Я не передёргиваю) А всего лишь даю понять, что если капнуть чуть глубже, ситуации похожи, чего автор статьи совсем не хочет видеть.
А продолжить вот этот вот список (Maven, Gradle...) сможете?
А помимо npm, yarn, pnpm тоже сможете? Автору и этого хватило.
К чему вы их упомянули рядом с Maven как будто это вещи одного порядка?
Не к Maven, а к Gradle, в котором конфигурации можно писать либо на Kotlin, либо на Groovy. Это не какой-нибудь JSON/XML по-быстрому выучить для конфигурации билда и зависимостей.
И то, как правило, если дисциплины на проекте нет и код ревью не делается достаточно профессионально.
То же правило действует и для проектов на JavaScript/TypeScript. Виновен ли в этом язык? Нет, конечно.
Любая Java VM полностью поддерживает спецификацию языка
У JavaScript тоже есть спецификация языка (ECMAScript) и её рантаймы поддерживают (точнее движки). Они реализуют разный API, это к спецификации языка не имеет никакого отношения.
Сколько времени делали поддержку GraalVM в Spring? Тоже небыстро. А если вы будете делать свой фреймворк, то вам тоже придётся озаботиться. Так и на кого это возлагать? На себя или мейнтенеров библиотек и фреймворков? Вопрос открытый.
Разные JDK реализуют стандарт по API, это конечно лучше, чем разный API на разных рантаймах JavaScript. Но эко-система JavaScript тоже потихоньку к этому идёт, пример этому - Web API. В этом плане просто язык помоложе будет, так как по сути с года 2012 начали его активно использовать вне браузеров, где кстати API довольно устойчив. И только относительно недавно начали создавать аналоги Node.js. Тот же молодой Bun пытается поддерживать API от Node.js в отличии от остальных (привет, Deno).
Случай с Java довольно уникален, потому что как не крути и не создавай комитеты, но она принадлежит Oracle. И без нужных откатов ничего вы не поделаете, достаточно вспомнить споры Oracle и Google по JVM/JDK в Android. Все просто бояться делать отличное. Либо будь добр реализовывай по стандарту или делай полностью своё. Но ведь если делать полностью своё и хоть капельку там будет похожего на стандарт, то Oracle нападёт на тебя с толпой юристов. И не у всех компаний есть столько денег на юристов, как у Google. А мы вообще-то любим free and open source, без него не будет развития, но с ним и приходит разнообразие в виде кучи библиотек, кучи разных рантаймов с разным API, что вам так не нравится.
То, что вы не встречались с проектами, которые работают (могут работать) только с yarn или pnpm, и не видите существенных отличий между ними, говорит о вашем опыте.
А я не говорил, что таких проектов нет, как и не говорил, что они ничем не отличаются от npm, не надо выдумывать. Я лишь сказал, что их некоторые используют за старые заслуги и что это редкость. npm за последние 10 лет очень сильно изменился, много оптимизаций произошло и всё благодаря сторонним пакетным менеджерам.
Столько поинтов про зоопарк, но у Java ситуация не лучше в этом плане. Maven, Gradle (Groovy, Kotlin). Пакетов эти тонны и в разных стилях. И если уж сравнивать кол-во зоопарков и велосипедов, то C++ точно победит в этом соревновании.
Не скажу за фронтенд, но бекенд вполне себе ок писать на node.js. Другие рантаймы либо слишком специфичны для каких-то cloud решений (но там в принципе обычно делают всё своё - базы, очереди, балансеры и пр), либо очень сырые - тот же bun. Для примера, в Java тоже есть несколько рантаймов, а кол-во SDK вообще тьма. Для C# тоже есть .NET Framework, .NET Core, Mono. Пакетные менеджеры - кто-то, конечно, использует по старым заслугам отличные от npm, но это редкость. Пакетов (библиотек) в Java/C#/C++/Python/Go и тд тоже много и на разные случаи жизни. Про стили кода странный поинт. В других ЯП ситуация та же, для этого собственно и придумали линтеры и разные гайды (опять таки вспоминаем C++). Языки с богатой семантикой часто предполагают, что одну задачу можно решить абсолютно по-разному, тут ситуация такая же, как и в Ruby/Python. Их вы как-то не затронули.
Вывод должен быть такой, что всё познаётся в детальном сравнении. Чем больше работаешь с технологией и делаешь больше разнообразных задач, тем больше замечаешь в ней минусы и недостатки, которые были скрыты под белизной хайпа или решения простых задач. Да бывает больно, но другие ЯП если и решат проблемы, то точно принесут новые. Выбирать язык надо с умом. А как именно на вряд ли кто-то скажет, всегда зависит от ситуаций. И в большинстве случаев, что знает команда, то используется.
Бабочка была действительно ужасной, настрадался с ней много: вечные залипания клавиш, иногда клавиши вообще выпадали.
А вот с тачбаром не соглашусь. Мне его очень не хватает. Да, он неудобен с точки зрения слепой печати, но он давал возможность не изучать многие горячие клавиши, потому что основные действия для конкретной программы отображались, и можно было просто посмотреть и тапнуть на нужное.
Я бы не записывал в плюсы, это просто реализация поиска изменений для оптимизации вызова DOM API. Например, в Angular его нет и там реактивные алгоритмы справляются в некоторых кейсах даже быстрее.
Это самое большое заблуждение, классовые компоненты не могут быть медленнее функциональных априори, кроме одного случая, о нём в конце. Функциональный компонент по сути является render функцией, которая будет выполнятся на каждом рендере, а значит и всё внутри будет заново аллоцироваться. Для избежания этого мы используем хуки - useState, useMemo, useCallback, а точнее для кэширования значений. Какие подводные камни на примере useCallback. Появляется оверхед в виде массива, который используется для кэширования функций - индекс (порядок вызова хука, из-за чего и нельзя загонять под условные операторы), сама функция, массив зависимостей. На каждом рендере появляется оверхед для сравнения массивов зависимостей, а самое главное, сама функция в любом случае аллоцируется, а значит занимает память и деаллоцируется с помощью GC (хоть и в первом поколении). В классовом компоненте вместо того, чтобы создавать стрелочные функции в render методе, мы можем сделать их методами класса, а значит у нас пропадает надобность их пересоздавать, так как мы имеем доступ к актуальному полю state, и соответственно у нас пропадает надобность их кэшировать, так как они не пересоздаются. В принципе любой бенчмарк покажет вам, что классовые компоненты более производительны, чем функциональные компоненты. Единственное исключение - если в функциональном компоненте не используются хуки.
Странно, там, где я сейчас работаю, компания сама предлагала на время испыталки поработать в формате ГПХ, а потом уже если всё хорошо, то заключить трудовой договор.
Это вообще классика, IP популярных VPS-провайдеров в автоматическом режиме пробиваются ботами на популярные уязвимости, и понятное дело, что злоумышленниками.
Но отмывание денег это легализация средств, полученных преступным путём. То есть по сути это способ СОКРЫТИЯ преступления - кражи, продажи запрещённых веществ, предпринимательства без государственной регистрации и т.д. И дальше мы приходим к тому, а какими средствами собственно происходит легализация средств. Этому способствуют обычно другие преступления, например, подделка чеков, документов. Но если говорить в контексте криптовалюты, то тут нет преступления, в ходе которого произошёл отмыв денег, потому что переводить крипту никто не запрещает. В большинстве юрисдикций, нет ответственности за сокрытия преступления, как и нет ответственности за пользование краденных средств. Поэтому законы об отмывании денег - это лишь инструмент репрессий от государства, когда они не могут доказать преступления, из-за которых совершили отмыв и с помощью которых отмыли деньги. Само по себе отмывание денег не является преступлением против населения. Да и легализованные средства идут дальше в налоговый оборот, что в идеальной картине мира улучшает качество жизни населения, чем если б эти деньги просто где-то лежали или были в чёрном обороте.
Если государство так хочет следить за происхождением криптовалютных средств, пусть делает очередной реестр (человек -> кошелёк) и делает закон об обязательной регистрации в нём при создании кошелька. Иначе это маразм в виде - раз 100% киберприступлений производиться с помощью ПК, давайте посадим всех производителей ПК, ведь они не обеспечили идентификацию и проверку действий пользователя на законность. С приведённым вами примером оружия, государство регулирует эту сферу в виде лицензий на создание, распространение и тд. И что-то таких производителей не сажают за то, что их клиенты продают оружие на чёрном рынке. И старый добрый пример с ножами, производители ножей не сажают за то, что большинство бытовых убийств совершенно их продукцией.
А какой вывод? Если государство хочет регулировать, пусть создаёт регуляцию, а сейчас пусть доказывает преступный умысел (привет, презумпция невиновности) и не сажает за то, что люди как-то не предусмотрели, что их продукция может использоваться для совершения преступления. Именно поэтому тут (и не только тут) в комментах у многих и полыхает. Этот прецедент даёт государству право посадить любого производителя, если его продуктом совершится преступление.
В документации написано, что она до сих пор EXPERIMENTAL
Kafka - это хорошо, а когда планируется допилить RabbitMQ?
Автор указал, что был webpack, а стал vite. Никаких подводных камней.
Все это понимают, кроме нанимающей стороны, которой нужно N лет опыта с M языком и с F стеком
Андерс Хейлсберг (создатель Delphi) возглавлял группу по созданию и проектированию C#, поэтому неплохой вариант - C# (Windows Forms).
Да, это по сути клон GitHub/Gitlab, сделанный на их движке Forgejo. Якобы свободная альтернатива. Но проектов там мало, в основном порты/форки/зеркала и "серые" проекты (читы, хаки античитов и прочая муть).
MV, MVVM, MVC и прочее относятся только к Presentation слою в чистой архитектуре. Можете взять любую схему, которая на ваш взгляд удобнее, но сам по себе MV не является clean architecture
Идея неплоха, даже напоминает чем-то Slint, но на вряд ли сыщет большой популярности, так как не очень понятно, а какую проблему существующих HTML/CSS/JS ваш транспилятор решает.
Так в мире JavaScript тоже. Опять же если не брать фронтенд, то это в подавляющем большинстве - Node.js. Остальное, как я и писал - сырое или что-то специально для cloud решений, там в общем всё кастомное, в том числе и рантаймы Java попадаются.
Я не передёргиваю) А всего лишь даю понять, что если капнуть чуть глубже, ситуации похожи, чего автор статьи совсем не хочет видеть.
А помимо npm, yarn, pnpm тоже сможете? Автору и этого хватило.
Не к Maven, а к Gradle, в котором конфигурации можно писать либо на Kotlin, либо на Groovy. Это не какой-нибудь JSON/XML по-быстрому выучить для конфигурации билда и зависимостей.
То же правило действует и для проектов на JavaScript/TypeScript. Виновен ли в этом язык? Нет, конечно.
Но в Java тоже есть анонимные функции с похожим синтаксисом. И даже есть анонимные классы. Чем вам не class expression?
Мне кажется, вы накидываете, только чтобы накидать. Но в суть не вникаете. И видимо плохо знаете Java, которую в противопоставление ставите.
У JavaScript тоже есть спецификация языка (ECMAScript) и её рантаймы поддерживают (точнее движки). Они реализуют разный API, это к спецификации языка не имеет никакого отношения.
Сколько времени делали поддержку GraalVM в Spring? Тоже небыстро. А если вы будете делать свой фреймворк, то вам тоже придётся озаботиться. Так и на кого это возлагать? На себя или мейнтенеров библиотек и фреймворков? Вопрос открытый.
Разные JDK реализуют стандарт по API, это конечно лучше, чем разный API на разных рантаймах JavaScript. Но эко-система JavaScript тоже потихоньку к этому идёт, пример этому - Web API. В этом плане просто язык помоложе будет, так как по сути с года 2012 начали его активно использовать вне браузеров, где кстати API довольно устойчив. И только относительно недавно начали создавать аналоги Node.js. Тот же молодой Bun пытается поддерживать API от Node.js в отличии от остальных (привет, Deno).
Случай с Java довольно уникален, потому что как не крути и не создавай комитеты, но она принадлежит Oracle. И без нужных откатов ничего вы не поделаете, достаточно вспомнить споры Oracle и Google по JVM/JDK в Android. Все просто бояться делать отличное. Либо будь добр реализовывай по стандарту или делай полностью своё. Но ведь если делать полностью своё и хоть капельку там будет похожего на стандарт, то Oracle нападёт на тебя с толпой юристов. И не у всех компаний есть столько денег на юристов, как у Google. А мы вообще-то любим free and open source, без него не будет развития, но с ним и приходит разнообразие в виде кучи библиотек, кучи разных рантаймов с разным API, что вам так не нравится.
А я не говорил, что таких проектов нет, как и не говорил, что они ничем не отличаются от npm, не надо выдумывать. Я лишь сказал, что их некоторые используют за старые заслуги и что это редкость. npm за последние 10 лет очень сильно изменился, много оптимизаций произошло и всё благодаря сторонним пакетным менеджерам.
Столько поинтов про зоопарк, но у Java ситуация не лучше в этом плане. Maven, Gradle (Groovy, Kotlin). Пакетов эти тонны и в разных стилях. И если уж сравнивать кол-во зоопарков и велосипедов, то C++ точно победит в этом соревновании.
Не скажу за фронтенд, но бекенд вполне себе ок писать на node.js. Другие рантаймы либо слишком специфичны для каких-то cloud решений (но там в принципе обычно делают всё своё - базы, очереди, балансеры и пр), либо очень сырые - тот же bun. Для примера, в Java тоже есть несколько рантаймов, а кол-во SDK вообще тьма. Для C# тоже есть .NET Framework, .NET Core, Mono. Пакетные менеджеры - кто-то, конечно, использует по старым заслугам отличные от npm, но это редкость. Пакетов (библиотек) в Java/C#/C++/Python/Go и тд тоже много и на разные случаи жизни. Про стили кода странный поинт. В других ЯП ситуация та же, для этого собственно и придумали линтеры и разные гайды (опять таки вспоминаем C++). Языки с богатой семантикой часто предполагают, что одну задачу можно решить абсолютно по-разному, тут ситуация такая же, как и в Ruby/Python. Их вы как-то не затронули.
Вывод должен быть такой, что всё познаётся в детальном сравнении. Чем больше работаешь с технологией и делаешь больше разнообразных задач, тем больше замечаешь в ней минусы и недостатки, которые были скрыты под белизной хайпа или решения простых задач. Да бывает больно, но другие ЯП если и решат проблемы, то точно принесут новые. Выбирать язык надо с умом. А как именно на вряд ли кто-то скажет, всегда зависит от ситуаций. И в большинстве случаев, что знает команда, то используется.
Передовой JIT-компилятор
Бабочка была действительно ужасной, настрадался с ней много: вечные залипания клавиш, иногда клавиши вообще выпадали.
А вот с тачбаром не соглашусь. Мне его очень не хватает. Да, он неудобен с точки зрения слепой печати, но он давал возможность не изучать многие горячие клавиши, потому что основные действия для конкретной программы отображались, и можно было просто посмотреть и тапнуть на нужное.
Некоторых технических спецификаций на русском нет, зато точно на английском (США) есть