Por cuestiones laborales, he investigado un poquito sobre grooveshark, un sitio interesantísimo en el que uno puede buscar una canción, un artista, un cantante, un grupo de rock, o lo que sea de música de todos los tiempos, y ahí está, y no sólo eso, se puede oír directamente en línea, y no sólo eso, se pueden hacer playlists, y no sólo se pueden tocar desde el navegador (juar juar, por un error de dedo casi pongo navergador), sino que se pueden compartir embedeandolas o incrustándolas en distintos sitios de html.
Por ejemplo, a continuación una lista de tracks de Charles Mingus:
Y en seguida una breve colección de variaciones de St. james infirmary:
Y hasta se pueden personalizar los colores y toda la cosa, el único revés es que todo es en flash, pero dentro de no mucho, por lo que me he enterado, podremos trasladar todo lo flashero a html5. El futuro del hipertexto es el html5.
18 de julio de 2011
Groove Flash Sharks
Etiquetas:
internet
11 comentarios:
Yo no veo como Flash sea un inconveniente, ni porqué sea necesario migrar todo al stack estándar (HTML5, CSS3), que previsiblemente será exáctamente igual que HTML4 y CSS2.1, lleno de implementaciones inconclusas, lleno de incompatibilidades entre los navergadores más comunes y por supuesto, el inevitable tormento de un nefasto lenguaje de programación: JavaScript. Todo eso es un verdadero asco. Ahora bien, Flash/Flex y Silverlight ya tienen toooodo lo que HTML5 promete y más... no entiendo como porqué se habría de migrar a tecnologías estándar de comité, cuando ya hay estándares de facto que funcionan de maravilla y sí se comportan idénticos en todas las plataformas. De aquí a que sale la versión oficial del stack estándar, ya pasaron otros dos años. ¿Plug-in? Ja, el navergador es el más asqueroso, impredecible, ineficiente y engorroso plug-in que existe.
Ah, lo olvidaba: Grooveshark es la onda.
Pues yo carezco del suficiente conocimiento para comparar críticamente lenguajes de programación, uso javascript de modo bastante básico y nunca me ha dado problemas de ningún tipo (y he leído por ahí que js es tan poderoso como Lisp, aunque tenga sintaxis de C).
En cuanto a los estándares, prefiero estándares abiertos y escrutables, y no creo que sea lo mismo un "comité" mundial de expertos en el tema, que uno ciudadano o político.
Coincido en eso del navergador impredecible e ineficiente, aunque eso no tiene que ver con los estándares sino con quienes desarrollan navergadores.
Para mí flash es un inconveniente porque todas las aplicaciones flasheras que he visto en línea pesan el triple de lo que pesa una con html/css/js; y porque el archivo flash es totalmente hermético, con lo que no sabes (ni tampoco puedes revisar de modo fácil) si te están instalando algún malware ni cómo funciona ni nada de nada.
Seguramente porque has usado JavaScript como dices, sólo de modo bastante básico. Pero tiene sus problemas y sí son cuestiones del lenguaje. Por otro lado, está el DOM y la implementación específica e incompatible de cada navegador, pero todo ello es problema del stack estándar en su conjunto.
JavaScript es un lenguaje pseudo orientado a objetos y muchas características se antojan forzadas, más como una adición improvisada y mal hecha, que una característica de diseño, y no hay que ir más lejos que los diccionarios y los prototypes.
Ahora bien, ni que decir del entorno de ejecución. Los motores de la mayoría de los navegadores son irremediablemente lentos (tal vez Chrome en el futuro solucione esto) a comparación de cualquiera de las alternativas de plug-in que te mencioné.
En eso de los estándares, bueno estrictamente hablando, el ECMA 262 en el que está basado JavaScript también es el estándar de ActionScript de Flash/Flex. Aún más, CSS se puede usar con Flex. Y el ECMA 334 (C#) se utiliza en Silverlight, así como también se puede usar JavaScript. Claro, ActionScript y C# son excelentes lenguajes y mucho mejor diseñados que JavaScript y con la ventaja de la resolución estática de tipos. No se diga de los entornos de desarrollo y de las herramientas de depuración y profiling. Y esto sólo por hablar de los estándares de comité.
Pero por otro lado, Flash es un estándar de facto, con presencia en el 97% de los clientes web, mientras que Silverlight 4, se acerca cada vez más, actualmente con 73%. Y esas plataformas son verdaderamente homogéneas, a diferencia de las irreconciliables diferencias de implementación entre distintos navegadores.
Si bien es cierto que muchas aplicaciones de Flex/Flash/Silverlight son más pesadas que sus hipotéticos equivalentes, seguramente es porque estás comparando aplicaciones de formulario. Pero considera por un momento en lo costoso que sería hacer Grooveshark en el stack estándar (si es que se pudiera). Seguramente sería un poco más pequeño, pero también monumentalmente más lento.
Algo más, todas las tecnologías de plug-in tienen una ventaja en términos de seguridad que no tiene comparación en el stack estándar (y por la cuál, el argumento del malware es improcedente): firma digital del código y ejecución en sandbox. Por estas razones, incluso las tecnologías de plug-in son mucho más seguras que JavaScript y compañía.
Y finalmente, no hay una sóla característica de HTML5 + CSS + el viejo JavaScript que actualmente no tengan Flex 4 y Silverlight 4. En sentido contrario, el stack estándar es un amateur en áreas como los gráficos vectoriales, animación, reproducción de video, interacción con micrófono y cámara, layout flexibles, componentes de UI robustos, y sobre todo, una biblioteca de clases verdaderamente robusta.
Y sí, definitivamente en Flex/Silverlight tiene mucho código propietario, pero a menos que seas un fundamentalista del Free Software, todo esto será un trade-off menor, en comparación con la extensa lista de beneficios sobre el primitivo stack estándar.
Pues alguien, seguramente muy idiota, ya tomó la decisión de hacer el grooveShark en el "stack estándar". Parece que no les importó el costo ni que esté monumentalmente más lento.
Wey, es cierto, yo recuerdo la primera vez que entré era un gran flash embedeado en un html. Pero lo acabo de revisar y ahora son algunas toneladas del verdadero asco nefasto JavaScript... Qué tontos la verdad, considerando todo lo que dijo acá el Tona Malvado debían haber conservado sus verdaderos estándares flasheros y toda la cosa.
Órale. Yo no sabía lo idiota que he sido todo éste tiempo, pensando que jQuery está bien chingón.
"Pero tiene sus problemas y sí son cuestiones del lenguaje." ¿Puedes ser más específico?
"muchas características se antojan forzadas, más como una adición improvisada y mal hecha, que una característica de diseño" ¿Puedes ser más específico?
"Claro, ActionScript y C# son excelentes lenguajes y mucho mejor diseñados que JavaScript" ¿Puedes ser más específico?
"con la ventaja de la resolución estática de tipos" ¿Por qué es esta una ventaja?, hay casos en los que representa una clara desventaja. e.g. las funciones que generan acumuladores en el apéndice de Revenge of the nerds de Graham (http://www.paulgraham.com/icad.html)
"irreconciliables diferencias de implementación entre distintos navegadores" Yo sólo he tenido algunos problemas con ie, y siempre he podido solucionarlos. A mí me suena más a que ms está queriendo imponer su propio estándar, y no a que haya "diferencias irreconciliables", but then again, ¿Puedes ser más específico?
"ventaja en términos de seguridad", sí security through obscurity, la cual en realidad no es seguridad frente a los hackers de hoy en día. Hay soluciones libres de todo, mucho más seguras que las soluciones privadas, tan sólo porque son abiertas y los que las desarrollan reciben retroalimentación por parte de otros desarrolladores con acceso al código fuente. Cuando una vulnerabilidad aparece en un proyecto de SL se soluciona en horas, mientras que por poner un ejemplo en windows, se tardan un poquito más.
"En sentido contrario, el stack estándar es un amateur", sí, y por eso se están mudando tantos al stack estándar, ha de ser una conspiración entre apple y la w3c...
Primera respuesta específica: Implementación inconsistente de delegados. En un lenguaje decente, llamar a una función directamente o a través de un delegado produce el mismo resultado (obj.func(); es equivalente a var delegate = obj.func; delegate();). Esto NO ocurre en JavaScript. Otro error garrafal es el tratamiento de null, undefined y los operadores de comparación ==, ===.
Segunda respuesta específica: JavaScript carece de varargs; aunque los parámetros siempre se tratan como un arreglo dentro del cuerpo del método (arguments), es imposible pasar parámetros a un método vía un arreglo, de manera que se desenvuelvan transparentemente, hay que usar "apply". ¿Característica de diseño o vulgar hack?
Tercera respuesta específica: Dos ejemplos. 1) Pésimo soporte de depuración. En otros entornos, se puede inspeccionar dinámicamente la pila de llamadas, incluyendo todos los stackframes, hasta ubicar aquel que originó la excepción. En JavaScript, sólo se puede inspeccionar el stackframe actual. Un lenguaje que sólo te dice... "tu programa falló en... ah... ¡en algún punto!", no es algo precisamente bien diseñado. 2) Pseudoprogramación orientada a objetos. A diferencia de ActionScript, donde hay declaraciones de clases, herencia, polimorfismo vía interfaces, espacios de nombre, etc., JavaScript es nefasto y aunque se le puede dar la vuelta, es sólo a través de hacks innecesariamente complicados.
Cuarta respuesta: No se a que te refieres ¿donde está el problema con la resolución estática de tipos? Te pido que ahora tú seas más específico. Pero bueno, asumo que me vas a mostrar un caso frontera donde la resolución dinámica tiene ventajas evidentes, pero limitadas... en un contexto más amplio, la resolución estática de tipos previene errores en las primeras fases del ciclo de desarrollo, que de otra forma podrían quedar como defectos ocultos y ser visibles sólo en tiempo de ejecución. Aún así, "dynamic binding" es útil en muchos casos, y en .NET o Java, la resolución dinámica de tipos es opcional y no una limitante de sus lenguajes de programación.
Quinta respuesta específica: Si todos los desarrolladores hubiesemos tenido una experiencia JavaScriptosa tan agradable como la tuya, seguramente no existiría el concepto de Cross Browser Support, o mínimo sería un concepto blasfemo. Quizá quieras checar este artículo: http://mzl.la/6tm7Aj. Empieza diciendo: "Improper browser detection can lead to web maintenance nightmares". A lo mejor te hace falta usar más JavaScript. Lo dejo a tu consideración.
Más sobre seguridad: Las características de licenciamiento del software no tienen nada que ver con el argumento original. Igual hay una enorme cantidad de frameworks y herramientas opensource en .NET, Java, Flex/Flash. A lo que me refería (específicamente) es que cuando descargas una aplicación de plug-in, los entornos de ejecución le solicitan permisos al usuario para ejecutar la aplicación en tu máquina. Aún si les das permiso, todas las operaciones son en sandbox, por lo que la probabilidad de que fastidien tu máquina son mínimas. Y aún más... la confianza de utilizar una aplicación firmada digitalmente por un proveedor de software, mediante un certificado SSL, no tiene equivalente en JavaScript.
Y finalmente, imagínate si alguien se atreviera a defender al Islam basado en el hecho en que es la religión que está captando mayor número de adeptos. ¿Ves lo ridículo del argumento? Creo que hasta tiene un nombre raro, algo así como "argumentum ad populum". No hay ninguna conspiración, el hecho de que muchos sitios estén migrando al stack estándar no significa necesariamente que sea mejor. Grooveshark migró todo lo que podía al stack estándar, es cierto, excepto lo más importante. http://bit.ly/eV8lsu
Ah por cierto Oscar, de la misma manera que estoy impresionado con Joomla! y con Drupal por estar programados sobre PHP (que a mis ojos le da un cerrón a JavaScript como lenguaje de porquería), en JavaScript también existen herramientas maravillosas. Mis favoritas personales son jQuery y ExtJS. Ahora bien, aún cuando son extraordinarias, el mérito es propio y no puede ser usado para defender o enaltecer el horrible lenguaje sobre las que están programadas.
Tu argumento de flash en el 97% y el otro programa en el 73% se parece un poco al argumento de los adeptos del Islam.
Por lo demás: me asombra el entusiasmo por grooveshark. ¿Listas de reproducción? No mames, eso lo teníamos desde 1991. Hace 20 años.
Y lo asombroso es que no parecen darse cuenta de que el problema de fondo es político y es totalmente acerca de la cultura libre. Grooveshark parece aún otro hack para lo más obvio que sería compartir tu música con quien quieras sin que los monopolios artificiales obstaculicen.
Seguro que empotrarlo en el navegador es dificil, y se han visto muy ingeniosos. Pero acá tengo un stack que me permite hacer lo mismo de una manera más elegante sin involucrar siquiera al navegador, ya no digamos a esos horrendos plugins.
¿Quién habrá inventado ese lugar común abominable de "como por qué"? Seguramente alguien en la televisión. Deshazte de él, hijo mío, es un pecado muy feo.
Publicar un comentario