#29 Me podrías explicar eso? xDD, enserio...
#34 Por ampliar horizontes. Yo personalmente no conozco ningún maquetador que no sepa alguna de esas
#35 Porque lo normal es que le toque al frontend developer en modo "multi-task-man". Pero el diseno y maquetación debería ser cosa de una persona que se encarga de ello. Yo lo he vivido, y ahora me encuentro con que los disenadores solo hacen los mockups y tu te tienes que pegar para reproducirlo en el navegador. No se como sera el caso de #1 pero pinta que solo trabaja maquetando y no "desarrollando".
Maquetar sin JS es muy del 2000. Sin no sabes JS o JQ o alguno de sus hijos ( Angular, Ember... ) estás probablemente maqueteando páginas sin relevancia hoy en día.
#3 llevo 4 años trabajando en el mundo front y backend web, y te voy a dicí una cosa, la mejor forma de mejorar es trabajar con un diseñador (o varios, como es mi caso) exigentes a más no poder, con proyectos que cuesten pelas. Pues te van a pedir efectos, transiciones, cargas y flautas varias muy jodidas de hacer, a eso sumas que quieres que la web vaya fluida totalmente y te tienes que estrujar el cerebro y usar frameworks tipo angularjs (es lo que uso yo), además de librerías varias que aun que angular es muy completo y funcional, nunca está de más...
Qué bien escribir yo... 
Me refería a que maquetar sin JS o herramientas que nazcan de este, no se pueden hacer sites usables, accesibles y modernos. No con una velocidad de producción aceptable.
Y el mercado está muy saturado como para hacer plantillacos de wordpress de hace 10 años.
#41 Pero de que demonios hablas? Entiendes la diferencia entre maquetar y desarrollar frontend? XD
Maquetar = estilos y templates
Desarrollo = js + uso de estilos (que hoy en día los desarrolladores frontend tengan que lidiar con maquetar no quiere decir que no existan/puedan/deban existir maquetadores al uso).
Que se pare el mundo que yo me bajo. Seguid pensando que "Maquetador" es un trabajo y que no tiene que ver que son ser un DESARROLLADOR FRONT END.
Pero eh, es vuestro futuro laboral.
#43 Yo he dicho otra cosa, que tú hayas entendido esto es cosa tuya.
Por enésima vez: existen maquetadores que sólo maquetan aka. trabajan con html/css. Puedo ponerte ejemplos concretos, pero imagínate que en tu curro (como frontend dev) tuvierais una plataforma (vease Zeplin) donde el disenador/maquetador te deja todos los elementos con los estilos definidos... la vida del frontend dev sería más efectiva. Y otra vez, sí, existen.
Pero no érais vosotros los detractores a muerte de js y jquery? Hace cosa de 2 años decíais que se puede Y ES NECESARIO hacer una web totalmente funcional sin javascript y que la experiencia de usuario tiene que ser la misma.
La misma mis cojones.
#45 Si te hace feliz yo sigo odiandolo, pero solo cuando se utiliza para algo mas que para animar, dar efectitos y polladas varias.
Pienso que Angular, backbone, node, etc. son una soberana mierda.
#48 Totalmente, con la diferencia que todos estos lenguajes han sido inventado por un grupo de hipsters.
Les pasara como a RoR
#47 No es cuestión de odiarlo, es mas cuestión de a donde va el mercado e inexorablemente el mercado va hacia cada vez utilizar mas Javascript. La gente odia Javascript, lo se, sin embargo cuando lo estudias en profundidad ves la potencia del lenguaje.
#53 incompleto, caotico e ineficiente, ¿porqué?. Quiero aprender y lo pregunto de verdad.
Ten en cuenta que yo el lenguaje lo miro tal y como es, un lenguaje para trabajar con el DOM de HTML y que, ahora le están dando algo mas de importancia y lo están aplicando a otros menesteres.
Decís que es ineficiente, sin embargo tenemos a NodeJS que lo utiliza como lenguaje de servidor basado en eventos. No sé, es algo extraño. Quizás los prototipos no son de lo mas manejables y que no tenga tipado o clases, pero bueno, para el objetivo principal de el lo veo un lenguaje mas que suficiente.
#57 No queria meter Typescript de por medio, pero entonces me estás dando mas razón a mi xDD. No se si te has percatado de que yo estoy defendiendo JS, no he metido el tema de clases porque aún no está extendido del todo.
#56 #57 Según tengo entendido, las clases de ES6 siguen siendo lo mismo que functions y prototypes pero con otra sintaxis. De hecho es incluso peor, por que pierdes la posibilidad de tener properties/methods privados (al menos de forma sencilla). Aunque hay propuestas para esto en camino.
El caso es que JavaScript no está pensado para ser usado con clases y la gente sigue empeñada en meterlas con calzador, posiblemente por falta de comprensión del mecanísmo de 'herencia' del lenguaje (que en mi opinión es bastante sencillo. Kyle Simpsons lo explica muy bien en su curso Advanced JS y en los libros YDKJS).
