por
pobrecito hablador
el Miércoles, 24 Octubre de 2012, 19:47h
(#1322802)
Sí vale, js está lleno de ese tipo de trucos. Pero ¿qué pasa si no hay un document? como en el lado del servidor.
Tengo que decir que también he trabajado incrustando motores de js (spidermonkey de mozilla, v8 de google y el engine del webkit de apple/kde) en otros programas. En ese caso no hay DOM que valga.
Y no es lo mismo un include (c) que un import (java, python) o namespace (c++). Incluso la forma mas primitiva (el include de C) permite evitar las colisiones de símbomos hasta cierto punto.
En js tienes que crear objetos/librería como el Math. Eso no es muy elegante que digamos, aparte de engorroso, ineficiente, y no garantiza el nivel de modularidad de python, por ejemplo. Aunque bueno, python tiene cientos de módulos listos para usar y js tres o cuatro.
por
pobrecito hablador
el Jueves, 25 Octubre de 2012, 06:13h
(#1322816)
Creo que te pasas de heróico intentando usar motores de JS de *navegadores* en otros entornos.
Es más, no entiendo esa necesidad de usar JS en el lado del servidor cuando creo que todo el mundo tiene claro que es y se diseñó como un lenguaje de lado de cliente. Aunque claro, es muy goloso tener ya un motor listo para usar sin demasiadas complicaciones.
No obstante, hay implementaciones de JS de lado servidor desde los 90: Microsoft ya permitía programar el ASP clásico en JS, ahora también tienes node.js que te permite lo mismo, ambos, con mayor o menor habilidad, permiten el uso de módulos externos.
En cualquier caso estamos en las mismas, el contexto de JavaScript no es el desarrollo en el lado del servidor de aplicaciones web o en aplicaciones independientes, sino como lenguaje del lado del navegador. No tenerlo en cuenta y usarlo para cualquier otra cosa solo puede causar frustración.
Re:dart
(Puntos:0)Tengo que decir que también he trabajado incrustando motores de js (spidermonkey de mozilla, v8 de google y el engine del webkit de apple/kde) en otros programas. En ese caso no hay DOM que valga.
Y no es lo mismo un include (c) que un import (java, python) o namespace (c++). Incluso la forma mas primitiva (el include de C) permite evitar las colisiones de símbomos hasta cierto punto.
En js tienes que crear objetos/librería como el Math. Eso no es muy elegante que digamos, aparte de engorroso, ineficiente, y no garantiza el nivel de modularidad de python, por ejemplo. Aunque bueno, python tiene cientos de módulos listos para usar y js tres o cuatro.
Re:dart
(Puntos:0)Es más, no entiendo esa necesidad de usar JS en el lado del servidor cuando creo que todo el mundo tiene claro que es y se diseñó como un lenguaje de lado de cliente. Aunque claro, es muy goloso tener ya un motor listo para usar sin demasiadas complicaciones.
No obstante, hay implementaciones de JS de lado servidor desde los 90: Microsoft ya permitía programar el ASP clásico en JS, ahora también tienes node.js que te permite lo mismo, ambos, con mayor o menor habilidad, permiten el uso de módulos externos.
En cualquier caso estamos en las mismas, el contexto de JavaScript no es el desarrollo en el lado del servidor de aplicaciones web o en aplicaciones independientes, sino como lenguaje del lado del navegador. No tenerlo en cuenta y usarlo para cualquier otra cosa solo puede causar frustración.