Comments 55
Хорошее названия для аналога яваскрипта, суть почти раскрыта
Вы имеет ввиду что в основном JavaScript код пишется на удачу, а вдруг заработает? :)
Забавно, и правда Vader, что это я.
Я даже погуглил перед написанием, но краудсоринг меня подвёл — Weider оказалось настолько частой ошибкой, что я принял его за правильный вариант.
Интересно было увидеть что же такой за Dart. Будем надеяться, что у этой штуки есть будущее.
Ну, то, что показали, смотрится вменяемо: типизация переменных (думаю, она быстро станет правилом хорошего тона), компактный синтаксис, фигурные скобки и точки с запятой на месте, привычные/понятные классы, интерполяция переменных и вызова кода в строках, обмен сообщениями… Кстати, так и тянет на многозадачность в стиле эрланга.
UFO landed and left these words here
Ну я подумал что немного утрирования тут не помешает :) Тем ни менее GWT с похожим и поначалу многообещающем подходом трансляции кода в JavaScript мейнстримом так и не стал. Посмотрим как сложатся дела у дарта.

Интересно что dart преполагают повышенную по сравнению с JavaScript производительность, хотя пока не очень то понятно откуда она возьмется (типизация?). Разрабочикам V8 может конечно и видней, подождем тестов каких-нибудь.
UFO landed and left these words here
В примерах увидел такое:

main() {
Element element = document.getElementById('message');
element.innerHTML = 'Hello from Dart';
}


Значит ли это, что Dart не имеет собственных методов работы с DOM и в веб-приложениях для доступа к сущностям нужно использовать JS? А как у него обстоят дела с Ajax'ами и прочими плюшками, необходимыми для веб-программирования? Есть ли Dart-фреймворки вроде jQuery?
>> Значит ли это, что Dart не имеет собственных методов работы с DOM и в веб-приложениях для доступа к сущностям нужно использовать JS?

С каких пор конструкция
>> Element element =…
является частью яваскрипт?

И к вашему сведению, доступ к дом дереву или ajax-функциям являются частью языка только как набор библиотек, доступный в рамках среды исполнения языка(в данном случае браузер)
Что мешает для нового языка реализовать соответствующие библиотеки на уровне среды исполнения языка?
Я не о конструкции вида «Element element =…», а о «document.getElementById('message');»
document.getElementById — это не конструкция языка. Это объект и метод DOM, который предоставляется браузером и который и сейчас может использоваться разными языками (в IE это javascript и vbscript, например).
Простите мою не осведомленность и неопытность… но Вы как хотите чтобы было?
О, рад, что Вы спросили. Мне, как всегда, не хватает встроенной функции doMagic() :) Как думаете, в этом языке её реализуют?
Думается мне, что это такой же глобальный объект document, созданный на Dart. Просто для совместимости с JS кодом оставили существующие имена методов. И это разумно, на мой взгляд.
Вот именно это я, в общем-то, и спрашивал: чем в данном случае является document и кем он создан. Пока это выглядит как присвоение результатов вызова методов JS-объектов в переменные Dart и последующее обращение к JS-объектам (это я исключительно про приведённый в комментарии пример).

Что касается совместимости, то она, имхо, лишняя.

Если язык использует свои конструкции и и типы, пусть бы и синтаксис отделили. Во-первых, это избавило бы от вопросов вроде моего (всё сразу было бы очевидно), во-вторых, в том же jQuery не зря ввели огромное количество полезных методов, поскольку в чистом виде JS бывает монструозен, а новый язык мог бы решить и эту проблему.
Зачем новый синтаксис? Вам не нравится точка как оператор обращения к свойству?

По библиотекам вроде jQuery:
Вы про спецификации слышали? Они, как бы, утверждаются не одним лишь гуглом.
Если и считать это проблемой, то это проблема не языка.
Интересно, что за виртуальная машина на стороне сервера, как замена nodejs? Своей машины в браузерах нет, все работает через трансяцию в JS? Хм, непонятно, сразу закапывать или немного помучать…
Хорошо, что не Darth, а то я бы уверился в то, что Google на тёмной стороне. По существу корпорации очень-очень надо постараться, чтобы хоть куда-нибудь сдвинуть JavaScript.
На Lion с xcode 4 из коробки dart vm и прочее собираться не хочет. Требует 10.5 sdk.

Если кто пробует — в tools/build.py добавьте после 108 строчки:
'-sdk',
'macosx10.6',

тогда получится
Презентовали — молодцы. Но с учетом того, что JS занимает 99% рынка, Google придется сильно постараться

По сути, без нормальной поддержки языка браузером и включения языка в стандарт HTML (), перехода не случится.
Мегаоптимизация прям. Из трех строчек — 30 килобайт.
cat hello.dart:

main() {
print('Hello, Dart!');
}

dartc hello.dart --optimize --out hello.js

Выдаст почти 30 килобайт javascript кода:
gist.github.com/1275479
Это же постоянные расходы.
Т.е. и на 50 килобайт вашего кода он выдаст 80 килобайт Javascript (50+30).
Разумеется, этот пример ненормален.

А вот основной выигрыш в удобстве разработки и поддержки.
Да, я уже заметил, спасибо. Теперь пытаюсь понять как это все дебажить нормально.
Судя по коду он генерирует сразу всю core library(читайте весь dart в 30 кб). Это ведь не компиляция, а трансляция(!) об этом и написано. Не думаю что там очень сильный анализатор кода, да и нафиг он нужен в трансляторе. В языка ведь даже версии нет еще. И тем более это не значит что 6 строчек будет 60 кб.
Накой оно надо7 Еще одно скриптовое чудо. Лучше бы Go развивали вот уж действительно быстро и для нагруженных проектов.
Я думаю, дело в том, что предназначение отличается. Go не предназначался (и не предназначается) в качестве замены JavaScript, а, скорее, просто как ещё один серверный язык с хорошей поддержкой многопоточности. А Dart — это язык, который призван лишь дополнить JS теми возможностями (в том числе и возможностями для оптимизации), которых там изначально нет, и которые не могут быть легко добавлены в сам JS. Вряд ли кто-нибудь будет предлагать вам писать на Dart на сервере, хотя, возможно, такие люди найдутся)
Dart как раз предлагается как язык и для сервера, и для клиента. И главная его плюшка как раз в том, что он и там и там будет работать, а это многое упрощает в веб-разработке.
Да, в спецификации (и во многих других местах) действительно делается на это акцент… Но, всё же, у Dart и Go сильно отличаются модели работы, причём у Go (для сервера) мне она нравится намного больше, чем сильно-однопоточный Dart
Ну они же хотят убить двух зайцев одной лопатой. В результате понятное дело что на сервере будет не все, что возможно было бы сделать если бы не требовалась совместимость с клиентом.
Вы слишком сильно обобщаете. Там работают тысячи программистов с разными взглядами и разными проектами. К тому же у Гугла есть Closure — функциональный ЯП.
я к тому, что Closure — это не язык, созданный гуглом. это уже существующий язык, переложенный на их VM.
Javascript, страдающего от «фундаментальных» изъянов, которые невозможно исправить путём эволюционного развития.

Маркетинг такой маркетинг. Нечего там исправлять, и ООП там нормальное, и всё что хочешь. Зачем из всего делать Java?
Первый и второй вывод (Производительность и Удобство разработки) противоречат друг другу:
— не будут иметь тех проблем с производительностью
— не требующая компиляции природа
Only those users with full accounts are able to leave comments. Log in, please.