Pull to refresh

Comments 93

Такими темпами роста скоро придется переучиваться многим js-программистам. Не только им, по идее, это в придачу может подстегнуть Opera и Firefox к реализации аналогичного функционала. Ушел щупать…
Firefox уже давно пацаны ваще ребята.
Человек прав, я многое из топика пробовал ещё в 3-ей версии Firefox.
Собственно, Мозила и есть основной разработчик нового «стандарта».
Да, согласен. Но Хром — «законодатель клубной моды», если он не зачешется, то остальные тоже ничего не будут делать.
Нормальные классы, модули, итераторы, приватные свойства! Сколько раз уже обещали это в JS все кто только могут. Но пока нигде не видать :( А ведь если бы это все было, то, пожалуй, JS можно было бы назвать лучшим языком в своем роде.
а там есть ненормальные классы? =)
это называется EcmaScript 4, реализация которой — ActionScript 3, JScript.NET.
Ну так это только в dev версии (и то небось не до конца доделано), пользоваться то этим пока все равно нельзя.
В том как сейчас есть своя таинственная прелесть этого языка :)
А зачем нормальные классы и самое главное, приватные свойства?
Для лучшей читабельности исходников сложных проектов.
Например, если открыть исходник какого-либо модуля на JS, очень сложно понять его API, во-первых, потому что прототипы каких-либо его объектов могут быть расширены в любом месте кода, во вторых из за того, что мало ясно, что предназначено для внутреннего пользования, а что — для внешнего. С четко регламентированным синтаксисом классов, модулей и приватных функций это проще.
Для этого достаточно внутренние методы и свойства именовать с подчёркиванием _method
А можно запихивать функции внутрь других функций. А можно писать в JSDoc'е перед ними /** @private */. А можно писать комментарий вначале — «не трогать!». В том то и проблема, что все делают по разному, а хочется, чтоб везде все было одинаково. Просто и понятно.
Подчёркивание в имени — стандартный способ. Его же используют и в других динамических языках.
Ну я на самом деле больше ратую за традиционные модульность и классы. С подчеркиванием вначале приватных свойств еще жить можно :)
Ну то есть ООП в JS нужен только из-за вопросов консерватизма. Чтобы мол было «как в Java и .Net»? Давайте тогда и остальные ООП подходы выбросим ;).
Да есть там ООП. Просто способов описания «классов» слишком много. И их код выглядит как-то не очень, они больше похоже на хаки… Поэтому я и предлагаю остановится на одном очевидном способе, который зарекомендовал себя в всех Явах, Сях++, Питонах и т. д.
… и больше не развивать языки :).
Просто синтаксис задавания классов слишком фундаментален, что бы было куда его развивать. Оператор присваивания тоже был придуман много лет назад, и как-то до сих пор никто не решил от него отказаться.
А вот другие, более прикладные вещи, конечно надо развивать, более того, в JS многие вещи и развиты больше чем в других языках.
ООН не такой фундаментальный, как Вы думаете ;). В Python и Ruby очень другой подход к ООП. Во многих ФП языках прекрасно обходятся без ООП, а в Erlang вообще, можно сказать, что каждый процесс — это объект.
Только вы так и не объяснили, зачем вам нужны классы. jQuery прекрасно работает и без них.
Ну так и исходник jQuery для неподготовленного человека практически не читаем. Далеко не все поймут, где там какие функции куда запихиваются, и что где происходит. А если бы код выглядел, например, как описание класса jQuery-коллекции в традиционном синтаксисе, то все было бы просто и понятно с первого взгляда.
jQuery я привёл как пример внешнего API, которое нормально работает без классов и т. п.

