Reflexión acerca del desarrollo javascript

[Panino5001]

Como ya no tenemos los Grupos sociales, pongo aquí este enlace a una presentación de Rebecca Murphey, que creo que puede prestarse a un buen debate:
http://www.slideshare.net/rmurphey/t...divide-5287573

[doylelives]

Muy interesante articulo, lo recomiendo nos hace pensar en que deberiamos tomar mas en serio el desarrollo de front-end.

[carlos_belisario]

aportando un poco al tema me dieron este link con un articulo interesante llamado tu no sabes javascript, saludos

[InKarC]

La filmina 10

"...it turns out that if you have absolutly no idea what you're doing in the lengauge you can still generally make things work" - Douglas Crockford, Yahoo!

Suena demasiado como una persona que esta furiosa por que haya gente capaz de hacer muchas de las cosas que el sabe hacer, pero que no tuvieron que estudiar tanto como el para poder realizarlas (gracias a los frameworks).

tu-no-sabes-javascript

Según ese articulo yo apenas tengo un "nivel básico"; pero aun así soy capaz de solventar cualquier problema y realizar cualquier efecto/funcionalidad en javascript... oh la ironia.

Por cierto; si consideran que tienen solidos conocimientos en Javascript les comento que ActionScript 3 (flash) es muy similar y solo necesitan aprender unas pocas cositas antes de comenzar a dominarlo.

[carlos_belisario]

Iniciado por InKarC

La filmina 10



Suena demasiado como una persona que esta furiosa por que haya gente capaz de hacer muchas de las cosas que el sabe hacer, pero que no tuvieron que estudiar tanto como el para poder realizarlas (gracias a los frameworks).


Según ese articulo yo apenas tengo un "nivel básico"; pero aun así soy capaz de solventar cualquier problema y realizar cualquier efecto/funcionalidad en javascript... oh la ironia.

Por cierto; si consideran que tienen solidos conocimientos en Javascript les comento que ActionScript 3 (flash) es muy similar y solo necesitan aprender unas pocas cositas antes de comenzar a dominarlo.

Utilizar una framework no esta mal en ningun lenguaje, el punto esta en que las personas aprenden solo la sintaxis de los fw y no la del lenguaje como tal, conozco varios casos que saben manejar JQuery pero no saben que significa esto

Código Javascript:

var item = document.getElementById('id_del_elemento'):
 

[InKarC]

Iniciado por carlos_belisario

Utilizar una framework no esta mal en ningun lenguaje, el punto esta en que las personas aprenden solo la sintaxis de los fw y no la del lenguaje como tal, conozco varios casos que saben manejar JQuery pero no saben que significa esto

Código Javascript:

var item = document.getElementById('id_del_elemento'):
 

Que man tan exagerado! Si solo con saber ingles uno ya sabe que hace.

cojaElementoPorId("")

[zerokilled]

buenas gentes...

@inkarc, creo que estas perdiendo de vista el verdadero mensaje. no se trata de si en un framework puedes o no solucionar un problema. no hay duda de que en un framework puedes solucionar problemas. el mensaje que se intenta transmitir es que hay quienes que, por no dominar a un nivel mas profundo el funcionamiento interno del lenguaje, se trancan en algun punto del desarrollo y luego no saben por donde atacar el problema. en mi opinion, y sin animos de ofender, hasta cierto punto la causa se puede atribuir a que los frameworks tienen mal acostumbrado a los que se inician por primera vez al lenguaje.

[InKarC]

No creo, uno cuando esta aprendiendo jQuery sin darse cuenta aprende javascript puro por los lados sin siquiera darse cuenta; esto debido a que muchas snippets/pedazos de codigo los combinan.

$("#link").click(function(){ alert(this.href); return false })
es equivalente a
document.getElementById("link").onclick = function(){ alert(this.href); return false }

Y los que se atrancan aquí en el foro de Frameworks muchas veces es por que no conocen la función de jQuery que les ayudaría a solventar su problema.

[Panino5001]

