El mercado de proveedores de aplicaciones web sin código es muy competitivo. Da la sensación de que cada día aparecen nuevos proveedores, lo que dificulta cada vez más la elección. Sin embargo, en el mercado europeo, en particular, todavía hay muy poco movimiento. Por eso, las empresas europeas de nueva creación recurren a menudo a grandes nombres como bubble.io para desarrollar sus propios productos mínimos viables (MVP) y prototipos. Sin embargo, esto puede ser problemático en términos del Reglamento General de Protección de Datos, ya que los servidores de Bubble (y, por tanto, los datos de los usuarios) se encuentran en Estados Unidos. Pero con WeWeb, ahora hay una alternativa europea seria a Bubble en el mercado sin código. En esta comparativa detallada, puede descubrir lo bien que se compara WeWeb con Bubble y por qué ya estamos utilizando el recién llegado en algunos de nuestros proyectos.
Bubble es una de las herramientas de creación de aplicaciones web sin código más exitosas y utilizadas. Desde su lanzamiento en 2013, se ha desarrollado una gran comunidad en torno al proveedor estadounidense y la herramienta es ahora tan completa que puede utilizarse para implementar casi cualquier aplicación. En los últimos años, Bubble ha recaudado más de 100 millones de dólares estadounidenses en financiación, otra señal del gran interés de los inversores por la tecnología moderna y el futuro papel del no-code en las empresas.
"Construir aplicaciones de producción 10 veces más rápido" es el titular de la página de inicio de WeWeb. La herramienta sigue siendo relativamente nueva en el mercado en comparación con Bubble. El constructor de front-end sin código se fundó en París en 2017 y, como empresa europea, es potencialmente más interesante para los clientes europeos. WeWeb ahora también tiene fuertes patrocinadores financieros en el fondo, aunque todavía no en la misma medida que Bubble. La gama de funciones es muy similar a la de Bubble, pero hay diferencias clave, que discutiremos más adelante.
La mayor diferencia entre los dos proveedores sin código radica en la provisión de niveles de desarrollo. Mientras que Bubble permite a los usuarios desarrollar interfaces de usuario, flujos de trabajo y bases de datos para las aplicaciones, WeWeb elimina por completo la base de datos. Esto significa que WeWeb siempre requiere un back-end externo para almacenar los datos de tu aplicación. Pueden ser tus propias bases de datos SQL, como MySQL, o proveedores de back-end como Firebase, Supabase o Xano. Lo que a priori parece una gran desventaja es normal en el desarrollo de software convencional. Allí, las tecnologías front-end y back-end están siempre separadas. Hay que admitir que Bubble va un paso por delante en este sentido, ya que los proyectos pueden implementarse más rápidamente gracias a la base de datos interna existente, porque no hay necesidad de conectar servicios externos. Sin embargo, veremos en la sección de escalabilidad que las tecnologías back-end externas tienen algunas ventajas.
Las herramientas sin código son sinónimo de fácil accesibilidad en comparación con el desarrollo de software convencional. Sin embargo, hay que decir que cuanto más amplia es la funcionalidad de la herramienta, mayor es la curva de aprendizaje. Esto puede sonar bien, pero supone una entrada y un ascenso tediosos, sobre todo al principio del camino.
Entonces, ¿cuál de las dos herramientas es mejor en términos de facilidad de uso? No hay una respuesta general a esta pregunta, ya que depende en gran medida del nivel de experiencia del usuario.
Lo que podemos decir de nuestra experiencia, sin embargo, es que la interfaz de usuario en Bubble se siente mucho más engorrosa que la de WeWeb. Es un poco tosca, menos intuitiva e innecesariamente complicada. Pero una vez que te has familiarizado con ella, cada clic es más fácil y las posibilidades parecen infinitas.
A grandes rasgos, así es como visualizaríamos la curva de aprendizaje de Bubble. Así que no deberías rendirte demasiado pronto. (Créditos: VisualiseValue).
Aunque cuesta un poco acostumbrarse a Bubble, se ha intentado simplificar mucho los términos técnicos para que el material sea más accesible, sobre todo para los novatos. Por ejemplo, Bubble utiliza la palabra "Cosa" para las entradas de datos. Un no-go desde la perspectiva del desarrollo clásico. Pero alguien que nunca haya tenido nada que ver con el desarrollo de software podrá reconocer "Cosa" como término para una entrada de datos más rápidamente que, por ejemplo, Entrada de datos. Sin embargo, por otro lado, esto tiende a significar que las personas con experiencia en desarrollo son incapaces de transferir la terminología de uno a uno y los términos a veces pueden inducir a error.
La interfaz de WeWeb es más fácil de usar que la de Bubble. Es muy similar a otras aplicaciones sin código como Flutterflow o creadores de sitios web como Webflow. Todo parece ordenado, limpio y estructurado. Sin embargo, una pequeña cosa que actualmente todavía reduce mucho la productividad en WeWeb es la falta de un menú contextual al hacer clic con el botón derecho. En Bubble, en cambio, puedes encontrar varias funciones, por ejemplo para copiar, agrupar o eliminar elementos o configuraciones. Esta función sigue faltando en WeWeb.
Los flujos de trabajo representan la lógica back-end de una aplicación. Junto con el editor de diseño y la base de datos, los flujos de trabajo son el tercer componente importante de Bubble. Sin embargo, el editor de flujos de trabajo de Bubble también deja mucho que desear en términos de diseño. Cuadrados grises claros sobre fondo blanco no son precisamente prueba de un diseño UI/UX sofisticado. Sin embargo, o quizás precisamente por eso, la estructura de los flujos de trabajo en Bubble es bastante simple. Los flujos de trabajo siempre empiezan con un evento y siempre funcionan según el principio si-esto-entonces-eso. Si (evento A) ocurre, (evento B) debería ocurrir. Un evento desencadenante suele ir seguido de una serie de eventos posteriores. Por ejemplo: Cuando el usuario haya iniciado sesión, envíalo a la página de inicio.
Éstos pueden ampliarse de múltiples y complejas maneras. Toda la potencia de Bubble queda patente en sus posibilidades y flujos de trabajo. No hay prácticamente nada que no pueda realizarse con Bubble en términos de lógica back-end. El único obstáculo para hacer realidad esta potencia reside en comprender el tipo de expresiones de Bubble. Sin embargo, Bubble ayuda a ello reconociendo inmediatamente cuándo hay errores en las expresiones o en los flujos de trabajo. También han actualizado recientemente su editor de expresiones para diferenciar más claramente entre los componentes individuales de las expresiones.
Aquí es donde WeWeb vuelve a destacar en términos de facilidad de uso. Los flujos de trabajo no se encuentran en una pestaña aparte, sino que pueden abrirse directamente desde el editor. En WeWeb, también puede ver qué elementos tienen un flujo de trabajo asociado en el navegador de elementos (lo que el árbol de elementos es en Bubble). Con Bubble, sólo puedes ver esto cuando haces clic en el elemento correspondiente.
Los flujos de trabajo en WeWeb también tienen una ventaja sobre las burbujas en que pueden tener múltiples ramas. Por ejemplo, un flujo de trabajo puede separarse después de una condición verdadero/falso. También puede definir ramas "En caso de error". Se trata de flujos de trabajo que se ejecutan cuando se producen errores. Estas características recuerdan a Zapier o a los editores de Make. Son contemporáneas y hacen que todo sea aún más comprensible y claro. Los flujos de trabajo de WeWeb también pueden incorporar bucles, algo que es posible con Bubble pero mucho más engorroso.
Todo el mundo comete errores, ya sea con el código tradicional o con el desarrollo sin código. Sin embargo, una gran ventaja del desarrollo sin código es que facilita bastante la depuración. La depuración es el proceso de resolver errores en la aplicación.
Con Bubble, ni siquiera puedes hacer funcionar la aplicación si hay errores claros. El rastreador de problemas ayuda con esto. Muestra todos los errores abiertos antes de que se conviertan en un fallo de la app. Sin embargo, algunos errores no son de naturaleza técnica en sí, sino más bien un error lógico, como una variable incorrecta o una entrada que falta. Bubble dispone de un depurador para detectar este tipo de errores. Puedes ejecutarlo en el navegador web en paralelo a la aplicación y ver paso a paso lo que ocurre en los flujos de trabajo. Esto hace que sea más fácil entender por qué ciertas cosas suceden de la manera que lo hacen.
En este momento (diciembre de 2023), WeWeb no tiene un depurador visual como Bubble y, a diferencia de muchas otras características, esto aún no se ha anunciado para 2024. No obstante, puedes depurar flujos de trabajo con WeWeb. Puedes seguir el progreso de los mismos en la parte izquierda (Logs) y ver qué ocurre en cada paso. También puede hacer clic en "Probar" para cada acción y ejecutar sólo este paso individual. De este modo también se reconoce visualmente qué ruta se ha ejecutado, por ejemplo.
A diferencia de WeWeb, Bubble incluye su propia base de datos. Esto aumenta la velocidad de los proyectos en dos niveles. En primer lugar, no es necesario conectar ninguna base de datos externa complicada. En segundo lugar, se puede suponer que el rendimiento de la aplicación se beneficia del hecho de que las solicitudes de la API no tienen que ser enviadas constantemente de ida y vuelta a una base de datos externa. La base de datos propia de Bubble es también muy sencilla y fácil de entender, incluso para personas sin experiencia en SQL. La creación de tablas (llamadas "Tipos de Datos" en Bubble) y entradas de datos (llamadas "Entradas" en Bubble) en las respectivas tablas es rápida. Y las relaciones entre las tablas -algo que es una ciencia en sí misma- también se comprenden rápidamente con Bubble. En lugar de tablas cruzadas y relaciones n:n, Bubble utiliza el término "lista de" y permite mantener una base de datos SQL sin tablas cruzadas. Sin embargo, no está claro cómo afecta esto al rendimiento de la aplicación con un número muy elevado de entradas.
Por lo tanto, a menudo es mejor utilizar una base de datos externa. Esto es algo posible con Bubble y necesario con WeWeb. Lo que a primera vista parece una desventaja para WeWeb es, por el contrario, en realidad un punto fuerte. WeWeb se ha ahorrado mucho trabajo proporcionando integraciones nativas con algunas de las mejores bases de datos. La ventaja de esto es que las conexiones proporcionadas son más fáciles de manejar para los no-codificadores. Con Bubble, por otro lado, tienes que utilizar plug-ins o incluso configurar tus propias conexiones API con los proveedores de bases de datos. Por lo tanto, WeWeb Apps se beneficia de la especialización de los proveedores de bases de datos en términos de rendimiento y escalabilidad.
Si quieres ampliar tu aplicación con funciones que un constructor sin código no ofrece, a menudo es necesario incorporar código personalizado. Se trata de fragmentos de código, a menudo HTML, CSS, JavaScript o similares, que mejoran tu aplicación visual o funcionalmente. Tanto Bubble como WeWeb permiten el uso de código personalizado. Sin embargo, WeWeb te facilita este proceso. Si quieres insertar código personalizado en la cabecera global o en el cuerpo del script en Bubble, tienes que hacerlo en los ajustes. Curiosamente, esto se puede encontrar en la configuración SEO. Para subpáginas o elementos individuales, puedes insertar código HTML personalizado al final del editor de propiedades correspondiente.
WeWeb ofrece la posibilidad de trabajar con código personalizado en muchos más lugares, incluso directamente en flujos de trabajo o elementos. WeWeb también le permite definir sus propias funciones, que más tarde puede llamar y reutilizar en flujos de trabajo, por ejemplo. Esto significa que usted escribe código una vez (por ejemplo, en JavaScript), lo guarda como una función y puede utilizarlo una y otra vez en toda la aplicación. Incluso puedes hacer uso de un asistente de IA que te ayude a escribir o configurar exactamente lo que necesitas. Bubble ha anunciado su asistente de IA para 2024. ¡Así que seguimos entusiasmados!
Por el momento, ni Bubble ni WeWeb permiten crear aplicaciones móviles nativas.
Sin embargo, Bubble permite optimizar las aplicaciones web para móviles. Bubble también ofrece plug-ins de terceros que convierten una aplicación Bubble clásica en una aplicación web progresiva, una forma de aplicación móvil que puede estar disponible a través de un enlace en lugar de a través de las tiendas de aplicaciones. Los creadores de aplicaciones web Glide y Softr ofrecen este tipo de enlaces. También existen los llamados "wrappers" que pueden convertir tu aplicación Bubble en una aplicación móvil nativa para que puedas publicarla en la App Store o en Google Play Store. Sin embargo, Bubble ha anunciado que apoyará el desarrollo de aplicaciones móviles en 2024.
WeWeb ofrece una opción interna para proporcionar aplicaciones web como PWA. Sin embargo, WeWeb también ha anunciado que permitirá el desarrollo de aplicaciones móviles nativas en 2024. Esto hará que Flutterflow, Adalo y compañía tengan mucha competencia.
Los desarrolladores que quieren aumentar su productividad confían tradicionalmente en la reutilizabilidad de los componentes. El mismo principio se aplica al no-código. Construye una vez algo que pueda reutilizarse varias veces con la misma aplicación. Bubble proporciona aquí todas las funciones centrales: Clases de estilo, biblioteca de componentes, eventos personalizados y elementos reutilizables. Sin embargo, todavía tenemos que hacer concesiones aquí y allá.
WeWeb ha seguido recientemente su ejemplo en este sentido y ha publicado o mejorado dos nuevas funciones que simplifican la reutilización de elementos.
Las clases de estilo describen estilos que pueden definirse para botones, elementos de texto y grupos (contenedores div en WeWeb). CSS (Cascading Styling Sheet), es decir, un lenguaje de visualización, se encarga de ello en segundo plano. Esto permite modificar todas las propiedades externas de un elemento. Sin embargo, en lugar de tener que escribir código fuente, Bubble proporciona una selección de atributos definidos que pueden configurarse fácilmente en la interfaz de usuario. Entre ellos se encuentran el color de fondo, la fuente, el tamaño o el color de la fuente y algunos otros dependiendo del tipo de elemento. Si establezco una clase de estilo para un botón, por ejemplo, puedo configurarla una vez y aplicarla a cualquier número de botones de mi aplicación con sólo unos clics. Por lo tanto, los ajustes sólo tienen que hacerse en un lugar. En la pestaña de estilo de la interfaz de Bubble, puedo gestionar todas las clases en una ubicación central. Una desventaja de las clases de estilo en Bubble es que estás limitado a los atributos definidos por Bubble. Si quiero cambiar una propiedad de un elemento que no aparece en Bubble, no puedo añadirla de forma independiente, sino que tengo que integrarla utilizando código personalizado que he escrito yo mismo. Afortunadamente, CSS es fácil de leer y sencillo de entender, así que no es tan difícil empezar con esto.
La versión de WeWeb también es fácil de usar. Puedes realizar y guardar los ajustes a través de una interfaz visual. Con WeWeb, la pestaña de estilo recuerda mucho a la estructura del código CSS. Los términos también son los de CSS. Este no es el caso de Bubble. La ventaja es que las personas con experiencia en CSS pueden orientarse más fácilmente en WeWeb. Antes sólo se podía definir la tipografía y los colores en la biblioteca de interfaz de usuario. Ahora también se pueden definir espaciados y clases. Lo especial de esta actualización es que puedes compartir estos elementos entre diferentes proyectos. Por ejemplo, los desarrolladores pueden copiar fácilmente identidades corporativas enteras en un nuevo proyecto o simplemente transferir elementos individuales que les gustaban en proyectos antiguos a los nuevos.
Se trata de secciones ya creadas, como pantallas de inicio de sesión o de registro, menús de navegación o tablas, que pueden añadirse a su propia aplicación con un solo clic y personalizarse individualmente. Ambas aplicaciones ofrecen una selección de componentes preconstruidos desde el principio. Con Bubble, sin embargo, estás limitado exclusivamente a los componentes proporcionados y la selección es todavía muy escasa por el momento (noviembre de 2023). En el futuro, está previsto que se puedan añadir tanto componentes personalizados como componentes de la comunidad. En cambio, en la WeWeb UI Library ya se pueden añadir componentes personalizados en este momento.
Los elementos reutilizables, o componentes reutilizables, son módulos especialmente desarrollados que pueden gestionarse de forma centralizada e instalarse en cualquier parte de la aplicación. Estos bloques de construcción son perfectos para una construcción eficiente con pocos requisitos de mantenimiento. Bubble domina muy bien esta función y ha introducido nuevas mejoras con las últimas actualizaciones del producto. Esto permite convertir cualquier sección, contenedor o similar en un elemento reutilizable para poder utilizarlo en cualquier lugar. Las últimas incorporaciones son parámetros (las llamadas propiedades) que pueden transferirse a un elemento de este tipo para que también puedan recibir y procesar datos de distintas áreas. Un elemento reutilizable puede ser, por ejemplo, una tabla que se utiliza en diferentes páginas. Una misma tabla puede ser visible en el área de administración y en el front-end del usuario. Pero gracias a los elementos reutilizables, no tienes que construirla dos veces. Y si quieres cambiar algo en ambas tablas más tarde, sólo tienes que hacerlo en un lugar.
WeWeb ha cubierto finalmente esta función desde diciembre de 2023. También se pueden encontrar en la Biblioteca de interfaz de usuario, donde se pueden gestionar y personalizar de forma centralizada. Estos componentes también pueden crearse en un proyecto y luego compartirse entre varios proyectos. Esta característica ha sido largamente esperada y hará que trabajar con WeWeb sea aún mejor y más escalable.
"¿Puedo obtener el código que se escribió en segundo plano al construir mi app descargado de Bubble?". Esta es una pregunta común que recibimos y la respuesta simple es desafortunadamente no. En Bubble no es posible exportar el código que hay detrás de la app desarrollada. Esto da lugar al llamado efecto vendor lock-in, ya que la aplicación está vinculada al proveedor. Hay que sopesar de antemano los riesgos que conlleva y lo que se quiere conseguir con el desarrollo en Bubble.
WeWeb, por su parte, tiene una función de exportación de código que permite a los desarrolladores exportar todo el código HTML, CSS y JavaScript y utilizarlo en su propio entorno. El producto final es una app vue.js, un framework web JavaScript para crear aplicaciones web de una sola página.
"¿Es adecuado el no-código incluso para el escalado?". Esta es otra pregunta habitual a la que cada vez podemos responder con un "sí". Sin embargo, siempre depende de cada caso de uso. ¿Se trata de sesiones de usuario simultáneas que pueden ser atendidas por la plataforma? ¿Se trata del almacenamiento y procesamiento de registros de datos en el back-end? ¿Se trata de volúmenes de datos que se transfieren a través de interfaces?
El hecho es que plataformas como Bubble o WeWeb pueden manejar varios miles de sesiones de usuarios que tienen lugar al mismo tiempo. En última instancia, estas tecnologías se ejecutan en Amazon Web Services, donde pueden añadirse recursos en función de las necesidades.
En el desarrollo clásico, varios desarrolladores colaboran trabajando en sus propias ramas del código ("branching"). El conjunto se coteja con los sistemas de control de versiones y se fusiona ("merging"). Bubble funciona de forma similar. Los colaboradores (como se les llama en Bubble) pueden trabajar en una aplicación al mismo tiempo. También se pueden utilizar ramas a partir del plan de 119 $/mes. Sin embargo, dos desarrolladores no pueden trabajar en la misma página de una app al mismo tiempo.
WeWeb, por su parte, acaba de lanzar una función revolucionaria. Similar a herramientas como Miro o Figma, el editor de WeWeb permite ver en tiempo real dónde se encuentran los desarrolladores colaboradores para poder trabajar en la misma página al mismo tiempo. Bubble tiene que ponerse al día aquí.
En primer lugar: no podemos ni debemos hacer aquí ninguna declaración vinculante, ya que no estamos autorizados ni en condiciones de emitir un juicio profesional al respecto. En este caso, póngase en contacto con un experto jurídico. La información que figura a continuación se ofrece únicamente a efectos de categorización, pero no proporciona información alguna sobre si una solicitud cumple realmente los requisitos del GDPR.
Las reglas de protección de datos pueden establecerse tanto en la base de datos de la burbuja como en la mayoría de las herramientas back-end externas (WeWeb) para garantizar que los usuarios sólo vean la información que están autorizados a ver. Es importante hacer que estos datos sean inaccesibles para las personas no autorizadas a nivel de la base de datos y no filtrarlos u ocultarlos en el front-end. En este caso, siempre existiría la posibilidad de acceder a los datos, puesto que el navegador ya los ha descargado en segundo plano.
Otra cuestión es la transferencia de datos a terceros países, por ejemplo, EE.UU.. Dado que ambos proveedores de herramientas utilizan la infraestructura de Amazon Web Services (región de EE.UU.) para proporcionar sus plataformas, usted ya proporciona a los proveedores datos personales en forma de su propia dirección IP cuando llama a las aplicaciones desarrolladas con ellos en el navegador. Dado que, en el caso de Bubble, la base de datos de la aplicación también se ejecuta a través de AWS, todos los demás datos personales que introduce al utilizar la aplicación (por ejemplo, la dirección de correo electrónico para iniciar sesión) se procesan inevitablemente en un servidor estadounidense. Una forma de evitarlo (al menos en parte) sería que Bubble te proporcionara tu propia instancia del servidor de Bubble en un servidor europeo. Por desgracia, esto es muy caro (a partir de 3.000 dólares estadounidenses al mes). Otra opción es utilizar un back-end externo para Bubble, como Xano. Es importante tener en cuenta aquí que la transferencia de datos tiene lugar a través de llamadas a la API que no están del lado del servidor. Esto ocurre cuando se utiliza el propio conector API de Bubble. En este caso, los datos se envían desde Bubble y por lo tanto se ejecutan a través del propio servidor proxy de Bubble al back-end. Para configurar las llamadas API del lado del cliente, en las que los datos se envían directamente desde el navegador del usuario al back-end, puede integrar su propio código JavaScript o utilizar un plugin adecuado (por ejemplo, Xano Connector Plugin).
Por otro lado, WeWeb ofrece llamadas API del lado del cliente de forma predeterminada a través de las integraciones de back-end proporcionadas. Esto significa que no se requiere ninguna configuración adicional.
Por muy buenas que sean las prestaciones, de poco sirven si los costes de las herramientas van más allá de lo financieramente viable. Por eso es importante analizar lo antes posible la estructura de costes y el modelo de precios de la herramienta en cuestión.
Bubble ofrece cinco niveles de precios diferentes, desde gratuito hasta 349 dólares al mes, así como una versión Enterprise sin precio fijo. Las características están vinculadas al plan de precios. El plan gratuito permite crear aplicaciones ilimitadas, pero sólo se pueden publicar desde el primer plan de pago. Algunas características como los flujos de trabajo recurrentes o la autenticación de dos factores también están disponibles únicamente con los planes de pago. Con Bubble, hay otro componente relevante para el modelo clásico de precios por niveles, a saber, los precios basados en el uso. La tarificación basada en el uso es más o menos como un taxímetro: cuanto más manejas (usas), más pagas. En Bubble, la unidad relevante se llama "unidades de carga de trabajo" (WLU). Cada suscripción mensual incluye un número de WLU. Si se superan, hay que pagar más. Por desgracia, Bubble no es muy transparente sobre cómo se calculan las WLU, y mucho menos sobre cómo puedes reducirlas en tu propia aplicación.
Hemos grabado todo un episodio de podcast sobre los nuevos precios de Bubble. Escúchalo aquí.
El precio de WeWeb es similar al de Bubble. Existe una versión gratuita, pero no permite activar la aplicación. Con los planes de pago, que tienen un precio de 39 y 149 dólares al mes, hay características adicionales tales como dominios personalizados, plug-ins ilimitados y más, además de la aplicación en vivo. WeWeb incluso tiene dos características de precios que se basan en el uso: visitas mensuales a la aplicación y GB de almacenamiento de datos. El límite de almacenamiento es estándar y fácil de controlar gracias a la transparencia. En cambio, no siempre se puede influir claramente en las visitas mensuales a la aplicación. Sin embargo, en comparación con WLU de Bubble, las visitas mensuales a aplicaciones son, al menos, claramente rastreables.
Sin embargo, el precio de WeWeb tiene otro inconveniente: el back-end externo. Al tener que utilizar una base de datos externa, hay que tener en cuenta los costes mensuales de Xano, Airtable y similares. En total, el conjunto puede ser varias veces más caro que Bubble.
La lista de deseos de funciones para Bubble y WeWeb es larga. Tanto en los foros de la comunidad como en X/Twitter, siempre hay peticiones de nuevas funciones. Y gracias a la creciente competencia en el mercado sin código, la presión es grande. Y por eso hay que reconocer que ambos proveedores cumplen. Constantemente se lanzan actualizaciones y anuncios con nuevas y futuras funciones. A partir de diciembre de 2023, la hoja de ruta de WeWeb para 2024 tiene este aspecto:
Pero Bubble también va a intensificar su juego. Bubble ha anunciado que permitirá el desarrollo nativo de aplicaciones móviles y el desarrollo asistido por IA en el futuro. Otros anuncios para 2024 pueden sonar menos significativos para aquellos que no estén familiarizados con Bubble, pero harán que trabajar con Bubble sea mucho más fácil. Entre ellos, el lanzamiento de un nuevo editor de expresiones y la posibilidad de realizar operaciones de datos en bloque. Bubble da así un paso importante para garantizar la escalabilidad de las aplicaciones sin código.
Entonces, ¿por qué caballo debería apostar para su próximo proyecto sin código? Por supuesto, depende de lo que quiera de la herramienta. No hay un claro ganador como "mejor herramienta sin código para aplicaciones web". Nuestra conclusión es la siguiente:
Bubble es un pionero en el espacio sin código y puntúa especialmente bien cuando se trata de la combinación de front-end y back-end. Esto permite a cualquiera configurar y probar proyectos rápidamente sin tener que preocuparse de qué back-end es el adecuado o qué hay que tener en cuenta en primer lugar. Bubble también cuenta con una enorme comunidad que no sólo responde rápidamente a las preguntas, sino que también crea plantillas y plug-ins. Esto hace que Bubble Stand sea más ampliable que WeWeb. Debido a esto y a la naturaleza de las expresiones y la lógica, Bubble es más adecuado para desarrolladores sin experiencia, aunque sigue siendo una herramienta sin código relativamente difícil de aprender.
WeWeb, por otro lado, es más para desarrolladores que quieren escribir menos código que para no desarrolladores que quieren construir algo. Todavía no clasificaríamos a WeWeb como una herramienta de bajo código, pero definitivamente está más cerca de esta categoría que Bubble. Según nuestra experiencia, los puntos fuertes de WeWeb son el editor, la opción de autoalojamiento más sencilla y la posibilidad de exportar código. Además, la separación de front-end y back-end -aunque más cara y posiblemente más compleja- es una buena base para la escalabilidad.
Si no hay criterios claros de K.O. para tu caso, como la exportación de código, entonces la única opción es jugar con ambas herramientas y ver cuál te conviene más como desarrollador sin código.
En VisualMakers trabajamos tanto con Bubble (+ Xano) como con WeWeb (+ Xano) y somos fans. Así que si tienes alguna pregunta sobre tu proyecto, ¡no dudes en escribirnos! Ven a nuestra comunidad Slack. Hay más de 750 entusiastas del no-código esperando por ti y tus preguntas.
