Как бы скоро не пришлось писать на Dart, TypeScript ...
 

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

Хочется верить, что в будущем, вся эта каша из Dart, TypeScript, CoffeScript, ClojureScript ... и т.д. принесет только развитие вебостроения, а не очередному витку перерождения коим был VBScript.

А то выйдет так: Пишем высокоуровневый код на "JangularSDK++", а для разных браузеров нужны

dart.js
type.js
moz.js
safar.js

Хочется уже счастливого будущего и согласия, а не поедания памяти кучей заглушек и либ и клепания css, js костылей.

Rust от Mozilla круче всех!
А вообще, не переживай ES6 всех убедит в обратном.

dart и type везде работают и думаю будут дальше работать :)
ES6 не убедит.
Без строгой типизации, интерфейсов, абстрактных классов и абстрактных методов потребность в языках вроде type останется.

Мне реально сейчас нехватает интерфейсов. Как уследить за парой десятков классов(конструкторов объектов) которые должны предоставить одинаковое api ? В JS остается только писать тест и проверят тестом все объекты, а вот интерфейс решил бы эту проблему за меня.

Или мог бы выкрутиться иначе. В type унаследовал бы это множество классов от одного родителя. А те методы которые должны быть переопределены в дочерних классах я бы в родителе объявил абстрактными. Вуаля если я забыл переопределить функцию или ошибся с параметрами функции то Я буду получать ошибку при компиляции. А вот JS не будет следить за тем переопределил ли я методы. В JS Я в лучшем случаю выхвачу runtime если воспользуюсь функционалом базирующимся на объекте с ошибкой, в худшем я получу изменение поведения без ошибки и буду долго искать причины.

Отдельно стоит упоминуть что у dart в хроме производительность выше, и очень может быть какой нибудь typescript можно будет скомпилировать в asm.js. Ну и еще Dart позволяет создавать консольные и десктопные приложения (основанные на хромиум).

Довольно плотно юзал TypeScript и в итоге от него отказался, т.к. для меня плюшек там меньше, чем косяков.

Например нет partial классов, что приводит к огромным файлам-классам аля Java или же нет возможности указать на что ссылается this внутри функции и т.д.

Вот CoffeScript другое дело, он просто добавил сахара, однако многие его плюшки добавились в ECMAScript 6 и сейчас я юзаю как раз его (ES6) и используют транслятор в ECMAScript 5.

Вообще я довёл до автоматизма у себя практику написания JSDoc и с тех пор у меня нет больше проблем с отсутствием поддержки ИДЕ и каши в коде. Сейчас работаю над своим проектом, где уже 45к+ строк кода и всё ок.
Но вот интерфейсов как в TypeScript (тут важно понимать, что в Java - это совсем другое) мне правда не хватает.

Dart может стать хорошей альтернативой, но не более того, ведь согласитесь, что от того, что есть Java и C# никто не перестаёт писать на Python или Ruby.

Кстати, вот тоже пример из практики: я пишу код в С-подобном стиле, т.е. меньше динамизма и больше статики, но когда нужно - юзаю гибкость JS. Такой подход приводит к тому, что после компиляции GCC мой код работает на 20-30% быстрее, да и вообще очень быстро, т.е. я почти уверен, что в ближайшем будущем компиляторы вроде GCC или Uglify научаться генерировать ASM.js если исходный код будет иметь специальные JSDoc.

Но в целом меня радуют проекты вроде Dart или TypeScript - это приносит разнообразия и конкуренцию, что есть хорошо.

Скинь ссылку плиз на транслятор ECMA6 который юзаешь.
Их дофига, аж глаза разбегаются :)
Потыкать и прикинуть хотца.


За TypeScript косяков не заметил. После долгой писанины на JS жутко непривычно следить за типами. В компиляторе постоянно вылазят ошибки с типами, но это не вина языка а отсутствие дисциплины у программиста :) К слову можно на некритичных участках использовать без типовые переменные, по принципу максимум сахара минимум ответственности :)