Hay, además de lo que menciona zerokilled, otro problema grave acerca de no saber bien qué es lo que se está haciendo (por desconocer el lenguaje base) y es que algunos usuarios de frameworks incurren en errores básicos sin siquiera darse cuenta. Y lo peor es que creen que el uso de un framework mágicamente los libra de esos errores y los hace sentirse seguros. Hay muchos ejemplos de esto en la web. Aquí se mencionan algunos: http://es.debugmodeon.com/articulo/jquery-abusos

Alguien que conoce el lenguaje base nunca vería aquí una equivalencia:

$("#link").click(function(){ alert(this.href); return false })
es equivalente a
document.getElementById("link").onclick = function(){ alert(this.href); return false }

Hay varias diferencias:
1)Si repito la primera línea pero asigno otra función como argumento, ambas funciones se ejecutan. Si hago lo mismo en la segunda, esto no ocurre.
2)la primera usa el modelo de eventos de DOM nivel 2, la segunda, DOM nivel 1
3)la primera no produce problemas de memoria en ningún navegador, la segunda sí porque contiene una referencia circular.

No estoy en contra del uso de los frameworks y la presentación de Rebecca tampoco lo está. Sólo hace notar el efecto colateral que los frameworks están produciendo. Muchos pueden haberse sentido ofendidos por sus comentarios, pero los que verdaderamente conocen el lenguaje y usan estas herramientas de manera correcta, que son muchos (y varios participan en este foro), seguramente no se sintieron tocados para nada.

[InKarC]

Me refería a una equivalencia practica, en lo se ejecuta en el explorador.

[_cronos2]

Iniciado por Panino5001

3)la primera no produce problemas de memoria en ningún navegador, la segunda sí porque contiene una referencia circular

Eeeerm... ¿podrías explicar un poco esto de referencia circular? No lo había oído
Saludos (:

[zerokilled]

que tal cronos!
quizas te interese este articulo. trata sobre los diferentes patrones que producen derrame de memoria en iexplorer. entre ellos, la referencia circular. http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

[masterpuppet]

Iniciado por Panino5001

Hay, además de lo que menciona zerokilled, otro problema grave acerca de no saber bien qué es lo que se está haciendo (por desconocer el lenguaje base) y es que algunos usuarios de frameworks incurren en errores básicos sin siquiera darse cuenta. Y lo peor es que creen que el uso de un framework mágicamente los libra de esos errores y los hace sentirse seguros. Hay muchos ejemplos de esto en la web. Aquí se mencionan algunos: http://es.debugmodeon.com/articulo/jquery-abusos

Alguien que conoce el lenguaje base nunca vería aquí una equivalencia:

Hay varias diferencias:
1)Si repito la primera línea pero asigno otra función como argumento, ambas funciones se ejecutan. Si hago lo mismo en la segunda, esto no ocurre.
2)la primera usa el modelo de eventos de DOM nivel 2, la segunda, DOM nivel 1
3)la primera no produce problemas de memoria en ningún navegador, la segunda sí porque contiene una referencia circular.

No estoy en contra del uso de los frameworks y la presentación de Rebecca tampoco lo está. Sólo hace notar el efecto colateral que los frameworks están produciendo. Muchos pueden haberse sentido ofendidos por sus comentarios, pero los que verdaderamente conocen el lenguaje y usan estas herramientas de manera correcta, que son muchos (y varios participan en este foro), seguramente no se sintieron tocados para nada.