Код jQuery и в классическом ООП был бы сложен, так как она сильно оптимизирована по размеру и скорости.
Ну jQuery лучше оставить как есть, ибо сейчас там в коде есть такие выкрутасы, которые традиционным ООП-языкам не снились и в страшном сне, и оттого она такая маленькая и производительная.
Но в более высокоуровневых модулях, на мой взгляд, подобное лучше не применять, чтоб каждый мог открыть исходники и сразу понять: вот это модуль, который отвечает за то-то, называется так-то. В нем есть 4 класса, каждый из которых отвечает за то-то и то-то.
Открываем ваш модуль, и сразу видим window.Visibility = {/*...*/}. То есть у меня уже забит глобальный объект Visibility и мне никуда от этого не деться. Я не смогу использоваться 2 модуля с одинаковым названием.
Как должно быть: модуль должен только лишь объявлять какой то объект, который я могу при желании импортировать в свой код, под произвольным именем и только после этого использовать. И для этого необходим какой-то стандартный механизм, чтобы каждый не изобретать что-то новое. Что-то подобное как раз и предлагается в «новом» явасрикпте.
Это прекрасно решено в node.js без всяких ООП. Просто для такого нужен прямо доступ к ФС, что в Вебе понятно нет.
Приватные методы и свойства удобны для реализации модульности, изоляции. В крупных проектах, где отдельные группы разработчиков работают на разных уровнях, это может быть проблемой. Технически, снаружи путём перебора свойств, можно добраться черти куда и поломать там все.
Конечно JS позволяет реализовать приватные методы через замыкания, но это не всегда удобно и читабельно.
Достаточно просто указать, что эти свойства внутренние. Например, через подчёркивание в имени.
Вы рассматриваете идеальную ситуацию, когда умный сказал глупому:
-«не бери».
Тот не взял.
В жизни, когда десяток другой программистов работаем над большим проектом, обязательно найдется персонаж, который вместо того, чтоб сделать запрос на доработку функционала «ядра», возьмет и сочинит пару костылей. И после того как у него заработает, не факт, что не упадет в другом месте.

ИМХО, получить ошибку от интерпретатора в данном случае будет гораздо лучше.


Он точно так же может и захачить объект, дописав или переписав динамически методы.
обязательно найдется персонаж, который вместо того, чтоб сделать запрос на доработку функционала «ядра», возьмет и сочинит пару костылей

Этот же персонаж в Джаве рефлексией может получить приватные свойства. И что теперь?
Ну я не думаю, что рефлексия есть распространенная технология среди junior разработчиков.
На мой взгляд, это разные уровни сложности: рефлексия java(вообще любая рефлексия) и «посмотреть в firebug и перебрать по цепочке».

Что плохогов том, что можно посмотреть в Файрбаг и перебрать по цепочке?
Тут не стоит вопрос «возможно ли вообще?», технически возможно везде, тут скорее «насколько легко ?»
Плохой человек, всегда нагадить сумеет ;).
Нет, тут как раз стоит вопрос «возможно ли вообще». Везде возможно, так что теперь? Просто не надо с мудаками работать.
Итераторы есть в CoffeeScript, как и синтаксис нормальных классов.
Да, но это целый дополнительный язык, на котором надо все переписывать, который надо изучать, который надо поддерживать и т. д. В больших проектах от него будет больше проблем, нежели пользы.
Переписывать ничего не надо — в нём можно так же легко использовать JS код. И это не отдельный язык, а просто альтернативный синтаксис. Так что изучение занимает пару дней.
И компилировать его надо для всех браузеров, + var в кофескрипте нет. Нет, кофескрипт не юзабелен.

Кстати, я не нашел, собираются ли разработчики Хрома реализовать альтернативный синтаксис функций вида (x) -> x*x. В кофескрипте, вроде-бы они есть.
В том-то и дело, что var нет, так как CoffeeScript сам его ставит. То есть вы никогда не забудете его написать.

Для всех браузеров в отдельности компилировать не надо — достаточно один раз откомпилировать. Если у вас серьёзная разработка, то так и так есть минимизация и сборка статики — так что ещё один шаг с компиляцией не доставит никаких проблем. В Ruby on Rails это вообще работает из коробки и прозрачно для разработчиков.
> В том-то и дело, что var нет, так как CoffeeScript сам его ставит. То есть вы никогда не забудете его написать.

В sctict mode я его тоже никогда не забуду поставить. Зато могу контролировать область видимости.

> Для всех браузеров в отдельности компилировать не надо — достаточно один раз откомпилировать.

Я к тому, что ни один браузер не хавает Coffee по умолчанию, и никогда не будет. И да, я всегда хотел узнать, но никогда не получал ответа :) Как отлаживать программу на Coffeescript? Вот, допустим, я пишу на JS у меня возникла ошибка. Смотрю в консоль, ошибка в строке XX. А как с этим обстоят дела в Coffee?

С отладкой сейчас: вы смотрите строку, где произошла ошибка и открываете её в CoffeeScript. CS — просто альтернативный синтаксис, там сразу понятно, какая строка JS за какую в CS отвечает.