В целом понимаю о чем идет речь, но можно простой ненадуманный пример с "динамизмом" и без "динамизма"? :)

кстати, может быть кто-нибудь знает иное решение это проблемы нежели тесты?
или, может быть есть системы/модули_для_ноды для автоматической генерации тестов? (примитивных)

что ты к ангуляру пристал? :)

Что ты так на этом все время акцентируешь внимание? Читай как "BackboneSDK++"

Тут я уже знаю историю развития - XUL мозиллы, позволяет делать это уже лет 5. Хорошая плюшка, но очень нишевая.

http://javascript.ru/forum/offtopic/...tor-ecma6.html

Ее нет даже в С/С++ зачем она в JS?

Вот современный С++ код:

template <typename __type, typename ...__arguments>
	inline std::unique_ptr<__type> make_unique_helper (std::true_type, __arguments &&...arguments) [[deprecated]]
	{
		using unique = typename std::remove_extent<__type>::type;

		return std::unique_ptr<__type>(new unique[sizeof...(__arguments)] {
			std::forward<__arguments>(arguments)...
		});
	}
;

Сейчас там в моде статическая аннотация типов с выводом на этапе компиляции:

template <typename __type>
   auto fn(__type x,  __type y) -> decltype(__type + __type) {
      return x + y;
   }
;

// decltype, указывает на то, что вывод типов должен происходить на на основании типов переданных аргументов
auto x = fn(1, 2); // 3
auto y = fn("1", "2"); // 12

std::cout << x << ', ' << y << std::end; // 3, 12

Я в JS крайне редко использую наследование, тем более множественное. Может стоит пересмотреть архитектуру?

Уверен что таких поделок на JS куда больше

Согласен, с GCC аннотация типов вообще сказка

Глянь в сторону LiveScript и ClojureScript, или мой любимый Rust

К сожалению нет ни одного проекта который бы поддерживал все возможности ES6, вот по частям:
https://github.com/termi/es6-transpiler
http://facebook.github.io/regenerator/
http://square.github.io/es6-module-transpiler/

Наверно он имел ввиду, что предпочитает императивный стиль объектно-ориентированному с высоким уровнем абстракции

Я имел ввиду, что в 8 из 10 случаев мой код работает так, как он выглядит, без магических полиморфных состояний, преобразований в ходе исполнения и т.д. Например я стараюсь избегать ситуаций введения свойства объекту если оно отдельно не задекларировано. Трюки вроде изменения прототипа в ходе исполнения программы, подмена методов и т.д. стараюсь избегать (но без фанатизма).

Кстати что касаемо ООП: я очень жирно юзаю классовый подход, ну т.е. конструктор, деструктор, прототип и т.д. Уровни наследования у меня могут по 10-15 узлов быть, но ни разу у меня не было нужды в множественном наследование (хотя его можно сделать через Proxy), т.к. на мой взгляд гораздо лучше юзать старую добрую "композицию", когда инстанс является свойством другого инстанса. Единственное место, где я использую множественные наследования - это в примесях различных свойств, но это другое совсем дело.

Пример "динамизма" из жизни:
Мне нужно было прокинуть ссылку на контекст инстанса во внутрь функции, но как аргумент или this я не мог сделать и также не мог перенести функцию в замыкание, т.к. они декларировались совсем в другом месте, поэтому я сделал следующий грязный трюк: внутри конструктора инстанса пересоздал эту функию с помощью toString и eval (т.к. код eval исполняется в том контексте, в котором вызывается eval). В целом это работало и задача выполнялась, но лучше таких штук избегать :)

Не, ОО - это хорошо:)

Вот до clojure добраться хочу, т.к. братишка лабает на Яве и оч хвалил кложур. Rust - это как я понял аналог Go от Гугл? На нём же пишут новый супер движок для ФФ, надо будет глянуть :)

monolithed ответил выше:)
ну и могу свой велосипед дать https://github.com/kobezzza/NeJS, но его юзать не советую, т.к. я планирую его выкинуть после того, как в https://github.com/termi/es6-transpiler сделают нормальную поддердку Arrow Function (без Bind)

