date-fns из коробки модульный, у него всё хорошо с этим. А вот про luxon не уверен. Фича «цепочки вызовов» по-моему не совместима с tree-shaking концептуально.
Не к переводу, а вообще про курс: какой-то он слишком простой. Объяснять, как навешивать событие на компонент целую главу как-то странно.
И чем не подходит официальная документация?
Классы дают полный доступ ко всему: состоянию, методам жизненного цикла. Они совершенно прозрачно и ожидаемо работают. Описывать код компонента классом с методами-обработчиками — вполне нормальная практика. Код легко читать.
Эти ваши хуки — магия, добавленная для любителей функциональщины.
Стоит упомянуть, что всё-таки есть способ запустить код в настоящем отдельном потоке в браузере — Web Workers. Да, с ограничениями и сложностями с обменом данными, но тем не менее часть тяжелых вычислений можно туда перенести, разгрузив код отрисовки интерфейса, уменьшив лаги.
Для определения ключевых слов «Алиса» и «Яндекс», да. Насколько я знаю, там маленькая обученная нейронка заточенная исключительно на эти слова.
Все остальное реализовано на серверах Яндекса.
Отдельный от основного процессора чип АЦП-ЦАП который этим занимается. Т.к. он на это заточен, то энергии тратит сильно меньше, чем основной, более универсальный процессор.
Подавляющее число задач не связаны с математикой вообще никак. CRUD и бизнес-логика редко требуют сложных вычислений. А вот знания 100500 библиотек на все случаи жизни, умение писать простой и понятный код (поддерживаемый), умение расставлять приоритеты, изучать постоянно что-то новое — нужно всегда.
Программисты решают задачи бизнеса. Если задача решается с приемлемым качеством и в приемлемый срок — он профи.
Если появится проблема, требующая знаний — получить эти знания или нанять человека, специализирующегося на них — не проблема.
Ставить ярлык "говнокодер" я бы не стал, если человек не умеет в диффуры.
Статья безусловно классная. Формулы страшные. Ну вот чисто внешне пугают. Как у Хоккинга: «каждая новая формула сокращает число читателей вдвое».
Я довольно востребованный прикладной программист с большим опытом. Но без образования и знаний математики. И с этой точки зрения статья обманула мои ожидания фразой «вообще не требует знаний».
Возможно вы учились в очень классной школе. Но мне кажется, вы переоцениваете уровень седьмого и десятого классов.
Я находил в настройках webstorm всё, что хотел. Там сотни параметров. Prettier такое даже не снилось. Я не против в принципе существования prettier, он лучше, чем вообще ничего. Но с форматированием в webstorm он находится в разных весовых категориях.
Проблема в том, что парсинг template string требует статического анализа. Поэтому jsx пока выигрывает.
Этот анализ уже реализован и во vue, и в svelte. Они хотя бы не требуют писать что-то похожее на html, как в JSX, который якобы html, но ненастоящий.
Я думаю, дальше дискутировать смысла нет, мы оба останемся при своих мнениях.
Pretifier — обычный Format Code. Все настройки для неё в ветке «Code Style» для всех языков.
Inspect Code — это фича чисто jetbrains (она появилась задолго до любого линтера, кроме разве что крокфордовского JSLint).
В дополнение к ней есть интеграция с JSLint, JSHint, Closure Linter, JSCS, ESLint, TSLint (вот они могут браться из node_modules, и учитываются настройки из файлов-конфигов для них в проекте)
.editorconfig тоже встроенная поддержка
Но js внутри html — это плохо.
vue.js и svelte.js c Вами не согласятся) Есть такой паттерн «Single File Components», когда компонент представляет собой один файл с шаблоном, логикой и стилями
Там встроенный аналог prettifier (гораздо гибче), и inspect code (он не устарел, он просто другой). Остальное — да, органично интегрируется из node_modules.
Недавно появилась (в EAP) фича по кастомной сортировки css свойств.
Я пытался серьезно слезть с иглы jetbrains. Месяц сидел на VS Code. Но постоянно плевался, не находя нужные мне фичи. Он даже JS внутри HTML при выравнивании не учитывает настройки и выравнивает по своему. Обвешиваться десятками левыми расширениями на каждый чих тоже надоело.
Тоже возникла такая мысль, что подход тот же, что и с обычными событиями. Слишком гибкая архитектура, сложно понять и отладить. Неявные логические связи, потеря причинно-следственной связи.
Возможно, у меня мало опыта с redux. Но его фишку с отдельной сущностью action, которая простой объект, я понять не могу. Какой-то переусложненный опосредованный способ дернуть метод, который может что-то в сторе поменять. Прям SQL или HTTP запрос какой-то. Но там понятно, разные среды исполнения. В SPA приложении-то зачем? Почему не напрямую дернуть метод?
Единственное, что приходит в голову — пригодится для общения с WebWorker.
Недавно открыл для себя Rematch.
Просто глоток свежего воздуха. Болейрплейта практически нет. При этом все фичи редакса не теряются, т.к. это всего лишь удобная обертка.
Главный плюс — не нужно писать кучу ACTION_TYPES, Action Creators, кучу switch в редьюсерах.
Советую глянуть видео и/или пощупать.
И чем не подходит официальная документация?
Эти ваши хуки — магия, добавленная для любителей функциональщины.
Все остальное реализовано на серверах Яндекса.
Весело.
Навигации тоже нет, при перезагрузке страницы сбрасывает в начало.
Подавляющее число задач не связаны с математикой вообще никак. CRUD и бизнес-логика редко требуют сложных вычислений. А вот знания 100500 библиотек на все случаи жизни, умение писать простой и понятный код (поддерживаемый), умение расставлять приоритеты, изучать постоянно что-то новое — нужно всегда.
Программисты решают задачи бизнеса. Если задача решается с приемлемым качеством и в приемлемый срок — он профи.
Если появится проблема, требующая знаний — получить эти знания или нанять человека, специализирующегося на них — не проблема.
Ставить ярлык "говнокодер" я бы не стал, если человек не умеет в диффуры.
Я довольно востребованный прикладной программист с большим опытом. Но без образования и знаний математики. И с этой точки зрения статья обманула мои ожидания фразой «вообще не требует знаний».
Возможно вы учились в очень классной школе. Но мне кажется, вы переоцениваете уровень седьмого и десятого классов.
Эм… ну да, фигня, начальная школа.
Как же все относительно в мире.
Этот анализ уже реализован и во vue, и в svelte. Они хотя бы не требуют писать что-то похожее на html, как в JSX, который якобы html, но ненастоящий.
Я думаю, дальше дискутировать смысла нет, мы оба останемся при своих мнениях.
Inspect Code — это фича чисто jetbrains (она появилась задолго до любого линтера, кроме разве что крокфордовского JSLint).
В дополнение к ней есть интеграция с JSLint, JSHint, Closure Linter, JSCS, ESLint, TSLint (вот они могут браться из node_modules, и учитываются настройки из файлов-конфигов для них в проекте)
.editorconfig тоже встроенная поддержка
vue.js и svelte.js c Вами не согласятся) Есть такой паттерн «Single File Components», когда компонент представляет собой один файл с шаблоном, логикой и стилями
Там встроенный аналог prettifier (гораздо гибче), и inspect code (он не устарел, он просто другой). Остальное — да, органично интегрируется из node_modules.
Недавно появилась (в EAP) фича по кастомной сортировки css свойств.
Я пытался серьезно слезть с иглы jetbrains. Месяц сидел на VS Code. Но постоянно плевался, не находя нужные мне фичи. Он даже JS внутри HTML при выравнивании не учитывает настройки и выравнивает по своему. Обвешиваться десятками левыми расширениями на каждый чих тоже надоело.
Тоже возникла такая мысль, что подход тот же, что и с обычными событиями. Слишком гибкая архитектура, сложно понять и отладить. Неявные логические связи, потеря причинно-следственной связи.
Единственное, что приходит в голову — пригодится для общения с WebWorker.
Просто глоток свежего воздуха. Болейрплейта практически нет. При этом все фичи редакса не теряются, т.к. это всего лишь удобная обертка.
Главный плюс — не нужно писать кучу ACTION_TYPES, Action Creators, кучу switch в редьюсерах.
Советую глянуть видео и/или пощупать.