affka6 окт 2015 в 16:40

Jii: Полноценное приложение с архитектурой Yii2 в браузере

4 мин

19K

Комментарии 28

SerafimArts 6 окт 2015 в 21:19

Предлагаю постараться и перейти на ES6\7 с бабелом в виде компилятора. Всё же он будет в разы ближе к php, нежели текущий ES4\5, да и удобнее — это уж факт. С другой стороны там выхлоп километровый, но со временем он минимизируется, учитывая то, что код на перспективу, а куски ES6 уже в некоторых браузерах реализованы.

affka 7 окт 2015 в 07:32

Много обсуждалось уже, много чего лучше стало с выходом nodejs v4, но еще далеко до идеала. Есть стоперы, из-за которых я не хочу переходить на es6:

Нужно компилировать под node.js. Компилированный код очень плохо дебажится, если библиотека подключена как зависимость. А я очень часто смотрю в исходники библиотек, чтоб понять что они делают.
Отсутствие неймспейсов. Нет возможности сделать ленивую автоподгрузку классов по мотивам PHP, import просто не умеет динамически подгружать модули. Отсюда и невозможность по строке подгрузить класс (в конфигурации Yii обычно указываются классы для создания компонентов/модулей/..)

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

hell0w0rd 7 окт 2015 в 08:30

Хоть я и не одобряю как yii, так и вашу поделку, осмелюсь спросить — а чего сложного в дебаге скомпилированного кода из es6 в es5? Есть сорсмэпы, да и babel генерирует понятный, читабельный код. Это вам не coffee.
Зачем вам в node ленивая подгрузка модулей? В php она нужна, потому что на каждый запрос новая инициализация, а зачем такое вам?

affka 7 окт 2015 в 08:50

А вы подебажьте сперва такой код, тот же babel добавляет кучу мусора (хоть и необходимого), чтобы сделать правильный mapping es6->5, это все сильно ухудшает чтение кода!

hell0w0rd 7 окт 2015 в 09:00

Я пользуюсь babel еще тогда, когда он был в 3 версии и назывался 6to5. Я отлично знаю, как с ним дебажить.
Покажите мусор, покажите что не работает. Хватит бросаться словами на ветер.

affka 8 окт 2015 в 08:00

В итоге зря меня заминусовали. Пообщавшись с hell0w0rd, выяснил следующее:
— отладка по es6 коду все же не возможна (именно в формета es6), потому что node запускает только скомпилированный код. И все что остается — добавить babel-runtime, loose mode, и т.п. чтобы сделать более читаемым. Но это не одно и то же!
— мусор это код, который получается когда вычитаешь из es5 кода es6 (diff). По ссылочке ниже "Вот так правильно" можно легко увидеть что добавляется. Все что добавилось — мусор/шум/необходимость — называйте как угодно, он ухудшает чтение кода.
— IDE пока еще плохо понимает es6 код (вылечится со временем), а скомпилированный код вообще не понимает! Возьмем за пример модуль postcss, написанный на es6 и компилируемый при публикации в es5. Т.е. когда я делаю npm install postcss — я получаю es5 код. В данном случае по нему работает документация, потому что там добавлена папка d.ts. Но делать такую папку в проектах — это большой труд, не говоря о том, что его нужно поддерживать. А без нее IDE уже ничего не знает.
В Jii же, использует jsdoc, который писать и поддерживать проще (т.к. jsdoc непосредственно в коде описывается) и IDE его отлично понимает, прекрасно работает навигация по коду и автоподсказки! И вы мне предлагаете перейти на es6, где этого нет!
— По неймспейсам — да, в какой-то мере это можно заменить модулями, вложенными по папкам. Но их прийдется подключать в каждом файле. В PHP, например, подобным образом прописывается use ...; в начале файла, но он там прописывается автоматом, как только ты прописал new MyClass и нажал Ctrl+Space. Для JS такого нет (хотя есть тикет с этой фичей в idea, может запилят когда-нить). Мое решение с неймспейсами позволяет не подключать все подряд.

