React или Vue? Выбираем библиотеку для фронтенд-разработки

Можно хоть на чистом JS, конечно. Но только в процессе создания большого продукта Вы фактически создадите свой микро (или даже не микро) фреймворк, а потом кому-то не вам его поддерживать.
Знал бы только React и радовался, но нет, нужно ещё понять, что такое MyAwesomeFoo, YetAnotherBar, CoolBaz. Получается работы по изучению в 5-10 раз больше.

React или Vue? Выбираем библиотеку для фронтенд-разработки

Вы ж спросили про поисковики)
И так, как это делается в React: сервер отрисовывает полностью сформированную, готовую страничку и отдаёт её клиенту. Затем клиент получает эту страничку и иницилизирует SPA поверх уже отрисованного div'а, но так как данные на сервере и клиенте обязательно совпадают, то клиентский код получает точно такой же результат рендера, виртуальный дом видит что нет разницы, и перерисовки на самом деле не происходит. В результате этого клиент получает обычный SPA, очень красиво и незаметно

React или Vue? Выбираем библиотеку для фронтенд-разработки

Оба поддерживают server-side rendering (самый настоящий). Немножко про варианты решения проблемы с индексацией можно прочитать тут http://vuejs.org/v2/guide/ssr.html

Обзор 5 самых популярных JavaScript фреймворков и библиотек 2017

TypeScript лёгкий, когда с ним уже чуть-чуть поработал или есть кого спросить, с наскоку же понять, как написать свой *.d.ts для непокрытой сообществом библиотеки мне показалось несколько сложно. Тем не менее я всецело за TypeScript.

Между "своей реализацией MVC" и приколоченной гвоздями не лучшей реализации чего-то там существует разница. Совсем новичку, может и чудесно, когда его за ручку водят по "лучшим практикам", но ничуть не реже получается, что приходится бороться с тем, что тебе дали, вместо того чтобы взять то, что тебе подходит. Не вижу ничего плохого в том, чтобы иметь возможность, в зависимости от задачи и предпочтений команды выбирать между Baobab, MobX, Redux. Мне кажется, это именно то, что входит в понятие свободы.

а тот же react в > 90% идет только с нодой...

Причина совсем не в том, что React хочет NodeJS-бэкенд, а в том, что с React совсем не сложно получить серверный рендеринг, это у всех на слуху, и чего бы не спросить тогда с разработчика сразу и эту фичу?
Ну, а так, действительно, бэкенд никак не ограничивает, можно хоть Angular, хоть React

Обзор 5 самых популярных JavaScript фреймворков и библиотек 2017

Пожалуйста, раскройте мысль, почему "за уши"?

Неизменяемый JavaScript: как это делается с ES6 и выше

Конечно, с чего бы это оптимизатору js понимать что за ужс натворил писатель этого творения.

Object.freeze тоже совсем не обязательная вещь — глубокая заморозка очень дорогая вещь, она полезна на стадии разработки, но в продакшене мы даже не должны пытаться ошибочно изменять иммутабельный объект, или же мы совершим ошибку, за которую нас справедливо покарают исключением TypeError (в строгом режиме).

Т.е. моё мнение, что с Object.freeze хорошо тестировать код и находить ошибочные попытки изменить объект, но плохо костылить "иммутабельность" в продакшене

Неизменяемый JavaScript: как это делается с ES6 и выше

Вы, верно, троллите, если пишете, что не видите проблемы насилования устройства аллокациями в цикле

const newPerson1 = {...person};
delete newPerson1[property];

// vs

const newPerson2 = Object.keys(person).reduce((obj, key) => {
  if (key !== property) {
    return { ...obj, [key]: person[key] }
  }
  return obj
}, {})

Неизменяемый JavaScript: как это делается с ES6 и выше

const person = {
  name: 'John',
  password: '123',
  age: 28
}
const newPerson = Object.keys(person).reduce((obj, key) => {
  if (key !== property) {
    return { ...obj, [key]: person[key] }
  }
  return obj
}, {})

А это вообще нормально N-1 раз копировать объект, добавляя по одному свойству за итерацию?

