2010-11-03 13 views
9

Retengo la persecución de las piezas ProcessingJS en gran parte debido a la hinchazón de la biblioteca. He encontrado que piezas como Ball Droppings no usan el analizador de sintaxis de procesamiento de la biblioteca, lo cual es bueno, ya que imagino que ralentizará más la página, especialmente al agregar la carga inicial y el tiempo de configuración. Aún así, me pregunto si vale la pena usarlo básicamente como una gran biblioteca de utilidad como UnderscoreJS. Por ejemplo, ¿cuán buena es su implementación con SVG en comparación con las otras bibliotecas que hay hoy en día como RaphaelJS? ¿Alguien ha llevado a cabo la implementación de la API de procesamiento de manera exhaustiva? Cuando hojeo el contenido veo un montón de repeticiones que realmente no necesito, así como algunas instancias de prácticas de codificación cuestionables. Pero la biblioteca todavía parece para funcionar decentemente, al menos en la página de inicio ProcessingJS, aunque los ejemplos están configurados para ejecutarse a 15 fps, y no el (en mi opinión) 24fps mínimamente aceptable.¿Está Processing.js vale la pena?

+0

Otra biblioteca es cake.js http://code.google.com/p/cakejs/ – SiggyF

Respuesta

8

Creo que depende en gran medida del proyecto en el que esté trabajando y de los conocimientos básicos que tenga con la biblioteca de procesamiento.

Processing.js es una gran opción si ya ha aprendido la API de procesamiento original (java) y desea aprovechar su conocimiento existente en el entorno web. Puede ser la única opción si desea trasladar un proyecto existente a la web; de hecho, este es probablemente el mejor momento para usarlo.

Si usted es un programador de JavaScript y no sabe mucho acerca del procesamiento es probable que no les gusta escribir la sintaxis de Java en el navegador y todo se vuelve aún más problemático si se tiene que mezclar con js. La API no se siente como JavaScript y hay un montón de código que podría escribirse de manera más elegante.

En cuanto al rendimiento no es una mala elección, en realidad la mayoría de los proyectos se ejecutan sin problemas y definitivamente puedo recomendar el uso de processing.js en circunstancias como las explicadas anteriormente.

Aquí está gran lista de varios motores de JavaScript por ahí: Javascript Graphic/Game Engines

Es difícil recomendar una sola biblioteca, ya que los requisitos son específicos para cada proyecto. Para gráficos simples/diagramas: RaphaelJs es muy agradable y lleva a cabo decentemente

+0

No veo cómo se puede ver la repetición de cada fotograma en JavaScript como un rendimiento. Puedo ver cómo en Java hay poco costo de rendimiento. Pero gracias por tu respuesta. En términos del puerto de procesamiento, mi principal problema es con el intérprete. ¿No es extraño escribir un intérprete en un idioma interpretado? Además, pasar de JavaScript a Java es casi como un paso atrás en términos de prototipado rápido. – hlfcoding

+0

Eso es lo que quería explicar: processing.js solo hace una cosa buena: tomar el código original de Java escrito para procesarlo y analizarlo en javascript que se ejecuta de forma nativa en un navegador. No es nada más y nada menos. No descartaría por completo el proyecto como una tontería, tiene su propio caso de uso (pequeño) ;-) – DominikGuzei

+0

En realidad, PJS ahora es compatible con JS normal, y al haber estado por un tiempo, parece: http://processingjs.org/articles /jsQuickStart.html#javascriptonlyprocessingcode – hlfcoding

4

lo bueno que es su implementación con SVG en comparación con las otras bibliotecas por ahí hoy en día como RaphaelJS

Processingjs no utiliza SVG como Hasta donde sé, solo usa lienzo. Raphaeljs solo SVG. Hay una lectura interesante here y también en wikipedia sobre la diferencia. La principal diferencia es que SVG almacena los datos vectoriales de los objetos para que pueda cambiar fácilmente la posición, el color, etc. de las cosas, pero también proporciona eventos de mouseover. Canvas - y processingjs - no hace tal cosa, se dibuja en el lienzo y olvida todo lo que tienes que hacer más trabajo. No sé sobre la diferencia de rendimiento entre los dos.

En lo que respecta a la API de processingjs, no tengo ni idea de cómo se implementa, pero como John Resig de jQuery está involucrado, no puede ser tan malo como mínimo.

Estoy de acuerdo con el usuario hlfcoding que escribir java en el navegador se siente raro. También estoy buscando una solución más limpia para mis futuros experimentos de lienzos.

No veo cómo se puede ver el rendimiento de cada fotograma en JavaScript como un rendimiento.

Así es exactamente como funciona el lienzo, tiene que calcular y representar cada fotograma en js, no está procesando nada específico. No creo que sea un éxito de rendimiento, detrás de la escena un navegador que ejecuta SVG hace lo mismo de todos modos.