«Javascript ha pillado al mundo por sorpresa con su potencia y su versatilidad, desde la aplicación a formularios a ser una pieza importante de en la presentación de una aplicación.... Pero, ¿que pasa cuando lo llevas a un nivel que no conocemos tanto? ¿que pasaría si usaramos Javascript para desarrollar juegos?» Andrés Nieto nos presenta algunos juegos desarrollados en javascript, incluso un emulador de MSX que permite cargar BIOS y ROMs. «Supongo que despues de esto, nadie podrá decir que Javascript es un lenguaje de complemento…»
Comentarios
Yo sólo os deseo que no tengáis que mantener y probar una aplicación mínimamente compleja hecha en JavaScript por otro programador (o por vosotros mismos hace algún tiempo)...
Me toca los cojones cuando a gentuza que está entrevistándote les dices que sabes "programar" en Javascript, y te dicen que eso no es exactamente programación... Tampoco tu eres un auténtico técnico al decir eso, y sin embargo estás en una empresa de mierda que no sabe distinguit su culo de su ombligo, pienso muchas veces
El mérito de esas aplicaciones tiene que ver mucho con la introducción del elemento no-estándar "Canvas" que con el Javascript en si mismo: http://en.wikipedia.org/wiki/Canvas_%28HTML_element%29
Mucho curro y mucho mérito. Hacer esas cosas en javascript es como hacer una zanja con pico y pala en la era de las excavadoras mecánicas.
¿Que programar y mantener JavaScript no es diferente a otros lenguajes? Veamos:
- El entorno de ejecución es totalmente imprevisible: hay multitud de diferentes configuraciones (versiones de navegador, sistema operativo, configuraciones de seguridad, etc.).
- Es "inseguro" (en el sentido de que el usuario puede verlo y modificarlo).
- El código puede estar disperso: insertado en HTML, en ficheros .JS, etc. Además, esto hace realmente difícil seguir su flujo de ejecución.
- El código (lógica) suele estar mezclado con la presentación (HTML).
- Hay pocas herramientas realmente útiles de programacción/debugging.
Nadie dice que JavaScript no sea útil y, por supuesto, se puede programar "bien" en JavaScript. Pero no estamos hablando de eso, sino de lo que realmente encontramos en la web. Os lo dice alguien que ha tenido que depurar una plantilla utilizada por un CGI, que después resultaba en sentencias document.write() que, a su vez, eran reinterpretadas por el navegador...
¿Double anal?
#1 Todo es posible, con un poco de dedicación
#18 Qué grande
#17 Es simplemente arte. De todos modos utilizan Canvas (lienzos) que al fin y al cabo es lo que se utiliza si vas a dibujar cualquier cosa en cualquier aplicación. Osea, que aunque sea javascript no está muy lejos de otras.
#16 Yo lo entiendo más bien porque puedes meter javascript "inlined" en tu documento HTML y es dificil de seguir. De todos modos, gracias a DOM, eso no es necesario. Lástima que aún mucha gente siga haciéndolo.
Yo, al menos, cuando escribo en javascript no meto ni un sólo byte de javascript en mi código XHTML, ni siquiera eventos como "onmouseover", "onchange", etc que es muy típico verlos por ahí dispersos. Con lo bonito que es document.getElementById('elobjeto').evento = accion ... :-P. Lo unificas todo en un sólo método y queda mucho más claro.
#c-8" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/77392/order/8">#8 "Qué más da el lenguaje, lo que importa es que el programador [...] realice un buen diseño y lo documente"
Mentira cochina
Ciertos lenguajes pueden ser un horror para debuguear. Sobre todo los que manejan la memoria directamente (C/C++); o los que tienen cosas como tipado dinámico débil, que pueden llevar a sorpresas inesperadas...
Además, aunque Javascript tenga debuggers más o menos logrados, sigue siendo más dificil de debuguear que Java o C#...
PD: no digo que el diseño y documentación no sean importantes; sólo que el lenguaje en si mismo tiene que ver, y mucho, con la facilidad de debugueo.
ryden, el problema con JS es que, de tan fácil que es empezar con él, los programadores pillan (pillamos) malas costumbres que luego cuestan una burrada soltarlas.
Tu ejemplo de cómo programar un evento es como debería hacerse, pero no como se suele hacer. Una pena, pero es así.
#3 O como hacer calculos mentales en la era de las computadoras electronicas, o andar en la era de los automoviles, o escribir a mano en la era de los procesadores de texto, o hacer artes marciales en la era de las armas nucleares, o pintar a mano en la era de la fotografia digital, o tocar la guitarra en la era de los sintetizadores...
Una vez se hizo un banco en javascript, no hace tanto tiempo.
#10 el navegador web es tu máquina virtual. Y los ejecutables, sean el formato que sean, también se ejecutan interpretándolos. ¿O acaso piensas que el procesador carga diréctamente el binario?
Se lo digo sin acritud (en serio).
#9 Quizá me malinterpretaste, pero yo no hablaba de detectar errores en programación sino que contestaba a #7 en el asunto de mantener y probar una aplicación hecha por terceros.
#12 No es diferente
- No es así, si sabes utilizar correctamente sus posibilidades estándar (por ejemplo, DOM para modificar el contenido).
- Tanto como el software libre (Es una ironía)
- Depende del programador hacerlo bien o mal, no del lenguaje. Si alguien quiere hacer algo mal, lo hará igual de mal en JavaScript que en brainfuck.
- Una cosa es lo que se suela hacer y otra cosa lo que se deba hacer.
- vim y consola de firefox, que no es un gdb pero a mí nunca me ha hecho falta más.
Yo tampoco digo que todo el mundo lo haga bien, pero sí que debería hacerlo y dejarse de tanto código espaguetti. Al fin y al cabo, es cultura
#14 No entiendo a qué viene tu comentario.
Para empezar no hablamos de aplicaciones sino de programación. Esos requesitos seguramente sean debidos al uso incorrecto del api de windows que crea una dependencia a ciertas versiones, o al uso de nuevas features no incluídas anteriormente. Si utilizas ANSI C no tendrás problemas en ningún sistema operativo ni con ningún compilador >=cutre.
#7 Qué más da el lenguaje, lo que importa es que el programador de JavaScript realice un buen diseño y lo documente. Yo creo que si todos aprovechásemos las posibilidades POO de JavaScript la gente tendría otro concepto de él. Es decir, no tomarlo como un mIRC Scripting sino como un pequeño java
#17 recuerdo que al principio meneábamos con lápiz y papel, y Galli calculaba nuestro karma con un ábaco y el css no era naranja sino en escala de grises
Que tiene de difícil "Debuguear" con C++ o C.
Precisamente "esos lenguages que usan memoria directamente" son los mas fáciles de debuguear, al tener tú el control total y absoluto del acceso a memoria.
Por cierto, para mi es un "lenguaje complemento" por el simple echo de que necesitas ejecutar el código desde un explorador web para que funcione.Si hubiera una maquina virtual de javascript ya seria otra cosa.
#12 "El entorno de ejecución es totalmente imprevisible: hay multitud de diferentes configuraciones (versiones de navegador, sistema operativo, configuraciones de seguridad, etc.)."
Esto... ¿igual que con cualquier programa? A ver si lo de los "requisitos mínimos: Microsoft Windows 98 o posteriores" lo he soñado
#15 ... #12 dice que no puedes controlar dónde ejecutas un código JavaScript, a lo que respondo que puede ocurrir lo mismo con cualquier ejecutable/lenguaje interpretado. Por eso, se dictan unos "requisitos" mínimos: sólo para Win, sólo para Linux, no apto para IE... ¿no?