На ноде без async/await уже не обойтись. Кто писал линейный асинхронный код обратно к callback и promise hell не вернется

а чем тогда лучше вариант ждать нативной поддержки и подключать babel, если можно сейчас использовать генераторы, тот же co использовать?

Это как раз мелочи. Корутины много где на генераторах построены. Но конструкцию async/await можно и в c# увидеть и в scala и в python

а для продакшена делаете билд бабелем или подключаете babel-register?

Делаем либу серверную и к ней запускатор в es5

Генераторы не работают с классами, т е нельзя красиво сделать асинхронный метод класса, завёрнутый в co или подобное

почему не работают? метод может быть генератором

да, но нужно завернуть отдельно, или в конструкторе или прямо на прототипе

The V8 team is already working to bring upcoming features such as async /await keywords http://v8project.blogspot.com.by/2016/04/es6-es7-and-beyond.html

Обзор популярных библиотек и фреймворков для JavaScript #javascript Для быстрого решения большинства нетривиальных задач в JavaScript, как и в других языка, есть множество полезных библиотек и фреймворков. Библиотеки помогают быстро реализовывать отдельные функции в приложении, а фреймворки являются надежным фундаментом для построения приложений на их основе. Ссылка на пост https://vk.com/wall-54530371_68384

import не нужен :)

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

как связаны import и подключение к бд?

Да никак, это пример, в котором бывает нужно переменную экспорировать раньше, чем у нее будет байндинг на какое-то значение

http://geekforbrains.com/post/after-a-year-of-nodejs-in-production

Это можно делать и без import разными способами, но с import/export это родная фича, с которой все начинает смотреться стройно

циклические зависимости это само по себе странно

зачастую это говорит о проблеме

Да, но вот в некоторых случаях без них обойтись нельзя

очень в редких

обычно третье звено может помочь

например, нормальный di

если использовать di, то от импортов можно избавиться вообще

в JS да

в ts все равно импортировать интерфейсы нужно

Что-то я не верю в TS

Не видел ещё читабельного кода на TS

Не видел ещё читабельного кода на TS

Видишь постоянно. TS = ES6 + статическая типизация

Я про неё и говорю

ES6 => меньше кода

TS => больше кода

меньше кода != читабельнее

читабельность != язык

тебе тогда не в Relay :)

почему?

потому что там кода дохрена

В итоге кода меньше

Хотя по честному, могли бы ещё меньше

Ну знаешь, когда ты видишь что функция принимает и отдаёт, когда компилятор не даёт сделать тебе ошибку внутри, это много стоит в больших проектах

+1

Но у меня ожидания, что будет как с Flux = текущий Relay лишь первая итерация. Уже посматриваю на Apollo.

за пару месяцев я уже несколько раз поймал багу на этапе компиляции

Relay это мода. Не станет он мейнстримом потому что сложен

скорее всего да

но GraphQL должен

кстати.. graphQL database еще никто не написал?

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

коннекты скорее всего ест

я обычно к postgres прикручиваю

к какой-нибудь mongodb

Ну мы обсуждали что GraphQL это xpath для json. То есть в общем-то догоняем стандарты двадцатилетние

но если можно было бы сразу graphql данные вставлять было бы замечательно

сложно представить

https://github.com/solidsnack/GraphpostgresQL

ага. я эту видел

но это всеравно sql

Reindex.io под капотом держит MongoDB

я не люблю такое "чтобы само"

мне не горит, просто интересно :)

поэтому даже не тогал reindex

Да нормальные пацаны

пацанты то может быть и норм

Мне в целом нравится тенденция, что сейчас всё автоматизируется в разработке

Декларативность привела к тому, что меньше пишешь, больше думаешь

Плюс масштабируемость таких паттернов высокая

Но сложнее читать и понимать, что происходит

Если речь о GraphQL, мне кажется большинству он не нужен

Наоборот

Я помню jQuery-километры кода

Паш, ты ведь тоже помнишь? ;)

Сейчас с React всё крайне удобно читается и понимается

Ну это проблему решил реакт, тут не спорю. Но доступ к данным - более деликатная тема

Сопровождение на порядки проще, но требует уже куда более фундаментальных архитектурных принципов

Ну вот например у тебя реляционная СУБД - пробрасывать запросы с клиента никто никогда не мешал

Но проблема с безопасностью

SQL вообще был языком для менеджеров и далёких от IT людей :)

Если заменить SQL на GraphQL, приннципиально ничего не изменится

SELECT * FROM users

Это было в англоязычном мире, у нас бы это выглядело: ВЫБРАТЬ * ИЗ пользователей

1С

Большое приложение React/Redux в итоге состоит из набора однотипных операций

Command / Query

Ну в этом нет ничего декларативного, наоборот - простая архитектура за счет кучи бойлерплейта. И ничего плохого в этом нет

Сообщество пока не решило проблему с этим, но движение в этом направление как раз мы и видим)

По сути React = это конфигурция

(реальный bottleneck = анимация)

фронтэнд - это просто)

ахах

Как два лендинга сверстать

именно. можно долго обсуждать как и что круче, и быстрее, и правильнее, но реальность проста - можно и на джквери на колбасить, и половина веба так и работает

Так и есть, вопрос затрат. Большой проект на jQuery и большой проект на React = два разных бюджета на сопровождение. Но если бюджеты в ИТ понятие гибкое, то время часто критично и в этом плане введение и взаимозаменяемость разработчиков в React просто космос.)

Да не вопрос, я тоже считаю что лучше реакта ничего нет. Но все таки чат по бэкэнду, сложности фронтенда не идут с бэкэндам ни в какое сравнение

Фронтэнд в крайнем случае можно целиком выкинуть и переписать)

:)))

лол

бекенд фигня