38 meneos
1131 clics
Este envío tiene varios votos negativos. Asegúrate antes de menear
Alternativas a Bootstrap: Frameworks CSS (I)
¿Buscas alternativas a Bootstrap para el diseño de una web? En este primer artículo encontrarás varios frameworks CSS diferentes para utilizar en tu web.
|
comentarios cerrados
Mientras el Windows 98 SE siga funcionando no cambiaré.
El día que se muera, igual pruebo el Windows ME, que comentan que es muy bueno...
Luego pasa lo que pasa, que se usan frameworks para todo, matando moscas a cañonazos.
No digo que los frameworks no sean herramientas estupendas, ahorran un montón de tiempo, pero no deberían usarse hasta tener mucha experiencia en JS y CSS a pelo, la mayoría de veces sobra.
Al menos es mi opinión en el poco tiempo que llevo metido en desarrollo web.
También podría usar bytecode, pero Java tampoco pasa por su mejor momento...
O todos los que están trabajando en Angular2, 3 o 4... qué frikis todos. ¡Ya hay que ser raro para trabajar con lenguajes que compilan y que son fuertemente tipados! Son tan poco habituales...
#12 En el caso de typescript, es mejor casi siempre. A no ser que tengas un equipo experto en Angular1, con muchos años de experiencia, lo normal es apostar por Angular2. De hecho el gran problema es que es tan tan tan diferente que muchos no pueden cambiarse. Al final se resume en que estás trabajando con entornos que compilan (más o menos), fuertemente tipados, que da robustez y seguridad a tu código.
Lo de Kotlin no es muy negociable... que sea mejor opción que Java no lo digo yo, lo dicen hasta en Android. Si trabajas sobre Android es completamente incomparable, potencia de lenguajes actuales (corutinas, programación lineal asíncrona, lambdas...) en JDK6; es como un nuevo amanecer. En JVM las mejoras son notables, pero no hasta ese punto; mucho menos código, más sencillo, más rápido, el mismo lenguaje te dirige hacia la escritura de código simple, limpio y seguro (como la no nulabilidad o la inmutabilidad).
Puedes poner una estrellita en la puerta de la nevera, en cuanto tengas cinco podrás conseguir esa bicicleta que tanto querías.
Eso sí, también te reconozco que, no habiendo exigencias de diseño, el bootstrap es una comodidad.
github.com/milligram/milligram
Yo maqueto mucho, y nunca he usado eso.
No podemos ofrecer productos de empresa maquetados en una aplicación de terceros.
Eso es como pedir html y que te venda uno con Dreamweaver.
Hay que saber CSS y cómo maquetar de verdad, para resolver problemas de maquetación y conocer el código a fondo.
Esto es otro hace paletos.
Tablas + php y sin CSS con. Dreamweavet era el estándar.
Ahora se meten un framework sin saber CSS, ni html, enganchan con PHP y MySQL torticeramente, con miles de tablas mal relacionadas y sin proyecto real, y ahí te quedas.
En mi empresa tenemos a uno así, como todo se maqueta puto y duro el tío es un inútil integral.
El problema es dar soporte a distintos navegadores y formatos.
Tengo un menú desplegable en CSS puro compatible hasta con ie7, y hay que echarle curro.
Lo mismo con js, si lo usas debes saber qué hace con vista de.compatibilidad y qué no.
Esto cuando tus clientes son la administración, con. PCS antiguos, es una odisea.
Aquí fallan los mierdi cms y sus colegas.
Es6/7 hará inútil el typescript, al tiempo.
Manía de convertir un lenguaje no tipado en uno que si lo es. Cuantos van ya?
Te lo dice alguien que lleva un par de años con typescript para empresas.
Esa falsa sensación de seguridad que además convierte en problema cosas que antes no lo eran.
La realidad es que te encuentras gente que no tiene en cuenta el código resultante de los transpiladores y hacen mierda. Eso sobretodo en css.
Bootstrap es perfecto para un backends y ahorrarte pensar o diseñar.
He contratado hace poco dos desarrolladores para un proyecto bastante chulo que llevo en mi empresa. Ahora mismo estamos empezando a crear la base de datos y le he pedido al BE que implemente un algoritmo para analizar títulos de cursos (casi 100 mil) y asignarles áreas de estudio, mirando un par de tablas. Lo quería optimizar reordenando cada X iteraciones ambos campos de estudio y sus "keywords", atendiendo al número de veces que se han encontrado/asignado anteriormente, y de paso crear una tabla de caché con los títulos por índice y los valores asignados como valor, para ahorrar unos segundos (pocos ahora en el testeo, muchos más en el futuro) y así reducir los problemas con cuellos de botella y sobrecarga en el servidor.
Pues el desarrollador me mira como si yo fuera un lunático. Poquísimos programadores saben implementar un algoritmo mínimamente creativo y optimizar su código, sólo saben usar los putos framework de los güevos.
Los frameworks son básicamente juguetitos interesantes de desarrollar, que ayudan al desarrollo en equipo y a estandarizar el trabajo, aparte de tener ya resueltos problemas típicos. Pero son sencillamente:
1. Más gordos, pero mucho más, de lo que normalmente necesitas
2. como consecuencia, mucho más lentos
3. se les supone más fáciles de desarrollar y mantener con ellos, pero no es verdad. Pídele un cambio chorra a un desarrollador y tírate de los pelos con sus respuestas
4. vuelven a la gente tonta. Sinceramente, yo ya no veo "ingenieros" en esta profesión (o no en el mundo web), sino picacódigos que copian y pegan soluciones que han visto en internet, pero NO SABEN RESOLVER UN PROBLEMA
El problema que subyace es algo que ya he comentado en Menéame y otros sitios, y cuando lo expreso me quedo bastante sólo, pero es así: los programadores las más de las veces son obreretes (muchas veces no tienen ni estudios relacionados) que ponen cuatro ladrillos, y tienen que compensar el que su trabajo es una mierda (típicas aplicaciones CRUD) con super complicar las cosas, para sentirse más valiosos e inteligentes. Pero no dejan de estar haciéndose pajas mentales con sus ladrillos de mierda.
Dudo que el ser humano haya involucionado en sólo una década. El problema al que te refieres es muy simple: programadores buenos hay muy pocos, los que hay ya están trabajando y probablemente sean muy caros.
Pero pienso que las empresas no tienen la culpa, sino la sociedad. Desde siempre se ha valorado muy poco nuestra profesión. Quizá porque pensábamos que cualquiera podía hacer un "pogramita guapo". Me da mucho coraje este tipo de cosas.
La tendencia general en el mundo web es conocer frameworks y liberías y mierdas, es lo que los programadores quieren y ponen de moda, y es lo que los RRHH demandan en las ofertas.
Todos esos problemas los soluciona Bootstrap. Realmente no sé ni por qué hay que buscarle alternativas. Y bueno, otra tecnología que está por llegar es WebAssembly, que espero que le dé una estacada a Javascript.
¿Qué problemas da el tipado? En sí. Las ventajas son infinitas . ¿O te refieres a los problemas que la transcompilaión en sí llega a generar?
Parte II: Alternativas a Bootstrap: Frameworks CSS ligeros
Parte III: Alternativas a Bootstrap: Frameworks CSS ultraligeros
Parte IV: Alternativas a Bootstrap: Frameworks para Grid
Parte V: Alternativas a Bootstrap: Componentes web
Cuando aparezca webassembly, pues lo mismo, a ver cuanta gente lo usa directamente en vez de una herramienta de terceros que "compila" a bytecode.
La gente se esta mal acostumbrando a usar "soluciones" de terceros "para todo" en vez de usar el standard.
Hay cosas que el tipado te complica algo sencillo.
Por ejemplo en react, tienes que pasar una propiedad con una acción de un elemento en el nivel 1 al nivel 25 (por ejemplo de una página a un botón) a no ser que utilices redux tienes que escribir 25 interfaces, si no, no te compila. Cada uno de los componentes intermedios tienen que tener esa propiedad para pasarla hasta el botón.
Y hay muchos más ejemplos.
Ni todo el tipado del mundo convertirá a un mediocre en un buen programador
Ni todo el tipado del mundo convertirá a un mediocre en un buen programador
No, pero al mediocre se le van a petar las cosas en desarrollo, no en producción.
Igual que la no-nulabilidad de lenguajes como C# y Kotlin; tal vez tengas que darle un poco más de trabajo al desarrollar, escribir algo más, pero las cosas se rompen rápido y en casa.
Luego al cliente le saltan fallos que no entendemos, tenemos que acceder a logs para investigar, dumps de memoria, hacer rollbacks... toda una pesadilla.
1) romperse en runtime no es romperse en producción, para eso están las pruebas.
2) puedes hacer código tipado que no falle al compilar y que falle en runtime = falsa sensación de seguridad.
3) debug con maps funciona regular.
4) la librerías tienen que estar tipadas para usarlas, y muchas veces no hay o la tienen antiguas.
A final añades capas de complejidad que no solucionan nada y añaden más entropía en la depuración.
Te lo digo que llevo dos años comiendo incomodidad y viendo como los errores se hacían difíciles de encontrar.