Если человек хочет писать на новом синтаксисе, пусть пишет.

export default потому что

на бакенде пользы никакой

Какая разница где

export default это огромный жирный плюс для построения красивых и удобных api

export default это огромный жирный плюс для построения красивых и удобных api

и в чем плюс в двух словах?

что можно делать require() и require().something одновременно?

не вижу большого жирного плюса

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

import { cube, foo } from 'my-module'; const cube = require('my-module').cube; const foo = require('my-module').foo;

за сахар сканает, не больше

default

Это слово я не просто так дописал, ага

ты думаешь, что оно решает?

оно ничего не решает

import the default export: export default function cube(x) {} import cube from 'my-module'; module.exports = function cube(x) {} const cube = require('my-module');

Разумных причин использовать import нет, только эстетические

а по поводу всего остального —harmony

в ноде пишут уже поддержку ES2017

а 2015 работает с 6-й версии по умолчанию

Иногда получается циклическая зависимость и import ее разруливает в разумных пределах

Иногда получается циклическая зависимость и import ее разруливает в разумных пределах

import не может разруливать ничего

разруливает движок

гениально

он и при require разрулит

используя require тоже можно разрулить, но код будет ужасный

пахнет проблемами архитектуры

я про те случаи когда это может понадобится

это какие же

с import такие случаи не пахнут проблемами

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

Например в одном файле ты описываешь конструктор. Есть другие файлы, которые содержат метода, которые ты в первый файл импортишь и ставишь их в качестве методов прототипа этого конструктора. На данном этапе ситуация пока ясна, верно?

типа трейтов?

В питоне как-то импорт более правильно работает. В начале говоришь откуда, потом что. В JS - в начале что, потом откуда. Никакого автокомплита :(

типа трейтов?

Да, типа трейтов

В js импорт гораздо лучше питоновского

в питоне всю строку переписать надо

В питоне как-то импорт более правильно работает. В начале говоришь откуда, потом что. В JS - в начале что, потом откуда. Никакого автокомплита :(

наоборот, сразу же видно что ты импортишь и потом откуда)

И эти короче методы делают всякие шутки полезные. Какие-то из них например в качестве аргументов принимают объект. И в зависимости от его инстанса делают ту или иную штуку. И один из этих методов как раз хочет проверить объект на то, является ли он инстансом того конструктора, о котором мы говорили. Так что бы это сделать, нужно тот конструктор заимпортить, а как его заимпортишь если он еще там undefined )))

упс, простите

случайно*

Да, типа трейтов

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

так вот жеж последнее мое собщение читай

так вот жеж последнее мое собщение читай

ох.. я думал это копипаста

"И эти короче методы делают всякие шутки полезные. " ПЫЩ ПЫЩ КРОВЬ КИШКИ

сарказм не понятен

а вообще не плохой комментарий по поводу импортов и циклическиз зависемостей ))) конкретно, по делу )) приятно общаться.

аргументировано. обожаю разговоры в подобном русле с коллегами

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

.constructor.name есть в принципе, если извращаться с кривой постановкой

а, да, вспомнил

const base = require('base'); const trait = require('trait')(base);

в trait же module.exports = function(base){ return ; }

так что разрулить можно

начнем с того, что все гораздно проще получается, если module.exportы ставить раньше чем require

так делаю тоже

кому?

в чем простота заключается?

начнем с того, что все гораздно проще получается, если module.exportы ставить раньше чем require

в trait как бы вообще require не требуется base в этом случае, я так и не понял о чем речь

import { cube, foo } from 'my-module'; const cube = require('my-module').cube; const foo = require('my-module').foo;

const { cube, foo } = require('my-module');

Иногда получается циклическая зависимость и import ее разруливает в разумных пределах

с бабелем-то?

он тупо в require переводит.

Вопрос не зачем импорт, а зачем на бэкенде аналог импорта реализованный бабелем.

ERROR: S client not available

На бэке да, import не нужен/

Не сам импорт, он вполне может быть и нужен потом. А вот транформ от бабеля на бэкенде непонятно зачем вообще.

*трансформ

то есть на бэке лучше совсем без бабеля? чисто вазможности ноды?

Ну конечно

Может быть еще вебпаком собирать ?

Ну, имхо, разницы особо нет, все равно для отладки сервак запускать через babel-node, а полностью билдить только при деплое, так что наличие бабеля на процессе разработки особо не сказывается

Если хочется юзать все новейшие фичи языка - бабель в руки

Если такой потребности нет - то и нет нужды в бабеле

Вобще странный спор

Но отправлять в продакшн код с фичами меньше, чем stage-4 все равно как-то не очень

Апи меняются, фичи переделываются

Так что если поиграться - то ок, в прод отправлять такой код достаточно опасно, как по мне

то есть на бэке лучше совсем без бабеля? чисто вазможности ноды?

async/await таки нужен

Я не говорил, что трансформы не нужны, я говорил что трансформы для поддержки обрезанного import на бэкенде не нужны.

Но отправлять в продакшн код с фичами меньше, чем stage-4 все равно как-то не очень

Ну, смотря какой продакшн.

stage-3 достаточно стабилен

Привет, прохожу курс Ильи Кантора. Сейчас на третьем уроке по созданию чата. Использую VS как IDE. Вопрос, у кого то возникали трудности с подключением к page.ejs стилей и скриптов?

Кроме nodeschool и доков ещё есть что-нибудь хорошо написанное?

Хотя бы в стиле официального реакт-туториала

По ноде?

Да

А для какой цели?

Быстро врубиться в основы и что-нибудь на нем сделать,какой-нибудь todo с react+node

Книги практически все устаревшие

ну смысла книги читать никакого. Но с react + node лучше стартер взять и код читать примеров. Если сам по себе Node то тут стоит начать типа как работают промисы и про сами по себе библиотеки изучить API и дальше очень сильно зависит от задачи, если хочешь загоняться то нужно типа читать код v8 или чуваков которые шарят в его коде ._.

ну смысла книги читать никакого. Но с react + node лучше стартер взять и код читать примеров. Если сам по себе Node то тут стоит начать типа как работают промисы и про сами по себе библиотеки изучить API и дальше очень сильно зависит от задачи, если хочешь загоняться то нужно типа читать код v8 или чуваков которые шарят в его коде ._.

Например,этот стартер? https://github.com/kriasoft/react-starter-kit

> @klond90 читать код v8 обязательно, без этого вообще на node.js лучше не начинать писать

ну для тех кто загоняется

:о

я загонялся мне было интересно :(