Comments 61
Ну что же, радует что появляются дополнительные инструменты. Раз вы выбрали Saltarelle, значит было из чего выбирать, т.е. расскажите про сам процесс выбора, с чем сравнивали, почему Saltarelle победил?
Ну и самое главное в чем преимущество, если оно есть, у Saltarelle перед GWT?
Ну и самое главное в чем преимущество, если оно есть, у Saltarelle перед GWT?
А не подскажите как при помощи этой бибблиотеки рисовать на Canvas из JS? Ведь наверняка System.Drawing не подерживается этой библиотекой?
Спасибо
Спасибо
Не так давно на Хабре выкладывали ссылку на сетевую игру bomberman, которая написана на GWT. Ребята сами сделали биндинг к canvas API. Я думаю, любая подобная библиотека поддерживает некий native API, с помощью которого можно на JS написать классы для Java или C#. Причём, в данном случае не обязательно даже использовать имеющийся System.Drawing или там Java 2D. Конечно, жаль, что не заработает уже имеющийся код. Но с другой стороны, в таких случаях редко стандартная библиотека эмулируется настолько хорошо, чтобы шёл имеющийся код.
В корне не согласен с утверждением, что JS подходит лишь для небольших скриптов. Во времена DHTML так и было, а сейчас JS развился до уровня любого интерпретируемого языка, ещё и фору многим даст по куче вопросов.
Аргумент «для C# есть Решарпер» — вообще непонятно о чём. А для JS есть куча редакторов, IDE, линтеров и т.п. и т.д. + нативная поддержка практически везде, где только можно, включая уже и серверные решения, и создание мобильных приложений.
Уверен, скоро и десктопный софт можно будет писать.
Впрочем, для тех кто знает C# и слабо (или совсем не) знает JS — наверно, этот проект позволит какое-то воемя держаться на плаву веб-разработки.
Аргумент «для C# есть Решарпер» — вообще непонятно о чём. А для JS есть куча редакторов, IDE, линтеров и т.п. и т.д. + нативная поддержка практически везде, где только можно, включая уже и серверные решения, и создание мобильных приложений.
Уверен, скоро и десктопный софт можно будет писать.
Впрочем, для тех кто знает C# и слабо (или совсем не) знает JS — наверно, этот проект позволит какое-то воемя держаться на плаву веб-разработки.
Аргумент «для C# есть Решарпер» — вообще непонятно о чём. А для JS есть куча редакторов, IDE, линтеров и т.п. и т.д. + нативная поддержка практически везде, где только можно, включая уже и серверные решения, и создание мобильных приложений.
Все эти кучи редакторов не умеют того, что умеет Решарпер или Эклипс. И дело не в редакторах, а в типизации.
Уверен, скоро и десктопный софт можно будет писать.
Да хоть сейчас. Rhino в руки, и с помощью Swing можно всё что угодно нарисовать. Вопрос в том, целесообразно ли. Маленькие вещи — да пожалуйста. Большой монструозный софт на миллионы строк — нецелесообразно. Запутаетесь и всё на свете проклянёте.
А ЗАЧЕМ типизация??? это как раз самая вкусная часть языка а вы тут снова…
Типизация нужна для того, чтобы производить хоть какую-то проверку корректности программы. Ну а как хороший побочный эффект — ещё автокомплит и полноценный рефакторинг в IDE.
Автокомплит есть практически в любом редакторе, а каким образом возможность рефакторинга зависит от инструмента — я не очень понимаю.
Отсутствие строгой статической типизации в JS — это один из крупнейших плюсов языка и нимколько не мешает проверке кода. Просто она проводится другими инструментами и способами.
Вдобавок ко всему, Решарпер привязывает разработчика к Visual Studio, а значит — к ОС Windows. Нельзя при желании перейти на *nix или OSX, или ещё что-нибудь, а отсутствие выбора — это плохо.
Отсутствие строгой статической типизации в JS — это один из крупнейших плюсов языка и нимколько не мешает проверке кода. Просто она проводится другими инструментами и способами.
Вдобавок ко всему, Решарпер привязывает разработчика к Visual Studio, а значит — к ОС Windows. Нельзя при желании перейти на *nix или OSX, или ещё что-нибудь, а отсутствие выбора — это плохо.
Автокомплит есть практически в любом редакторе,
Автокомплит вида «все слова, начинающиеся с заданной последовательности символов, которые есть в файлах проекта» — это вовсе не автокомплит вида «показать методы, которые гарантированно есть у данного объекта, с полным перечнем аргументов, принимаемых методом да ещё и с подробной документацией».
а каким образом возможность рефакторинга зависит от инструмента — я не очень понимаю.
В процессе рефакторинга возникают ошибки, которые может отлавливать IDE. Некоторые операции IDE вообще может сделать сама, если ей доступны типы на этапе компиляции
Отсутствие строгой статической типизации в JS — это один из крупнейших плюсов языка и нимколько не мешает проверке кода. Просто она проводится другими инструментами и способами.
Юнит-тесты? А зачем писать сотни юнит-тестов, если можно просто взять другой язык? К тому же, не всегда можно покрыть код юнит-тестами.
Вдобавок ко всему, Решарпер привязывает разработчика к Visual Studio, а значит — к ОС Windows. Нельзя при желании перейти на *nix или OSX, или ещё что-нибудь, а отсутствие выбора — это плохо.
Eclipse, Netbeans для тех, кому нужна кроссплатформенность. А, впрочем, есть и MonoDevelop, хотя она сильно уступает VS. Но всё же лучше, чем те самые «IDE» для JavaScript.
показать методы, которые гарантированно есть у данного объекта, с полным перечнем аргументов, принимаемых методомДело в том, что в JS нельзя гарантированно знать (до выполнения кода), какие методы есть у какого-либо объекта. И это огромный плюс.
Юнит-тесты? А зачем писать сотни юнит-тестов, если можно просто взять другой языкС этого я и начал — если не устраивает (или не знаете/не понимаете) один язык — просто возьмите другой.
Дело в том, что в JS нельзя гарантированно знать (до выполнения кода), какие методы есть у какого-либо объекта. И это огромный плюс.
И в чём же тут большой плюс?
В гибкости.
В каком месте это даёт гибкость, где её нельзя достичь с C# или Java? Примеры можно? И уж не слишком ли дорогой ценой эта гибкость даётся?
А я и не сравниваю JS с другими языками. Основной смысл — если берёте язык, используйте его так, как он устроен. Если это не устраивает — просто возьмите другой язык.
Вот и всё, что я пытаюсь до вас донести.
Вот и всё, что я пытаюсь до вас донести.
Основной смысл — если берёте язык, используйте его так, как он устроен. Если это не устраивает — просто возьмите другой язык.
Ага, вот, собственно, человека не устраивал язык JavaScript и устраивал язык C#. Он взял и сделал возможным писать в браузере на C# таким вот образом. Вы тут приходите и говорите, что, мол, это нужно только для людей, которые не осилили C#.
Кстати, вот по поводу использовать язык так, как он устроен. Да, динамическая типизация позволяет любому объекту добавить метод в любой момент, и это обеспечивает гибкость небольшими усилиями. Но та же гибкость достигается чуть большими усилиями в статически типизированных языках с помощью паттернов factory и strategy, а так же генерацией байт-кода на лету в .NET и JVM, если нужно что-то совсем специфическое. При этом JavaScript благодаря своей фишке затрудняет написание больших проектов. Вот и вывод: взяли JavaScript, не пишите ничего большого. А если нужно что-то большое, то что делать? Вот люди и придумывают решения.
Удачи работать с транзакционкой на JS.
с чем?
За все время работы, я не встречал ни одной системы, которая работала бы с транзакционными данными, и была написана на языке без строгой типизации. Может для чистой веб разработки это и не важно, но есть класс задач, которые я бы не рискнул делать на том же самом JS. То есть вообще не подписался бы под таким проектом. И eсли бы попытались заставить — уволился бы. Для чистого веба JS -Ok, но для энтерпрайз и OLTP — упаси.
Ну я рад, что вы не взялись а я вот взялся и сделал ) Значит мне не грозит еще недостаток работы в следующие 30+ лет. Так что могу только приветствовать и помогать в развитии таких идей. Чем больше людей будут так думать, тем больше моя стоимость :)
OLTP на JS? Если не секрет, то где?
Не буду голословно утверждать, что OLTP, но скажем так, самые ответственные части сложных финансовых систем с реал-тайм доставкой данных (трейдинг и т. п. при этом чур чур не форекс)
На JS? Node.js? Стоимость простоя системы в час?
Да. Посчитать мне это конечно сложно. Но какие часы. Представьте, что даже просто разрыв конекта это отключение всех финансовых организаций всей страны (топовых финансовых организаций). За полтора года было две траблы самого высокого уровня, лишь одна связана с очень редким случаем критичного стечения обстоятельств в моей системе. А дальше, обычный рабочий режим, благо, есть выходные и ночь для технических работ. В общем, считайте, что если даунтайм равен часу, вся компания закрывается.
Если честно, не представляю, систему такого уровня на JS. Мы, к примеру, страхуем все финансовые риски наших клиентов… То есть потеря клиента по вине нашего софта обходится нам весьма и весьма. Но у нас полноценный OLTP, с обновлением без даунтайма и тд, плюс защита от подмены кода и тд. Не представляю как делать системы с такой защитой на JS. Ну и работу с бинарными данными и тд…
Дык :) Мне то как раз платят за то, что я это делаю.
Может я чего упустил, но ради интереса, как открыть транзакцию в бд на JS? к примеру в MS SQL?
Может я не очень понял, при чем тут транзакции в MS-SQL и как они связаны с языком системы (поскольку транзакции то обеспечиваются на уровне БД), но если вы посмотрите здесь, и вам действительно это интересно, то найдете: cretz.github.com/node-tds/
Вы можете открыть распределенную транзакцию, в которой будут участвовать как сервисы, так и бд. Причем в транзакции могут участвовать как ваши сервисы, так и сервисы ваших контрагентов. Есть еще к примеру WS-Atomic Transaction, WS-Security и тд. Плюс поверх сложность проекта, если это просто шлюз к платежным системам — это одно, если это сама платежная система, то это другой разговор. Даже теоретически не могу себе представить проект такой сложности на JS. Но во мне всегда говорит параноик=) У меня все сборки подписаны, даже конфигурационные данные я шифрую и подписываю на случай подмены. Сторонний код(все кроме ядра) может грузиться в отдельный AppDomain и не иметь доступа к ядру. Я видел модули к ноде для WS-Trust, но там использовалась UserName аутентификация. Плюс опять же производительность. Разные модели масштабирования. И, что самое важное, поддержка такого решения в большой команде с разным уровнем разработчиков. Я имел возможность посмотреть на такие проекты на RoR и не могу сказать, что для OLTP систем это подходит. Java,.Net, C++ — ИМХО идеальны для таких систем. Но это просто личный опыт.
Сложность в том, что вы сами понимаете, я не могу раскрывать многие детали внутренних реализаций. А без данных мы только можем обмениваться фразами типа «а у меня длинее». Без претензий, но язык — это не важно. Любое решение можно сделать на любом языке — просто потому, что все в итоге сводится к одному и тому же бинарому коду. Нет, у меня не платежная система, только информация и немного аналитики (которая во многих случаях на других языках), часть данных мне также поставляют системы на С++ или удаленные сервисы. Но из этого всего конечный продукт и ценность, критичную по скорости и надежности, создает моя система на ноде и JS. Думаю, нам нет смысла дальше что-то обсуждать просто по причине того, что через фразу-другу мы оба упремся в NDA, а это что-то да значит.
Интересно было узнать что на ноде даже клиент для ADFS сделали=) Думаю лучше выбирать инструмент в контексте задачи, опыта и доступных ресурсов. Я лично очень люблю .Net и иногда Java. Если требуется динамическое поведение просто использую DLR. Благо платформа очень гибкая в этом плане. Но это ИМХО=) Может мы даже с вами где-нибудь да и интегрировались хе хе=)))
Я пишу на JS достаточно крупные вещи, «миллионов строк» там, конечно, нет, но если у вас в одном каком-то модуле написана простыня на миллион строк — тут дело точно не в JS. А стремиться к правильному коду — у вас не будет методов длиннее пары десятков строк.
Если разработчик путается в языке — возможно, ему стоит заниматься задачами на других языках. Или разобраться в том, в котором путается до начала работы.
Про Решарпер — приведите пару примеров того, что есть в нём и нет в других инструментах?
Если разработчик путается в языке — возможно, ему стоит заниматься задачами на других языках. Или разобраться в том, в котором путается до начала работы.
Про Решарпер — приведите пару примеров того, что есть в нём и нет в других инструментах?
Я пишу на JS достаточно крупные вещи, «миллионов строк» там, конечно, нет, но если у вас в одном каком-то модуле написана простыня на миллион строк — тут дело точно не в JS.
Проекты на миллион строк != классы на миллион строк. Ну пожалуйста, сколько там строк в ядре Линукса? Скажем, в крупном проекте может быть какое-то число пакетов, в каждом — какое-то число классов, каждый класс в среднем строк 200-300.
Если разработчик путается в языке — возможно, ему стоит заниматься задачами на других языках.
Разработчик прекрасно знает язык, но может путаться в проекте на миллион строк, т.к. такой объём информации просто невозможно удержать в голове (и вообще, такой крупный проект, очевидно, писали несколько разработчиков). Да что там миллионы, даже десятков тысяч хватит, чтобы взяться за голову в случае динамической типизации.
Про Решарпер — приведите пару примеров того, что есть в нём и нет в других инструментах?
Конкретно про Решарпер не могу, но могу про Eclipse или про IntelliJ Idea. Так вот, я могу беспрепятсвенно переименовать метод. Я могу убрать метод или свойство и сразу увижу куски кода, которые зависели от этого метода и убрать лишние вызовы. Я могу найти все вызовы метода. Я могу найти все реализации метода во всех подклассах. Возможно ли такое с JavaScript?
Если речь про большой проект — то вовсе не надо держать в голове каждую строку каждого метода, надо держать в голове сами методы, объекты и связи между ними, а это уже от языка вообще не зависит.
Про поиск по проекту — конечно же, в любом нормальном редакторе есть поиск по файлам проекта. Почему вы считаете, что это уникальная фича? Попробуйте, для разнообразия, поработать в Sublime Text 2, например.
Про поиск по проекту — конечно же, в любом нормальном редакторе есть поиск по файлам проекта. Почему вы считаете, что это уникальная фича? Попробуйте, для разнообразия, поработать в Sublime Text 2, например.
Если речь про большой проект — то вовсе не надо держать в голове каждую строку каждого метода, надо держать в голове сами методы, объекты и связи между ними, а это уже от языка вообще не зависит.
Итак, проект — это миллион строк. Средний размер метода — 10 строк, средний размер класса — 100 строк. Итого 100000 методов в 10000 классах. Готовы держать такое в голове?
Про поиск по проекту — конечно же, в любом нормальном редакторе есть поиск по файлам проекта. Почему вы считаете, что это уникальная фича? Попробуйте, для разнообразия, поработать в Sublime Text 2, например.
Это не уникальная фича, любая IDE это умеет. Только вот тут есть нюанс: если язык статически типизированный, то IDE построит логическую модель программы и будет искать по ней методы не по названию, а по типу. Она найдёт именно данный метод данного класса. В случае с динамикой доступен лишь обычный текстовый поиск. Это уже совсем не то же. Я же писал про поиск конкретных вещей. Вот есть у меня метод и я хочу перейти к его определению. Ctrl+Click. Если же тип переменной — интерфейс, то Ctrl+T, и выбор нужного метода из коротенького списка (или мгновенный переход, если реализация одна). Как это выглядит в ST2? А может ли ST2 автоматически построить диаграмму зависимостей в коде?
А 100000 методов и 10000 классов C# вы в голове удержите? Тут уже нет никакой зависимости от языка.
Судя по аргументам, единственная «проблема», которая вызывает все остальные неприятные для вас следствия — это динамическая типизация. Странно в таком случае использовать JS, ведь это одна из основных фишек языка.
Судя по аргументам, единственная «проблема», которая вызывает все остальные неприятные для вас следствия — это динамическая типизация. Странно в таком случае использовать JS, ведь это одна из основных фишек языка.
А 100000 методов и 10000 классов C# вы в голове удержите? Тут уже нет никакой зависимости от языка.
Вот именно. За меня всё это в «голове» будет держать IDE и всё время мне помогать.
которая вызывает все остальные неприятные для вас следствия — это динамическая типизация.
Нет, это не так. У меня есть и другие претензии к JS. Это — одна из важнейших.
Странно в таком случае использовать JS, ведь это одна из основных фишек языка.
Во-первых, большинство использований JS для меня — это пара строчек, которые добавляют небольшой динамический функционал к HTML. Если же нужно что-то крупное, есть GWT. Динамическая типизация — это фишка скриптового языка и использовать его надо как скриптовый, а не писать на нём что-то сложное. Если же нужно что-то сложное, то, к сожалению, у меня нет выбора, т.к. других языков в браузере просто не предусмотрено. Потому и приходится использовать костыли вроде GWT или того, который представлен в статье.
К слову, в том же ST2 очень легко работает переход к опрределению метода, никаких проблем с этим не возникает.
Что такое «диаграмма зависимостей» я не понял.
Что такое «диаграмма зависимостей» я не понял.
К слову, в том же ST2 очень легко работает переход к опрределению метода, никаких проблем с этим не возникает.
Сдаётся мне, это работает в очень ограниченном числе случаев. Ну вот правда: есть у меня вызов foo.bar(). Скажем, метод bar объявлен в совершенно разных классах. Это хорошо, если название специфическое. А если нужно перейти к методу с названием add, то что делать? Выбирать из длинного списка всех имеющихся методов add?
Не называть метод «add». Смысловые названия методов и переменных — это полезно в любом языке.
Эмм… Ну и как это будет? Вместо
писать
? O_O
order.Invoice.Items.Add(...)
писать
order.OrderInvoice.InvoiceItems.AddInvoiceItem(...)
? O_O
Вот допустим будете вы реализовывать метод:
И ни одна JS-IDE в мире не подскажет вам методы и свойства объекта iRenderableObject.
Что уж говорить о случае, когда вы используете прототипное наследование:
И ни одна JS-IDE в мире не подскажет вам, что у объекта foo в цепочке прототипов есть метод test.
function Render(iRenderableObject){
...
}
И ни одна JS-IDE в мире не подскажет вам методы и свойства объекта iRenderableObject.
Что уж говорить о случае, когда вы используете прототипное наследование:
function A(){};
function B(){};
A.prototype = new B();
B.prototype.test = function(){}
var foo = new A();
И ни одна JS-IDE в мире не подскажет вам, что у объекта foo в цепочке прототипов есть метод test.
Конечно не подскажет, ведь iRenderableObject на момент написания кода — это просто имя переменной, не больше. Что вы туда передадите, то там и окажется.
Поэтому с JS приходится думать, а не просто выбирать что-то из списка автокомплита.
Поэтому с JS приходится думать, а не просто выбирать что-то из списка автокомплита.
Конечно не подскажет, ведь iRenderableObject на момент написания кода — это просто имя переменной, не больше. Что вы туда передадите, то там и окажется.
А то мы тут все этого не понимаем!
Поэтому с JS приходится думать, а не просто выбирать что-то из списка автокомплита.
Думать — это помнить наизусть 100500 методов? Нет уж, увольте от таких «думать». Я пойду над дизайном системы подумаю, над организацией процесса разработки, над выбором инструментов, а не потрачу своё время на зубрёжку.
Если вы придумали «дизайн системы», в котором вам всегда надо помнить все 100500 методов — видимо, такой уж «дизайн системы» придумали.
Да как минимум, стандартная библиотека языка. DOM, DOM HTML, Canvas, XMLHttpRequest и т.д. Вот и получается 100500 методов. Иногда IDE выдаёт автокомплит при использовании этих API, иногда — нет. Если забыл, как правильно писать parentNode или parent, или в каком порядке идут параметры в insertBefore, милости просим отвлекаться, переходить в браузер и искать ответ в документации.
Просто JS становится таким современным ассемблером. Быст, гибок, универсален — да. Но писать на нем что-то масштабное крайне сложно. Да, наверное есть уникумы кто может создавать и развивать крупный проект на JS, но это единичные фанатики (в хорошем смысле этого слова, вспомним эмулятор линукса на JS). Для обычного программера держать в уме 100500 строк на JS — совершенно не реально, да и не зачем.
Я, по хорошему, вам завидую, если и правда вы один из таких энтузиастов JS, но со временем JS как и ассемблер уйдет в очень узкую нишу. И наверное, нет смысла его из этой ниши вытаскивать.
Поймите меня правильно, я не против JS, но для всякой работы должен быть свой инструмент. И если раньше мужики избу ставили только с помощью топора, то это вовсе не повод сегодня отказываться от дрели и шуруповерта.
Я, по хорошему, вам завидую, если и правда вы один из таких энтузиастов JS, но со временем JS как и ассемблер уйдет в очень узкую нишу. И наверное, нет смысла его из этой ниши вытаскивать.
Поймите меня правильно, я не против JS, но для всякой работы должен быть свой инструмент. И если раньше мужики избу ставили только с помощью топора, то это вовсе не повод сегодня отказываться от дрели и шуруповерта.
А в чём именно сложность написания крупного проекта на JS? Вот хотя бы одну причину назовите. «Путаюсь в динамической типизации» — не считается.
С JS приходится не думать, а гадать — что же вам туда передадут.
Теоретически, если бы у JS появилась типизация входных параметров в функции — чем бы это понизило гибкость?
Да, придется использовать интерфейсы, но зато автокомплит и автоматическая проверка на тип аргумента.
Теоретически, если бы у JS появилась типизация входных параметров в функции — чем бы это понизило гибкость?
function Render(param:iRenderable, key:Number){
...
}
Да, придется использовать интерфейсы, но зато автокомплит и автоматическая проверка на тип аргумента.
Уже можно писать десктопный код.
Если мне память не изменяет JS — один из мэйнстримовых языков для Win8.
Если мне память не изменяет JS — один из мэйнстримовых языков для Win8.
А поддержка Knockout.js планируется?=) Это было бы просто супер.
Sign up to leave a comment.
Saltarelle: open source C# — JavaScript компилятор