Потому что несколько десятков дысяч советских людей имевших доступ к отечественным компьютерам не идут ни в какоге сравнение с десятками миллионов людей по всему миру имеющих доступ к зарубежной технике. Чем больше база людей, тем больше инноваций, софта и денег вокруг - и цикл прогресса замкнулся. Отсюда вывод - нужно возводить мосты, а не строить стены.
Добавлю свои 5 копеек. Столешница еще должна быть наклонной, чтобы локти не выворачивались. Сплит клавиатура, а посередине должен быть pointing device (точпад или трекпад/болл), а если справа мышь то смысла заморачиваться нет.
Согласен со всем вышеизложенным! Свою либу компилирую Тайпскриптом, ставлю таргет ESNext, чтобы не деградировать новые фичи языка, пользователи уже под себя пусть компилят. Если не хотят, то можно брать с CDN которые подтягивают и компилят из npm (с параметрами компиляции). Не забываем файлы деклараций.
Интересно посмотреть ваши промпты. Если вы написали "напиши мне игру - три в ряд", то не удивительно что он мог сделать плохо, так как вариаций таких игр множество и правил тоже, которые могут конфликтовать. А вот если вы делали описание очень подробно, то тогда ваши выводы имеют место.
Мешкам с костями нужно еще шевелиться, переваривать еду, осуществлять другие процессы жизнедеятельности, пальцами тыкать в клавиатуру... Так что половину энергии надо вычесть из 8400, для справедливости.
Как программисту мне нравится собирать лего-конструктор из языковых конструкций и абстракций, создавать свои абстракции. А работа с ИИ похожа на работу менеджера. Видимо профессия таки уходит в /dev/null что не может меня не огорчать.
Реакт сам - как плохой пример разделения ответственности. Создание ДОМ элементов это одна ответственность. Обновление этих элементов это вторая. Управление стейтом это третья. Это все хитроумно переплетено и от этого мы имеем все проблемы.
Создание компонента и обновление стейта объединено в одну функцию, из-за этого у нас постоянный ре-рендер, нужны хуки и рефы чтобы хоть как-то с этим справляться. Начинаются танцы с бубном с оптимизацией, мемоизацией, разбиением на фрагменты при реконсилиации, сервеный рендеринг, серверные компоненты, и вот уже компилятор, который также не решит этих проблем.
Потому что нет разделения ответственности, где человек сам смог бы выбирать когда и как создавать ДОМ, синхронно или асинхронно. Когда и как обновлять дом. Какую стратегию управления стейтом использовать в каждом конкретном компоненте. Поэтому это все и было реализовано во Фьюзоре.
Сейчас эпоха offline-first PWA приложений и игр. Они работают одновременно и на десктопе, и мобиле и в браузере (причем написанные один раз адаптивной версткой). Устанавливаются как нативные приложения.
Бекенд нужен для сложных вычислений, для синхронизации между устройствами, для предоставления данных, а не для отрисовки фронтенда. Бэкенд и фронтенд лучше разделить, а фронтенд скомпилировать в статические ресурсы и положить в CDN.
Если устали от сложных фреймворков, то посмотрите в сторону Фьюзора. Он задумывался как убийца Реакта и остальных фреймворков. Простая библиотека с 2 функциями - создать и обновить DOM элемент. Всё! Стейт менеджер подключаете свой если нужен. А если не нужен можно обычные переменные использовать.
Как вы решаете проблему, когда набегают кучи хомячков и голосуют за статьи и комменты исходя из своего эмоционального состояния, а не путем логического обоснования?
А во взрослом возрасте эти проблемы сами по себе растворяются? Мне кажется взрослые так же плотно "сидят" на этом быстром дофамине и мы еще не осознали всю степень звездеца с этим связанного.
3 раза подряд одна и таже информация повторена про service worker. Дальше не лмстал, уж извините. В следующий раз хоть прочитайте то что постите.
Во Fusor-е можно декларативно указывать параметры в названии пропсы, например:
click_e_capture_once.В настройках KDE можно найти все эти визуальные эффекты, как в прочем и все другие более важные утилиты, ничего не устанавливая дополнительно.
Потому что несколько десятков дысяч советских людей имевших доступ к отечественным компьютерам не идут ни в какоге сравнение с десятками миллионов людей по всему миру имеющих доступ к зарубежной технике. Чем больше база людей, тем больше инноваций, софта и денег вокруг - и цикл прогресса замкнулся. Отсюда вывод - нужно возводить мосты, а не строить стены.
Добавлю свои 5 копеек. Столешница еще должна быть наклонной, чтобы локти не выворачивались. Сплит клавиатура, а посередине должен быть pointing device (точпад или трекпад/болл), а если справа мышь то смысла заморачиваться нет.
А я-то всегда думал что головная боль это про Виндовс, а оказывается наоборот...
Согласен со всем вышеизложенным! Свою либу компилирую Тайпскриптом, ставлю таргет ESNext, чтобы не деградировать новые фичи языка, пользователи уже под себя пусть компилят. Если не хотят, то можно брать с CDN которые подтягивают и компилят из npm (с параметрами компиляции). Не забываем файлы деклараций.
Как говорится - потрудитесь сделать поще, сложно - само получится.
Интересно посмотреть ваши промпты. Если вы написали "напиши мне игру - три в ряд", то не удивительно что он мог сделать плохо, так как вариаций таких игр множество и правил тоже, которые могут конфликтовать. А вот если вы делали описание очень подробно, то тогда ваши выводы имеют место.
Мешкам с костями нужно еще шевелиться, переваривать еду, осуществлять другие процессы жизнедеятельности, пальцами тыкать в клавиатуру... Так что половину энергии надо вычесть из 8400, для справедливости.
Как программисту мне нравится собирать лего-конструктор из языковых конструкций и абстракций, создавать свои абстракции. А работа с ИИ похожа на работу менеджера. Видимо профессия таки уходит в /dev/null что не может меня не огорчать.
Джун точно также как и Мидл уйдет, как только поймет что "так можно было".
Реакт сам - как плохой пример разделения ответственности. Создание ДОМ элементов это одна ответственность. Обновление этих элементов это вторая. Управление стейтом это третья. Это все хитроумно переплетено и от этого мы имеем все проблемы.
Создание компонента и обновление стейта объединено в одну функцию, из-за этого у нас постоянный ре-рендер, нужны хуки и рефы чтобы хоть как-то с этим справляться. Начинаются танцы с бубном с оптимизацией, мемоизацией, разбиением на фрагменты при реконсилиации, сервеный рендеринг, серверные компоненты, и вот уже компилятор, который также не решит этих проблем.
Потому что нет разделения ответственности, где человек сам смог бы выбирать когда и как создавать ДОМ, синхронно или асинхронно. Когда и как обновлять дом. Какую стратегию управления стейтом использовать в каждом конкретном компоненте. Поэтому это все и было реализовано во Фьюзоре.
При грамотной верстке, SEO прекрасно рабоает уже с 2018 года, в том числе и для SPA приложений.
Сейчас эпоха offline-first PWA приложений и игр. Они работают одновременно и на десктопе, и мобиле и в браузере (причем написанные один раз адаптивной версткой). Устанавливаются как нативные приложения.
Бекенд нужен для сложных вычислений, для синхронизации между устройствами, для предоставления данных, а не для отрисовки фронтенда. Бэкенд и фронтенд лучше разделить, а фронтенд скомпилировать в статические ресурсы и положить в CDN.
Если устали от сложных фреймворков, то посмотрите в сторону Фьюзора. Он задумывался как убийца Реакта и остальных фреймворков. Простая библиотека с 2 функциями - создать и обновить DOM элемент. Всё! Стейт менеджер подключаете свой если нужен. А если не нужен можно обычные переменные использовать.
Поддержку Typescript из коробки на подвезли еще?
А как насчет notepad?
Fusor 3KB вместо React 45KB, нативный роутинг 200 байт вместо ReactRouter 50KB, например так, и offline-first PWA.
Как вы решаете проблему, когда набегают кучи хомячков и голосуют за статьи и комменты исходя из своего эмоционального состояния, а не путем логического обоснования?
А во взрослом возрасте эти проблемы сами по себе растворяются? Мне кажется взрослые так же плотно "сидят" на этом быстром дофамине и мы еще не осознали всю степень звездеца с этим связанного.