SPFx sin programar: qué es posible de verdad
Última actualización:
En sentido estricto, no. SharePoint Framework es una cadena de desarrollo en TypeScript y React: escribes código, compilas un bundle con Heft y produces un .sppkg. No hay un diseñador visual que genere SPFx, y nunca lo ha habido.
Pero casi nadie que busca esto quiere SPFx. Quiere lo que SPFx produce: un componente que parezca parte de la página, que lea sus datos de SharePoint y que haga algo que los web parts nativos no hacen. Eso sí se consigue sin escribir código, y hay cuatro vías.
La distinción importa porque cambia a quién necesitas. «Necesitamos un desarrollador de SPFx» es un problema de contratación. «Necesitamos un componente en esta página que agrupe nuestras incidencias por estado» es un martes.
Qué implica SPFx de verdad
Conviene saberlo aunque solo sea para juzgar presupuestos y estimaciones:
- TypeScript y React como lenguajes, con las versiones que impone SPFx y no tú: hoy React 17 y Fluent UI v8.
- Una cadena de build, ahora Heft; gulp se retiró a partir de SPFx 1.22, lo que rompió muchos proyectos ya montados.
- Una versión de Node fijada. Cada versión de SPFx soporta un rango concreto, y equivocarse produce errores de compilación que parecen otra cosa completamente distinta.
- Un paso de empaquetado y despliegue: generar el
.sppkg, subirlo al catálogo de aplicaciones y aprobar los permisos de API que pida. - Mantenimiento continuo. Esta es la parte que nadie menciona al principio. Microsoft mueve el framework; en abril de 2026 retiró del todo los web parts domain-isolated, lo que obligó a tocar todas las soluciones que los usaban.
Ese último punto es el coste real de la vía SPFx, y no aparece en ningún presupuesto. El código que encargas hoy es algo que posees durante todo el tiempo que lo uses.
Las cuatro vías sin código
| Vía | Qué te da | Límite |
|---|---|---|
| Formato JSON de listas | Colores e iconos condicionales, barras de progreso, botones, tarjetas | Una lista, sin agregación y sin estado |
| Web parts nativos | Noticias, documentos, enlaces, contenido destacado, incrustaciones | Solo lo que trae Microsoft |
| Power Apps incrustado | Lógica de aplicación real y formularios de varias pantallas | Se renderiza en su propio contenedor; conectores premium con licencia por usuario |
| Plataforma de componentes no-code | Trackers, cuadros de mando, directorios y paneles de enlaces con aspecto nativo sobre tus listas | Acotado por lo que el esquema de la plataforma pueda expresar |
Esa cuarta fila es la que más se parece a lo que la gente se imagina cuando dice «SPFx sin programar»: un web part de verdad en la página, con el tema del sitio, leyendo una lista de SharePoint — pero producido describiéndolo en vez de construyéndolo. Por debajo es un paquete SPFx real; simplemente no eres tú quien lo mantiene.
Cómo saber cuál necesitas
Baja por esta lista y párate en el primer sí:
- ¿Es una lista que tiene que verse mejor o avisar de cosas? Formato JSON. Gratis, sin despliegue, esta misma tarde.
- ¿Microsoft ya trae un web part para eso? Noticias, documentos, enlaces, vídeo, contenido destacado: usa el suyo.
- ¿Necesitas recuentos, varias listas juntas o un componente con su propio diseño? Este es el terreno de la plataforma no-code, y el punto donde las opciones gratis se acaban de verdad.
- ¿Necesitas trabajar sin conexión, en móvil o capturar datos en varias pantallas? Power Apps.
- ¿Necesitas una integración real con un sistema externo o una lógica de permisos rara? Ahora sí necesitas SPFx, y vale lo que cuesta. Mira la comparativa completa.
La mayoría de los requisitos se paran en el 1 o en el 3. El error caro es empezar por el 5 porque la primera persona a la que se preguntó era un desarrollador, y los desarrolladores contestan correctamente a preguntas de desarrollo.
Preguntas frecuentes
¿Existe un diseñador visual que genere código SPFx?
No, y conviene decirlo claro porque hay proveedores que insinúan lo contrario. Lo que existe son plataformas que publican un único paquete SPFx ya construido que luego renderiza componentes a partir de configuración. El resultado en la página es un web part SPFx real; la diferencia es que configuras en vez de compilar, y el código es de otro.
¿Podríamos generar el código SPFx con IA y saltarnos al desarrollador?
El código puedes generarlo. Y lo vas a poseer igual: la cadena de build, la versión de Node, el despliegue y todos los cambios de framework que haga Microsoft a partir de ahí. Generar código es la parte barata del desarrollo a medida y siempre lo fue — la cara es la década siguiente.
¿Los componentes no-code se ven distintos de los hechos a medida?
No deberían, y es razonable verificarlo antes de comprometerse. Un componente construido sobre SharePoint Framework y con Fluent UI hereda el tema del sitio y encaja en la página como cualquier web part de Microsoft. Lo que sí se ve distinto es una aplicación incrustada en su propio contenedor: esa es la costura visible, y viene del modelo de incrustación, no de si se escribió código.
¿Y si se nos queda pequeña la vía no-code?
Entonces encargas desarrollo a medida para el componente concreto que se salió, y dejas todo lo demás donde está. Ese es el final sensato para casi cualquier organización: lo raro se lleva código propio y presupuesto de mantenimiento, y las veinte cosas normales no.