Пользователь
30,2
рейтинг
2 октября 2012 в 04:51

Разработка → TypeScript: язык для разработки больших приложений на JavaScript



Microsoft представила язык программирования TypeScript, который является надмножеством JavaScript, поддерживает статическую типизацию, модули, определение классов и интерфейсов. TypeScript транслируется в чистый JS, исполняется в любых браузерах, в Node.js и т.д.

Транслятор TypeScript вышел под лицензией Apache 2.0, с исходниками на CodePlex. Microsoft предлагает плагины для Emacs, Sublime Text и Vim.

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



Playground — сравнение TypeScript и JavaScript на любом коде

Playground

Выпуск TypeScript произошёл ровно через год (почти день в день) с момента, как Google представил язык программирования Dart. В отличие от Google, компания Microsoft сразу выпустила вместе с TypeScript целый набор инструментов и заявила абсолютную совместимость с JavaScript. Выглядит так, как будто TypeScript можно использовать в серьёзных приложениях прямо сейчас, в то время как выпуск Dart кажется не вполне подготовленным.
Анатолий Ализар @alizar
карма
749,5
рейтинг 30,2
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (140)

  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      yaScript?
      • +3
        Можно и просто: скриптовый язык Яндекс.
        • +13
          Тогда уж Яндекс.Скрипт :)
          • +25
            Я.зык
            • +7
              Я.Васкрипт
              • +3
                йа вас крипт
      • +5
        на основе Dart, но с другим логотипом
        • 0
          YaD, Dyartanyan, Yart…
    • +21
      image
  • +14
    Сегодня уже успел поработать на TypeScript. Впечатления очень хорошие.
    Разработчики молодцы и добавили как раз то, чего мне (да и думаю многим другим) не хватало в JS.

    Выходной код выходит чистым, его удобно читать.
    Плагин для VS 2012 удобен, теперь все плюшки среды разработки доступны и для JS.

    Пока ешё не разбирался как настроить автоматическую минификация выходного JS, но надеюсь проблем не возникнет

    Советую и вам попробовать, действительно удачное расширение JS.

    PS
    Если работаете с jQuery, до нужно добавить в начало скрипта ссылку:
    ///
    Исходник взять тут: typescript.codeplex.com/SourceControl/changeset/view/d397c54a55db#samples%2fjquery%2fjquery.d.ts
    • 0
      ///
    • +3
      Разработчики молодцы и добавили как раз то, чего мне (да и думаю многим другим) не хватало в JS.
      Какой у Вас опыт с другими языками?
      • 0
        Я изучал на курсах Basic, Pascal когда ещё в школе учился, потом Perl, Php, C++.
        Сейчас пишу на C# и JS.

        TypeScript не отменяет плюшек JS, только расширяет его возможности.
        Такая типизация помогает в разработке. К тому же в ближайшее время скорее всего появятся юнит тесты для TS.
    • +1
      Зависимости никакой?
    • +1
      Плагин для VS 2012 удобен

      Так значит оно и для Visual Studio есть, не только для Emacs, Sublime Text и Vim? Отлично, будем надеяться на относительно скорое появление поддержки со стороны ReSharper…
  • +2
    Сори за флуд, резался пример.
    Вот ссылка для работы с JS:

    /// <reference path=«jquery.d.ts» />

    По сути это набор интерфейсов необходимый для типизации фреймворка, поэтому не забывайте на странице подключить используемую версию jQuery.
  • +5
    Ох ты! Да это именно то, что я ждал!
    Редко когда меня что-то действительно так радует, а в особенности если это что-то от майкрософт.

    Спасибо,
    премного благодарен.
  • –25
    Я конвертировал jQuery в TypeScript! Можно забрать отсюда: code.jquery.com/jquery-1.8.2.js
  • +6
    Теперь разрабатывать WinJS приложения под Windows 8 станет легче
  • –10
    Обьясните как украшатель js, который транслируется в итоге в js может иметь статическую типизацию?
    • +3
      Хотя бы на уровне среды разработки. Вот указываешь как аргумент функции function foo(bar x) { } и работа с x будет подсвечиваться с соответствующими полями и методами. Собственно это то, чего так не хватало в JS
    • +3
      А в чём проблема? Это же условное ограничение, а не расширение функций — проверил на этапе компиляции что типы соответствуют и всё. Разумеется в итоговом js не будет статической типизации.
      • +1
        Уже представляю утиный каст типов. типа Node x = (Node)y; превратится в var x = cast(y, Node);
        	function TypeCastException(message, typeFrom, typeTo) {
        		this.message = message;
        		this.typeFrom = typeFrom;
        		this.typeTo = typeTo;
        	}
        
        	function cast(objFrom, objTo) {
        		var success = true;
        		for (var p in objFrom)
        			if (!(p in objTo)) {
        				throw new TypeCastException("Невозможно преобразовать объект к указанному типу", objFrom, objTo);
        				break;
        			}
        			else
        				if (typeof(objTo[p]) != typeof(objFrom[p])) {
        					success = false;
        					break;
        				}
        		if (success)
        			return objFrom;
        		throw new TypeCastException("Невозможно преобразовать объект к указанному типу", objFrom, objTo);
        	}
        
    • +17
      На уровне транслятора? В машинных кодах тоже типизации нет, но это же не мешает языкам со статической типизацией в них компилироваться.
    • +2
      Вот ещё хороший анонс blogs.msdn.com/b/somasegar/archive/2012/10/01/typescript-javascript-development-at-application-scale.aspx. Как сказали уже выше, вся проверка типов происходит во время компиляции, а благодаря небольшим декларативным файлам на TypeScript и полной совместимости с js, можно получить удобство типизации и IntelliSense для всяких готовых js-библиотек вроде работы с dom, winRT и др.
  • –4
    Что-то у меня в мозг не укладывается «язык программирования» и «автодополнение функций» в одно целое.
    Вот в C++ есть «автодополнение функций»? Должно же быть где-то, мощный же язык…
  • –8
    «Серебрянная пуля» последнее время заменяется выражением «для масштабируемых приложений».

    Ничего в описании языка не говорит о его пригодности для создания масштабируемых приложений. Не говоря о том, что этого текста нет на странице самого языка.
    • +4
      Прямо на главной же странице:
      Scalable
      TypeScript offers classes, modules, and interfaces to help you build robust components.

      These features are available at development time for high-confidence application development, but are compiled into simple JavaScript.

      TypeScript types let you define interfaces between software components and to gain insight into the behavior of existing JavaScript libraries.
      • 0
        > Прямо на главной же странице:
        > Scalable

        А, этого я как-то не увидел. Видать, конца слайд-шоу не дождался :)
    • +1
      Масштабируемая для разработки. Сейчас используют и синтаксический сахар вроде CofeeScript, всякие ClojureCompiler, и линт, даже трансляторы почти каждого языка есть в js. Во всю эту кашу, которая у каждого своя, в этот процесс сборки, вполне себе встраивается TypeScript, никого ничем не напрягая, хотя бы из-за полной совместимости с js позволяет писать код легче и привычнее большему количеству разработчиков. К серверной масштабируемости и проблемам node.js отношения не имеет.
      • 0
        > Масштабируемая для разработки.

        Это я должен был телепатировать из текста?

        Надмножество TypeScript сделано для того, чтобы реализовать функции, необходимые для разработки и поддержки серьёзных масштабируемых приложений.


        Где тут говорится про «масштабируемость для разработки»?
  • –6
    Хм, все понятно, для Ruby, CoffeScript, для .NET, TypeScript :)
    • +26
      Ваша пунктуация доставляет, я только с 4 раза правильно прочитал :D
    • –1
      CoffeScript ни как не завязан не ruby. Причем уже давно, ему нужен только js движок и всё. Имхо TS кроме как раздувания кодовой базы не принесет. Сколько помню свою работу с JS, всегда было желание уменьшить количество вводимого кода, а не писать еще больше (типы и прочее)
      • 0
        Простите, опечатка " не ruby" -> «на ruby»
        • 0
          Можно было изменить комментарий. У вас было 2 минуты еще)
  • –4
    Не очень понятно, чем хуже вместо
    class Greeter {
        //...
    }
    

    писать, например
    var Greeter = Backbone.Model.extend({
       //...
    });
    


    Ну а статическая типизация на уровне среды разработки в нормальных IDE реализуется через комментарии в стиле jsdoc.

    /**
    * @param (Int) myParameter
    * @return {String} myReturnValue
    */
    function intToString() {
       //...
    }
    
    • +6
      Согласитесь, что типизацию в приведенном вами примере нельзя назвать полностью «нормальной», пользуясь вашим же «термином». Хотя, конечно же, норма — это всего лишь овладевшая массами патология )
      • 0
        Я называл «нормальной» не типизацию, я назвал нормальными IDE. WebStorm, например, понимает такие комментарии и обращает на них внимание при автодополнении + показывает ошибки, если передается неверное количество аргументов, либо они не подходящих типов.

        На самом деле, я понимаю конечно, что интерфейсы и классы — это привычно и удобно большинству.
        • 0
          Вы спрашивали про разницу, я лишь указал на нее. То, про что вы говорите в WebStorm, больше похоже на intellisence. TypeScript же есть компилятор, например, вы может воспользоваться консольной утилитой для компиляции ts файла в js.
          • +1
            *транслятор
            • +1
              … лишь вопрос терминологии, не придирайтесь. Но таки в свойствах tsc.exe написано: TypeScript Compiler
      • –1
        Вот именно «паталогия» овладевшая массами, диктует т.н. «правила» из которых и вылупился TypeScript.
        Если я сейчас явно скажу, что TypeScript это обертка вокруг pure js в угоду тех, кто привык писать «true OOP», то меня закусают. Написали бы лучше нормальный модульный фреймворк без тормозов и глюков, где разрешили бы вот так (или похоже) организовывать синтаксис. Нет — надо влепить еще одну надстройку. Зачем? js требует именно того синтаксиса, который требует. И никак иначе. Подсветка, подсказки, навигация по методам? Да тот же нетбинс отлично с ней справляется. Как-то почему бы не оставить в покое js?
        (только лишь личное мнение)
  • –7
    Как же надоели эти неосиляторы яваскрипт.
    • +3
      Неосиляторы ассемблера, пишущие на высокоуровневых языках вас тоже раздражают? Только байткод?
      • +7
        Сравнение ассемблера с высокоуровниевыми языками совершенно неуместно, т к разница между яваскриптом и появляющимися обертками, которые транслируются в яваскрипт, не настолько велика.
        Обычно основная проблема кроется в реализации ООП-подхода в яваскрипте, потому как там вместо обычной классовой модели используется делегирующее наследование на базе прототипов.
        На мой взгляд лучше освоить прототипы (что не так уж и сложно, вопреки мнению большинства) и разрабатывать на нативном языке, а не плодить уровни абстракций, которые так любят протекать…
        • +2
          Вы совершенно правы по поводу отличий в подходе к наследованию, но любая модель наследования, в любом случае, позволяет создавать уровни абстракции. И они могут «протекать» независимо от используемого подхода.

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

          Я согласен с тем, что использование классового наследования в JavaScript не имеет большого смысла, но мы же говорим уже о совершенно другом языке, который транслируется в JS.
          • 0
            > почему вы думаете, что разработчики не могут освоить прототипное наследование?

            Потому что людям неохота думать. Им подавай ООП в стиле C++/Java, все остальное воспринимается в штыки.
            • +1
              Может прототипированное наследование не удобное?
              Хотя нет, вы правы, просто все вокруг дураки.
              • +2
                > Может прототипированное наследование не удобное?

                Отмазка, которую я постоянно слышу про прототипное ООП, функциональное программирование, ленивые вычисления и т.п. Людям очень сложно выходить за рамки своей зоны комфорта.
                • +1
                  Не удобство наследования в JS заключается в сложной реализации более чем 1 уровня наследования.
                  Есть контраргументы, а не фразы состоящие целиком из воды?

                  И не надо мне приписывать того, что я не говорил(ленивые вычисления и т.п.)
                  • 0
                    > Не удобство наследования в JS заключается в сложной реализации более чем 1 уровня наследования.

                    1. Моделируйте задачу так, чтобы несколько уровней наследования не нужно было
                    2. Используйте extend (за примерами — в тот же ExtJS)

                    Ну и www.crockford.com/javascript/inheritance.html, особенно Conclusion.

                    > И не надо мне приписывать того, что я не говорил(ленивые вычисления и т.п.)

                    Я ничего не приписывал. Я просто написал, что отмазка «не удобно» является всего лишь отмазкой, которая с завидным упорством применяется людьми, которые на секунду выглянули за приделы своего C++-like мирка.
                    • 0
                      1 — ответ в стиле одной известной IT компании: «Такого функционала нет — значит оно вам не нужно и держите наши продукты правильно» =)

                      Согласен с вами о необходимости использовать технологии, соответствующие задаче (если вы это имели ввиду), но кажется вы немного утрируете. Например, кому-то удобно ездить в автомобиле домой с работы (если он работает далеко от дома) а кто-то пытается убедить, что «вы из своего автомобильного мирка не видите прелести поездки на велосипеде», работаю в четырех кварталах. Пример натянутый, но суть постарался передать: «программируйте с использованием языка» (с).
                      • 0
                        > 1 — ответ в стиле одной известной IT компании: «Такого функционала нет — значит оно вам не нужно и держите наши продукты правильно» =)

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

                        > Пример натянутый,

                        Именно. Любая аналогия, особенно с автомобилями, неверна.

                        Задам пару вопросов на засыпку:
                        — почему, когда берется в руки NoSQL, все наперебой кричат, что надо моделировать задачи, исходя из конкретного NoSQL-движка, а не опираясь на знания из мира реляционных баз данных?
                        — почему, когда берется в руки функциональное программирование, все наперебой кричат, что надо перестроить свое мышление, чтобы начать думать не в императивном стиле
                        — почему, когда берется в руки Javascript, внезапно виноват Javascript, что там прототипное наследование, и «оно нипанятно»?
                  • +2
                    Не удобство наследования в JS заключается в сложной реализации более чем 1 уровня наследования.

                    Где вы такую глупость взяли? У меня вполне во фреймворке есть 4 уровня:
                    Geometry => Shape => Rectangle => RoundedRectangle
                    И оно отлично работает. И никакой сложности. Я даже особо не задумаюсь, если решу добавить ещё один уровень.
                    • 0
                      Ну что же вы стесняетесь?
                      Сказали А, говорите Б.
                      Покажите нам вашу реализацию.
                      • 0
                        • +1
                          var Rectangle = LibCanvas.declare( 'LibCanvas.Shapes.Rectangle', 'Rectangle', Shape ...
                          

                          Дальше можно не продолжать…
                          Вы подтвердили мои слова.
                          • 0
                            Аргументируйте.
                            • +1
                              class Rectangle implements Shape
                              

                              vs

                              declare = function (declareName, Parent, params) {
                              	if (prototyping) return this;
                              
                              	params = methods.prepareParams(declareName, Parent, params);
                              
                              	// line break for more user-friendly debug string
                              	var Constructor = function ()
                              	{ return methods.construct.call(this, Constructor, arguments) };
                              
                              	// <debug> - should be removed on production
                              	if (params.name) {
                              		Constructor = new Function('con', 'return {"' + params.name + '": ' +
                              			function(){ return con.apply(this, arguments) }
                              		 + '}["' + params.name + '"];')(Constructor);
                              	}
                              	// </debug>
                              
                              	for (var i = 0, l = mutators.length; i < l; i++) {
                              		mutators[i].fn( Constructor, params[mutators[i].name] );
                              	}
                              
                              	Constructor.prototype.constructor = Constructor;
                              
                              	if (params.declareName) methods.define( params.declareName, Constructor );
                              
                              	return Constructor;
                              };
                              
                              // Дальше идет ещё много-много кода
                              


                              Дальше очевидное объяснять?
                              • –2
                                Вам сюда исходники Джавы кинуть? Или какого-нибудь Хибернейта? С глупой и бессмысленной фразой «Дальше очевидное объяснять?»
                                • 0
                                  Вы хоть помните с чем не согласились?
                                  Что послужило появление этой ветки?
                                  • 0
                                    Что послужило причиной*
                                  • 0
                                    Ага. Что наследование реализовать в ЖС тяжело.
                                    Не тяжело. Слегка многословно, но хорошая библиотека устраняет эту проблему.
                                    И что?
                                    Зато в ответ я получаю невероятную гибкость.
                                    • –1
                                      Ваши слова:
                                      Ага. Что наследование реализовать в ЖС тяжело.
                                      Не тяжело.


                                      А вот на самом деле мои слова:
                                      Не удобство наследования в JS заключается в сложной реализации более чем 1 уровня наследования.


                                      Я показал различая сложности?
                                      Показал.

                                      p.s.
                                      Вообще использование библиотеки для реализации базового функционала, мне видеться большим таким костылем. Но увы JS. Именно поэтому я так много смотрю в сторону CoffeeScript, TypeScript и Dart. Нужно для себя сделать выбор.
                                      • 0
                                        Я показал различая сложности?
                                        Показал.

                                        Ничего вы не показали. Просто кинули кусок кода библиотеки.

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

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

                                        Это всё-равно, что говорить, что Питон — такой большой костыль потому что в ПХП общение с веб-сервером встроено в язык. И ещё кинуть код Джанго в комметы как «доказательство очевидного».

                                        Или Руби вместо Питона и кинуть код РоР в комменты. А потом добавить: «а пхп это прям в языке есть», Руби/Питон нуждается в костылях.
                                        • –1
                                          Прочитал, улыбнулся.
                                          Не понять различая в сложности реализации одного и того же функционала, надо суметь :)
                              • +1
                                Почему вы не приводите код, реализующий ключевое слово implements?
                                • 0
                                  Я как бы на то и намекаю, что я не писал ни строчки кода, что бы реализовать implements.
                                  Кстати, забавный момент, когда я писал комментарий, я только раза 2 видел ts и вместо extends, я написал implements. И если на js реализовать extends возможно, то implements…
                                  • +1
                                    > Я как бы на то и намекаю, что я не писал ни строчки кода, что бы реализовать implements.

                                    Не писали вы, писал кто-то другой. Или вам религия запрещает использовать чужие реализации?

                                    > И если на js реализовать extends возможно, то implements…

                                    Они внезапно чем-то сильно отличаются?

                                    JS хорош тем, что в нем можно реализовать много чего: www.crockford.com/javascript/inheritance.html

                                    JavaScript can be used like a classical language, but it also has a level of expressiveness which is quite unique. We have looked at Classical Inheritance, Swiss Inheritance, Parasitic Inheritance, Class Augmentation, and Object Augmentation. This large set of code reuse patterns comes from a language which is considered smaller and simpler than Java.

                                    Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies. Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.
                                    • –1
                                      Не писали вы, писал кто-то другой. Или вам религия запрещает использовать чужие реализации?

                                      Для ts это native statement. Или вы хотите мне привести реализацию JS интерпретатора в коде ассемблера?

                                      Они внезапно чем-то сильно отличаются?

                                      Всем. Вы знакомы с интерфейсами?
                                      • +1
                                        > Для ts это native statement.

                                        И?

                                        > Всем. Вы знакомы с интерфейсами?

                                        Чем — всем? С интерфейсами, знаком. И?
                                        • –1
                                          И?

                                          Е! Я ещё много знаю гласных.
                                          Хотите что-то узнать спрашивайте корректно и конкретно.

                                          Чем — всем? С интерфейсами, знаком. И?

                                          Вы похоже не знаете что такое интерфейсы и для чего они нужны, раз спрашиваете и приводите не корректную(в контексте обсуждения элементов языка) ссылку на какую то библиотеку.
                                          • +1
                                            > Хотите что-то узнать спрашивайте корректно и конкретно.

                                            Ну вообще-то, это вы задаете вопросы и что-то пытаетесь спорить.

                                            Повторю максимально простым языком:

                                            То, что implements для ts — это ключевое слово, не значит, что где-то за ним не стоит какой-то код. Например, код компилятора/транслятора. Но вас это посему-то не смущает.

                                            Но вот реализация extends, приведенная в этой ветке, вас почему-то смущает. Потому что вы видите ее код? Потому что она реализована в виде библиотеки, а не в виде кода внутри компилятора? Чем она вас смущает?

                                            > Вы похоже не знаете что такое интерфейсы и для чего они нужны, раз спрашиваете

                                            Я задал конкретный вопрос, на который вы так и не смогли ответить.

                                            > приводите не корректную(в контексте обсуждения элементов языка) ссылку на какую то библиотеку.

                                            Ссылку на библиотеку я не приводил. Я привел ссылку на краткое описание того, как в JS можно реализовать как «классическое» (C++-like) наследование, так и другие типы наследования. И, главное, я даже привел цитату, которую вы решили не читать и не понимать:
                                            Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies. Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.
                                            • 0
                                              Ну вообще-то, это вы задаете вопросы и что-то пытаетесь спорить.

                                              Я?! *удивление* Пожалуйста цитату приведите.

                                              То, что implements для ts — это ключевое слово, не значит, что где-то за ним не стоит какой-то код. Например, код компилятора/транслятора. Но вас это посему-то не смущает.

                                              Меня не смущает, т.к. это возможности языка, а не библиотеки.
                                              Напоминаю, что мы сравниваем два языка между собой, а не код трансляторов и интерпретаторов языков.

                                              Я привел ссылку на краткое описание того, как в JS можно реализовать как «классическое» (C++-like) наследование,

                                              У меня нет желания вчитываться в абстрактные полотнища текстов.
                                              Я «прошерстил» текст на наличие упоминания интерфейсов. Там этого не оказалось. Отсюда вывод, что ссылка ни коем образом не коррелирует с контекстом беседы.

                                              И, главное, я даже привел цитату, которую вы решили не читать и не понимать

                                              Зачем мне понимать чьё то мнение про поводу необходимость реализации чего-то в JS? Объясните?
                                              • –1
                                                > Напоминаю, что мы сравниваем два языка между собой, а не код трансляторов и интерпретаторов языков.

                                                Напоминаю, что вы не сравниваете, а пытаетесь всех убедить, что C++-like наследование в JS реализовать сложно: habrahabr.ru/post/153077/?reply_to=5250583#comment_5229441

                                                > У меня нет желания вчитываться в абстрактные полотнища текстов.
                                                Я «прошерстил» текст на наличие упоминания интерфейсов.

                                                Интерфейсы приплели только вы. Если для вас наследование ограничивается только и строго реаизацией интерфейсов, извините, о чем мы тут вообще говорим?

                                                > Зачем мне понимать

                                                Именно. У вас не стоит цели что-то понимать
                                                • 0
                                                  Напоминаю, что вы не сравниваете, а пытаетесь всех убедить, что C++-like наследование в JS реализовать сложно: habrahabr.ru/post/153077/?reply_to=5250583#comment_5229441

                                                  Там написано совершенно другое. Я утверждаю, что реализация более чем 1 уровня наследования в JS сделано очень ну удобно, т.к. оно повышает сложность реализации задачи. Про реализацию C++-like наследования придумали вы.

                                                  Интерфейсы приплели только вы.

                                                  Я написал про интерфейсы. Я вообще завел речь про интерфейсы. Я же вообще стал говорить о их очень сложной реализации в JS(если вообще возможной)
                                                  Но вы начали говорить о том, что это можно сделать и приводить непонятные статьи не имеющие к этому никакого отношения. Это стали делать вы, т.к. процитировали мою запись с указанием implements.

                                                  P.S.
                                                  У вас в интересах стоит лингвистика, но вы умудрились абсолютно переврать смысл написанного собеседником, подменять понятия и вообще наговаривать, вот пример:
                                                  Ну вообще-то, это вы задаете вопросы и что-то пытаетесь спорить.

                                                  Позор.
                                                  • 0
                                                    > Я утверждаю, что реализация более чем 1 уровня наследования в JS сделано очень ну удобно, т.к. оно повышает сложность реализации задачи.

                                                    Про что я написал, в частности

                                                    Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies. Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.


                                                    и

                                                    habrahabr.ru/post/153077/?reply_to=5251967#comment_5215845

                                                    Более того (повторяюсь) JS позволяет реализовывать различные способы наследования, а не только одну какую-либо концепцию.

                                                    Но вы упорно гнете «аааааа хочу интерфейсы».

                                                    Хорошо. Хотите. Вы способны ответить на один вопрос, ответа на который вы избегаете уже три сообщения подряд: в чем настолько большая разница между extends и implements?

                                                    > Я написал про интерфейсы. Я вообще завел речь про интерфейсы. Я же вообще стал говорить о их очень сложной реализации в JS(если вообще возможной)

                                                    Ветка с вашим участием вообще началась тут: habrahabr.ru/post/153077/?reply_to=5251967#comment_5207411 если что.

                                                    И началось там не с интерфейсов, а с наследования.

                                                    После чего у вас «несколько уровней наследования» ВНЕЗАПНО превратилось строго и исключительно в implements.

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

                                                    Сначала объясните, как у вас «несколько уровней наследования» превратилось в разговор строго и исключительно про implements, а потом поговорим про подмену понятий
                                                    • 0
                                                      Мнение авторов какого то портала на счет многоуровневого наследования можете оставить при себе. О нем никто кроме вас не говорит. И зачем вы вообще заговорили не понятно.

                                                      Напоминаю, вы начали обращаться ко мне, а не я к вам. Я лишь обобщенно сравниваю два языка.
                                                      Вы начали навязывать мне мнение не относящееся к тематике — «возможности языков и сложность реализации конструкций в языка».

                                                      После чего у вас «несколько уровней наследования» ВНЕЗАПНО превратилось строго и исключительно в implements.


                                                      Мои слова, которые, вы не хотите читать, похоже:
                                                      Кстати, забавный момент, когда я писал комментарий, я только раза 2 видел ts и вместо extends, я написал implements. И если на js реализовать extends возможно, то implements…

                                                      Тут я говорил, что первоначальный мой тезис был не корректен, т.к. я использовал не правильный statement. И что если с многоуровневым наследованием(которое подразумевается в extends) не все так плохо в JS, то с интерфейсами там действительно проблема.
                                                      Где вы тут увидели
                                                      Но вы упорно гнете «аааааа хочу интерфейсы».

                                                      я понять не могу.

                                                      Ветка с вашим участием вообще началась тут: habrahabr.ru/post/153077/?reply_to=5251967#comment_5207411 если что.

                                                      Проблему с многоуровневым прототипированным наследованием, реализованным в JS, мне кажется, я описал хорошо.
                                                      Резюме мнения каких то людей, можете приводить где угодно, но не в дискуссии где требуют аргументы. Отсылка к прочтению каких то больших текстов является не только плохим тоном, но и абсолютно не способствует понятию вашей мысли.
                                                      Если же у вас нет желания четко высказать где люди ошибаются, то лучше вообще не писать.

                                                      • 0
                                                        > Мнение авторов какого то портала на счет многоуровневого наследования можете оставить при себе. О нем никто кроме вас не говорит.

                                                        Я утверждаю, что реализация более чем 1 уровня наследования в JS сделано очень ну удобно, т.к. оно повышает сложность реализации задачи.


                                                        > И если на js реализовать extends возможно, то implements…

                                                        Повторю вопрос, на который вы упорно не хотите отвечать: В чем настолько большая разница между extends и implements?

                                                        > Проблему с многоуровневым прототипированным наследованием, реализованным в JS, мне кажется, я описал хорошо.

                                                        Где?

                                                        > Резюме мнения каких то людей, можете приводить где угодно, но не в дискуссии где требуют аргументы.

                                                        А ну да, я помню «Зачем мне понимать» ©

                                                        > Если же у вас нет желания четко высказать где люди ошибаются, то лучше вообще не писать.

                                                        Я уже написал, несколько раз. Причем подкрепил свое мнение ссылками и аргументами. Вы неспособны пока ответить даже на один простейший вопрос.
            • +2
              В ООП, реализованном через классовое наследование не нужно думать? Очень спорное утверждение.

              А если (по вашим словам) в ООП, реализованном через прототипное наследование, нужно думать намного больше, то м.б. действительно лучше рассмотреть другие альтернативы? Я имею ввиду нормальных во всех отношениях разработчиков. На брейнфаке, к примеру, нужно думать достаточно.

              Наследование обязано уменьшить сложность. А думать нужно всегда (мы же с вами на ИТ портале, где люди обычно думают).
              • +1
                Это самое наследование, прототипное, в JS было активно используемым далеко не всегда.
                Пишу на JS с 1999 года, помню тег .
                Ничто особенно не мешало мне и тогда писать нормальные «снежинки».

                • 0
                  Тег LAYERS
                • 0
                  Просто на JS уже пишут гораздо больше чем «снежинки» и текст, летающий за курсором мыши =)
                  • 0
                    Согласен, но даже сейчас лично мне далеко не всегда нужно наследование.
                    Точней, обычно оно мне вообще 300 лет не сдалось.

                    При этом я написал достаточно больших приложений, и уверен, что неплохо понимаю о чем говорю.
                    По идее, Наследование должно что-то там где-то там «Упрощать».

                    На мой взгляд кто-то излишне продвинутый когда-то придумал использовать прототипы JS для того, чтобы реализовать «классы». Но, мне продолжает казаться, что они задумывались совсем не для этой забавы. Соответственно, то, что понимается Вами под «наследованием» здесь не является тем что понимается под «прототипированием» мной.
                    • 0
                      Скажите, а вы один работали над этими «большими» приложениями или там была команда хотя бы в человек *дцать?
                      • +1
                        Там была и есть команда в «дцать».
                        На последнем проекте активно используется Ext.JS, где как раз и используются все перечисленные методы «классовой деградации».
                        Естественно, в угоду синтаксису приходится злоупотреблять ими и мне :)
                        Но я отнюдь не могу сказать, что мне это сильно нравится :)
                        Т.е., если бы этого не было, я бы как-нибудь бы справился :)

                        Так же продолжаю массово пользовался jQ, т.к. «free».

                        Кроме того активно пишу расширения для браузеров, там тоже бывает нужно.

                        На ранних порах была самодельная библиотека, в которой, конечно же, было «прототипирование» объектов.

                        Для меня это как по «поворот хрусталика» — просто использовать правильный термин, тогда становится ясно «что подразумевается».
                        Т.е., мне нужен не Базовый Класс, а именно Прототип Объекта :)

                        Вот, Вы же, например, знаете, что можно написать:

                        var myTheBest = function(){
                        }
                        
                        myTheBest.SomeProperty = 111;
                        


                        К сожалению, встречаются кадры, которые, например, могут думать об этой конструкции разное, или вообще о ней ничего не знают.
                        Т.к. это «разрыв шаблона».

                        Но думать здесь нечего, это просто есть.

                        Вот примерно об этом пытаюсь донести.
              • 0
                > В ООП, реализованном через классовое наследование не нужно думать?

                Я этого не говорил

                > А если (по вашим словам) в ООП, реализованном через прототипное наследование, нужно думать намного больше

                Этого я тоже не говорил

          • +2
            Так, в том то и дело, что:
            для многих классовое наследование может быть просто удобнее

            это в большинстве случаев и есть признак того, что человек не хочет разбираться.

            Разработка на JS, или, если угодно Vanilla.JS может быть не менее, а порой и более быстрой, если принять язык таким, какой он есть.
            • +1
              По поводу изучения и принятия системы разработки языка я с вами согласен и не спорю с этим!
              Повторюсь, речь о другом ЯП, транслируемом в JS.
              • 0
                :)

                С этим я тоже согласен, просто в этой ветке немножко отклонилось в сторону JS, поэтому позволил себе высказаться именно про JS.

                Идея более удобного средства выражения мыслей, гораздо более удобного большинству, мне, безусловно Импонирует. Тем более, что, думаю, мне бы он тоже понравился.
        • –1
          Я очень хорошо разбираюсь в js, но люблю использоваться coffeescript, т.к. меня банально утомляет писать одни и теже конструкции для ООП-подхода, а весь этот синтаксический шум, который приходит вместе с js просто замыливает код и отвлекает внимание.

          Ни в коем случае не критикую js, это прекрасный язык и я люблю его, но его выразительность оставляет желать лучшего.

          Кстати пока я не нашел дыр в абстракции, предлагаемой coffeescript, даже такие безумные вещи как «new MyClass args...» не дают течи.

          Поправьте меня, если ошибаюсь.
  • +12
    Немаловажная деталь, автор TypeScript — небезизвестный ru.wikipedia.org/wiki/Хейлсберг,_Андерс, один из основных авторов Dellhi и c#
    • +1
      Точно, судя по способу описания параметров в языке, чувак точно дельфист :-)
      • +1
        в ActionScript (ECMA-собрат) так же указываются, btw
      • 0
        На самом деле они сделали это специально. Идея заключается в том что запись типа «int i;» синтактически подразумевает обязательное присутствие указания типа переменной. А «i: int» как бы подсказывает, что тип второстепенен. Впрочем не берите мои слова на веру. Спросите у одного из разработчиков.
    • 0
      Я сначала подумал что переработал и дельфи уже везде мерещится…
  • +9
    Microsoft осуществили мою мечту! Статически типизированный JS с модулями!
  • +3
    Последние вести по поводу Javascript выглядят как репортажи с места боевых действий — постоянно появляются все направления развития этого языка и его инструментов. Динамика вокруг языка очень радует.
    • +2
      Ага, каждая пятая новость на хабре — «Посмотрите, у нас есть что-то похожее на js» или «Мы придумали новый транслятор с языка %language_name% на javascript»))
      • +2
        И отлично! Дальше уже Ваш выбор — вникать или пропустить мимо. Главное, что могут найтись заинтересованные люди, которым это может оказаться полезно. Даже если это никогда не пойдет в продакшн, все равно вдохновит других разработчиков, расширит взгляд на язык или просто доставит приятных минут дома за чашкой чая. Just for fun, как говорится :)
        • +1
          Я не говорил, что это плохо) Просто факт.
    • 0
      JavaScript — это Бейсик сего дня! (В хорошем смысле.)
  • 0
    Не знаю, как остальным, но мне всегда в JS нравилась схожая с С конвертация в bool (если быть точнее, работа оператора if похожая на работу в С).

    if (a.field) {
    ...
    }
    


    получается такого не будет и придётся сочинять огород
    if (a.field != null && a.field != undefined) {
    ...
    }
    


    Удобно было бы иногда использовать встроенный typecast
    • +3
      Зря так думаете, такая вот конструкция вполне успешно компилируется:

      var a = { field: {} };
      if (a.field) {
      				
      }
      

      На выходе в js она без изменений.
      Как уже было сказано, TypeScript это лишь надмножество JavaScript.
      • 0
        Ну отлично, если так. Просто разговор шёл про типизацию, я подумал, что там будет как в java — без ножей и веревок :-)
    • +3
      Позвольте поправлю, в соответствии со спецификацией,
      if (a.field != null && a.field != undefined) {
      эквивалентно
      if (a.field != null) {
      так как != null проверяет на 'null' и 'undefined'.
      что в строгом сравнении идентично
      if (a.field !== null && a.field !== undefined) {
      Первая констуркция совершенно бессмысленна, так как разворачивается в
      if ((a.field !== null && a.field !== undefined) && (a.field !== undefined)) {
      • 0
        Маленькая ремарка: правильнее писать не a !== undefined, а typeof a !== 'undefined'.
        Так как в первом случае сначала произойдёт попытка получить значение 'a', а уже потом сравнивать с undefined.
        После того как значение не будет найдено, в него произойдёт подстановка значения undefined.

        typeof a !== 'undefined' не получает значение самой переменной 'a', а просто выясняет принадлежность типа, на который ссылается референс 'a'. В свою очередь может показаться что они эквивалентны, но лишь на уровне реализаций.
        • 0
              var a = null;
              typeof a; //"object"
          

          И тогда проверка typeof a !== 'undefined' валится, если вы работаете с Явой на бэкэнде и вам присылают явные null в ответах :(
          • 0
            не вижу противоречий
            typeof a !== 'undefined' && a !== null
            отлично отработает ваш случай.
            но я бы рекоммендовал всегда писать в случаях если вам нужно проверить есть ли значение писать != null;
            • 0
              Ну я это и имел ввиду, что нельзя все проверки заменить только на typeof a !== 'undefined', надо обязательно проверять на null, если есть вариант, что придет null.
              • 0
                typeof a !== 'undefined' вообще использовать не надо. a != null отлично применяется практически для всего кода.
                • 0
                  Если не поставить первым typeof a !== 'undefined', то при undeclared a вывалится ошибка в if (a != null). Так что использовать надо все методы, но там, где это надо.
                  • 0
                    undeclared? А зачем использовать undeclared переменные? О.о
                    • 0
                      Бывает, что ты не знаешь, существует такая переменная или нет, а проверить надо.
                      • 0
                        Это миф. При правильном подходе к разработке на JS такого практически не бывает. Единственное, что я сходу смог вспомнить — это определение глобального объекта в неизвестной среде (клиент/сервер).
  • 0
    Мне лично система типов кажется несколько слабой. Скажем, если использовать closure compiler и проставлять везде аннотации, то можно составлять гораздо более интересные конструкции: параметризация Array.<тип>; объединение (тип1|тип2), nullable: тип?; описывать записи {поле: тип, поле2: тип2}. Подробнее описывается в документации.
    При желании, CC можно сконфигурировать так, что он не будет компилировать код в случае нарушения типов или классификаторов доступа (аннотации private, @protected и т.п.). Код, при этом, будет оставаться вполне себе исполняемым и без компиляции.

    В случае, если без привычного способа объявления классов совсем плохо, то можно использовать Traceur compiler тоже от Гугл, который реализует некоторые из фишечек следующей спецификации JS (те же классы, например) и работает по схожему принципу с Typescript (кросскомпиляция в наиболее поддерживаемое подмножество JS). Тут компиляция, разумеется, уже необходима.
  • 0
    В javascript добавляют статическую типизацию, в шарпы наоборот — динамическую. Забавая конвергенция.
    • +1
      Для разных задач разные подходы. По-моему это наоборот очень круто. Если нужно написать небольшой скриптик (для чего JS изначально и разрабатывался), то можно писать в старом стиле — там не нужна ни типизация, ни ООП. А если нужно написать что-нибудь понавороченней, то тут как раз TypeScript поможет не запутаться в анонимных функциях-обёртках, прототипах и т. п.
      • +1
        А я и не спорю, что круто. Мне оба подхода дороги и важны, причем они вполне уживаются вместе. Рад, что расширяется набор инструментов для комфортной работы.
  • +2
    >… в то время, как выпуск Dart кажется не вполне подготовленным.
    Ибо Dart даже до m1 не дорос ещё.
  • +3
    у Microsoft есть и другие козыри в рукавах, например Koka
    • 0
      А еще в какой-то степени — ScriptSharp, конвертер C# в JavaScript, который разрабатывает один из архитекторов ASP.NET.
      Старый сайт с примерами сломали, новый еще не сделали :(
      scriptsharp.com/
      • 0
        Насколько я знаю, Script# уже не разрабатывается, но есть альтернатива: www.saltarelle-compiler.com/
  • 0
    Интересно, надо посмотреть…
  • 0
    Еще одно возможное применение TypeScript — причесывать некрасивый JavaScript.
    Например, так: gist.github.com/3814708
    • 0
      А в чём разница?
      • 0
        ASI, скобочки после конструктора, разные мелкие вещи вроде фигурных скобок.
        Пример не особенно иллюстративен, каюсь.
  • 0
    Ох если бы они сделали перегрузки еще
    • 0
      Если верить Language Specification, 6.3 Function Overloads, то они их сделали.
      • 0
        Я слепой, не видел спек, только глупый «Learn» ни о чем
        • 0
          На самом деле, как я понял, overloading у них или не до конца реализован, или реализован крайне странно (только на уровне объявления типа функции).
          • 0
            Ну судя по манулу, просто в итоговом коде создастся несколько функций с разными именами, и обращения к этим функциям (к какой из них) разрешаться еще в компайл-тайм, по-крайней мере это самый оптимальный способ
            • –1
              Е-мае… так сложно посмотреть 50 минутное видео?
              channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-TypeScript

              (если лень смотреть все перемотайте на 12 минуту — там есть материал про function overload)
            • –1
              А нет… извините… немного не понял вопрос… то что вы хотите получить можно получить вот так
              class TestClass {
                  someMethod(stringParameter: string): void;
                  someMethod(numberParameter: number, stringParameter: string): void;
              
                  someMethod(stringOrNumberParameter: any, stringParameter?: string): void {
                      if (stringOrNumberParameter && typeof stringOrNumberParameter == "number")
                          alert("Variant #2: numberParameter = " + stringOrNumberParameter + ", stringParameter = " + stringParameter);
                      else
                          alert("Variant #1: stringParameter = " + stringOrNumberParameter);
                  }
              }
              
              
              var t = new TestClass()
              t.someMethod("a");
              t.someMethod(1, "a");
  • 0
    Один из больших минусов сейчас — это то, каким образом можно дебажить (так, чтоб ставить брекпоинты в исходном .ts, отслеживать типы и т.д.

    Может сокро source maps прикрутят… будет интересно.

    А в целом, имхо лучше бы они в IE потехоньку подкручивали ES6. Например те же классы:
    wiki.ecmascript.org/doku.php?id=harmony:classes
    wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes

    Просто выходит что TypeScript — это просто чуть чуть улучшенный JS — так почему бы впилить его в IE.

    Если сравнить с Dart:, так те намного более координально изменили синтаксис, сделали «нативное» выполнение хоть в одном броузере, обеспечили возможность «дебагинга» исходнгого кода.
    • 0
      > Например те же классы:

      От идеи натягивать на JS C++-like ООП отказались еще года два тому назад. Причем главным противником с основной аргументацией против выступил как раз МС
  • 0
    import http = module(«http»);

    как это транслируется в _браузерный_ жаваскрипт?

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