Если кто знает как можно подключить sourcemap для Php/Webstorm, например, чтобы IDE при переходе к определению метода переходила на код es6 — поделитесь решением. Или ссылку на пример дайте, где это реализовано.

hell0w0rd 8 окт 2015 в 10:28

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

Попробуйте babel-node, там используется библиотека node-source-map-support и сорсмэпы работают.
Чтение кода ухудшает использование ES5, по сравнению с ES2015. Мне почти не приходилось дебажить свой код, все решалось написанием тестов.

Я пока отвечал вам на все это, пришел к мнению, что вам нужно перейти на typescript. У него существенно лучше поддержка в IDE и редакторах, тк по языкам с типами и детерминированными конструкции для импортов/экспортов функций/классов гораздо проще сделать все удобные штучки для IDE. Лично для меня в этом языке только async/await не хватает.

affka 8 окт 2015 в 11:18

Здесь написал для того, чтобы минусовщики тоже увидели. Это не ссор, это обсуждение.
1. babel-node пробовал, да. Вот только он бесполезен если подключать модуль как внешнюю библиотеку, т.к. там код уже скомпилированный в es5. Или как-то можно хитро прописать переключатель? Хотя в любом случае костыльно… Это еще каждому разработчику пойди объясни все это.
2. А написание тестов чем спасает? Вы же в процессе написания тоже дебажите, когда ошибка возникает. От тестов, конечно, зависит, но далеко не всегда по тексту ошибки понятна ее причина.

У TypeScript куча других минусов (помимо плюсов), главный из которых — невозможность подключить любую библиотеку, нужно писать адаптер и расписывать типы.

hell0w0rd 8 окт 2015 в 11:27

Перечитайте первый пункт моего ответа. node-source-map-support подключить можно и без babel-node.
Тесты спасают 90% случаев. Если, конечно, разбивать все на маленькие модули и тестировать все по отдельности. У меня раз в неделю-две возникает необходимость что-то дебажить, в остальном решается либо тестами, либо console.log банально. Для меня это выбор — писать на приятном глазу языке, или расставлять костыли для IDE. Каждому свое.

А вы как будто не расписываете типы, чтобы можно было использовать библиотеку с вашей точки зрения (вы написали что без автокомплита не можете программировать)?.. Ну и есть огромный репозиторий .d.ts файлов почти на все популярные библиотеки. Постоянно обновляется и дополняется. Им, кстати, пользуется js плагин в idea.

SerafimArts 7 окт 2015 в 10:04

Babel генерирует понятный код в отличие от coffee? Я не ослышался? Феерическая глупость. Берите любой пример, на кофе он будет в разы лаконичнее и понятнее. https://gist.github.com/SerafimArts/9e24db3ad5e71e0b3431

hell0w0rd 7 окт 2015 в 10:11

Феерическая глупость — использовать инструменты без чтения документации. Советую ознакомиться с loose mode, зачем он нужен и почему по дефолту без него.
Вот так правильно

SerafimArts 7 окт 2015 в 10:20

Согласен, он делает код намного более читаемым, моя вина, не знал об опции. Но всё равно выхлоп у кофе будет лакончинее, хоть и не на много, особенно в таких вещах:
http://babeljs.io/repl/#?experimental=true&evaluate=true&loose=true&spec=false&code=var%20a%20%3D%20[1%2C%202%2C%203]%3B%0A%0Afor%20%28var%20i%20of%20a%29%20{%0A%20%20console.log%28i%29%3B%0A}

http://coffeescript.org/#try:a%20%3D%20%5B1%2C%202%2C%203%5D%3B%0A%0Afor%20i%20in%20a%0A%20%20console.log%20i