Estoy de acuerdo en prácticamente todo lo que expones Panino5001, excepto en el plurar de frameworks(y creo que la presentación de R. Murphey habla de jQuery solamente no de FW's en general, si no es así corriganme), lo que se da en jQuery no es tan acentuado en otros FW's, jQuery apunta a un publico determinado y su usuario promedio nada tiene que ver con el usuario promedio de dojo por ejemplo.

Saludos.

[Panino5001]

@_cronos2: me parece muy elocuente esta explicación acerca de de referencias circulares: http://www.javascriptkit.com/javatut...k/index3.shtml

@masterpuppet: en efecto, la presentación de Rebecca habla de jQuery. No obstante esto, el problema es extensible a otros frameworks menos populares, con un agravante adicional (desde mi punto de vista): jQuery es, de los populares que estudié, el mejor diseñado y el más retroalimentado. Mientras que lo más objetable de jQuery es que hace demasiadas cosas y es poco modular, otros abusan de variables globales o de de la extensión de objetos host y son, por lo tanto, más peligrosos para los usuarios no avezados que los usan confiando en ellos plenamente.
Totalmente de acuerdo que mencionás acerca de dojo: es otro usuario. Es el mismo usuario que usaría jQuery sin sentirse parte del problema que menciona Rebecca.

[_cronos2]

Muchas gracias por la info @ZK y @Panino.
Saludos

[Aijoona]

Por partes:

@InKarC

La frase de Crockford no nace de la envidia sino de la realidad, realidad no exclusiva de JavaScript.
En general, te puedo afirmar que el 85%+ de programadores no tienen un base sólida de conocimientos de las herramientas (lenguajes, frameworks, patrones, analísis, etc), pero aún así 'hacen'* el trabajo.

Los framewors en general cumplen un rol MUY pequeño en ámbito JavaScript, y siendo que Crockford es un autentico pope del lenguaje, es bastante infantil proponer el tema de la envidia.

* Me permito una aclaración, en el día a día me encuentro con muchas soluciones que me alegran el día con su funcionamiento, pero basta que vea el código fuente para empezar a vomitar.
Programar no es solo escribir código.

---------------------------------------------------------------------------------------------------------------

Con respecto al saber JavaScript o no, siento ser purista, pero todo el API DOM no es parte de JavaScript, con lo cual entender como funciona un selector o los quirks de los eventos es irrelevante en cuanto al lenguaje.

Los frameworks (jQuery, MooTools, Prototype, Ender, Zepto, etc) hacen un GENIAL trabajo a nivel desarrollo, transformando un API de mierda (DOM) en algo usable.
El gran problema que expone el slide, es cuando hay que pegar el salto de paginita a aplicación, siendo que esto requiere del uso de las herramientas a conciencia y no es precisamente un problema que deba achacarse al framework en cuestión.

Como experiencia personal, tuve la suerte de trabajar con 3 cms in-house (5% JS, 30% JS y 100% JS), y puedo afirmar que las problematicas que surgen a nivel arquitectura no son un problema inherente del lenguaje sino de los requerimientos.
Y en estos caso si que no importa cuanto JavaScript sabes sino que tan buen programador sos, que tan bien desarrollas una arquitectura de n niveles y m modulos, como manejas las excepciones, la extensibilidad, el comportamiento más alla del caso feliz, etc.

[Panino5001]

Iniciado por Aijoona

Los frameworks (jQuery, MooTools, Prototype, Ender, Zepto, etc) hacen un GENIAL trabajo a nivel desarrollo, transformando un API de mierda (DOM) en algo usable.

¿Porqué te parece que es una API mala o no usable?

[Aijoona]

Es super contra intutiva, inconsistente, etc.

DOM se fue haciendo a los golpes a medida que pasaba el tiempo, muchas veces de manera propietaria, con lo cual todo converge en lo que es hoy en dia.

Es usable, pero comparada al API que proveen las librerias...

[zerokilled]

DOM se fue haciendo a los golpes a medida que pasaba el tiempo, muchas veces de manera propietaria

en realidad, eso es porque para ese momento no existia el DOM, sino BOM (browser object model). el DOM nace de la necesidad que todos los navegadores tuvieran el mismo modelo. en lo personal, no creo que la culpa haya sido el DOM, sino los fabricantes de navegadores.

[Panino5001]

Iniciado por zerokilled

en lo personal, no creo que la culpa haya sido el DOM, sino los fabricantes de navegadores.

Opino lo mismo. Creo que el estandar está bien definido y que el problema es que en algunos casos no es correctamente aplicado por los navegadores. Pero no me parece que sea una deficiencia de la API en sí misma.

[InKarC]

Iniciado por zerokilled

en realidad, eso es porque para ese momento no existia el DOM, sino BOM (browser object model)..

Falso; nunca ha habido un momento en que Javascript haya tenido BOM y no DOM, Javascript desde la version 1.1 creada en 1996 ha estado compuesta por: Ecmascript, DOM y BOM.

Fuente; y también lo mencionan en Professional JavaScript for web developers/Nicholas C. Zakas. — 2nd ed.

[buzu]

un API de mierda

Eso me suena a cita directa de Crockford. El señor es muy bueno en cuanto a JS, pero tiene sus opiniones muy amarradas. Nunca he entendido por que la gente se queja tanto del DOM, tiene cosas malas, como por ejemplo su funciones con nombres largos. Sin duda que se puede hacer una version más corta, pero no creo que la API sea del todo una porquería. Tiene algunas cosas rescatables.

En cuanto a los frameworks, siempre me ha parecido mala idea que alguien empice con frameworks sin saber como trabaja el lenguaje en realidad. He visto montones de porquerías en jQuery. La gente no aprende a hacer optimizaciones y te encuentras con código que hace la misma busqueda de un elemento más de dos veces.

Veamos un ejemplo que alguien puso acá

$("#link").click(function(){ alert(this.href); return false })
}

