Почему я выбрал Next.js, а не Gatsby, Gridsome или Nuxt?

[DirectoriX]

Простите, конечно, но почему целые языки (.NET, Go, PHP, Ruby) сравниваются всего лишь с фреймворками на JS (Angular, React, Vue.js)? Неужели все эти JSные генераторы настолько заточены под одно семейство библиотек, что не в состоянии справиться с другим?
Мне действительно интересно, почему так раздробили JS (не фронтендер).

[bano-notit]

Да, генераторы заточены под конкретную реализацию конкретной библиотеки. Потому что у каждой библиотеки своя архитектура и свои инстурменты.

почему так раздробили JS

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

[AlexElkin]

Думаю дело не в языках, а в том что речь идет о статик сайт генераторах, а они перечислены в правой части таблицы и слева к ним приписаны технологии на которых они работают.
к слову есть ведь и для ванильного js свой ssg — 11ty

[js_n00b]

Короткий ответ на вопрос в заголовке для тех, кому лень читать всю статью: потому что в компании, где он работает, используют React

[devopg]

ктонибудь пояснит зачем выбирать next, а не vue?

[Bromles]

Конкретно в случае автора статьи — потому что у них в компании используют реакт.

Лично я бы выбрал Nuxt, но это скорее вкусовщина. Не люблю jsx, флешбеки к jsp сразу же возникают. А во Vue (который в Nuxt) нормальная организация кода, раздельная (хоть и тоже можно на jsx извращаться)

[cyc100]

Возможность комбинирования статических и динамических страниц

Такая возможность востребована при создании мультиязычных статических сайтов. Визуальное содержимое разноязычных страниц обычно одинаково.

Разные SSG предлагают разные решения по хранению media для разных языковых версий страницы, например:
создание общей папки и ручного прописывания путей — в таком случае теряется ассоциированность файлов со статьей или разделом (путь имеет вид "/assets/data/ru/post_id/media" вместо "/ru/post_id/media"), администрировать вручную становится сложно (тексты и media для страницы находятся в разных каталогах).

либо создание папки для каждой страницы и хранение media в ней. Однако в таком случае media-файлы дублируются (в каждой языковой версии файлы скорее всего будут одинаковые).

Если у кого-то есть успешный опыт создания мультиязычного сайта с помощью SSG, прошу поделиться, как Вам удалось реализовать хранение мультимедийных данных к страницам и публикациям?

Я пока встретил успешную реализацию только у Grav (однако, это не ssg, а flat-file cms) — тексты для каждой языковой версии разные и хранятся в одной папке, media находится в этой же папке.

Также важен fallback для отсутствующей языковой версии. В Grav fallback успешно реализован, а что насчет SSG? Есть ли у кого подобный опыт?
Спасибо!

[Bromles]

Замечу, что Nuxt.js поддерживает многие плагины, подключаемые к вью. Часть из них заранее адаптирована и доступна почти из коробки (npm install и все, можно использовать. Пример: @nuxt/axios, @nuxt/auth), часть прикручивается самостоятельно без особого труда (пример: PrimeVue)