Как бы скоро не пришлось писать на 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