Async/Await в javascript. Взгляд со стороны

Цепочка промисов через then выполняется последовательно, параллельным является Promise.all, например. И он прекрасно сочетается с async/await, например,:

await Promise.all([ajax1, ajax2])

Можете привести пример кода из "сложного Ajax приложения, делающего вызовы по возможности параллельно"? Я не понимаю за счёт чего оно внезапно станет "по-умолчанию" параллельным на промисах?

Что нового в IntellIJ IDEA 2016.3 EAP

Дополнительно протестил, похоже проблема и здесь в 'use strict', без него, когда flow начинает работать, всё становится чудесно

Что нового в IntellIJ IDEA 2016.3 EAP

Спасибо, отличная новость.

Что нового в IntellIJ IDEA 2016.3 EAP

Да, всё как в посте: /usr/bin/flow и его же запускал в терминале. Версию JavaScript указал верно.

Кроме этого, интересует, что означает опция Enable flow resolve, в примере с testFn оно так агрессивно пытается резолвить, что ругается даже на string из аннотации функции.

Что нового в IntellIJ IDEA 2016.3 EAP

Flow всё так же не работает, или есть какой секрет по настройке?

'use strict';

// @flow

function testFn(): string{
    return 5;
}

Для ide всё ок, а для flow из терминала ожидаемый:

test.js:6
  6:     return 5;
                ^ number. This type is incompatible with the expected return type of
  5: function testFn(): string{
                        ^^^^^^ string

Found 1 error

Выбираем состав изоморфных React-приложений на следующие 12 месяцев

Для этого source maps существуют, которые покажут где был создан .myClass_test-2hscR из :local(.myClass)

Если этого недостаточно, то можно так:

https://github.com/webpack/css-loader#local-scope

You can configure the generated ident with the localIdentName query parameter (default [hash:base64]). Example: css-loader?localIdentName=[path][name]---[local]---[hash:base64:5] for easier debugging.

Что означает буквально следующее: вы можете собрать отладочную версию хоть с вот такими классами .app-components-test---myClass---2hscR

Выбираем состав изоморфных React-приложений на следующие 12 месяцев

Спасибо, теперь понятно ваша проблема. Если модули чисто от CSS, то действительно боль может выйти, согласен, но в случае того же React этот модуль должен был импортироваться там же, где и объявляется сам компонент, т.е. в общем то ищем где рендерится эта кнопка, а там уже и найдём концы.

import styles from './styles';  // <= Здесь концы

...

render(){
    return (
        <div class={styles.panel}>
            <button  class={styles.button}/>
        </div>
    );

}

Выбираем состав изоморфных React-приложений на следующие 12 месяцев

этот стек

Окей, первоначально воспринял коммент как критику непосредственно перечисленных в нём проектов. Если же воспринимать с позиции "автор топика собирает этот стек для проектов на год (что всё равно не легко с учетом постоянных хайпов)", то да, полностью согласен

Выбираем состав изоморфных React-приложений на следующие 12 месяцев

void хорош, но довод был в целом не про то, что мы можем как то писать или не писать, а про то как писать так, чтобы не рисковать неоднозначной трактовкой кода.

Боюсь только тема слишком холиварная, а рассуждений обеих сторон вполне хватит на stackoverflow в тематических вопросах.

Выбираем состав изоморфных React-приложений на следующие 12 месяцев

Да не, на год вполне еще можно планировать. Правильные технологии за год не протухнут окончательно, хоть и не будут уже вызывать энтузиазма.

Выбираем состав изоморфных React-приложений на следующие 12 месяцев

О, можно подробнее развить мысль? Мне глобальные переменные как раз таик неприятны из-за возможных конфликтов имён, тогда как локальные стили позволяют мне с большой долей уверенности подключать компоненты из разных источников, написанных разными людьми и не бояться что они переопределят стили друг друга

Выбираем состав изоморфных React-приложений на следующие 12 месяцев

const myFn = function () {
  alert("Surprise!");
} // <-- No semicolon!

(function () {
  //...
})();