👀 El no-code es una basura*
Esta semana he probado Cursor, una herramienta que promete revolucionar la manera de trabajar y hoy vengo a traer una pequeña reflexión tras trastear (bastante) con ella.
👋🏻 ¡Hola!
Volvemos a la carga con la newsletter, con el objetivo de que tengamos las mejores historias de gente que ha hecho cosas con No-code, pero es que tengo tantas cosas que contarte y reflexiones que compartir que darían para un libro.
Es por eso que hoy quiero hablarte un poquito de lo que ha sucedido en las últimas ¿dos? semanas con los movimientos por parte de Flutterflow y Toddle de desvincularse del término No-code y acercarse al Desarrollo Visual y la locura colectiva con Cursor de los últimos días.
Pero antes, déjame decirte que estamos en la recta final de #LaSemanaNoCode en la que hemos conocido las historias de Julia Barrueco, Adrià Solé y Agustín Abreu de cómo se ganan la vida con No-code. Pero es que mañana aún nos queda conocer la historia de Sonia Calvo y cómo ha cambiado del mundo del marketing deportivo a ser Bubble Developer.
Y que es muy gratis (¡Jaime Mesa!) y que te puedes apuntar directamente desde este enlace.
Así que vamos a meternos de lleno en un lodazal reflexivo, que espero que me discutas, compartas y comentes con tu propia opinión.
El No-code es una basura.
Vengo defendiendo el término No-code aproximadamente desde hace unos 4 años. Como persona inquieta en medio de la pandemia, descubrí primero herramientas como Zapier o Webflow y posteriormente descubrí que había una comunidad de gente con tanta pasión como yo.
El término que denominaba a la gente que estaba más o menos en la misma situación que yo, personas con ganas de construir tecnología para dar alas a sus ideas pero que por suerte o desgracia no tenemos la habilidad técnica como para poder hacerlo.
Había una barrera, que es el aprender a programar que era infranqueable.
Y mira que lo intenté. Hasta intenté aprender Python en la carrera. Me hice cursos de HTML y CSS. Me hice un Bootcamp en FreeCodeCamp. Pero lo que era capaz de hacer era bastante, bastante cutre.
El tiempo que tendría que invertir para que realmente pudiera hacer las cosas que tenía en mente sería demasiado grande. Y más que tiempo es que no me entra en la cabeza.
Es por eso que cuando descubrí esta comunidad, me ilusioné.
¿Así que hay miles de personas de todo el mundo que piensan igual que yo? So cool.
A través de este término descubri comunidades como Makerpad, otras herramientas como Bubble, Glide, Adalo. Vamos, un movimiento de gente que apostaba por esta manera de construir.
Con el tiempo, el ecosistema ha madurado, las capacidades de las herramientas también, hay más casos de éxito y más gente que se dedica a ello. Han salido herramientas nuevas que han transformado lo que se puede hacer y en definitiva el ecosistema no deja de crecer.
Es por eso que aluciné cuando Flutterflow publicó el siguiente vídeo:
Y si bien, estoy de acuerdo con muchos puntos de los que comentan creo que el enfoque es totalmente erróneo por su parte a la hora de querer transmitir una idea esencial.
Que sea No-code, no significa que sea peor
Una concepción que tiene mucha gente es que optar por un desarrollo con herramientas No-code significa que vas a obtener un producto de menor calidad, o menos robusto o con menos posibilidades.
Para mi eso parte de la premisa de que es necesario definir qué es peor.
He conocido a decenas de emprendedores que tienen una idea “brillante” que están seguros de que van a ser capaces de convertir en un negocio. Optan por la vía del desarrollo. Contratan una agencia que se lo haga. Invierten el dinero que tienen (o que han sido capaces de captar) y construyen la primera versión de su aplicación.
Por el camino han pasado 6 meses y entre 10 y 20.000€.
Lo lanzan al mercado y se han dado cuenta de que realmente no funcionaba. Que el problema que resolvían no era realmente un problema. Que el usuario al que querían atacar era otro.
Y ese dinero y ese tiempo no se va a recuperar. Tendrán que contratar una nueva partida de desarrollo para poder llegar a poder aplicar los nuevos cambios que requieren para validar si ahí era el lugar.
Probablemente el resultado sea una aplicación funcional, escalable y robusta. Pero si nadie la quiere, ¿de qué sirve?
Es ahí donde una solución hecha en No-code, desarrollada en semanas, con mucha menos robustez (o no) te permite ahorrarte todos esos meses y esa inversión, para permitirte validar más rápido y lanzarte delante de usuarios en el menor tiempo posible.
En este caso el No-code no es que sea peor, si no que es mejor.
Y como este tantos otros casos en los que hemos podido implementar mediante herramientas No-code soluciones a problemas en tiempos que serían imposibles de hacer con código.
Y créeme, si haces las cosas bien con estas herramientas no tiene por que fallar, no tiene por qué no ser escalable.
Lo que sí, tendrá limitaciones, lo que nos acerca al mundo del Low-code.
Superando las barreras del No-code, abrazando el Low-code
Las primeras herramientas No-code estaban centradas en proporcionar una capa de abstracción bastante heavy.
Bubble es el ejemplo perfecto, dando una capa de abstracción por encima del código que hace que puedas construir aplicaciones sin saber todo el código que hay debajo. Simplemente con entender cómo lo hace Bubble podrás construir lo que tengas en mente.
Sin embargo, con este enfoque llegan también las limitaciones, sea porque aún no lo ha desarrollado la herramienta de forma nativa o porque te han pedido un requisito que no es posible hacer en este momento.
Es ahí donde entra el territorio Low-code, en el que buscamos combinar la facilidad de construir interfaces y lógica mediante un constructor visual, pero a la vez poder implementar ciertos “snippets” de código que permitan saltarnos las limitaciones que actualmente proporciona la herramienta.
Esto te permite que las limitaciones, abrazando este enfoque de construir de manera visual y enriquecer con código de manera tradicional, sean realmente pocas.
Es lo que se conoce como el mundo del Desarrollo visual y créeme que es algo que deja de ser nuevo. Visual Basic en los 80 ya abrazaba este enfoque para poder construir aplicaciones de Basic de manera visual, combinando una interfaz en la que “Lo que ves es lo que es” (WYSIWYG en inglés) con la robustez de escribir código para implementar la lógica necesaria.
Herramientas de Desarrollo Visual
Flutterflow es una herramienta de desarrollo visual.
Ese es el posicionamiento que han tomado, de cara a definir bien qué es lo que están haciendo y para que sirve la herramienta.
No es algo para hacer “juguetes”, si no una manera diferente de construir aplicaciones profesionales que resuelvan los problemas de usuarios reales.
Mediante sus Widgets ya pre-construidos y siguiendo las reglas de Dart, puedes ir construyendo tu aplicación de manera sistemática, construyendo lógica y UI de manera visual. Lo que se conoce como el front-end de la aplicación es posible crearlo totalmente de manera visual.
Para que esto es posible es necesario hacer ciertas abstracciones del código - si no estaríamos directamente escribiendo código - por ejemplo cuando creas un Workflow en Flutterflow o haces una llamada no estás escribiendo el código tú mismo, si no que añades un nodo que hace eso y que por detrás estará construyendo el código por ti.
Vamos, eres un desarrollador visual.
Conviértete en profesional del mundo de la tecnología, sin saber programar en el No-code Specialist
Llevamos 4 años de vida, viendo como cada vez esto va teniendo más demanda. Los “desarrolladores visuales” (pun intended) o No-coders podemos construir tecnología mejor y más barato en muchísimos casos.
Y esto supone que mucha más gente pueda acceder a esto, ya sea para generar ingresos en su tiempo libre o para dedicarse a ser profesional de esto.
Por eso abrimos nuestra 3ª edición, después de formar a 35 profesionales y que muchos de nuestros alumnos ya estén trabajando de esto.
Si crees que puede ser para ti, vente, te conocemos y vemos si tiene sentido. Te garantizamos que aprender, vas a aprender mucho :)
Y aquí es donde creo que el posicionamiento de Flutterflow es totalmente correcto y es algo que llevo defendiendo años.
Una persona que no sabe programar, gracias a estas herramientas, puede hacer desarrollos de aplicaciones profesionales, que puedan resolver problemas de usuarios.
Somos desarrolladores visuales, no-coders o como quieras denominar el término. Pero lo importante es que buscamos una manera alternativa de solucionar problemas mediante la tecnología, una manera que tiene muchísimos pros (como la rapidez, la facilidad de aprender, etc…)
Cuando llegó el coche, no se llamo “No-caballos”
El problema aquí está con que no les gusta el término. Un término que empieza con una negación de algo (dicen) no es algo que les represente.
Hacen la analogía con los caballos y el coche. Cuando llegó el coche nadie inició el movimiento “No-caballos”.
Sin embargo aquí es donde creo que cometen un error de forma.
Y es que detrás del término No-code se ha formado esta maravillosa comunidad, de gente que compartimos y construimos nuestro camino sin saber programar, pero con el mismo objetivo.
Con este vídeo rechazan a toda esta comunidad toda esta base de usuarios que les hemos apoyado desde el principio de la herramienta, en pos de posicionarse con un término que lleva años en el mercado.
Y el fondo no lo discuto. Buscamos lo mismo.
Pero las formas pierden.
Y no están solos en esto. Toddle, otra herramienta que hasta hace nada se posicionaba en este territorio No-code/Low-code ha decidido hacer una campaña similar.
Resumiendo, su posicionamiento es que son un framework visual para construir código.
Que no son No-code. Que es muy profesional. Que es para desarrolladores.
(Puedes leer el artículo al completo por aquí)
Y qué quieres que te diga, no lo comparto. Creo que la comunidad No-code es de las más sanas que hay en el mundo de la tecnología y que alejarse de este término no es el mejor movimiento del mundo.
Por que al final nuestra misión es democratizar el acceso a construir tecnología, y estas herramientas hacen exactamente esto.
Así que, me gustaría escucharte a ti. ¿Qué opinas? Respóndeme a este email y estaré encantado de debatir :)
Y hasta aquí la newsletter de hoy. Si te ha gustado, o si quieres ayudarme a que llegue a más gente - ya sabes cómo puedes hacerlo. Compartir, que es muy gratis.
Hola Alex! Que quieres que te diga, creo que se trata mas bien de una estrategia comercial y de apuntar mas bien a otro nicho para FlutterFlow (developers o perfiles más técnicos) que quieren desarrollar de forma más eficiente. De Toddle no opino porque no la conozco.
Al final desarrollar algo medianamente complejo con FF requiere conocimientos de APIs, BBDD, de lógica, de gestión del estado local y global, de construir interfaces con componentes y parametrizar valores…
Viniendo del mundo del desarrollo tradicional me siento en casa desarrollando con FlutterFlow.
Además el termino no-code siempre me ha resultado raro en tanto en cuanto hace referencia a la herramienta y no al propósito de lo que hacemos que es desarrollar (de una forma alternativa a la tradicional).
A mi me parece bastante correcto el termino desarrollador visual, aunque siendo todavía más radical ¡creo que el término “desarrollador de software” también nos aplica!
Hola Álex,
Totalmente de acuerdo con lo que comentas.
Gracias al no-code se ha democratizado el acceso a construir tecnología y mucha gente ha visto la oportunidad de ganarse la vida con ello.
En este caso el "No" no es peyorativo, sino una característica que da valor a este movimiento.
¡Larga vida al no-code!
Saludos.
Ester