Почему простые текстовые игры не пишут в браузере на javascript, используя другие решения

Question

Почему простые текстовые игры не пишут в браузере на javascript, используя другие решения

Данила Кудрявцев Ученик (103), закрыт 4 года назад

Javacript может обеспечить быструю разработку чуть ли не здесь и сейчас
Никаких приложений собирать не нужно, по скольку всё в браузере.
Остаётся лишь использовать 000webhost для загрузки в интернет бесплатно
Какие плюсы и минусы у этих вариантов?

Answer 1

Не забывайте, что до недавнего времени JS лишь представлял собой лишь помощник браузеру.
Сейчас есть множество игр, построенных целиком на JS, но буквально до недавнего времени JS не был столь мощным языком и не очень хорошо работал со сложной анимацией.
Для любых игр часто требуется сообщение с сервером, а NodeJS сравнительно молодая технология, и можно сказать, только сейчас набирает свою мощь.
В играх же часто используется анимация (если только это не совсем текстовой квест)
Canvas появился только с выходом HTML5, а этот стандарт принят был только с 2014 года.
Еще у JS есть минус в кроссбраузерности.
В результате использование целиком JS было на порядок сложнее, чем, например, flash технологии, которая так же легко позволяет работать в ней и дизайнерам-художникам, не требуя изучение тонкостей JS-анимаций и является универсальной платформой.

Answer 2

Фредерика Бернкастель Мудрец (10651) 4 года назад

Ну вообще-то, пишут¹.
И javascript в 2019 уже собирается (webpack, parcel, browserify, grunt, gulpjs, emscripten²)
И вместо 000webhost можно использовать и GH Pages, чтоб без рекламы и приколюх от хостингера (tm).

А вообще, если кто-то не хочет использовать js для таких задач, то это значит что он знает другой ЯП лучше и ему там удобнее писать.

Сноски:
¹Например, Milovana³, куча визуалок на MonogatariIO/KawaiiJS, CandyBox.
² Emscripten так-то компилирует не js, а код с других ЯП в wasm и оборачивает в js, что позволяет использовать Си++/Haskel/%YOURLANG% в браузере.
³ Переход по этой ссылке не рекомендуется по причине NSFW.

> Javacript может обеспечить быструю разработку чуть ли не здесь и сейчас
js-is-good-because-it-allows-to-write-code-faster.jpeg
Да, может обеспечить, зато код потом будет стрёмно поддерживать.

ЛоэнронПрофи (883) 4 года назад

>> Javacript может обеспечить быструю разработку чуть ли не здесь и сейчас
js-is-good-because-it-allows-to-write-code-faster.jpeg
> Да, может обеспечить, зато код потом будет стрёмно поддерживать.

Ну знаете, это субъективно. Если руки растут оттуда, на чем люди стандартной сборки сидят, но какой язык ни возьми будешь стрематься даже подойти к этому коду.
Хороший же JS код прекрасно поддерживается.
А все эти ваши жалобы " у него не строгая типизация переменных, как это "1" + 1 = 11 ???777семьсемьсемьадинадинадин " или "асинхронность убивает мне мозГ, где маи любимые потоки?! ааааа "
ну знаете... проблема скорее в негибкости ума, чем в самом языке.
Просто если брать те же игры, для JS не слишком много платформ, а технология three.js ну так себе, если честно.

Фредерика Бернкастель Мудрец (10651) > А все эти ваши жалобы " у него не строгая типизация переменных, как это "1" + 1 = 11 ???777семьсемьсемьадинадинадин " Нет, проблема именно в языке. Динамическая типизация это зло, которое используется только в несерьёзных вещах. Даже в php ввели строгую типизацию (strict_types + Type hinting) и в Python, а в JS нет (хотя есть TS/Flow/Dart, но их компилить надо блин). Конечно, если есть мозги (или eslint), то код можно писать более-менее сносно. Но вопрос, зачем всё это, если есть что-то получше? > асинхронность убивает мне мозГ, где маи любимые потоки?! ааааа Вот с этим не соглашусь, терпеть JS стоит чисто из-за возможности использовать лёгкую асинхронность (хотя иногда она бывает лишней и получается Callback hell, но это решаемо при помощи использования Promises + async/await).