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

[Gozar]

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

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

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

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

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

[monolithed]

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

[DjDiablo]

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

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

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

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

[kobezzza]

Довольно плотно юзал 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 - это приносит разнообразия и конкуренцию, что есть хорошо.

[DjDiablo]

kobezzza

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


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

[nerv_]

я пишу код в С-подобном стиле, т.е. меньше динамизма и больше статики

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

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

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

"JangularSDK++",

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

[Gozar]

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

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

Ну и еще Dart позволяет создавать консольные и десктопные приложения (основанные на хромиум).

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

Скинь ссылку плиз на транслятор ECMA6 который юзаешь.

Нормальный транслятор ECMA6

[monolithed]

Без строгой типизации, интерфейсов

Ее нет даже в С/С++ зачем она в 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

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

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

Ну и еще Dart позволяет создавать консольные и десктопные приложения (основанные на хромиум).

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

Вообще я довёл до автоматизма у себя практику написания JSDoc и с тех пор у меня нет больше проблем с отсутствием поддержки ИДЕ и каши в коде.

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

Вот CoffeScript другое дело, он просто добавил сахара, однако многие его плюшки добавились в ECMAScript 6

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

Скинь ссылку плиз на транслятор ECMA6 который юзаешь.

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

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

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

[kobezzza]

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

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

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

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

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

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

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

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

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

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

[DjDiablo]

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

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

Вот что я имел ввиду
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, то пока в редакторе эту фигуру не нарисуешь то ошибку не увидишь.

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

10-15 узлов

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