¿Cuáles son las limitaciones / problemas con las soluciones existentes para crear aplicaciones (móviles / web) sin codificación?

En un nivel alto, los problemas no son diferentes de programar CON código en que algunas cosas que crees que necesitas construir son más difíciles que otras. Y algunos son imposibles con las herramientas existentes. La pregunta es, como siempre, si realmente necesita esa característica. ¿Es esencial para el estado actual de su aplicación? Lo más probable es que probablemente encuentres algo que funcione, por ahora. Si no puede, ¡entonces probablemente no esté utilizando la herramienta adecuada!

Los problemas son que puede pasar MUCHO tiempo jugando con complementos y cosas que no necesita. Pero debido a que es “fácil”, puede terminar agregando una carga de widgetery que puede desordenar. Todos los que hayan pasado una hora haciendo un 90% de un Powerpoint, y luego otras 2 horas jugando con imágenes y animaciones lo entenderán.

Otro problema es que definir algo para que un codificador construya agrega un aspecto de verificación y retroalimentación. Ser capaz de hacerlo todo usted mismo significa que puede construir fácilmente para sí mismo y quedar ciego. Hay un lado positivo, en el que puedes iterar algunas cosas fácilmente, mostrarlo, cambiarlo. Y no tienes nada de los ojos de tu equipo de desarrollo 🙂

Las limitaciones son … Las limitaciones. Algunos creadores de aplicaciones son plantillas “solo” y son bastante limitadas, otros como Appery probablemente pueden hacer la mayoría de las cosas, ya que puede agregar Javascript y API. Pero entonces necesitas ser un programador para eso … o tener acceso a uno. Esto me pareció frustrante.

Como otros han señalado, hay un continuo de “programación” desde simples creadores de aplicaciones con plantillas, hasta herramientas más complejas como bubble, hasta herramientas “necesarias para codificar” como un aperitivo y luego escribir código con bibliotecas (cuán diferente es la extracción de programación visual en una docena de bibliotecas JS … ¿en serio?) para crear código a mano desde cero.

Elija la herramienta adecuada para el trabajo y hágalo.

El problema intrínseco con esto es que siempre podrá hacer más con el código sin procesar que con algo que está diseñado para permitirle crear cosas sin codificación. Piénselo en términos de una persona que habla un idioma extranjero con fluidez frente a una persona a la que se le han dado varias declaraciones genéricas para entenderlo. La persona fluida siempre podrá comunicarse más rápido, pero requiere mucho más tiempo para aprender bien el idioma. Cualquier persona puede usar las declaraciones genéricas para comunicarse sin invertir tiempo, pero son extremadamente limitadas en comparación.

Tendrá problemas tanto desde el código como desde la perspectiva de UX. ¿Qué es lo que sucederá si desea tener un flujo de usuarios particular o acceder a un sensor particular independientemente de las soluciones existentes?

Si estas cosas funcionaran correctamente, entonces no habría habido necesidad de desarrolladores de aplicaciones en este mundo. Son muy defectuosos y proporcionan una experiencia de usuario mediocre a la aplicación.

El problema con ese tipo de aplicaciones es encontrar el equilibrio correcto entre la complejidad y la flexibilidad de UX.
No hay una respuesta correcta aquí, realmente se reduce a lo que los clientes necesitan.
Si los clientes son desarrolladores, nunca existirá un UX que permita la misma flexibilidad del código regular manteniendo la misma productividad.
Si su UX es más productivo que la codificación, significa que se está concentrando en un subconjunto de posibilidades.

De todos modos, digamos que descubres cuál es el equilibrio correcto: ¿será difícil de implementar?
La respuesta es sí, en comparación con la programación regular que está operando en un nivel superior. Es similar a la programación del compilador o intérprete, pero también debe preocuparse por el front-end.

Para darle una idea de cuánto esfuerzo podría tomar: en el trabajo proyecté e implementé un sistema similar con dos colegas. Le permite definir gráficamente fuentes de datos, conjuntos de datos, modelos y API REST.
Actualmente hemos implementado fuentes de datos SOAP y de bases de datos. Para que pueda convertir gráficamente su infraestructura SOA existente en REST con la capacidad de refactorizarla un poco: cambiando la granularidad de los servicios, los nombres de campo … ese tipo de cosas.
Además, creamos un portal del lado del cliente que le permite componer páginas con widgets. El valor agregado de la solución es que tenemos widgets regulares que esperan resultados fijos de la API. Pero también tenemos dinámicas que puede vincular a las nuevas API expuestas en la puerta de enlace api. ¿Tienes algunos widgets para CRUD? Funcionarán para cada nueva Api.

Bueno, para construir todo esto en un estado beta, tomó 3 años de hombre. Pero fue lo más divertido que hice hasta hoy. 🙂

Gracias por A2A!
En mi opinión, sin codificar realmente estás construyendo algo, no lo estás creando o desarrollando. Las aplicaciones están destinadas a ser desarrolladas. Crear aplicaciones sin codificación es ayudar a aquellas personas que no conocen la codificación.
Si crea una aplicación sin codificar, no comprenderá completamente qué está sucediendo exactamente. Si conoce la codificación, debe hacerlo usted mismo.

Una gran limitación es que una persona que no conoce la mentalidad lógica de la codificación todavía tendrá problemas para crear una aplicación útil a partir de bloques de construcción pregenerados.

Los buenos programadores escriben el menor código posible. Si ya hay una biblioteca que tiene la función que necesitan, la usan. Una gran parte de su esfuerzo se dedica a planificar y organizar antes de que se escriba algo.

Si alguien no puede hacer eso, entonces tendrán problemas para crear una aplicación útil.

Piense en ello como la diferencia entre cocinar y bombardear una cena congelada. Una aplicación de creación de aplicaciones solo puede construir lo que fue creada para construir. Al escribir y codificar una aplicación usted mismo, solo está limitado por lo que puede hacer el hardware. Escribir código para hacer un brindis sería difícil (para niveles de dificultad al acercarse agitando los brazos y volar), pero usar una aplicación de creación de aplicaciones para descargar un archivo xml de un servidor FTP y agregar los datos a una base de datos existente probablemente sería imposible. (Y es un código bastante trivial).

no obtienes control, no puedes ser lo suficientemente flexible y no puedes crear una interfaz de usuario realmente llamativa. Entonces, si planeas hacer algo pegadizo, ¡en algún momento tienes que codificar y ensuciarte las manos! 😀

feliz codificación !!

Sí, son características que no podrá realizar. Sí, es difícil hacer algo bueno con estos, porque eso no es para lo que están destinados.

Esta pregunta contiene una suposición: que no puede aprender algo de codificación, y que no codificar es más fácil que codificar.

Pero hacer algo bueno con ellos puede ser más difícil que aprender suficiente codificación para hacer una buena estructura alámbrica o incluso un mvp de tu aplicación. La codificación no es tan difícil, mi consejo es intentar aprender un poco. Te sorprendería lo bien que va una vez que te sumerges.

Nunca he intentado usar este marco en el que podría construir sin codificación, pero se anuncian como un cambio de juego, pero en mi sincera opinión como diseñador web y móvil con suficiente comprensión del desarrollo, creo que el problema es que usted tendrá algunas limitaciones porque estos marcos se crearon con un conjunto de características y, básicamente, eso será todo lo que obtenga y su creatividad para probar algo nuevo sin codificarlo usted mismo será muy limitada. Espero que de alguna manera responda tu pregunta.

– Cualquier característica que pensaste y no te dijeron
– no debería ser demasiado difícil, derrota su propósito

Es porque necesito una tarjeta de crédito y no tengo una.