На мой взгляд самый неочевидный момент с модулями, после common.js:
export const foo = bar;
!==
exports.foo = bar;
То есть:
// lib.js
export function foo() {}
// app.js
import lib from './lib';
console.log(lib.foo); // undefined
Это можно понять и по спекам и по вашей статье, но просто это немного необычно, после common.js, так скажем не ожидаемо. Но это легко исправить:
import * as lib from './lib';
Ну вот я и говорю, посмотрите аналогичный код на JS, по каждму аргументу тоже можно догадаться, что же там написано. И вместо того, чтобы работать надо каждый раз либо гадать, что же значит флаг, либо лезть в доки.
А если написать с длинными аналогами, то получится жесть:
Ну и самое главное. Специальные инструменты всегда будут решать задачу лучше, чем такие общие, как npm-scripts. Им можно заменить таск раннер, тут я согласен. Но им не стоит заменять систему сборки. Webpack, на пример, умеет запускать веб сервер и держать ваши css/js/html/etc. в памяти, что ускоряет процесс сборки и сберечь ваши ssd.
Посмотрел код, вроде es6, а вроде ужас какой-то. Нафига вы столько написали, когда как раз для описанных задач есть webpack. Где в 1 строку вписывается правило для сборки less или чего вы там еще хотите.
Эм, получается Xсode никак не подписывается и при отправке бинарника всем наплевать?
Давно же говорили, что надо искать дыры не в ПО, а компиляторах. Добавь в gcc такую фигню и миллионы серверов могут получить зараженное ядро.
Ну смотрите. youtrack.jetbrains.com/issue/WEB-14275 — небольшой баг es6 провисел у вас почти год. Есть четкое ощущение, что исключительно к релизу следующей версии IDE он был исправлен.
В текущем последнем EAP до сих пор не работают подсказки по es6 import, хотя функционал уже есть для require.
Под странными фичами я подразумеваю обновление внутреннего компилятора, когда весь мир сидит на gulp/webpack/grunt. Я просто не понимаю целевую аудиторию этой фичи. Я также не понимаю зачем релиз за релизом поддерживать по одной системе тасков, все те же gulp/grunt/webpack, когда есть задачи вроде качественной поддержки JS.
Тем не менее я понимаю, что JS гораздо сложнее поддерживать, чем php/ruby/python и возможно, даже, C++. Куча вариантов объявить одно и то же, куча вариантов экспортировать.
Что значит незаслуженно? Вся, то есть вот реально вся функциональность webstorm доступна в других IDE для веба. PHPStorm, PySharm, RubyMine — есть js по умолчанию и node.js плагином.
Плюс есть ощущение, что JS занимаются когда есть возможность, или нужно выпустить релиз. Потому что поддерижваются странные фичи, при отсутствии качественной поддержки современного JS, где код разделен на модули, у каждого файла свой скоуп. Минимально введите «get» у объекта. И получите список в 200 методов с префиксом get по всем вообще существующим объектам. Ну и ES6 поддерживается еле-еле. Грубо говоря в 10 WS поддерживается только синтаксис.
Вообще на это можно смотреть по другому. Если вы платите раз в год, как я понял, вы получаете свежий релиз на всегда. То есть оплачивая раз в месяц — вы просто оплачиваете рассрочку.
Скажите, а что будет, если по каким-то причинам я пропущу 1-2 месяца платежей, по различным причинам? По возобновлению платежей подписка восстановится? Как в этом случае вы поступаете с возможностью получить на всегда предыдущую версию?
На фоне сэкономленных на покупке средствах, эти траты кажутся незаметными.
На сколько я понял 6s будет стоить столько же, сколько сейчас 6. Если смотреть цену в России — 53 за 64gb. По текущему курсу (70р) 6s на предзаказ получается ~52.5. Где экономия-то?)
Плюс вроде как в US сторе цены без налогов, могу и ошибаться.
export const foo = bar;!==exports.foo = bar;То есть:
Это можно понять и по спекам и по вашей статье, но просто это немного необычно, после common.js, так скажем не ожидаемо. Но это легко исправить:
import * as lib from './lib';А если написать с длинными аналогами, то получится жесть:
Ну и самое главное. Специальные инструменты всегда будут решать задачу лучше, чем такие общие, как npm-scripts. Им можно заменить таск раннер, тут я согласен. Но им не стоит заменять систему сборки. Webpack, на пример, умеет запускать веб сервер и держать ваши css/js/html/etc. в памяти, что ускоряет процесс сборки и сберечь ваши ssd.
Вот вам аналогия для вашего кода:
Вам серьезно нравится такое читать? Ведь всегда можно заглянуть в документацию и узнать что же значат эти магические аргументы!
Давно же говорили, что надо искать дыры не в ПО, а компиляторах. Добавь в gcc такую фигню и миллионы серверов могут получить зараженное ядро.
В текущем последнем EAP до сих пор не работают подсказки по es6 import, хотя функционал уже есть для require.
Под странными фичами я подразумеваю обновление внутреннего компилятора, когда весь мир сидит на gulp/webpack/grunt. Я просто не понимаю целевую аудиторию этой фичи. Я также не понимаю зачем релиз за релизом поддерживать по одной системе тасков, все те же gulp/grunt/webpack, когда есть задачи вроде качественной поддержки JS.
Тем не менее я понимаю, что JS гораздо сложнее поддерживать, чем php/ruby/python и возможно, даже, C++. Куча вариантов объявить одно и то же, куча вариантов экспортировать.
Плюс есть ощущение, что JS занимаются когда есть возможность, или нужно выпустить релиз. Потому что поддерижваются странные фичи, при отсутствии качественной поддержки современного JS, где код разделен на модули, у каждого файла свой скоуп. Минимально введите «get» у объекта. И получите список в 200 методов с префиксом get по всем вообще существующим объектам. Ну и ES6 поддерживается еле-еле. Грубо говоря в 10 WS поддерживается только синтаксис.
На сколько я понял 6s будет стоить столько же, сколько сейчас 6. Если смотреть цену в России — 53 за 64gb. По текущему курсу (70р) 6s на предзаказ получается ~52.5. Где экономия-то?)
Плюс вроде как в US сторе цены без налогов, могу и ошибаться.