Какой инструментарий для разработки на TypeScript+React актуален на момент лета 2021?

Антон Швец, Ну вот, это уже аргументированный ответ! Благодарю Вас.

Какой инструментарий для разработки на TypeScript+React актуален на момент лета 2021?

user_of_toster, тем, что он за меня решает, какая должна быть структура у проекта, как должны называться файлы и т. д. Чем больше фреймворк навязывает ограничений, что холоднее последователь "Чистой архитектуры" относится к фреймворку.

Какой инструментарий для разработки на TypeScript+React актуален на момент лета 2021?

Василий Банников, Да может и всё можно сделать в функциональных компонентах. Я не готов вести холивар по поводу "какая парадигма программирования лучше - функциональная и объектно-ориментированная". Субъективно могу сказать, что попробовал обе, причём сначала функциональную, но когда стал въезжать в концепцию ООП, то понял, насколько это величайшее изобретение. С тех пор большую часть кода я пишу через классы и полностью доволен. Из мнения других специалистов могу процитировать одного из авторов книги "Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию", который говорил, что использование ООП вместе шаблонами проектирования даёт наиболее лёгкие в поддержке приложения.

Так что субъективно для меня переход на функциональный стиль - это в некотором роде "откат назад".

Какой инструментарий для разработки на TypeScript+React актуален на момент лета 2021?

Александр, Благодарю Вас за комментарий? Звучит как концепция Watcher-ов. Во Vue это из коробки. И что, в React, самом популярном фреймворке в мире, нет никакого другого элегантного решения, кроме как хуки, чтобы выполнить определённую функцию при изменении конкретной переменной? Как же это задачу решали во времена, когда хуков не было? (Сам, если честно, не помню).

Какое максимальное количество типов устройств и операционных систем можно поддерживать написав приложение на Dart+Flutter на момент июня 2021?

Василий Банников

Приношу свои извинения за Ваше потраченное время.
Про JavaFX я написал, чтобы мне её не рекомендовали.

Почему несмотря на устаревание HTML, CSS и JavaScript не делается шагов в сторону альтернатив, отвечающим спросу рынка веб-разработки?

Для оптимизации работы того, что дают на выходе фрэймворки и защиты "от дурака".

Понял. Этот пункт исчерпан.

Между React, Vue и Angular - только последний пытается Вам что-то втереть про архитектуру.

Если в Nuxt.js нельзя изменить имена папок и их расположение по умолчанию, то он тоже навязывает.
На Next.js не разрабатывал.

Если хватает скилов делать это так же качественно и, что более важно для бизнеса, так же быстро - почему нет?

Понял. Этот пункт исчерпан.

В сухом остатке заказчикам нужно чтобы были клиенты и продажи. И чем быстрее и больше, тем лучше. Что там за технологии им нет никакого дела.

Понял. Всё верно с точки зрения теории бизнеса.

Изменение стилей в зависимости от доступной ширины cкоро появится.

Благодарю Вас за эту хорошую новость!

Вкусовщина.

Вы не посмотрите на разработчика как на больного, если он скажет что-то вроде: "Я люблю писать на чистом CSS, а не на лаконичных препроцессорах, потому он сложнее, там нет вложенных правил и миксин, поэтому нужно всё делать ручками, а все это занимает много времени и я получаю от этого удовольствие."?

Ага, в веб пришли дяди и тёти с серьёзных языков, потому что веб отжимает у них работу и стали жаловаться что тут нет их любимого ООП.

Так то-то и оно, что JavaScript - несерьёзный язык :)

А так ли актуальная эта проблема в 2021?

Я очень рад, если нет. Это означает, что можно вернутся к парадигме ненавязчивого JavaScript-а.

Далеко не всем нужны визуальные редакторы. Именно поэтому их решают на стороне CMS

Ладно, не будем об этом, а то возникнет бессмысленный спор, нужно ли использовать готовые CMS.

А если и внести это в JS, то можно ли угодить всем?

Ну так кому не надо, тот путь и не использует. Никто же не заставляет всех использовать генераторы функций, например.

И да, мы совсем забыли упомянуть, что мы таким образом замыкаем весь трафик на себе, а Ваш сайт можете выбросить в помойку.

Благодарю Вас за такую ценную информацию! А что значит "замыкаем трафик на себе"? URL AMP-версий страниц не принадлежат тому же домену, что и канонические страницы?

Решали проблему узких каналов, а в итоге каналы уже более менее у всех широкие, но само железо теперь страдает делать это всё на клиенте.

Это точно. Особенно хотелось бы заметить, что бэк-енд команда часто перекладывает свою работу на фроне-енд команду, заставляя последних, например, фильтровать и сортировать данные на клиентской стороне. Но как-то так получается, то у бэк-енд команды обычно привилегированное положение и на их лень смотрят сквозь пальцы :)