por que usar return false? por que no preventDefault()? quizá quien puso el ejemplo no sabe de la existencia y beneficios de preventDefault(), por ejemplo regresar un valor diferente de false y aún así detener la acción por defecto del evento.

En cuanto a la presentación que panino nos comparte, la vi hace ya un tiempo y me pareció una de las mejores que he visto. También anda un video de la presentación por ahí, por si alguien está interesado en verlo.

[McPinkY18]

hola panino hola!!! :) yo creo que la api de javascript puro y su sintaxis es genial!!

sera por que soy un Java Developer! bueno no importa, pero creo tambien que deben aprender primero el lenguaje antes de usar un framework ;)

[masterpuppet]

@McPinkY18, lo que se esta criticando es el API del DOM, no Javascript,

@Buzu no sigo muy bien tu planteamiento, si tiene "algunas cosas rescatables", es que el API es mala, sino serial al revés, tendría algunas cosas malas.

Creo que el API se podria mejorar, pero el problema es lo que comentan zeroKilled y Panino5001, la pobre implementación de los browsers.

[Aijoona]

Iniciado por buzu

Eso me suena a cita directa de Crockford. El señor es muy bueno en cuanto a JS, pero tiene sus opiniones muy amarradas. Nunca he entendido por que la gente se queja tanto del DOM, tiene cosas malas, como por ejemplo su funciones con nombres largos. Sin duda que se puede hacer una version más corta, pero no creo que la API sea del todo una porquería. Tiene algunas cosas rescatables.

Tiene cosas malas, pero justamente tener nombres largos y semanticos se considera una buena practica a nivel programacion.
Y si, tiene cosas rescatables, como ser el hecho de que anda.

Iniciado por buzu

En cuanto a los frameworks, siempre me ha parecido mala idea que alguien empice con frameworks sin saber como trabaja el lenguaje en realidad. He visto montones de porquerías en jQuery. La gente no aprende a hacer optimizaciones y te encuentras con código que hace la misma busqueda de un elemento más de dos veces.

Veamos un ejemplo que alguien puso acá

Obtener una referencia a un elemento en reiteradas ocasiones es algo que puede resolverse a nivel selector (si es que no esta hecho) con un cache de corta duración.

Con respecto a usar o no el API nativa, como ser el caso del preventDefault, si el framework te da la herramienta la vas a usar.

De nuevo, el problema no lo generan los frameworks, sino una generación de programadores que no sabe javascript, no le interesa profundizar, pero aun así trabaja con el lenguaje.

-----------------------------------------------------------------------------------------------

Gente, que sea inconsistente entre todos los browsers es UNO de los problemas, me atrevería a decir que no el peor.

Teniendo la perspectiva de alguien que ya tiene una idea del lenguaje, realmente no aprenderia el API provista por DOM, preferiria en todo caso tercerizar el esfuerzo de hacerla algo usable mediante el uso de un framework.

Que los mutators de properties de un element no sean metodos me pone loco, y no en el buen sentido.

Que el API de eventos apeste, tenga pocos metodos, que no tenga valores por defecto y que sus firmas apesten*, me pone loco y no en el buen sentido.

*link

