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