what tutorial truescript setup official language handbook c# javascript .net asp.net-mvc

c# - tutorial - JSIL vs Script#vs SharpKit



typescript tutorial pdf (5)

Estoy considerando Script #, JSIL y SharpKit como una herramienta para usar para compilar C # a Javascript, así que puedo programar las funciones del lado del cliente de AJAX usando C # en Visual Studio.

¿Cuáles son los pros y los contras de cada JSIL, Script # y SharpKit?

Mi proyecto es un proyecto MVC4 usando un motor de maquinilla de afeitar y C #, si importa.

Otra alternativa es WootzJs . Revelación completa, soy su autor.

WootzJs es de código abierto y se esfuerza por ser un compilador cruzado bastante ligero que permita todas las funciones principales del lenguaje C #.

Características notables del lenguaje compatibles:

  • Declaraciones de yield (generadas como una máquina de estado eficiente)
  • Métodos async/await (generados como una máquina de estado como el compilador C #)
  • parámetros de ref y out
  • arboles de expresion
  • lambdas y delegados (con la adecuada captura de this )
  • soporte de genéricos tanto en el compilador como en el tiempo de ejecución (la conversión no válida a T lanzará una excepción de conversión)
  • Semántica de C # (en lugar de semántica de Javascript) para objetos cerrados cerrados

Se implementa utilizando Roslyn, lo que significa que será el primero en la línea en aprovechar las mejoras futuras del lenguaje, ya que ahora se implementarán a través de Roslyn. Proporciona una versión personalizada de mscorlib para que sepa exactamente qué funcionalidad de biblioteca está realmente disponible para usted en sus scripts.

¿Cuáles son sus desventajas?

  • El Javascript no tiene la intención de parecer "bonito". Está claramente generado por una máquina, aunque los métodos individuales deberían ser fáciles de razonar al mirarlos.
  • Debido a su amplio soporte para las bibliotecas centrales y la reflexión, la salida generada no es la más pequeña en el bloque. La minificación debería producir un archivo JS de ~ 100k, pero aún no se admite la minificación.
  • WootzJs contamina descaradamente los tipos nativos con funciones para encapsular el comportamiento de aquellos tipos que solo se encontrarían en C #. Por ejemplo, todos los métodos de System.String se agregan al tipo de String JavaScript nativo.
  • En la actualidad, existe poco soporte para enlazar a bibliotecas de JavaScript de terceros. (Actualmente solo jQuery)

Comparaciones con otros compiladores cruzados:

  • Script # es muy estable y tiene una amplia integración con bibliotecas de JavaScript de terceros. Además, tiene una excelente integración de Visual Studio y proporciona una implementación personalizada de mscorlib . Esto significa que usted sabe con precisión qué funcionalidad se ha implementado realmente en el nivel de herramientas. Si, por ejemplo, Console.Write() no se implementa, ese método no estará disponible en su editor.

    Sin embargo, debido a su analizador personalizado, todavía está bloqueado en C # 2.0 (sin siquiera los genéricos encontrados en esa versión de C #). Esto significa que el desarrollador moderno de C # está renunciando a un enorme conjunto de características de lenguaje de las que la mayoría de nosotros dependemos sin reservas, especialmente los genéricos mencionados anteriormente, además de las lambdas y LINQ. Esto hace que Script # sea esencialmente un principio para muchos desarrolladores.

  • JSIL es un trabajo extremadamente impresionante que compila de forma cruzada IL en Javascript. Es tan robusto que puede manejar fácilmente la compilación cruzada de grandes videojuegos en 3D. El inconveniente es que, debido a su integridad, los archivos Javascript resultantes son enormes . Si solo quieres mscorlib.dll y System.dll, se trata de una descarga de 50 MB. Además, este proyecto realmente no está diseñado para ser utilizado en el contexto de una aplicación web, y la cantidad de esfuerzo requerido para comenzar es un poco desalentador.

    Este kit de herramientas también implementa un mscorlib personalizado, lo que le permite saber qué capacidades están disponibles para usted. Sin embargo, tiene una integración de Visual Studio deficiente, lo que obliga a crear todos los pasos de compilación personalizados necesarios para invocar al compilador y copiar el resultado en la ubicación deseada.

  • SharpKit : este producto comercial se esfuerza por brindar soporte para la mayoría de las funciones de lenguaje C # 4.0. Por lo general, tiene éxito y existe una buena posibilidad de que este producto satisfaga sus necesidades. Es liviano (archivos .JS pequeños), es compatible con las funciones del lenguaje C # moderno (genéricos, LINQ, etc.) y generalmente es confiable. También tiene un gran número de enlaces para bibliotecas de JavaScript de terceros. Sin embargo, hay un número sorprendente de casos perimetrales que invariablemente encontrará que no son compatibles.

    Por ejemplo, el sistema de tipos es superficial y no admite la representación de genéricos o matrices (es decir, typeof(Foo[]) == typeof(Bar[]) , typeof(List<string>) == typeof(List<int>) ) . El soporte para la reflexión es limitado, con varios tipos de miembros incapaces de soportar atributos. El soporte del árbol de expresiones no existe y la implementación del rendimiento es ineficiente (no hay máquina de estados). Además, un mscorlib personalizado no está disponible, y los archivos C # de script y los archivos C # normales se entremezclan en sus proyectos, lo que obliga a decorar cada archivo de script con un atributo [JsType] para distinguirlos de las clases compiladas normalmente.

Script # pros:

  • Gratis
  • Fuente abierta
  • Genera JavaScript limpio

Guiones # contras:

  • Admite un subconjunto de lenguaje C # 2.0 solamente
  • Puede compilarse solo en un proyecto separado, no puede mezclar / reutilizar el código entre el cliente y el servidor
  • Baja frecuencia de actualizaciones de versiones
  • No ofrece soporte
  • Compatibilidad limitada con la biblioteca de terceros, la API de C # es diferente a la API de JavaScript.
  • No es de código abierto
  • Depuración en JavaScript solamente

Profesionales de SharpKit:

  • Producto comercial
  • Soporta lenguaje C # 4.0 completo
  • Alta frecuencia de actualizaciones de versiones.
  • El soporte esta disponible
  • El código cliente / servidor se puede mezclar y reutilizar dentro del mismo proyecto
  • Amplia compatibilidad con bibliotecas de terceros, mantenida como código abierto: la API de C # coincide exactamente con la API de JavaScript
  • Admite la depuración básica de C # para los navegadores Chrome
  • Genera JavaScript limpio

SharpKit contras:

  • Tiene una versión gratuita sin límite de tiempo, pero limitada a proyectos pequeños / de código abierto
  • No de código abierto (solo las bibliotecas son de código abierto)

JSIL pros:

  • Gratis
  • Fuente abierta

Contras de JSIL:

  • Se convierte de IL (lenguaje intermedio), no de C #, lo que significa una capa de abstracción más baja ya que el código ya es de bajo nivel.
  • Código JavaScript complejo generado: casi como IL, difícil de leer y depurar

Respuestas a los comentarios:

Kevin: la salida de JSIL no es mala , simplemente se genera para lograr un comportamiento completo de .NET, muy parecido al modo CLR de SharpKit. Por otro lado, SharpKit admite la generación de código nativo , en la que cualquier código JavaScript nativo se puede generar desde C #, exactamente como se habría escrito a mano.

Muestra del código JavaScript generado de SharpKit: http://sharpkit.net/Wiki/Using_SharpKit.wiki

El desarrollador puede optar por crear una generación de código más compleja y obtener más funciones, como el soporte para sobrecargas de métodos en tiempo de compilación. Cuando se especifica, SharpKit genera sufijos de método para métodos sobrecargados.

La secuencia de comandos # requiere .NET 4 para poder ejecutarse, pero no admite la sintaxis completa de C # 4.0, como Genéricos, parámetros de referencia y salida, alias de espacio de nombres, etc.

Si está buscando integrarse directamente con un proyecto MVC, algo como Script # o SharpKit o algo es probablemente su mejor apuesta. Sé que Script # tiene cosas integradas para hacer ese tipo de integración más fácil, así que empieza por ahi

Si desea probar a usar JSIL, es probable que tenga las funciones principales que necesita, pero las cosas que podría desear, como la integración de Visual Studio, la implementación automatizada, etc., no están ahí. Actualmente está dirigido principalmente a la compilación cruzada de aplicaciones, por lo que hace un buen trabajo, pero no tan bueno como en otros casos de uso.

Trataré de dar un resumen de las razones por las que quizás desee considerar a JSIL sobre esas otras alternativas. Realmente no puedo comentar en profundidad los pros y los contras de esas alternativas ya que no las he utilizado:

JSIL tiene un soporte extremadamente amplio para las funciones disponibles en C # 4. Algunas notables (ya sea porque otras herramientas no las admiten o porque son complicadas) incluyen:

Structs , yield , Structs , ref / out , Delegates , Generics , Nullables , Interfaces y Enums .

Algunos de los anteriores, por supuesto, no tienen soporte completo ; para tener una idea de las cosas que funcionarán, puede ver los casos de prueba ; cada uno es un pequeño archivo .cs autónomo que se ha probado para garantizar que JSIL y C # nativo producen el mismo resultado.

El motivo de este amplio soporte es que mi objetivo es que JSIL le permita traducir una aplicación de C # completamente no modificada a JS en funcionamiento. Para todas las demostraciones en el sitio de JSIL, esto es cierto, y tengo algunos puertos casi completos de juegos reales más grandes en las alas para los cuales esto también es cierto.

Otra razón es que JSIL hace que sea relativamente sencillo para tu C # y tu JavaScript para hablar.

Todos sus tipos y métodos de C # están expuestos a través de una interfaz que es tan fácil de usar como javascript. Las versiones de JS tienen una resolución y distribución de sobrecarga básicas para que las interfaces C # nativas se puedan llamar desde el código de script como si fueran JS nativos en la mayoría de los casos. No tiene que seguir ningún paso para etiquetar específicamente los métodos que desea exponer a JS, o darles nombres especiales, o algo por el estilo, a menos que así lo desee.

Cuando quiera llamar desde C # a JS, puede hacerlo de varias maneras:

  • JSIL.Verbatim.Expression permite insertar javascript en bruto directamente en la versión traducida de una función.
  • JSIL.Builtins.Global puede combinarse con dinámica y var para escribir código similar a JavaScript directamente en sus cuerpos de función C #.
  • El atributo JSReplacement se puede usar para reemplazar las invocaciones de una función de C # con una expresión de JavaScript parametrizada.
  • Todas las características anteriores se pueden combinar con el mecanismo de JSIL para alterar la información de tipo, llamada Proxies, para permitirle modificar la información de tipo de las bibliotecas que usa, incluso si no tiene código fuente, para asignar sus métodos a JavaScript. has escrito
  • Y, finalmente, los métodos C # que no se traducen a JS producen un método vacío llamado Externo que luego puede reemplazar con JavaScript en tiempo de ejecución para que funcione nuevamente. Cualquier método externo que no hayas reemplazado produce un mensaje de advertencia claro en los tiempos de ejecución para que sepas lo que falta.

JSIL hace un uso agresivo de la información de tipo, junto con los metadatos que proporciona, para intentar optimizar de forma segura el JavaScript que genera para usted. En algunos casos, esto puede producir un JavaScript equivalente mejor de lo que habría escrito a mano. El área principal donde esto es cierto en la actualidad es el código que utiliza estructuras, pero también puede aplicarse en otros casos.

Por ejemplo, en este fragmento de código , JSIL puede determinar estáticamente que, a pesar del número de copias de estructura que implica el código, ninguna de las copias es realmente necesaria para que el código se comporte correctamente. El JavaScript resultante termina sin tener copias innecesarias, por lo que se ejecuta mucho más rápido de lo que obtendrías si tradujeras ingenuamente la semántica del C # original. Este es un buen punto intermedio entre escribir cosas ingenuas basadas en estructuras (¡Vector2s en todas partes!) Y volverse completamente loco con la optimización del valor de retorno a mano , lo cual, como he descrito en el pasado, es bastante propenso a errores .

Bien, ahora para algunos inconvenientes. No consideres esta lista exhaustiva:

  • Grandes partes de .NET BCL no tienen implementaciones proporcionadas por JSIL para usted. En el futuro, esto se puede solucionar mediante la traducción de todo el Mscorlib de Mono a JavaScript, pero no lo tengo tan bien como para defenderlo como una solución inmediata. (Esto está bien para los juegos hasta ahora, ya que no usan gran parte del BCL). Este problema se debe principalmente a los problemas de IP relacionados con la traducción de mscorlib de Microsoft. Si pudiera hacerlo legalmente, lo estaría haciendo bien. ahora - funcionó la última vez que lo probé.
  • Como se mencionó anteriormente, no hay integración de estudio visual. JSIL es bastante fácil de usar: puede alimentarlo con un archivo .sln para obtener un montón de salidas .js automáticamente, y configurarlo automáticamente con un archivo de configuración al lado del proyecto, pero no está tan pulido o integrado como digamos, Script #.
  • Ningún vendedor o personal de apoyo. Si quiere que se solucione un error ayer o está teniendo problemas, soy prácticamente su única apuesta en la actualidad (aunque hay algunos contribuyentes prolíficos que ayudan a mejorar las cosas, ¡y más siempre son bienvenidos!)
  • El rendimiento de JavaScript es un maldito laberinto lleno de minas terrestres invisibles. Si solo quieres que las aplicaciones funcionen, es probable que no tengas ningún problema aquí, pero si, como yo, intentas que los juegos reales se ejecuten rápido en los navegadores, JavaScript hará que tu vida sea un infierno y, en algunos casos, JSIL lo empeorará. . Lo único bueno que puedo decir aquí es que estoy trabajando en ello. :)
  • Los optimizadores y optimizadores de JavaScript como Closure no son explícitamente compatibles, ya que requieren que el generador de código salte a través de un montón de aros. Pude ver que esto es un bloqueador real dependiendo de cómo pretenda usar su código.
  • El analizador estático todavía es un poco frágil y todavía hay brechas en el soporte de idioma. Cada gran aplicación que instalo con JSIL generalmente revela uno o dos errores en JSIL, no grandes interruptores de juego, sino que definitivamente rompen una característica o hacen que las cosas funcionen lentamente.

¡Espero que esta información sea útil! Gracias por tu interés.

Tenemos SharpKit durante dos años y debo decir que se actualizó la forma en que escribimos el código. Los pros como los veo:

  • El código es mucho más estructurado: ahora podemos desarrollar la infraestructura tal como lo hicimos en C # sin "golpearnos la cabeza" con el prototipo.
  • Es muy fácil refactorizar.
  • Podemos usar los fragmentos de código que resultan en una mejor productividad y menos tiempo de desarrollo
  • Puede controlar la forma en que se representa el JS (tiene varios modos para elegir).
  • Podemos depurar nuestro código C # en el navegador (actualmente solo se admite en Chrome, pero aún así: ->)
  • ¡Gran apoyo! Si les envías una consulta, obtienes una respuesta muy rápida.
  • Soporta un gran número de bibliotecas y fácilmente extensible

Los contras:

  • La documentación es un poco deficiente, sin embargo, una vez que la conozca, aumentará su desarrollo.