Que tengas que tener un nivel super avanzado para saber que setear un estilo de un elemento genera un repaint (y posiblemente un reflow), me pone loco y no en el buen sentido.

Y así puedo seguir con muchas cosas.

En fin, me voy a trabajar

[Panino5001]

@Aijoona: pensé que eran cuestiones más graves. Con respecto a los mutators otro diría: "es flexible". Lo de los estilos tampoco se lo achacaría a la API sino a cómo lo implementan los navegadores.
Lo bueno es que w3c acepta retroalimentación y estas cosas pueden plantearse.

[buzu]

@Aijoona: lo que mencionas tiene que ver más con implementación que con la especificación del API. Por otro lado, es precisamente lo que tu mencionas:

preferiria en todo caso tercerizar el esfuerzo de hacerla algo usable mediante el uso de un framework.

Lo que detiene a muchos. Creo que yo lo llamaría flojera, por no decir otra cosa, y no lo hago con la intención de ofender. Simplemente que si no estamos dispuestos a entender un lenguaje en su forma más pura, creo que nos hemos equivocado de profeción. Yo disfruto mucho la sencilles de los frameworks y el hecho de saber que todo funcionará igual en navegadores más comunes sin que yo tenga que preocuparme por las diferencias, pero aun así creo que es necesario saber esas diferencias y el impacto que tienen en el desempeño a modo que podamos crear nuevos patrones más eficientes que los existentes para resolver dichos problemas de incompativilidad.
Y con esto:

Que tengas que tener un nivel super avanzado para saber que setear un estilo de un elemento genera un repaint (y posiblemente un reflow), me pone loco y no en el buen sentido.

No se si estoy de acuerdo o no, pero me viene a la mente lo que Crockford dice, y parafraceo: Resulta que aun que no tengas la mas mínima idea de lo que estás haciendo en el lenguaje, la mayor parte del tiempo puedes hacer que funcione.
Yo creo que esto es un problema. Si quieres hacer algo en C o Java sin tener idea de lo que haces no lograrás nada, pero ej Javascript si. Esto trae que muchos novatillos y no tanto terminen haciendo el oso y creando código de lo más feo. Quien olvida por ejemeplo el fiasco que hizo google cuando sacó su framework de javascript.

[Aijoona]

Justificar los tantos achacando culpas a la implementación es absurdo, ya que algunos de los problemas que menciono son parte de la especificación.

Saber que son los repaints y los reflows, y saber que cosas los triggerean no es algo trivial, y mucho menos intuitivo. Más teniendo en cuenta que los efectos colaterales de una asignacion no son intuitivos, ademas de que recién las próximas versiones de ES implementan mutators sin setter/getters (véase property descriptors).

Y no digo por novato, aún usuarios avanzados no tienen idea, por el simple hecho de que la documentación online es de regular a pésima.

---

A mi me gusta JavaScript, pero a alguien que no, y que no tiene ganas de perder el tiempo con un API floja, una documentación bastante pobre y una metodología ajena a sus paradigmas...

No digo que sea definitivo, ya que como mencionaron, muchos usos y costumbre de frameworks decantan en el estandar. Pero en mi opinión, lejos están de proveer una herramienta a la altura de las circunstancias.

[_cronos2]

Iniciado por Aijoona

Saber que son los repaints y los reflows, y saber que cosas los triggerean no es algo trivial, y mucho menos intuitivo. Más teniendo en cuenta que los efectos colaterales de una asignacion no son intuitivos, ademas de que recién las próximas versiones de ES implementan mutators sin setter/getters (véase property descriptors).

Sigo pidiendo información
¿Qué es esto de repaints y reflows?
Y lo de mutators sin setters/getters, ¿cuáles?
Saludos y gracias :D

[Aijoona]

Bueno, vos sos un claro ejemplo de alguien que tiene idea de lo que es el desarrollo web, pero esta ajeno a cosas MUY avanzadas con escasa documentacion y difusión*.

*Ademas de que es algo no necesariamente intuitivo.

Rendering: repaint, reflow/relayout, restyle

Todo lo que es estilo de un elemento no tiene getters/setters y sin embargo tienen efectos colaterales.