С отладкой через год: в Хроме уже начали реализовывать поддержку технологии, когда в отдельном файле указывается каким строкам JS’а какие строки в других файлах соответствуют. Это не только для CoffeeScript, но и чтобы нормально отлаживать обусфуцированные и сжатые файлы в production (когда баг не повторяется локально).
> С отладкой сейчас: вы смотрите строку, где произошла ошибка и открываете её в CoffeeScript. CS — просто альтернативный синтаксис, там сразу понятно, какая строка JS за какую в CS отвечает.
То есть оно не убирает переносы и не добавляет новые?
Тот же пример:
outer = 1
changeNumbers = ->
inner = -1
outer = 10
inner = changeNumbers()
var changeNumbers, inner, outer;

outer = 1;

changeNumbers = function() {
var inner;
inner = -1;
return outer = 10;
};

inner = changeNumbers();
Здесь демонстрируется добавление новых строк. Вот возникла у меня ошибка в строке 5 скомпилированного кода, а в CS она соответствует строке 3. Или с этим всё в порядке? Возникла в третьей, значит в CS она же в третьей?
Сорри за переносы, я тупо копировал с офф сайта.
Нет, номера строк сдвинутся. Вы просто смотрите, что проблема в строчке «inner = -1» и находите её примерно в том же месте в CS — не так удобно, но скоро будет исправлено на уровне отладчика.
В ES.Next такой альтернативный синтаксис только для однострочных функций. В CoffeeScript же всегда можно пистать меньше символов.
Можно, но можно и запутаться, где что.
changeNumbers = ->
inner = -1
outer = 10
inner = changeNumbers()

Без фигурных скобок нифига не понятно. Плюс, я хочу чтоб функция ничего не возвращала (точнее андефайнед), в JS я просто пропускаю return XX, а в Coffee нужно писатьchangeNumbers = ->
inner = -1
outer = 10
undefined
inner = changeNumbers()
Питонисты как-то понимают всё прекрасно на основе отступов :). Вопрос привычки, которая формируется за день программирования.

CoffeeScript про return наследует идею из Ruby, где всё возвращает значение. В любом случае (хотя я не понимаю, зачем вам нужна функция, которая всегда ничего не возвращает), вы привели редкую ситуацию — и лучше один раз в год написать undefined, чем каждый час писать лишний return.
Не хочется ввязываться в этот холивар, но и мимо пройти не получается ))
Важность return в читабельности. Например, в питоне отказались от слова new — и, казалось бы, все живы, но читабельность (сугубо ИМХО) подпортилась.
Грепанье кода глазами пока так и не отменили :)
Не очень понял, зачем грепать return. Достаточно посмотреть в конец функции.
>>Переписывать ничего не надо — в нём можно так же легко использовать JS код.
Чем больше языков используется в проекте, тем сложней его поддерживать. Пусть даже один из них компилируется в другой.
Согласен, что лишний раз новый язык лучше не вводить. Но если преимуществ достаточно (отсутствие проблемы с забытым var, нормальные итераторы, более короткий синтаксис), то преимущества перевешивают недостатки. Мы перешли на CoffeeScript на русском Групоне и остались очень довольны, что используем его во всех остальных проектах. 37signals на basecamp’е тоже остались очень довольны.
Я еще раз говорю, нет проблем с забытым var в строгом режиме. Есть проблема CS, когда не знаешь, где объявлена переменная. Итераторы — дело времени, короткий синтаксис не должен быть в ущерб прозрачности кода.
А более удобный синтаксис и куча сахара, типа классов?
На JS тоже можно эмулировать классы.
Само собой. Просто код на CoffeeScript оказывается в 1,5—2 раза короче и сильно понятнее. Хотя бы потому что там есть string[0..5] вместо substring и substr (в которых постоянно путаешься).
Ничего понятного я там не увидел. Да и за годы разработки никогда не работал с substring и substr.
А как Вы вырезаете подстроку из строки?
Slice. А вообще, зависит от задачи: если нужно взять число из начала строки, то parseInt или parseFloat.
А как часто вы вырезаете строку из подстроки, чтобы выносить это в отдельный сахар? Давайте вообще ВСЁ вынесем в сахар — уберем методы и будем пользоваться только сахаром. array.indexOf(elem) заменим на array?elem, array.slice(2,3) на array[2..5], а array.splice(2,3) на array[2..5]!. И так далее. Будет весело разбираться в кипе непонятных символов. Иногда лучше написать лишних 4 буквы, тем более, что операция крайне редкая.
array.slice(2,3) → array[2..5] — так и есть :)
На самом деле синтаксический сахар, что я приводил — это всё из Ruby и Python. Там все довольны.
Да и итераторы появятся через год, а будут во всех браузерах через года 4.
Ну в этом поможет компилятор, который не будет задействован для нормальных браузеров.
Ну так сейчас это и есть CoffeeScript, а с появлением инструмента отладки, вы не будете знать, что он компилируется в JS ;).
Всё Ruby on Rails сообщество на него медленно переходит.
RoR сообщество кажется вечно на что-то переходит, сначала варианты деплоймента меняли, потом API на двух мажорных версиях меняли, теперь HTML/CSS/JS на DSL меняют. Мне даже интересно, что будет следующим.