P.S. Согласен, что у кофе не учитывается Symbol.iterator, что и даёт излишний код в случае babel. Но это не отменяет того, что кофе всегда будет лаконичнее на выходе.

hell0w0rd 7 окт 2015 в 10:27

Ну конечно лаконичнее. Ведь код babel и код coffee делает разные вещи. for-of — синтаксис для обхода итераторов, а for-in в coffee — для массивов. Подучите матчасть по javascript.
Вот вам примерчик:

const numbers = new Set([1, 2, 3]);
for (const num of numbers) {
  console.log(num);
}

А вот вам вдогонку пример, как coffee убивает производительность вашего кода:

// coffee
foo = (args...) ->
  console.log(args)

// js
var foo,
  slice = [].slice;

foo = function() {
  var args;
  args = 1 <= arguments.length ? slice.call(arguments, 0) : [];
  return console.log(args);
};

SerafimArts 7 окт 2015 в 10:39

Я так понимаю по примеру, что есть какая-то проблема в slice.call? Т.к. babel возвращает результат в виде цикла по аргументам:

"use strict";

var foo = function foo() {
  for (var _len = arguments.length, args = Array(_len), _key = 0; _key < _len; _key++) {
    args[_key] = arguments[_key];
  }

  console.log(args);
};

hell0w0rd 7 окт 2015 в 10:42

github.com/petkaantonov/bluebird/wiki/Optimization-killers#32-leaking-arguments

SerafimArts 7 окт 2015 в 10:55

Из примера я понял, спасибо, что подобный код был специально реализован в виде цикла ради какой-то оптимизации, но что подразумевается под «утечкой аргументов» (leak arguments)? Не все аргументы возвращаются после slice и некоторые «утекают»? Это всё, что могу предположить.

hell0w0rd 7 окт 2015 в 11:08

В кратце — использование arguments вне функции (возвращение из функции, передача в качестве параметра, использование в замыкании), все это не дает v8 (и возможно другим движкам) оптимизировать функцию.

SerafimArts 7 окт 2015 в 12:18

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

SerafimArts 7 окт 2015 в 08:36

1) Source maps. Не знаю как в ноде, но в браузере они показывают проблемы в исходном файле, а не скомпилированном. Т.е. выхлоп смотреть не нужно, слава всевышнему.
2) Автолоада нет, но вполне возможно написать массив из нужных путей и сделать его подгрузку:

var classes = ['Some/Any'];
...
classes.forEach(name => {
    var cls = require(name); // В случае, когда класс указан как `export default class`
    var instance = new cls;
});

affka 7 окт 2015 в 08:53

1. А мне вот как раз для node.js и интересно. Плюс такого точно не будет для отладки в режиме реального времени, когда хочется посмотреть какие данные пришли в точку останова.
2. Тоже костыль еще тот, некоторые люди заботятся о потребляемой памяти (особенно когда есть только shared хостинг), и такие люди уже обращались с замечаниями, что они хотят подключать только то, что будет использоваться — github.com/jiisoft/jii/issues/16

hell0w0rd 7 окт 2015 в 09:11

Это не забота о потребляемой памяти, это техническая неграмотность. Любой node сервер работает в асинхронном режиме, а require — синхронная функция. То есть так или иначе в какой-то момент весь ваш код будет загружен в память, и именно в момент подгрузки ваш асинхронный код залочится, а для кого-то это может быть критично, а не пара мегабайт байткода.

hell0w0rd 7 окт 2015 в 08:38

Ах да, и неймспейсы не нужны.

const EventListener = require('react/lib/EventListener');

У вас есть файловая система и common.js/es2015 modules.

SerafimArts 7 окт 2015 в 10:26

Добавлю, что ES7 я не просто так упомянул. В нём есть безумно крутая штука, называемая декораторами, что позволит писать ещё более приближённые к исходнику вещи, например определять абстрактные методы: https://gist.github.com/SerafimArts/c418e63a2a5ce0be75e5