Я использую классы в сложных приложениях постоянно но наследования редко превышает три/четыре уровня, множественное наследование (примеси) почти не использую. Очень активно юзаю агрегацию и композицию. Где ты у меня множественное наследования вычитал мне непонятно.

Вот что я имел ввиду
rectangle ={x,y,z,render:function(){},remove:function(){} }
circle ={x,y,z,render:function(){},remove:function(){} }
text ={x,y,z,render:function(){},remove:function(){} }
... и еще 100500 классов.
Если где то забыл переопределить render, то пока в редакторе эту фигуру не нарисуешь то ошибку не увидишь.

Вот только ради этого мне и нужен интерфейс, не хочу тест под каждую фигуру ваять. Да и неудобно это тестить, так как там почти нет логики просто работа с канвасом. Писать тест только для того чтобы проверить все ли свойства и методы на месте меня не улыбает как то.

Я шизею)))))))
Как ты разбираешься только.
Где же я объявил функцию render? Ах да 11 уровней ниже :D

Соглашения, JSDoc, нормальная ИДЕ и здравый смысл)

угу дофига, но в DART никакой возни с компиляторами или утилитами. Нет такого гемора как с прикручиванием webkit к ноде. Реально собранный готовый к употреблению продукт прямо из коробки.

1) создать проект
2) выбираем Chrome package project
3) жмем "ok"
4) жме "run"
enjoy !!! готовое десктопное приложение на базе хрома уже работает !!!

В качестве CSS фреймворка предложен bootstrap, хош на JS пиши, хош на dart или и на том и на другом одновременно.

Ее нет даже в С/С++ зачем она в JS?
Ну думаю что неявное определение типа это тоже самое что отсутствие типа.
Подозреваю что такой код не проконает.

auto year=2020;
year="две тысячи двадцать";

Типы есть почти во всех языках, разве что правила приведения могут отличаться.

К примеру, в С/С++ можно сделать так:

int number = 1;
number = 'a';

А Erlang, где отсутствует статическая аннотация типов, так нельзя делать даже с переменной того же типа:

$ erl
0> Number = 0 .
1> Number = 1 .
** exception error: no match of right hand side value 1

Тип как был целым числом так и остался, в JS тип изменится (number перестанет быть числом).
Я это к тому что нет оснований утверждать что в C++ нет типов. Просто акцент сместился в сторону автоматического определения типов и шаблонов<>. Все это работает на этапе компиляции и к исполнению это никакого отношения не имеет.

Erlang вообще не обычный язык :)

если все одинаковое, можно так

var obj = {
    a: null,
    b: 1,
    c: NaN
};
      
console.assert( Object.keys( obj ).join() === 'a,b,c', "Doesn't equal" );

Или с методами прототипа сверять, если интересуют только методы.

Вообще, если все одинаковое, можно написать один тест и только необходимые объекты в него подставлять (тестируемые).

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

Я так тоже не утверждал.
Точнее в сторону обобщенного программирования (generic) и автоматического вывода типов на этапе компиляции :)

Так что мешет использовать JSDoc-аннотацию и GCC?

а для тупых можно поподробней? :)

аналогичный вопрос

надоели уже хаять его без повода )

https://developers.google.com/closur...s-for-compiler
GCC понимает эти анотации и использует их чтобы генерировать как можно более оптимальный и эффективный код.

Многие JS IDE понимают JSDoc, в частности WebStorm понимает стандарт GCC JSDoc и использует его для статического анализа кода и автокомплита.

Соглашения - ну тут всё понятно, ибо когда мы вводим рамки и следуем им, то наш код становится более предсказуем и очевиден.

Ну а здравый смысл - это думать, что делаешь:)

Никто, ничего не хает. Где ты это углядел не ясно. Не пора закончить этот затянувшийся разговор про ангуляр?

В Erlang нельзя изменять значение переменной, не ясно какое отношение это имеет к типам? Ну разве, что производительность это повышает, как и в статической типизации.