Приложение 2-3 летней давности превращается Legacy, с которым работать уже not fun & not cool :)
Верно, поэтому на рельсах получается писать быстро и удобно :-).
Ура, молодцы. Умеют, могют. Теперь ждем двух вещей:
1. Experimental JavaScript features будет включен по умолчанию
2. Компилятор для морально устаревших браузеров в плане поддержки ES.Next (IE, Opera)
Компилятор для морально устаревших браузеров в плане поддержки ES.Next (IE, Opera)
Хороший вброc.
1) Термин «морально устаревший» как бы субъективен, вы выдаёте ваше отношение за «факт».
2) ES.Next (это который Harmony?) как бы ещё в разработке, его никто не обязан поддерживать. Поправьте если ошибаюсь.
3) Если верить wiki en.wikipedia.org/wiki/ECMAScript см. «Conformance tests», то у Оперы как раз всё очень хорошо.
Там большинство замечаний касаются не работы с JS. (Не будем считать за JS реализацию отдельных функций).
Про js написано что «там ужастный GC». Ну так, никто и не обещает его бысторой работы, обещают правильную. Добро пожаловать в web :)

Напомню, изначально говорилось, про то что Opera и IE не поддерживают в JS в той мере, в какой его поддерживает Chrome, при этом в укор ставилось что они не поддерживают фичи ещё не введённые в стандарт. Я уею дорогая редакция.
Они — отстающие по всем параметрам ;)
Я боюсь, за это время документация несколько перетерпела изменения, соответственно, трасеур может быть не очень актуальным. Нужно проверить.
ну и дебажить его, мягко говоря, непросто.
Из-за этого я и боюсь его использовать.
Мне тут в голову пришла бредовая идея: вместо
(function(){
  var x = 5, y = 10;
})();

использовать
{
  let x = 5, y = 10;
}

Этот код так же будет запускаться моментально (возможно, даже, быстрее, так как функции приходится инициализироваться, а затем, запускаться), в глобальную область видимости ничего не попадет (благодаря let). Но, конечно, возвращаться ничего не будет.
Вообще фигурные скобки без ничего в JS воспринимаются как литерал объекта, так что такая запись, скорее всего, будет ошибочной.
а вот и нет :) Фигурные скобки воспринимаются в первую очередь как блок кода, а уже потом этот блок кода проверяется на соответствие синтаксиса литералу объекта. Другое дело, что сейчас (в сегодняшней реализации) блок кода штука бесполезная, никаких плюшек (ну, разве что, кроме фолдинга в редакторах) не сулящая.
Обзор вкладок Mac
Проведите тремя пальцами вниз по трекпаду, чтобы увидеть все свои вкладки. Нажмите на уменьшенное изображение нужной вкладки, чтобы выбрать ее. Эта функция особенно удобна в полноэкранном режиме.
Sorry, this experiment is not available on your platform.

Будет ли доступна данная функция пользователям Windows?
В прикладном плане, новость интересна тем, что это скоро появится на nod.js, а значит можно будет продуктивно использовать в разработке серверсайда. На клиентской стороне, для публичного web-а эти нововведения упрутся в некоторые отстающие браузеры.
const в Хроме давно есть в strict mode, хотя и работает оно специфически.
Only those users with full accounts are able to leave comments. Log in, please.