Комментарии 54
Простейшие примеры выглядят как-то неоправданно раздуто. На чистом C# и на чистом JS было бы гораздо компактнее.
+1
на чистом JS было бы гораздо компактнее
Ну, с этим никто не спорит, у подобного подхода есть своя цена. «Раздутость» кода связана с поддержкой всех C#-штук, которые мы должны уметь делать. К счастью, сгенерированный JavaScript нам не нужен для дальнейшей работы — разрабатывать и отлаживать можно на C#.
+1
А что делать, когда есть большой кусок кода / библиотека написанная на JS. Как реализовано взаимодействие C#<->JS?
Можно ли из C# дернуть JS методы, а из JS потом вызвать C#-колбек?
Можно ли из C# дернуть JS методы, а из JS потом вызвать C#-колбек?
+1
Не уверен, не изучал вопрос. Попробуйте написать авторам библиотеки.
0
Через dynamic поди
0
Если вас интересует серверный JS, то есть библиотека edge, которая позволяет делать интероп между кодом на C# и JS без всякой трансляции.
Если же говорить именно про Duocode, то тут всё странно. В официальном FAQ есть только про вызовы C# из JS, а для всего остального они вроде бы написали врапперы. Всегда можно, конечно, посмотреть, как они делают эти врапперы, но есть более прямолинейный подход. Вы можете в своём коде при инициализации получить объект со списком лямбда-функций. Когда JS вызывает ваш код на C#, он передаёт в него ссылки на все необходимые функции, и вы их потом вызываете.
Но я бы не стал использовать Duocode, пока не появится серьёзных портов чего-нибудь с C# в браузер. Все существующие трансляторы (Netjs, IL2JS) так и не были доведены до конца вследствие технических сложностей такой реализации.
Если же говорить именно про Duocode, то тут всё странно. В официальном FAQ есть только про вызовы C# из JS, а для всего остального они вроде бы написали врапперы. Всегда можно, конечно, посмотреть, как они делают эти врапперы, но есть более прямолинейный подход. Вы можете в своём коде при инициализации получить объект со списком лямбда-функций. Когда JS вызывает ваш код на C#, он передаёт в него ссылки на все необходимые функции, и вы их потом вызываете.
Но я бы не стал использовать Duocode, пока не появится серьёзных портов чего-нибудь с C# в браузер. Все существующие трансляторы (Netjs, IL2JS) так и не были доведены до конца вследствие технических сложностей такой реализации.
0
«А теперь представьте ситуацию: есть заядлый C#-разработчик. Он очень любит C#, все-все проекты на нём пишет. Но судьба распорядилась так, что ему понадобилось написать клиентское веб-приложение.»
И он берёт TypeScript и радуется жизни. Или не берёт, но почему?
И он берёт TypeScript и радуется жизни. Или не берёт, но почему?
+5
TypeScript — отличная штука. Но предыдущее детище Хейлсберга всё-таки радует намного больше в плане синтаксиса и инструментария.
0
(Disclaimer: мне нравится C#, как язык.)
Потому что заядлые C#-разработчики такие заядлые, видимо. Многие просто не хотят ничего учить.
Потому что заядлые C#-разработчики такие заядлые, видимо. Многие просто не хотят ничего учить.
+2
Тут не в обучении дело, TypeScript достаточно простой. Но C# всё-равно значительно обгоняет его в плане возможностей.
+1
JS-то еще проще.
Я в принципе понимаю, что вы хотите сказать, но вообще-то JS обладает полнотой по Тьюрингу:) Единственное, чего мне действительно не хватает — это атрибутов.
значительно обгоняет его в плане возможностей
Я в принципе понимаю, что вы хотите сказать, но вообще-то JS обладает полнотой по Тьюрингу:) Единственное, чего мне действительно не хватает — это атрибутов.
+1
Ну, это не аргумент, Brainfuck тоже полный по тьюрингу. В C# есть мощный reflection, богатые возможности по работе с ООП, клёвый LINQ, куча синтаксического сахара (особенно с C# 6). Да, я знаю, что в JS есть куча библиотек, которые всё это пытаются эмулировать, но функционал всё равно не тот.
Плюс, не стоит забывать про инструментарий. Да, статическая типизация в TypeScript помогает, но с помощью VS2015+ReSharper9 я могу за 5 минут выполнить такой рефакторинг большого проекта, на который в любом другом трансляторе в JS у меня бы ушёл минимум день. Да, JS проще, маленькие проекты на нём быстро поднимаются. Но если у вас сотни тысяч строк бизнес-логики, то поддерживать такой проект на JavaScript — не самая лёгкая задача.
Плюс, не стоит забывать про инструментарий. Да, статическая типизация в TypeScript помогает, но с помощью VS2015+ReSharper9 я могу за 5 минут выполнить такой рефакторинг большого проекта, на который в любом другом трансляторе в JS у меня бы ушёл минимум день. Да, JS проще, маленькие проекты на нём быстро поднимаются. Но если у вас сотни тысяч строк бизнес-логики, то поддерживать такой проект на JavaScript — не самая лёгкая задача.
+1
Ну, это не аргумент. Вместо LINQ у нас map/reduce и карринг, ООП у нас тоже есть, сахар — дело вкуса. Reflection'а не хватает, тут согласен. Рефакторинг я делаю в WebStorm точно с такой же скоростью.
Я что-то сомневаюсь в больших проектах на компилируемых в JS языках. Во-первых, из-за поддержки всех тех фич все это будет неимоверно весить и тормозить, во-вторых, рано или поздно придется дебажить в каком-нибудь IE9, в котором поддержки source map нету и не будет. В-третьих, этого GWT-подобного добра сколько угодно, и ни один большой проект на них не написан, почему-то.
Набросать что-то на скорую руку, если JS ты не знаешь, а надо срочно — запросто. А делать что-то большое, не зная досконально нижележащих технологий — рискованно.
Но если у вас сотни тысяч строк бизнес-логики, то поддерживать такой проект на JavaScript — не самая лёгкая задача.
Я что-то сомневаюсь в больших проектах на компилируемых в JS языках. Во-первых, из-за поддержки всех тех фич все это будет неимоверно весить и тормозить, во-вторых, рано или поздно придется дебажить в каком-нибудь IE9, в котором поддержки source map нету и не будет. В-третьих, этого GWT-подобного добра сколько угодно, и ни один большой проект на них не написан, почему-то.
Набросать что-то на скорую руку, если JS ты не знаешь, а надо срочно — запросто. А делать что-то большое, не зная досконально нижележащих технологий — рискованно.
+4
НЛО прилетело и опубликовало эту надпись здесь
Ок, Catberry намекает на то, что если руки растут из того места, то и правда можно. Увы, таких разработчиков не так уж и много. А C# просто не даст совершить тех ошибок, которые среднестатистический Js-разработчик делает каждый день (это не камень в сторону Js, просто говнокодеров в последнее время слишком много развелось). Плюс, повторю мысли из соседних комментариев о пользе DuoCode-подхода:
А по поводу больших проектов: как бы не развивался Js в наши дни, я не верю, что возможности рефакторинга сравнятся с C#+VS2015+R#. Плюс, если проект хорошо написан, то большая часть проблем уходит сразу. А если он плохо написан? Мне доводилось делать рефакторинг огромного количества говнокода на C#, инструментарий сделал эту работу не такой сложной. А если бы это был проект с нестрогой динамической типизацией, то я бы скорее плюнул и написал бы с нуля и нормально.
- Более богатый синтаксис и возможности платформы (тот же reflection). Ну не может тут Js составить достойную конкуренцию, не его это судьба.
- Портирование существующих C#-проектов на сторону клиента
А по поводу больших проектов: как бы не развивался Js в наши дни, я не верю, что возможности рефакторинга сравнятся с C#+VS2015+R#. Плюс, если проект хорошо написан, то большая часть проблем уходит сразу. А если он плохо написан? Мне доводилось делать рефакторинг огромного количества говнокода на C#, инструментарий сделал эту работу не такой сложной. А если бы это был проект с нестрогой динамической типизацией, то я бы скорее плюнул и написал бы с нуля и нормально.
0
НЛО прилетело и опубликовало эту надпись здесь
А reflection лично мне за всю разработку на JS особо не понадобился.
Это больше вопрос привычек и парадигмы мышления. Когда много и хорошо решаешь какие-то задачи с помощью какого-то инструмента, то сразу замечаешь, когда инструмент у тебя отобрали. Например, я как функциональщиной увлёкся, начал иногда в C# ощущать небольшой дискомфорт (LINQ вывозит, но не всегда).
Как по мне — основные преимущества динамических языков проявляются в небольших проектах. Например, если мне нужно что-то небольшое написать, то я порой с C# переключаюсь на Python. А в большом проекте с динамическими фишками нужно быть аккуратным. Если нет достаточно опыта и квалификации, то можно крайне легко усложнить себе дальнейшую жизнь.
0
это не камень в сторону Js, просто говнокодеров в последнее время слишком много развелось
Я полгода как ушел с большого проекта на шарпе. Если человеку важна только скорость, а не качество, если он не знает основ, если он, в конце концов, кое-какер — то его не спасет то, что он шарпер.
0
Чем это отличается от Script#?
+1
Script# (он всё ещё живой?) и другие подобные поделки имеют очень ограниченный функционал, ибо распарсить C# самим и выполнить нормальную трасляцию всех фич (а потом ещё и дорабатывать продукт под новые версии C#) — крайне сложная задача. DuoCode использует Roslyn для получения синтаксического дерева, что убивает основную сложность. Больше нет ограничений и багов по работе с самим C# — остаётся только аккуратно сгенерировать JavaScript по синтаксическому дереву.
0
Он уже мерт, да и в нем нет поддержки даже .NET 4.0, не говоря уже о более современных версиях.
0
1. Проект хороший, но пока немного сыроватый. Очень надеюсь, что в скором времени ребята допилят его до хорошего уровня.
2. MSIL->LLVM — это прикольно, но если начинать работать сразу с IL, то не будем ли мы лишены полезной для трансляции информации? Выхлоп DuoCode местами пока немного пугает, но он вполне читаем: легко можно разобраться что и где делается. Не думаю, что из IL (а особенно после трансляции в LLVM) можно вытащить код такого же уровня читаемости.
2. MSIL->LLVM — это прикольно, но если начинать работать сразу с IL, то не будем ли мы лишены полезной для трансляции информации? Выхлоп DuoCode местами пока немного пугает, но он вполне читаем: легко можно разобраться что и где делается. Не думаю, что из IL (а особенно после трансляции в LLVM) можно вытащить код такого же уровня читаемости.
0
По идее к MSIL прилагается pdb с нужной инфой, а дальше уже включаются штатные средства LLVM для поддержки работы с отладочной информацией. То есть в итоге мы таки получим .map-файлы нужные отладчику.
+1
Трансляция LLVM в asm.js не предполагает читаемости, поскольку asm.js сделан не для людей. У таких модулей всегда есть исходный код (в данном случае C#), и есть чёрный ящик на JS с известным нам API.
Мне кажется, вам просто более привычен подход TypeScript «давайте сделаем выдачу читаемой». Я как раз никогда не мог понять, зачем это нужно. Вы не могли бы объяснить?
Мне кажется, вам просто более привычен подход TypeScript «давайте сделаем выдачу читаемой». Я как раз никогда не мог понять, зачем это нужно. Вы не могли бы объяснить?
0
Зачем делать результат работы typescript читаемым? Чтобы скомпилированный код можно было нормально отладить когда map файл не доступен или не позволяет понять суть происходящего.
0
Хм, вопросов стало только больше.
Если source map не доступен, нужно сделать его доступным. У разработчика есть возможность, у остальных нет необходимости.
Если транслятор статически типизированного языка не даёт гарантий относительно качества target кода, то транслятору место на свалке истории. Даже в C/С++ с их чудесами при наличии undefined behaviour в коде никогда не нужно отлаживать ассемблер. Если такие ситуации возникают, то вместо отладки транслированного кода нужно создавать тикеты вот здесь.
Если source map не доступен, нужно сделать его доступным. У разработчика есть возможность, у остальных нет необходимости.
Если транслятор статически типизированного языка не даёт гарантий относительно качества target кода, то транслятору место на свалке истории. Даже в C/С++ с их чудесами при наличии undefined behaviour в коде никогда не нужно отлаживать ассемблер. Если такие ситуации возникают, то вместо отладки транслированного кода нужно создавать тикеты вот здесь.
-1
Source map не доступен в IE, например, и тут от разработчика ничего не зависит.
-1
Да доступен уже почти год как.
Если говорить про более старые версии IE, то необходимость отлаживать исходный код сугубо из-под IE может быть связана только с тем, что не использованы fallback/shim библиотеки для работы с некоторым функционалом с плохой кросс-браузерностью. Разработчиков таких библиотек, конечно, уже ничего не спасёт, но я пока не слышал ни об одной библиотеке в духе jQuery или es5-shim, написанной на TypeScript.
К сожалению, от разработчика всегда всё зависит.
Если говорить про более старые версии IE, то необходимость отлаживать исходный код сугубо из-под IE может быть связана только с тем, что не использованы fallback/shim библиотеки для работы с некоторым функционалом с плохой кросс-браузерностью. Разработчиков таких библиотек, конечно, уже ничего не спасёт, но я пока не слышал ни об одной библиотеке в духе jQuery или es5-shim, написанной на TypeScript.
К сожалению, от разработчика всегда всё зависит.
-1
Есть такой вопрос, зачем все это? Ведь даже микрософт не сделал такого транслятора, а создал TypeScript.
0
TypeScript появился в 2012, когда Roslyn находился в весьма зачаточном состоянии, а вести удобную разработку Js-прилоежний уже хотелось.
Вопрос про политику Microsoft заслуживает отдельного обсуждения. Я думаю так: TypeScript — универсальная штука, которую можно использовать для любых Js-проектов. А DuoCode — нишевое решение, оно подойдёт не всем (зато в своей нише может очень хорошо пригодится).
Вопрос про политику Microsoft заслуживает отдельного обсуждения. Я думаю так: TypeScript — универсальная штука, которую можно использовать для любых Js-проектов. А DuoCode — нишевое решение, оно подойдёт не всем (зато в своей нише может очень хорошо пригодится).
0
Хочется странного. Вон, Nemerl'овцы всё туда же.
+1
Выбрать в качестве разработки язык C#, чтобы потом внутри писать
document.getElementById
… Это какое-то извращение. C# прекрасный язык, но имхо инструмент нужно выбирать под задачу.+5
А с другой стороны хочется удобный инструмент. Плюс, отписывался выше: что если нужно портировать существующую C#-логику на сторону клиента?
0
У нас сейчас как раз проект, подразумевающий переписывание клиента с Silverlight на HTML5. Автоматическая конвертация, как впрочем и ручное построчное переписывание, превращает приложение в "лет ми спик фром май харт". Так что в долгосрочной перспективе, если подразумевается хоть какое-нибудь развитие и поддержка, лучше использовать «родные» вебовские подходы.
+1
У нас одна из редакций Grapholite на Silverlight написана. Огромное количество C#-кода, в котором возможности рефлексии и биндинг-магии используются на полную. Сколько не смотрели в сторону HTML5, не хватает духу попробовать подобный функционал повторить на HTML5.
0
В C# cтатическая типизация, всё же.
0
Интересно, можно ли будет скомпилить сам Roslyn под JavaScript? Давно уже есть одна идея, может как раз получится ее реализовать.
0
Идея крайне увлекательная, но сложная. Если получится, то будет мега-круто.
0
Благодаря существованию трансляторов CIL -> JS скомпилить можно. А вот насколько оно будет юзабельно…
0
Не думаю, что сейчас есть хоть один транслятор, способный на это. У всех существующих есть ошибка в реализации разных моментов языка, от встроенных массивов размерности больше 1 до полного отсутствия атрибутов и рефлексии. Крупные проекты обычно хоть что-нибудь из этого используют, а поэтому не транслируются.
0
Раньше занимался задачей написания универсального C# кода под .NET и JavaScript. В итоге удалось создать общую графическую библиотеку, использующую функции GDI+ под .NET и функции canvas из html5 под JavaScript. Реализовывал тогда это с помощью Script#. Думаю, с помощью данной либы получилось бы реализовать все более изящно, без многочисленного количества костылей.
0
Попробовал установить, но оказалось, что данные проект пока что находится в закрытой бете. Будем ждать…
0
Нашел недавно WootzJs, тоже построенный на Roslyn. Ну и еще есть трансляторы, построенные на NRefactory (SaltarelleCompiler). Интересно, зачем их так много?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DuoCode: транслируем C# в JavaScript