Я его еще использую как статический анализатор, т.е. если функция ожидат принять строку, а передается число, то выдается ошибка.

Ну это так к слову :)

У меня это вебшторм делает:)

может быть :D

kobezzza, спасибо за ссылку.

а можно напримере? Вот я по ссылке, кот. ты выше привел копирую кусок кода

/**
 * A shape.
 * @interface
 */
function Shape() {};
Shape.prototype.draw = function() {};

и делаю так

var obj = new Shape();
*!*
obj.paint();
*/!*

и хочу, чтобы в строчке отмеченной красным мне IDEшка ошибку бросала (не запуская код, разумеется). Это возможно?

Разумеется.


Используя JSDoc ты получаешь полноценную поддержку IDE, как скажем при использовании Java.

В большом проекте это не вариант, да и не заставишь всех перейти на какой-то редактор.
Да я и сам часто пишу код в vim'e :)

// ==ClosureCompiler==
// @compilation_level ADVANCED_OPTIMIZATIONS
// @output_file_name default.js
// ==/ClosureCompiler==

/** @param {string} string */
function hello(string) {
    return string
}

hello(1);

Будет получено предупреждение:

Number of warnings: 1

JSC_TYPE_MISMATCH: actual parameter 1 of hello does not match formal parameter
found   : number
required: string at line 6 character 6
hello(1);

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

Протестить можно тут http://closure-compiler.appspot.com/
Список опций тут http://code.google.com/p/closure-compiler/wiki/Warnings

Мой конфиг:

#! /usr/bin/env sh

# Google closure compiler
# [url]http://code.google.com/p/closure-compiler/wiki/Warnings[/url]

# --compilation_level
# WHITESPACE_ONLY | SIMPLE_OPTIMIZATIONS | ADVANCED_OPTIMIZATIONS

# --compilation_level
# QUIET | DEFAULT | VERBOSE


timestamp=debug # `date +%s`

compiler=../tools/google/closure-compiler/build/compiler.jar
output=../cache/static/__init__

java -jar ${compiler} \
	--js="${output}.js" \
	--externs=../trunk/__slot__.js \
	--js_output_file="${output}.${timestamp}.js" \
	--create_source_map="${output}.${timestamp}.json" \
	--warning_level=QUIET \
	--summary_detail_level=3 \
	--charset=UTF-8 \
	--language_in=ECMASCRIPT5_STRICT \
	--compilation_level=SIMPLE_OPTIMIZATIONS \
	--formatting=SINGLE_QUOTES \
	--jscomp_error=ambiguousFunctionDecl \
	--jscomp_error=checkDebuggerStatement \
	--jscomp_error=checkRegExp \
	--jscomp_error=checkVars \
	--jscomp_error=const \
	--jscomp_error=constantProperty \
	--jscomp_error=es5Strict \
	--jscomp_error=internetExplorerChecks \
	--jscomp_error=invalidCasts \
	--jscomp_error=missingProperties \
	--jscomp_error=suspiciousCode \
	--jscomp_warning=undefinedNames \
	--jscomp_error=undefinedVars \
	--jscomp_warning=uselessCode \
	--jscomp_warning=externsValidation \
	--jscomp_warning=duplicate \
	--jscomp_warning=deprecated \
	--jscomp_warning=accessControls \
	--jscomp_warning=visibility \
	--jscomp_warning=checkTypes \
	--jscomp_warning=fileoverviewTags \
	--jscomp_warning=nonStandardJsDocs \
	--jscomp_warning=strictModuleDepCheck \
	--jscomp_warning=unknownDefines \
#	--jscomp_warning=globalThis \
#	--source_map_format=DEFAULT \
#	--use_types_for_optimization \
#	--create_name_map_files=true \
#	--print_ast \
#	--print_pass_graph \
#	--print_tree \

Ну выбор редактора - это личное дело каждого:) Но так или иначе у меня также проводится анализ на этапе сборки и выкладки: jshint (пробовал также Closure Linter, но он какой то кривой) + gcc.


