Идея неплоха, даже напоминает чем-то 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. Их вы как-то не затронули.
Вывод должен быть такой, что всё познаётся в детальном сравнении. Чем больше работаешь с технологией и делаешь больше разнообразных задач, тем больше замечаешь в ней минусы и недостатки, которые были скрыты под белизной хайпа или решения простых задач. Да бывает больно, но другие ЯП если и решат проблемы, то точно принесут новые. Выбирать язык надо с умом. А как именно на вряд ли кто-то скажет, всегда зависит от ситуаций. И в большинстве случаев, что знает команда, то используется.
Бабочка была действительно ужасной, настрадался с ней много: вечные залипания клавиш, иногда клавиши вообще выпадали.
А вот с тачбаром не соглашусь. Мне его очень не хватает. Да, он неудобен с точки зрения слепой печати, но он давал возможность не изучать многие горячие клавиши, потому что основные действия для конкретной программы отображались, и можно было просто посмотреть и тапнуть на нужное.
ОКВЭД - это довольно формальная штука, конечно, есть вероятность попасть на проверку и получить штрафы, которые совсем копеечные (1-2 тысячи рублей), но на практике довольно редко такое встречается (за 2022 год всего 18к дел, связанных с нарушением регистрации, из которых наказание понесли 79%, а общее кол-во административных дел, связанных с предпринимательством - 236к)
А что с донатными помойками? Там пахнут? Пахнут, как и в беттинге/гемблинге. В беттинге событие произошло или не произошло, это не зависит ни от игрока, ни от конторы. В гемблинге, например, в тех же слотах прямо и пишут процент возврата. Но биржи вы почему-то не помянули, хотя там тоже есть риски для клиентов и про них говорят. Так можно притянуть любой high-risk бизнес, пользователи ведь жалуются, значит точно мошенники
Не всегда имеется возможность использовать Python. Например, на iOS и Android это довольно непростая задача, интерпретатор весит немало, производительность будет так себе с такими прослойками. Тот же Tensorflow использует JNI на Android, а на iOS вообще можно статически слинковать. Если написать нейронную сеть на C++ в виде библиотеки, то в большинстве случаев её можно подключить к любому своему приложению: либо слинковать, либо через FFI
Или написать свою реализацию пагинации, count и items хватает вполне, фронтенд может сгенерировать ссылки, посчитать кол-во страниц и тд. К тому же получаете полный контроль на полями, можете вставить хоть ещё 1000 других. Делается это всё буквально в пару строк кода.
<?php
class SomeController extends Controller
{
public function __construct(private Repository $repository) {}
public function action(Request $request): Response
{
[$count, $items] = $this->repository->find(
$request->query('limit', 10),
$request->query('page', 1),
);
return response()->json([
'count' => $count,
'items' => $items,
'meta' => $this->getSomeMeta(),
]);
}
}
Бизнес-потребность
Очень сложно назвать изменение ответа в API бизнес-потребностью. Про поле status в HTTP API уже было много раз обсуждалось - антипаттерн. По поводу дат, обычно соглашаются на стандарт ISO, так как многие сериализаторы и библиотеки умеют с ним работать, а потребитель уже сам решает, что и как делать с этой датой в соответствии с требованиями, хочет показывает в ISO, хочет показывает в Y-m-d\TH:i, на вряд ли пользователи будут смотреть, что же там им API отдал.
По-моему, вы на пустом месте усложнили себе жизнь. Конечно, это полезно разобраться в магии Laravel и попробовать сделать ещё больше магии, но для решения бизнес-задач явно не стоит.
В общем всё сводиться к тому, что не захотели пилить монорепозиторий на несколько репозиториев. По-моему опыту, недостатки монореп гораздо сильнее, чем преимущества (если говорить про микросервисы и бекенд).
Зависит от сайта. Если блоги/форумы/е-ком, то в принципе не стоило делать SPA, классические MVC-фреймворки, например, Laravel и Ruby on Rails прекрасно делают серверный рендеринг и без JS-фреймворков. А если без регистрации к продукту доступа нет, то вообще ноль смысла всё это рендерить на сервере, достаточно парочку статичных лэндингов сделать и их уже оптимизировать под поиск.
Вообще никаких моральных метаний по этому поводу, ну и получают, ну и очень хорошо, всегда приятно работать с высокооплачиваемыми и квалифицированными специалистами.
Это у вас так, но есть ещё множество людей, которым далеко не всё равно, а ещё им может быть обидно, особенно, если такой успешный в зарплате коллега менее квалифицирован или хуже выполняет задачи.
Во-первых, производительность этого метода сильно выше — мощности сервера сильно превосходят мощности принимающей стороны, а, значит не нужно будет рендерить страницу на стороне клиента перед отображением
Но клиент не один, их много. Да и вообще это не факт, продают же виртуалки по одному ядру и 512 мегабайт RAM.
Во-вторых, у такого контента более качественная SEO-оптимизация. Страница, сгенерированная на сервере, уже содержит весь текст, и поисковые машины сразу могут корректно индексировать его и поднять в топ релевантной выдачи. Если сайт генерируется на стороне пользователя, то поисковый робот не увидит этот контент.
Только ради SEO переходить на SSR довольно болезненно, а в больших проектах практически нереально.
Идея неплоха, даже напоминает чем-то 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-компилятор
Бабочка была действительно ужасной, настрадался с ней много: вечные залипания клавиш, иногда клавиши вообще выпадали.
А вот с тачбаром не соглашусь. Мне его очень не хватает. Да, он неудобен с точки зрения слепой печати, но он давал возможность не изучать многие горячие клавиши, потому что основные действия для конкретной программы отображались, и можно было просто посмотреть и тапнуть на нужное.
Некоторых технических спецификаций на русском нет, зато точно на английском (США) есть
ОКВЭД - это довольно формальная штука, конечно, есть вероятность попасть на проверку и получить штрафы, которые совсем копеечные (1-2 тысячи рублей), но на практике довольно редко такое встречается (за 2022 год всего 18к дел, связанных с нарушением регистрации, из которых наказание понесли 79%, а общее кол-во административных дел, связанных с предпринимательством - 236к)
А что с донатными помойками? Там пахнут? Пахнут, как и в беттинге/гемблинге. В беттинге событие произошло или не произошло, это не зависит ни от игрока, ни от конторы. В гемблинге, например, в тех же слотах прямо и пишут процент возврата. Но биржи вы почему-то не помянули, хотя там тоже есть риски для клиентов и про них говорят. Так можно притянуть любой high-risk бизнес, пользователи ведь жалуются, значит точно мошенники
Не всегда имеется возможность использовать Python. Например, на iOS и Android это довольно непростая задача, интерпретатор весит немало, производительность будет так себе с такими прослойками. Тот же Tensorflow использует JNI на Android, а на iOS вообще можно статически слинковать. Если написать нейронную сеть на C++ в виде библиотеки, то в большинстве случаев её можно подключить к любому своему приложению: либо слинковать, либо через FFI
Или написать свою реализацию пагинации, count и items хватает вполне, фронтенд может сгенерировать ссылки, посчитать кол-во страниц и тд. К тому же получаете полный контроль на полями, можете вставить хоть ещё 1000 других. Делается это всё буквально в пару строк кода.
Очень сложно назвать изменение ответа в API бизнес-потребностью. Про поле status в HTTP API уже было много раз обсуждалось - антипаттерн. По поводу дат, обычно соглашаются на стандарт ISO, так как многие сериализаторы и библиотеки умеют с ним работать, а потребитель уже сам решает, что и как делать с этой датой в соответствии с требованиями, хочет показывает в ISO, хочет показывает в
Y-m-d\TH:i, на вряд ли пользователи будут смотреть, что же там им API отдал.По-моему, вы на пустом месте усложнили себе жизнь. Конечно, это полезно разобраться в магии Laravel и попробовать сделать ещё больше магии, но для решения бизнес-задач явно не стоит.
Так как всё же быстро выучить Archimate? Записаться на курс? )))
Заголовок хоть и кликбейтный, но статья хорошая для стартовой точки, чтобы понимать, куда двигаться
В общем всё сводиться к тому, что не захотели пилить монорепозиторий на несколько репозиториев. По-моему опыту, недостатки монореп гораздо сильнее, чем преимущества (если говорить про микросервисы и бекенд).
Есть разные готовые средства управления монорепозиториями, которые позволяют раздельно деплоить/запускать/итд разные проекты внутри такого гиганта.
Зависит от сайта. Если блоги/форумы/е-ком, то в принципе не стоило делать SPA, классические MVC-фреймворки, например, Laravel и Ruby on Rails прекрасно делают серверный рендеринг и без JS-фреймворков. А если без регистрации к продукту доступа нет, то вообще ноль смысла всё это рендерить на сервере, достаточно парочку статичных лэндингов сделать и их уже оптимизировать под поиск.
Это у вас так, но есть ещё множество людей, которым далеко не всё равно, а ещё им может быть обидно, особенно, если такой успешный в зарплате коллега менее квалифицирован или хуже выполняет задачи.
Но клиент не один, их много. Да и вообще это не факт, продают же виртуалки по одному ядру и 512 мегабайт RAM.
Только ради SEO переходить на SSR довольно болезненно, а в больших проектах практически нереально.