Почему несмотря на устаревание HTML, CSS и JavaScript не делается шагов в сторону альтернатив, отвечающим спросу рынка веб-разработки?

Вадим,

Благодарю Вас за комментарий!

Честно говоря, не ожидал такой ярой защиты в пользу HTML, CSS и JavaScript (я не только про Ваш комментарий).
Но я не раскаиваюсь, что спросил. Очень интересно наблюдать, какую негативную реакцию у общества
вызывают попытки усомниться в том, что принято считать само собой разумеющимся :)

Полностью не верно. Фрэймворки не для увеличения производительности, а для улучшения опыта разработки.

Очень интересно... Зачем же тогда понадобилось изобретать такой велосипед, как Virtual DOM?
Это получается, что если мне не нужна та архитектура, которую навязывают фреймворки, то я могу писать приложения по-старому, на ненавязчивом JavaScript-e, на JQuery или вовсе нативно не волнуясь о производительности?

> Подскажите, а как устаревает HTML и CSS?
> Ну и какие Вы видите альтернативы для указанных технологий? Что должно заменить html css js?

Поскольку таких технологий нет, то я могу лишь сказать, что эти технологии должны быть такими-то и такими-то.
Рассуждать об этом занимаясь реализацией этих технологий легче всего, но я всё-таки укажу, что не хватает HTML, CSS и JavaScript, но что нужно заказчикам и исполнителям.

HTML

Если не затрагивать внешний вид нативных элементов, то в HTML можно улучшить, наделив его всем тем же функционалом, что и любой популярный препроцессор (шаблонизатор). Иными словами, жить будет намного легче, если браузеры будут нативно понимать такие препроцессоры, как Pug.

CSS

1. Возможность полной стилизации всех нативных HTML-элементов. Например, если нам нужен красивый DataPicker, то стилизуем нативный как обычную кнопку, а не берём его из фреймворков и тем более не реализуем сами. На данный момент стилизовать некоторые нативные элементы очень сложно. Например списки (к примеру, невозможно кроссбраузерно задать расстояние между маркером и началом текста), некоторые input-ы, в частности радиокнопки и загрузчики файлов. Отдельно хотелось бы сказать про таблицы, которые при определённых условиях игнорируют min-width, имеют проблемы с вертикальным выравниванием нетекстового контента (например, кнопок) и не поддерживают скроллинг.

2 Изменение стилей в зависимости от доступной ширины родителя Проблема отсутствия данного функционала рассмотрена в этом вопросе.

3. По синтаксису идеальную замену CSS я представляю себе наподобие вроде Stylus-а со всеми его возможностями.

JavaScript

1. Если интегрировать JavaScript с TypeScript-ом, с точки зрения синтаксиса будет почти идеал. Который год в JavaScript не могу ввести ключевые слова interface, abstract, private, protected.
2. Проблема медленного доступа к DOM должна быть полностью решена.

Одна из самых трудных задач, которая востребована на рынке и простых решений которой нам не даёт нативный JavaScript - это создание WYSYWIG-редактора. Редко когда заказчики горят желанием верстать статьи для своих корпоративных блогов, гораздо чаше просят наподобие: "Нам пожалуйста WYSYWIG-редактор, заточенный под наши нужды и наш дизайн, и ничего лишнего не надо." Как много редакторов, которые имеют русскую локализацию? Я знаю только CK и MCE. О чём это говорит? О том, что его создавать их могут только гении или те, у кого много оплачиваемого свободного времени. А если бы JavaScript действительно бы отвечал на спрос рынка, был бы нативный класс типа Editor наравне с Array или Promise, в котором мы через опции указываем, что нам надо, и вся логика для WYSYWIG-редактора готова.

И напоследок хотел бы сказать, что обилие фреймворков, таких технологий AMP и PWA, говорит не в пользу HTML, CSS и JavaScript, а о том, что нативно очень многого не хватает, а реализовать всё это - непросто, иначе у каждого новичка был бы Bootstrap и React собственного производства.

Почему несмотря на устаревание HTML, CSS и JavaScript не делается шагов в сторону альтернатив, отвечающим спросу рынка веб-разработки?

Благодарю Вас за конструктивный ответ!

Как создать видеохостинг с нуля?

Недавно забанили аккаунты Дональда Трампа, в том числе - YouTube аккаунт (на момент написания этого сообщения блокировка была пока временной). Хотя большинство из нас не собираются устраивать резню в США, сам факт блокировки этого аккаунта даёт понять, что делать свои видео заложниками YouTube - опасно. Вполне возможно, что в будущем YouTube начнёт блокировать всё, что не соответствует "западной идеологии", а потому остаётся надеется, что будет это не скоро и за оставшееся время можно будет освоить технологии самостоятельного создания видео-хостингов. Я к тому, что тема данного вопроса - актуальна.