Ну кстати в WebStorm когда делаешь комит, то он ещё раз алертом выводит о всех варнингах и ошибках, а также комментариев todo. Ну и конечно бывает, когда варнинг сделан осмысленно:)

kobezzza, monolithed, :thanks:

вы обсуждали angularjs без меня? Я требую продолжения :)

x-yuri, целая ветка форума есть под него :)

Целая ветка форума это конечно круто, но зачем она мне, если вы и так уже все тут собрались :) ну или почти все...

p.s. пишу из убунты, если что :)

С возвращение Темный Лорд. :)

:thanks:

Типо попытка начать срачь?

т.е. все-таки придется

интересные слайды по dart

Согласно диаграммам производительности, dart быстрее js в ~2 раза.

Тем не менее, все идет к тому, что в один "прекрасный" день в браузере будут:
1. js
2. dart
3. typescript

Второй, насколько я понял, гугловцы разрабатывали отчасти потому, что не видят перспектив развития первого (js).
Итого:
*цитаты с википедии

nerv_, скорее всего усиление TypeScript и Dart будут сильнее способствовать развитие JS, что уже само по себе хорошо.

Я верю, что TS и Dart станут прекрасными платформами и разбавят эту жуткую монополию JS, но над революционными фразами о "замене" я могу лишь посмеятся :) Чуваки уже 18 лет не фиксят баг с typeof null, чтобы не сломать совместимость, а тут VM с языком возьмут и поменяют :)

Да даже не в совместимости дело, а что во первых:
1) 90% проблем в JS надуманы и лечатся банальными соглашениями (и я молчу про то, что в ECMAScript6 многие из низ исчезнут) и нормальной IDE;
2) Dart - это веб-ориентированная Java. Под Java существует огромное количество VM под разные динамические языки: JS, Python, Ruby и т.д. как думаете почему? Да просто динамика удобна, и это ещё одна причина, почему JS никуда не денется.
3) Заявления про скорость надуманы, учитывая, что сейчас Dart транслируется в JS :) И что, на Дарте нельзя наговнокодить так, что он будет тормозить как утюг-самоход? Можно, конечно. И что, на JS нельзя писать быстрый и эффективный код? Можно, конечно.
4) В Дарте нет замыканий :)
5) Гугл прекрасно знают о перспективах развития JS, тем более что они очень впечатляющее, но у них есть ресурсы на попытку пропихнуть свою технологию, с дальнейшей попыткой монополизации, нельзя их за это винить. Тоже самое делает МС.
6) Технический директор Мозиллы Брендан Айк, создатель JS ;)

Ну есть вообще то виртуальная dart машина, и сборка хромиум с интегрированной машиной. Другое дело что вряд ли она где то кроме хрома появится.

Проблемы языка не должна лечить IDE, и заменять конструкции языка комментами я бы не сказал что это ВАУ как правильно.

Замыкания в Dart таки есть

Function say(String something) { // "Function" is an optional return type annotation
  return () => print(something);
}

void main() {
  var talk = say("How are you?"); // Function say(...) closes over variable talk. 
  talk(); // prints "How are you?"
}

В остальном согласен, выпиливание JS маловероятно

Пожалуйста, расскажи мне о "впечатляющих перспективах развития JS" :)

Можешь перечислить 3 самые острые надуманные проблемы, которые "лечатся соглашениями", и еще 3, кот. нивелирует новый стандарт?

Мне, почему то, монополия JS не кажется жуткой. Жутким кажется 3+ языков в браузере, в кот. придется разбираться.

правильная мысль, т.к. я могу писать в простом блокноте

Я лично за подключение динамических библиотек.
Ну чтобы можно было писать на каком хочешь языке, а результатом должен быть ELF-файл
И пока этого не будет, недовольство будет расти и расти.

Ведь по сути это отлиная идея, дать возможность писать на каком хочешь языке при наличии песочницы.

PS: Надуюсь что гугл все-таки вытянет NaCl

Только не лопни пока будешь надуваться :D

А чем тебе asm.js не альтернатива elf ? (ну кроме веса конечно).