А почему бы...
Не накидать маленький скрипт на JavaScript для расширения браузера Tampermonkey которое возвращает плюсы, минусы и убирает убогую анимацию. Да не, бред какой-то. Есть умельцы?
0 просмотренных постов скрыто
Почему JS (и TS) это плохой язык
Я знаю, что на эту тему уже было сказано много, но настал мой черед. На JS я пишу больше 10 лет, так что терпел я достаточно :)
Когда мы говорим “джаваскрипт”, мы подразумеваем много разных вещей:
Стандарт EcmaScript
Среда исполнения (NodeJS, браузер)
Экосистема (библиотеки, фреймворки, тулинг)
Иногда есть смысл поговорить об этих вещах по отдельности, но сегодня мы обсудим их все сразу, и назовем это просто “джаваскрипт”. А именно, я объясню, почему джаваскрипт это плохой язык.
Что значит плохой?
А что значит “плохой” (или хороший)? Кто-то из великих сказал: “есть 2 типа языков, те которые не ругают, и те на которых пишут”. Джаваскрипт буквально олицетворяет вторую категорию: его ругают почем свет стоит, и при этом он самый популярный язык программирования в мире.
JS это хороший язык в том смысле, что он, определенно, решает свою задачу (иначе он не был бы столь популярен), и это очень плохой язык в смысле того, насколько много усилий нужно приложить, чтобы решить тривиальную задачу.
Если последнее утверждение кажется вам неочевидным (как же так, hello world на JS можно написать в 1 строку, а на условном Go в 5-10), то нужно уточнение — программисты не слишком часто пишут хеловорды на работе. Чаще всего человеку, волею судеб столкнувшемуся с JS нужно работать с графическим интерфейсом, либо писать серверный код, и размеры таких приложений в большинстве своем превышают тысячу строк кода.
JS не масштабируется
Не даром слоган TS — “JavaScript that scales”. Во всяком случае, был. Этот язык был спроектирован много лет назад для решения задач, которые совершенно не похожи на сегодняшние. Написать скрипт, максимум, в несколько сотен строк кода это совершенно не то же самое, что поддерживать огромный проект с десятками сложнопереплетенных сущностей, где цена отказа это большие деньги.
Да, разработчики EcmaScript и движков вроде V8 большие молодцы, что развивают язык. Так, например, в нем со временем появились импорты и async-await, но, во-первых, там есть нюансы (об этом чуть позже), а, во-вторых, этого недостаточно. Помимо этого нужна как минимум статическая типизация, линтинг и форматтер. Если мы говорим про фронтенд среднего и выше размера, то добавьте сюда: минификацию, обфускацию, сжатие картинок, транспиляцию под старые браузеры и, черт знает, что еще. Вам может особенно “повезти”, если вы разрабатываете под какую-то нестандартную платформу вроде Chrome или VSCode расширения, где на вас упадут дополнительные ограничения с которыми вы останетесь один на один. И часто проблема решается написанием каких-то кастомных скриптов для сборки вашего кода каким-то нетривиальным способом.
Короче, из коробки JS годится лишь для написания очень маленьких вещей, а как только ситуация меняется, начинаются маневры, и поверх основной технологии (собственно, языка), начинают наслаиваться дополнительные, и все это (из-за основной причины, отсутствия нужных инструментов в самом языке), ходит ходуном и шатается от ветра как карточный домик.
Итого, JS “из коробки” не масштабируется — факт. Для масштабирования требуется сильное усложнение системы путем добавления в нее компонентов неочевидного качества. И дело даже не в комьюнити - разработчики сторонних инструментов большие молодцы, что решают насущные проблемы, но они просто не могут решить их по настоящему качественно, потому они сами вынуждены писать на джаваскрипте. Это рекурсия и порочный круг.
Фронтенд это боль
Как вы могли понять из предыдущего абзаца, проблема “JS не предоставляет из коробких нужных инструментов” удесетеряется в случае, если вы пишете не для сервера, а под браузер. Это забавно, учитывая, что JS был создан для фронтенда, а бэкенд на нем, в итоге, писать проще.
Это не значит, что надо тащить JS на бэкенд, он все еще остается плохим языком, просто на фронтенде страданий еще больше. К тому же, злая ирония такова, что на бэкенде, где JS еще можно как-то стерпеть, есть из чего выбрать (например, Go), а вот на фронтенде выбора нет. Более того, выбор может пасть на JS (и вполне адекватно, к сожалению) даже когда вы пишете мобильное и/или десктопное приложение, например, на React Native или Electron. Как сложилась такая ситуация, отдельная история, но это факт, и с ним надо мириться.
Ситуация с фронтендом настолько ужасна, что самый популярный и стабильный фреймворк React заставляет вас писать на языке jsx (tsx), который является абстракцией над JS и HTML. Альтернативы еще хуже, например, Svelte также добавляет свой html-js-подобный язык с различными магическими директивами.
В итоге этот “динамический” язык не работает без кучки компиляторов, каждый из которых имеет свои конфиги, свою экосистему плагинов (каждый из коротых в любой момент может может сломать обратную совместимость, не обновиться вовремя, стать depracated и прочее).
Веб нельзя ломать
Логика разработчиков JS проста — миллионы сайтов и приложений работают на джаваскрипте, следовательно, из джаваскрипта ничего нельзя удалить. В итоге в него все добавляют и добавляют, как следствие, на нем можно писать в десяти разных стилях и одна проблема решается дюжиной разных способов. Как думаете, как это влияет на качество и удобство разработки? Правильно, влияет очень плохо. Два проекта даже на React могут выглядеть совершенно по разному, не говоря уже о проектах с разными фреймворками. Они даже синтаксически (из-за бесконечного юзания различных настроек и сахаров) легко могут отличаться.
Но это по беды. Так как ни одно минимально работающее приложение на JS невозможно без огромной пачки зависимостей (будь то рантайм или для тупо сборки), то будьте готовы к тому, что пакеты не дружат друг с другом. В одном пакете CommonJS импорты, в другом ES6 импорты, в третьем еще какая-нибудь херня. Или ситуация, что пакет который вам нужен внезапно не поддерживает нужный вам формат импортов.
Я остановлюсь тут, но, мне кажется, подобных причин для поломки, которые следуют из того факта, что “веб нельзя ломать” можно выдумать еще много.
TypeScript не помог
Опять же, не поймите неправильно. Ребята из Microsoft большие молодцы, что решают насущную проблему, и без них было бы намного хуже. Однако, их решение, во-первых, не решает проблему полностью а, во-вторых, добавляет своих проблем.
Начнем с того, что у вас в системе +1 компонент - компилятор тайпскрипта. У него (ну разумеется) есть свой конфиг. Версия вашего компилятора должна матчится с вашими зависимостями.
Далее, TypeScript не дает никаких гарантий. Вообще. Как же так? Компонент в систему добавили, +1 язык выучили, а undefined все еще is not a function? Причина в том, что TS был разработан для gradual adoption, то есть плавной интеграции с JS. Разработчики предположили (и правильно предположили), что просто взять и переписать весь джаваскрипт в мире на TS не получится, и любой TS-код будет взаимодействовать с небезопасным JSом. Как следствие, очень и очень часто в своем TypeScript проекте вы будете видеть тип any который как бы говорит “хз что это, делай с этим что хочешь но на свой страх и риск”. Классная типизация, да?
Выводы
JS это плохой язык и тулинг эту проблему не решает, видимо, потому что это просто невозможно в принципе
Иногда брать JS/TS можно и нужно, ситуации бывают разные, но это за пределами статьи
Если вы не писали на Go, советую попробовать, вы удивитесь, насколько жизнь может быть приятнее (как бонус еще и конская производительность)
Дополнительно
Я посвятил три года изучению языков программирования и написал свой. Он совсем не похож на JS потому что он потоко-ориентированный (dataflow/flow-based) и в нем все работает параллельно by default. В его архитектуру я заложил все, чтобы работать с ним было легко и приятно. К сожалению, сейчас у меня нет времени заниматься им, но мне будет приятно, если вы на него посмотрите.
Мои Telegram Каналы
Еще у меня есть 2 tg канала где я пишу про запуск своего проекта и программирование с помощью LLM.
Показать полностью
City States Idle - менеджмент игра про построение бизнеса
С прошлого поста про игру на хакатон прошло чуть больше года, было не до геймдева. Всё как обычно началось с желания создать игру, игру которая бы сочетала элементы idle и менеджмента. Хотелось, чтобы игроки могли развивать свой город, но при этом не были привязаны к постоянному управлению. Так родилась концепция City States Idle.
Выбор технологий
Для реализации проекта был выбран игровой фреймворк Phaser, так как эта библиотека отлично подходит для создания браузерных игр и имеет множество готовых инструментов для работы с графикой и физикой.
Первый прототип
Первым делом был создан базовый прототип с гексагональной сеткой. Это было ключевым элементом игры, так как гексагональные плитки позволяли создавать интересные стратегические решения при планировании карты. Очень помог плагин rexBoard для создания сетки.
Система покупок и размещения
Следующим этапом стала разработка системы покупок. Реализовал механику, где игроки могли приобретать новые плитки за внутриигровую валюту. Каждая плитка могла содержать различные типы зданий, которые нужно было стратегически соединять для оптимизации производства ресурсов.
Система производства и доставки
Одним из ключевых элементов стала система производства ресурсов. Здания автоматически генерировали ресурсы, но так же и перерабатывали их. Это создавало интересный баланс между развитием инфраструктуры и управлением финансами.
Графика
Как обычно графика сгенерирована нейросетями, лучший помощник при разработке игр.
Система соединений
Важной частью геймплея стала система соединений между зданиями. Здания должны были быть связаны с другими открытыми зданиями для эффективной работы - некий стратегический элемент в процессе игры.
Инструменты
Отдельно пришлось создать редактор карт на базе самой игры и локальный сервер для обработки и хранения этих карт. Это очень сильно облегчило создание и редактирование карт.
Оптимизация и балансировка
После создания базовой механики приступил к оптимизации производительности. Изначально для неактивных зданий использовался шейдер, но при росте карты наблюдались проблемы с производительности, в итоге легче было отказаться от шейдера и использовать дубликаты зданий, но в grayscale режиме и с прозрачностью.
Так же пришлось поиграться с ценами товаров и скоростью производства зданий, чтобы достичь некоторого баланса.
Релиз и обновления
После успешного тестирования игра была выпущена в раннем доступе. Это позволило получить обратную связь от реальных игроков и внести необходимые корректировки. Планируется добавление новых уровней и усложнение механики игры, добавлением нового функционала.
Заключение
Разработка City States Idle стала интересным проектом, который объединил элементы градостроительства и idle-геймплея. Продолжается работа над улучшением игры, основываясь на обратной связи от игроков и новых идеях для развития проекта.
Показать полностью
4
Архитектура управления сущностями на сервере
У проекта появилась чёткая архитектура управления сущностями. Теперь NPC, игроки, питомцы и другие объекты взаимодействуют в мире через систему менеджеров — рассказываю, как это работает.
В игровом мире есть разные типы сущностей: NPC, игроки (Player), питомцы (Pet) и другие. Каждая из них имеет свои состояния (движение, атака, бездействие) и требует управления.
Основные сущности и их поведение
• NPC – управляет собой (перемещение, атака, idle).
• Player – управляется игроком (те же состояния: ходьба, атака и т. д.).
• Pet – похож на NPC, но принадлежит игроку.
Менеджеры и их задачи
1. NpcManager – создаёт NPC, реагирует в случае смерти NPC.
2. PlayersManager – отвечает за вход игроков в мир.
3. PetsManager – управляет питомцами (аналогично NPC, но с привязкой к игроку).
4. EntitiesManager – главный координатор:
o Управляет NpcManager и PlayersManager.
o Обрабатывает взаимодействия (например, если игрок подошёл к NPC, оба получают информацию друг о друге).
5. VisibilityManager – отвечает за видимость объектов:
o Определяет, кто кого видит.
o Периодически обновляет списки видимости для оптимизации.
6. MovingManager – обновляет позиции всех подвижных объектов в мире.
Зачем это нужно?
Такая система позволяет:
• Эффективно управлять сотнями сущностей.
• Оптимизировать обновление состояний (движение, видимость, атака).
• Гибко добавлять новые типы объектов (монстры, питомцы, NPC-торговцы).
Блог про разработку сервера для Lineage 2 в телеге https://t.me/lineage2js
Показать полностью
Подводные камни при переходе с ES5 на ES6
🗿 Подводные камни при переходе с ES5 на ES6
Недавно мы с командой, наконец-то перешли с ES5 на ES6.
Всё прошло достаточно плавно, нам пришлось исправить всего несколько ошибок в рантайме. Почти все ошибки были в очень старых файлах, где были отключены проверки typescript с помощью @ts-nocheck.
Ошибка 1️⃣ — Action is not a constructor
Ошибка возникла в нескольких местах, где мы использовали стрелочную функцию в качестве конструктора. Раньше она не возникала, потому что стрелочная функция компилировалась в обычную function.
const Action = () => {}; // ES6
const action = new Action(); // Action is not a constructor
var Action = function () {} // ES5
var action = new Action(); // Всё ОК
Ошибка 2️⃣ — Функции, объявленные через let, больше не попадают в window
let openAction = function () {}
window.openAction() // window.openAction is not a function
// Раньше let заменялся на var и всё работало
var openAction = function () {}
window.openAction() // всё ок
Дело в том, что когда переменная объявляется глобально через var, она автоматически становится свойством глобального объекта window. Подробнее тут.
Ошибка 3️⃣ — Cannot access variable before initialization
Одна из ошибок случалась, когда мы пытались получить доступ к переменной promise до её инициализации.
class Queue {
executing;
run(thenable) {
const promise = new Promise(async (resolve, reject) => {
// пытаемся получить значние promise
while (this.executing != promise) {
// ...
}
// ...
});
}
}
// Cannot access 'promise' before initialization
new Queue().run(Promise.resolve())
Раньше, const превращался в var и ошибки не было. Это связано с понятием временной мертвой зоны TDZ, которая не возникает у переменных, объявленных через var.
Были и другие ошибки, но они по сути вариации или комбинации тех ошибок, что я привел выше.
👉 Кстатии, размер бандлов уменьшился процентов на 20.
#TypeScript #JavaScript
Показать полностью
1
Переезд с tailwind 3 на tailwind 4
Недавно обновляли корпоративную дизайн систему. Кроме чистки компонентов и их упрощения решили переехать с tailwind 3 на tailwind 4. В качестве сборщика у нас Vite, фреймворк Svelte.
В предыдущей версии компонентов мы не скупясь писали блоки стилей прямо в компонентах, применяя функцию tailwind @apply - это сильно причёсывает код в плане чистоты, как шаблона, так и чистоты стилей.
Стартанули мигрирование, прогнали миграционную утилиту от tailwind, все по православному, но - при запуске apply не работал и tw классы не резолвились. Пошли читать доку, вычислили новые правила про вызов функции @reference в каждом блоке стилей в компоненте. НО блэ, в доке приводят примеры:
либо ссылаемся относительным путём к своему конфигу tailwind @reference "../../app.css"
либо красиво и лаконично @reference "tailwindcss" - но тогда твой конфиг отваливается, корпоративные токены и вся прочая мишура остаётся за бортом.
Пошел гуглить, ведь наверняка есть варианты создать свой алиас, чтобы не писать относительные пути. Wasted несколько часов и стаканов кофе, чтобы найти решение в дебатах на github.
Добавляем в конфиг фреймворка алиас:
alias: {'corp-tailwind': './src/corp-tailwind.css'
},
В компонентах в блоке стилей пишем (у нас scss):
<style scoped lang="scss">
@ import "corp-tailwind" reference;
...
</style>
Почему такой пример нельзя было привести в документации tailwind, я так и не понял. Надеюсь, кому-то пригодится данная заметка.
Показать полностью