valor texto span obtener etiqueta con change cambiar boton asignar agregar jquery ria script#

jquery - texto - ¿Qué ventajas puede aportar ScriptSharp a mi conjunto de herramientas?



change text jquery (5)

El proyecto del compilador jsc habilita estos escenarios:

  • C # a MSIL a JavaScript para navegador
  • C # a MSIL a JavaScript para AppJet
  • C # a MSIL a PHP5 para soluciones de hosting
  • C # a MSIL a Java para applets del navegador
  • C # a MSIL a Java para aplicaciones
  • C # a MSIL a Java para JavaCard
  • C # a MSIL a C99 para aplicaciones de código auxiliar nativas
  • C # a MSIL a ActionScript3 para Flash 9
  • C # a MSIL a Adobe Alchemy C para Flash 9
  • C # a MSIL a C # 2.0

Con un poco de esfuerzo, Visual Basic también podría usarse como idioma de origen. El compilador jsc nunca lee su código fuente, incluso si GWT y Script # hacen eso. Mi compilador lee tu IL.

compilador jsc es

  • un proyecto experimental
  • esfuerzo de un hombre todavía
  • bastante útil ya.
  • 3 años.
  • esperando donaciones para optimizar el tiempo de compilación y la salida

El último ejemplo es una animación de plasma donde se puede usar una implementation single entre esas plataformas:

FlashPlasma http://jsc.sourceforge.net/examples/web/FlashPlasma/assets/FlashPlasma/Preview.png

Actualmente usamos jQuery para agregar la bondad de RIA a nuestras aplicaciones, pero recientemente hemos implementado el motor de búsqueda Coveo en nuestro portal de Sharepoint y descubrimos que ScriptSharp se utilizó en su producto. ¿Qué puede aportar ScriptSharp a la mesa?

En mi última empresa usé Script # muy extensamente. Me las arreglé para escribir algunos controles geniales (de hecho, una pila MVC del lado del cliente completo) que no podría haber hecho con mi conocimiento de javascript. Sin embargo, no lo usaría de nuevo por varias razones.

  • El proyecto es de código cerrado y el soporte no es excelente (prácticamente no existe desde que se cerró el foro). Hay bastantes molestias cuando lo usas en gran profundidad, lo que podría solucionarse si tienes la fuente. Esto se convierte en un problema cada vez más grande cuanto más ha invertido en el código s #.
  • Se limita a un subconjunto de .NET 2.0, e incluso entonces es una abstracción con fugas.
  • Recientemente, las pruebas unitarias de Javascript y VS intellisense para javascript han mejorado mucho, por lo que la importancia de la escritura estática se reduce algo
  • Usándolo limitó mi aprendizaje de jquery y javascript

La herramienta para js solo está mejorando y hasta que Script # sea de código abierto, está en un punto muerto.

Si está interesado en compilación cruzada, también puede echar un vistazo al proyecto http://jsc.sourceforge.net/ , que le permite usar .net 3.5 y compilarlo en JS, Java, Flash o incluso PHP. Aunque no estoy seguro de cuán eficiente es el código que se produce ...

edición: hay un nuevo proyecto llamado JSIL que también reescribe el código .net a JS

Estoy usando ScriptSharp mientras hablamos, después de haberlo descubierto hace aproximadamente 2 o 3 semanas. Sinceramente, me encanta. El Javascript nativo es un desafío, y el modelo DOM hace que la programación del lado del cliente sea aún peor. Luego descubrí jQuery hace unos seis meses, y pensé que era una bendición. jQuery aumentó mi productividad, pero todavía me atasco a menudo con jQuery porque todavía tienes que escribir y depurar y ajustar Javascript.

Ingrese ScriptSharp. Ha aumentado mi productividad en jQuery y ha reducido enormemente mis dolores de cabeza. Las mayores ventajas que puedo ver son el hecho de que el poder de C # y Visual Studio es suyo mientras escribe el código. El poder de esto no puede ser subestimado. Ahora los pequeños errores de JavaScript que solían tardar horas en depurarse se eliminan en el momento de la compilación. Las líneas de código son probablemente el doble que con jQuery, pero la productividad es mucho mayor, ¿a quién le importa? Básicamente solo escribe código, con muchos menos ciclos de compilación / prueba / depuración. Las horas se convierten en minutos.

Diré que inicialmente fue bastante difícil lograr que ScriptSharp funcionara con Microsoft AJAX hasta que me enteré de un paso muy importante que debe tomar para poder trabajar con él. Me saqué el pelo durante días antes de saber esto. (Creo que esto está documentado en el archivo Léame de PDF de 61 páginas de ScriptSharp, pero es muy fácil ocultarlo). La clave es elegir el tipo de proyecto "Script # Class Library dentro de un sitio web" (o "MS Ajax Class Library Inside un sitio web ") al crear una biblioteca ScriptSharp. Esto coloca el proyecto ScriptSharp en el directorio Bin / Scripts del sitio web y, muy importante , dirige la salida compilada a ese directorio en lugar de al directorio predeterminado "bin" del proyecto ScriptSharp. Quizás un ejemplo sea instructivo:

Web Site or Application directory/ Bin/ Scripts/ <-- "..//" config setting sends .js files here. ScriptSharp Project directory/ Bin/ <-- will not be used at run time Debug/ <-- will not be used at run time

En resumen, encontré este proyecto que vale la pena. Voy a escribir mi propio CÓMO (que en mi caso implica el uso de Controles de usuario web) sobre cómo enlazar todo y publicar una URL aquí. Ahora que he descubierto Script Sharp, me ha hecho muy productivo en mi desarrollo de RIA. Si solo fuera más visible, y si solo el sitio de CodePlex todavía estuviera allí.

Me gustaría compartir mis clases de envoltorio jQuery para Script #. Puede acceder y usar las potentes funciones de jQuery en su proyecto Script #, ahora mismo.

Consíguelo desde aquí: http://www.springsys.com/blog/

Prototipo de script fuerte: GWT de Microsoft

Según esta página:

  • Un lenguaje limpio con las construcciones naturales.
  • Refactorización y exploración más sencillas.
  • Posibilidad de generar documentación.
  • Posibilidad de personalizar el código de script fácilmente.

No estoy seguro de estar de acuerdo con todo esto, pero ese es el argumento de venta de todos modos. Parece que está escrito con algunas características OO. Las opiniones siguen: Como he mencionado en otras ocasiones, los desarrolladores de Java y C # aparentemente quieren deshacerse de los aspectos prototipados / no tipificados de Javascript porque se sienten incómodos al escribir código de esa manera. Los lenguajes de prototipado no tipificados tienen su lugar.