Figma werkt aan nieuwe tools om apps en websites te bouwen

Figma werkt aan een nieuwe AI-tool waarmee apps kunnen worden gemaakt. Het bedrijf ontwikkelt ook een nieuwe tool waarmee gebruikers websites kunnen maken. Dat blijkt uit gelekte screenshots. Het is niet duidelijk wanneer Figma de functies wil introduceren.

Uit een post van Threads-gebruiker Jane Wong blijkt dat er aan een AI-tool voor het maken van apps wordt gewerkt: Figma AI App Maker. Deze tool maakt gebruik van het Claude Sonnet 3.7-taalmodel en zou met tekstprompts, Figma-bestanden en afbeeldingen overweg kunnen om te coderen.

Wong heeft ook screenshots van Figma Sites gedeeld. Dat is een tool waarmee gebruikers websites kunnen ontwerpen en publiceren. Figma Sites geeft gebruikers de optie om vooraf gemaakte website-secties te gebruiken, kant-en-klare interacties in te stellen en de onderliggende code van de website aan te passen.

Screenshot Figma AI App Maker. Bron: Threads-gebruiker Jane Wong

Reacties (57)

[fenrirs]

Ik verlang soms echt terug naar 2001. Met VB of 4D kon ik destijds in no time werkende! applicaties met ingewikkelde gekoppelde dropdowns en fileuploads bouwen. Component aanklikken en code tikken. Dat is mij met websites eigenlijk nog nooit gelukt (maar ik ben dan ook geen professional)
Voor mijn favoriete stack (django+htmx+alpine) blijft het toch elke keer weer custom JS, Custom python en custom css om precies te maken wat je wilt (maar misschien heeft iemand tips, zit aan python backend ‘vast’)

[Reactie gewijzigd door fenrirs op 21 april 2025 13:01]

[Ablaze]

Ja, dat is inderdaad een beetje vreemd.
Rond de eeuwwisseling hadden we prachtige WYSIWYG IDEs waarmee je in een handomdraai grafische user interfaces kon maken. De theming en gebruikte componenten waren bijna altijd consistent tusen applicaties, zodat het voor gebruikers makkelijk was om toepassingen te begrijpen. Voor interactiviteit in websites kon je Flash gebruiken, dat ook snel werkte voor developers (alleen jammer van alle security issues).
Na 25 jaar ziet alles er wat leuker uit voor gebruikers, maar zijn we qua productiviteit niets opgeschoten, zelfs met een AI die ons helpt code te genereren.

[CapnCrinkle]

Ik heb destijds een prachtige WYSIWYG editor gebouwd waar erg veel mensen enorm blij mee waren. Maar er wordt hier naar mijn gevoel nogal over 3 grote dingen heen gekeken.

1 ) Alles is tegenwoordig dynamisch. Dit betekent gewoon aanzienlijk meer complexiteit.
2 ) Alles is tegenwoordig grafisch complexer en er is véél meer mogelijk dan toen. UX was toen praktisch non-existing.
3 ) De reden dat mijn WYSIWYG editor niet meer mee kon met de tijd, was wegens alle nieuwe vormen van apparaten en vertalingen. Vertalingen was één ding, maar veel mensen wilden content anders presenteren op verschillende apparaten van telefoons tot tablets en uiteraard hadden we nog 'vierkante' beeldschermen maar ook breedbeeld, nog niet de bek open te breken over support voor 'gelimiteerde gebruikers' en alle verschillende resoluties, waar vooral destijds nog niet echt standaarden voor waren en ook zaken als responsive nog amper in de schoenen stonden.

Ik, persoonlijk, ben een echte maatwerkprogrammeur en vermijd frameworks zoals Django, Magento, Wordpress, React, Angular etc als de ziekte en moet bekennen dat ik me ook niet enorm herken in de bovengenoemde problematiek. Mogelijk omdat ik gewoon altijd al heb gecodeerd op de manier die frameworks proberen te verbergen om het rendabel te maken voor de slechtste developers onder ons. (Hoop dat dit laatste zinnetje geen flamewars gaat veroorzaken, maar feit is dat frameworks een manier zijn om te zorgen voor "idiot proofing")

En, hoewel ik aan de ene kant veel van deze problemen niet zie, maak ook ik wel degelijk problemen mee met alle verschillende form-factors van apparaten, verschil moeten maken tussen touch-screens en non-touchscreens, waarmee ook zaken als window resizing (pop-up keyboards enz), vreemde form-factors, en überhaupt het afvangen van allerlei mogelijke client-side screwups welke vroeger gewoon niet mogelijk waren, omdat er tegenwoordig gewoon aanzienlijk veel meer features zijn.

[martijnvanegdom]

Ik vind dat lijstje intrigerend.. Want als je maatwerk levert dan snap ik dat je geen CMS software als Magento, en Wordpress wil gebruiken.

Maar Django, React en Angular dat zijn heel andere type frameworks.. waarom zou je dergelijke oplossing vermijden? Ik wil ook geen flamewars, maar ik ben even benieuwd wat je dan gebruikt?
Puur HTML / CSS / Javascript? En waarom zou dat beter zijn dan bijvoorbeeld React & Angular. Nogmaals geen flamewars echt oprecht geïnteresseerd waarom je dergelijke frameworks vermijd?

[Reactie gewijzigd door martijnvanegdom op 21 april 2025 21:00]

[CapnCrinkle]

De TL DR;
Ik kies bewust voor eenvoud. Geen overbodige dependencies, geen lock-in, geen 500MB build-pipelines. Gewoon: vanilla JS, CSS, HTML, PHP en NodeJS. Het draait snel, stabiel, en is overal te onderhouden – zelfs vanaf een internetcafé, als het moet.

De volledige reactie;
Klopt, zijn totaal andere frameworks inderdaad. Mijn nadruk ligt altijd vooral op geen afhankelijkheden, geen tooling lock-in en snelle service kunnen verlenen (netter maken kan later nog. Éérst eerste hulp, dan ziekenhuis)

Het lange verhaal kort is in 5 punten (waarom ik ze niet gebruik):
1 ) Ik heb ze niet nodig.
2 ) Als je een miljoen regels nodig hebt voor "Hello World", doe je iets fout. (Maker van angular die dat zei nadat hij terug ging naar vanilla JS development, IIRC)
3 ) React crashte op DOM’s waar mijn vanilla JS moeiteloos doorliep – vooral op mobiel was het verschil absurd groot.
PC; 0.6s vs 0.98s renderduur
Smartphone: (1.2s vs 3.8s). (cijfers zijn even losjes uit geheugen, maar het was ongeveer zoiets)
4 ) Low maintenence. Mijn maatwerkprojecten draaien als een zonnetje – onderhoud is zelden nodig.
5 ) Ik heb een hekel aan werken met Python, dus no harsh feelings towards Django I guess.

In het minder kort wat ik dan wél gebruik:

Nou, dus, terug naar wat ik gebruik;
Ik gebruik vanilla JS, vanilla CSS (Geen onnodige interpreters zoals SCSS of LESS, die steeds minder relevant zijn nu CSS zelf variables en nesting ondersteunt.), HTML, PHP en NodeJS. Ook heb ik met C# en C gewerkt maar tegenwoordig maak ik "cloud oplossingen". (Bonuspunten voor hippe taal?)
Ik kan van iedere pc en iedere plek op de wereld, binnen enkele minuten hotfixes maken en live knallen zonder speciale tools nodig te hebben, buiten de authenticatie welke ik op mijn beveiligde USB stick bij me draag. Tevens heb ik 20 jaar oude PHP producten welke gewoon moeiteloos (meeste binnen 5 minuten) zijn geüpdatet naar PHP 8.3, helemaal vanaf 4.x en 5.x. Nooit issues mee gehad wegens geen frameworks welke dan compleet instorten.

In de eerste instantie had ik een eigen core library, een soort jQuery met allerlei custom modules (datepickers, datehandlers, tablegenerators, typische gebruiken) maar dan veel minimalistischer en doelgerichter.... Deze heb ik uiteindelijk volledig gedumpt omdat vanilla JS het nu niet meer nodig heeft. De komst van async/await, promises, queryselectors, "closest", observers, 'betrouwbare' properties, classes, scoped variables en scopeless functions heeft vanilla js gewoon 3000 keer beter bruikbaar gemaakt dan het was.

Mijn persoonlijke ervaring:
Als je eenmaal begint met vanilla JS en andere vanilla coding, leer je heel snel de pitfalls en ga je compleet op automatische piloot goed om met de code. De code kent geen geheimen meer voor je en er is ook geen "magic". Je kunt aan een functie precies aflezen wat er gebeurt en maakt dan ook nog weinig bugs mee. De meesten zullen vooral zijn mbt user-interaction icm visuals... of zijn dat glitches? Features, anyone? Anyway;

Probeer het eens!
Veel mensen hun beeld over vanilla JS loopt ook nog enorm achter. Er zijn enorm veel nieuwe functionaliteiten welke je minder afhankelijk maken van frameworks en libraries. Als je er eenmaal een projectje mee doet en je loopt gewoon een paar keer tegen de lamp, ontdek je dat super snel! Pro tip; Gebruik chatGPT om wat vragen te stellen hoe je iets b.v. op kunt lossen en dan ontdek je snel hoeveel vanilla-power javascript eigenlijk heeft.

Tot slot
--- Eigenlijk had ik een heel verslag geschreven, maar besloot 90% te verwijderen. Als je meer wil weten wil ik best met je praten in chat. Als snel groeiend softwareleverancier heb ik intussen meer dan genoeg voorbeelden van concurrentie én oud-werkgevers, over waarom die frameworks toch niet altijd zo handig zijn... muahahaha. All of your users are belong to me now

Mijn eerste vraag aan jou zou dan ook als snel zijn; Waarom zou ik wél dat soort frameworks gebruiken?

Important note: Ik gebruik wél complexere libraries, zoals voor PDF generatie of voor zaken waar ik zelf niet zoveel van begrijp, zoals een canvas om op te tekenen en noem het maar op. Het is niet zo dat ik ieder wiel opnieuw uit ga vinden

[martijnvanegdom]

Super nuttig reactie! Ik ben het op heel veel punten helemaal met je eens. vanilla Javascript is echt krachtig. En zeker beter geworden de laatste jaren met beter browser support. En voor heel veel dingen heb je geen library nodig. En ik heb heel wat front-end ontwikkelaars gezien die even snel een library er in knallen en een jaar later is de boel weer stuk. En voor kleine(re) projecten werkt vanilla Javascript prima.

Echter mijn ervaring dat als de projecten een stuk groter worden of als je oudere browser moet ondersteunen (wat in enterprise omgevingen nog weleens het geval is) dat je dan toch aanloopt tegen de grenzen van de javascript. En dat met name van het makkelijk herbruikbaar maken van component. Ja we hebben 'web components' en zelfs dat is toch nog een beetje archaïsch..

En eigenlijk is dat de reden dat React gebruik, voor mij bied react precies dat: het snel kunnen hergebruiken van componenten. En verder geld dat ook ik zo weinig externe libraries wil hebben. Overigens dat probleem wat jij had met React dat heb nog nooit gezien.. terwijl ik ondertussen heel wat projecten in react heb gezien.

En voor PDF generatie of dat soort dingen, dan kies in er vaak voor omdat in een web-api te wrapper of om een wrapper om te library te bouwen en de interface tussen mijn code en de library zo klein mogelijk te houden.

[CapnCrinkle]

Haha, had eigenlijk niet zo'n positieve reactie verwacht. De meeste developers zweren bij wat ze kennen en zijn al snel toxic als jij niet alles vind wat zij ook vinden. Zie bijvoorbeeld **Klikt allereerste reddit link over vanilla JS vs framework aan" deze reddit post. Alle downvoted comments zeggen dat vanilla JS prima is voor een klein in-house projectje, en die zijn al enorm in de minderheid...

Echter mijn ervaring dat als de projecten een stuk groter worden of als je oudere browser moet ondersteunen (wat in enterprise omgevingen nog weleens het geval is)

Daar was ik het vroeger volledig mee eens — ik heb frameworks ook niet altijd links laten liggen. Maar inmiddels voel ik me daar anders over.
Ik lever momenteel een groot internationaal softwarepakket voor infrastructuurbeheer, en de realiteit is dat klanten tegenwoordig gewoon vragen: "Wat hebben we ervoor nodig?"
Mijn antwoord: een moderne browser.
Vaak zijn ze hier al blij mee, omdat ze geen complexe oplossingen hoeven te implementeren.

Moderne browsers zijn tegenwoordig allemaal evergreen, en vrijwel al mijn klanten — zelfs degenen die voorheen nog met doordrukbonnen werkten — zijn inmiddels overgestapt naar Windows 11 met een complete Office 365-omgeving of gebruiken Macs.

Daarnaast is het simpelweg een feit dat bedrijven vaak niet meer verzekerd zijn voor datalekken als ze niet up-to-date zijn. Dat is een extra motivatie om alles netjes op orde te houden, en daar zie ik in de praktijk ook steeds minder weerstand tegen.

Ik werk al jaren samen met een Europese enterprise-organisatie aan een volledig vanilla JS-gebaseerd systeem — zonder frameworks, zonder problemen. Sterker nog, we zijn de competitie er kei hard uit aan het werken omdat wij ver (extreem ver) onder hun laagst mogelijke prijzen zitten. Dit is voornamelijk te danken aan lage draaikosten en weinig tot geen onderhoud op wat al staat.

En eigenlijk is dat de reden dat React gebruik, voor mij bied react precies dat: het snel kunnen hergebruiken van componenten.

Klopt helemaal — dat is precies het sterke punt van React.
Maar de reden dat ik ervoor kies om géén gebruik te maken van React is omdat ik simpelweg niet wil dat mijn complete product continu afhankelijk is van React-versies en compatibiliteit. Een product als de mijne updaten met allerlei van dat soort framework updates en plugins zou dagen als niet weken kosten, tegenover nu minuten.
Ik wil niet dat ik bij elk nieuw component moet kijken of het nog werkt met de huidige versie, of dat ik het hele project moet updaten omdat iets in de API is veranderd.

Wat componenten betreft: mijn product zit er vol mee.
Ik kan in een paar minuten een component bouwen dat de klant toelaat snel te schakelen tussen verschillende kalendertypes met vergelijkbare functionaliteit.

Zelf hanteer ik een werkwijze die ik "subject-based programming" noem — het lijkt sterk op component-based development, maar met een nadrukkelijkere koppeling tussen visuele UI-onderdelen en het functionele onderwerp.
Dat maakt het super makkelijk om elementen in de interface te linken aan de onderliggende code, wat de maintainability enorm verhoogt.

Overigens dat probleem wat jij had met React dat heb nog nooit gezien

Snap ik! Het ging in mijn geval om echt extreem grote tabellen en performance benchmarks. Een vrij unieke situatie — dit speelde ook al wat langer geleden. Tegenwoordig zijn dat soort tabellen veel makkelijker te managen en zijn er ook aardige componenten voor om de performance te verbeteren.

dan kies in er vaak voor omdat in een web-api te wrapper of om een wrapper om te library te bouwen en de interface tussen mijn code en de library zo klein mogelijk te houden.

Exact wat ik ook doe. 😄
Kernfunctionaliteit in een dunne wrapper, zodat ik volledige controle hou over m’n eigen codebase en eventuele upgrades makkelijk af te vangen zijn.

Gezien hoe jij praat, denk ik dat je met een beetje experimenteren en eventueel wat hulp van ChatGPT, binnen no-time je eigen vanilla component-structuur zou kunnen opzetten.
En waarschijnlijk zou je merken dat het je verrassend weinig moeite kost. Ik had het zelf al-doende binnen een half uurtje uitgevogeld (maar ik programmeer dan ook al aardige tijd in vanilla)

Maar goed — er is werk zat voor React developers, en React an sich is zeker geen slechte keuze.
Alleen: ik ga geen enterprise software bouwen met een framework waarvan ik:

• geen enkele controle heb over toekomstige richtingen,
• afhankelijk ben van externe partijen,
• en updates kan krijgen die potentieel breaking zijn, waarvoor ik dan hele stacks moet updaten met hele dependency lijsten

Mijn gedachtegang, ironisch genoeg compleet het tegengestelde van wat heel veel mensen zeggen, is dus juist:
Op enterprise-niveau is controle en stabiliteit essentieel, en daar past vanilla gewoon veel beter bij dan een third-party framework.

Ik weet dat heel veel mensen bij bedrijven aan een enterprise software werken als één van 20.000 developers en daar hun mening op hebben gebaseerd, maar ik vraag me af hoeveel van die mensen daadwerkelijk een moderne vanilla applicatie hebben gezien. Ik heb zelf hoge functies gehad bij dit soort bedrijven en de meeste developers daar hebben überhaupt nooit vanilla gewerkt en hadden vaak niet eens door dat bepaalde functies welke ze gebruikten gewoon native JS waren, en niet van een framework. Leukste daarvan vond ik zelf altijd de arrow functions () => {}, waarvan ze oprecht dachten dat deze van het framework kwamen.

Er zijn al meerdere kleinschalige studies geweest waaruit is gebleken dat frameworks dus helemaal geen tijd of geld besparen, maar mogelijk zelfs méér kosten dan maatwerk. Enige nadeel is dat dit allemaal heel moeilijk is om echt uit te meten (al helemaal aangezien niemand exact hetzelfde gaat doen op 2 verschillende manieren).

[Reactie gewijzigd door CapnCrinkle op 22 april 2025 00:17]

[martijnvanegdom]

Haha, had eigenlijk niet zo'n positieve reactie verwacht.
De meeste developers zweren bij wat ze kennen en zijn al snel toxic als jij niet alles vind wat zij ook vinden.

In mijn ogen is dat een beetje dom ;-) Het is altijd heel aardig om eens te luisteren naar andere meningen en naar de redenatie er achter. Dat is veel leerzamer dan iemand nodeloos proberen te overtuigen van je gelijk. Natuurlijk moet je als je in een project samenwerkt op een bepaald moment een beslissing maken.. maar dat zijn we hier niet.. dus geen reden om elkaar 'in de haren te vliegen' omdat we anders denken.

Op enterprise-niveau is controle en stabiliteit essentieel

...

Alleen: ik ga geen enterprise software bouwen met een framework waarvan ik:
geen enkele controle heb over toekomstige richtingen,
afhankelijk ben van externe partijen,
en updates kan krijgen die potentieel breaking zijn, waarvoor ik dan hele stacks moet updaten met hele dependency lijsten

Ook helemaal mee eens. En dus als je iets van een third-party gaat gebruiken, of dat nu een programmeer taal is of een library, of zelfs een operating system is, of wat anders, dan kijk je naar de stabiliteit op de lange termijn van wat je wil gebruiken.

En in beleving voldoet React dan wel aan de criteria. React word door zoveel grote organisaties gebruikt in zulke grote omgevingen gebruikt (Netflix, Cloudflare, Facebook, Reddit - slechts een paar voorbeelden) dan zelfs als morgen Facebook besluit te stoppen met React, of de boel echt helemaal om te gooien, dat zijn er genoeg die belang hebben bij een fork als de stabiliteit in gevaar komt.

Alleen.. uiteindelijk heb je hierin geen keuze.. je bent ergens afhankelijk van een third-party. Of dit nu je framework is (mompelt iets over AngularJS en Angular) of programmeertaal is (mompelt iets over Python 2 en 3 comptabiliteit) of je operating system is (iets over een relletje met RedHad en CentOS) je bent ergens van afhankelijk. En hoe je dat managed is uiteindelijk denk ik de echte kunst van het vak.

binnen no-time je eigen vanilla component-structuur zou kunnen opzetten.
En waarschijnlijk zou je merken dat het je verrassend weinig moeite kost.

Ik ga zeker eens opnieuw kijken en ik ben zeker opnieuw nieuwsgierig. Want met alle verbeteringen in vanilla Javascript van de afgelopen jaren zag ik al steeds minder reden voor frameworks als React..

[CapnCrinkle]

In mijn ogen is dat een beetje dom ;-)

En in beleving voldoet React dan wel aan de criteria.

Is ook gewoon zo. Dat is niet eens echt een beleving denk ik. Gewoon compleet objectief is React één van de meest stabiele, moderne, nuttige frameworks die ooit omhoog is gekomen. Het is niet voor niets dat deze Angular en een paar anderen erg snel uit heeft gespeeld.

je bent ergens afhankelijk van een third-party

100%. Ik probeer het wel te spreiden, zodat als er één uitvalt, het ander nog werkt. Zo heb ik onze mail en telefoon bijvoorbeeld losgerukt van de product-servers en ook bij compleet andere partijen, zodat als er een storing is en de telefoon, het product óf de mail valt weg, er nog 2 alternatieven zijn. Alles bij één partij vind ik sowieso gevaarlijk. Iets als React zie ik dan wel als "alles bij één partij". Je hebt natuurlijk wel gelijk over forks, maar die verliezen wel vaak het vertrouwen bij de wat meer 'officiële instanties'. En let's be honest; Hoe vaak heeft React nu al in het developernieuws gestaan omdat er weer een malafide package tussen de modules zat?

Mijn laatste argument tegen 'magnetronmaaltijden':
Ik verwacht binnen enkele jaren een bezoekje van de EU of regering of wie daarvan ook aan komt kloppen, waarin ze haarfijn gaan uitpluizen welke tools ik allemaal gebruik, welke afhankelijkheden ik heb en waar de data naartoe gaat. Tenslotte staat er enorm veel informatie mbt nationale veiligheid in mijn product. Ergens dus ook wel lekker als je straight out of the box kunt zeggen; Oh, die Amerikaanse pakketten gebruiken wij niet. (Vooral nu...)

[Bux666]

Sterker nog, we zijn de competitie er kei hard uit aan het werken omdat wij ver (extreem ver) onder hun laagst mogelijke prijzen zitten. Dit is voornamelijk te danken aan lage draaikosten en weinig tot geen onderhoud op wat al staat.

Ik lees met interesse deze draad mee. Over jouw stukje hierboven: dat heb ik zelf nooit goed begrepen: waarom zou je een webapplicatie altijd naar de laatste versie van alles willen hebben? Ja...beveiligingszaken maar ik heb klanten die nog een oeroude versie van Laravel draaien en prima. 'Never touch a running system.'. Die ga ik echt niet bijwerken naar 12.x nu. En dus heb ik al die kosten ook niet...
Daarom gaat de ballon 'lage draaikosten en weinig tot geen onderhoud' bij mij niet op.

[CapnCrinkle]

[...]

Ik lees met interesse deze draad mee. Over jouw stukje hierboven: dat heb ik zelf nooit goed begrepen: waarom zou je een webapplicatie altijd naar de laatste versie van alles willen hebben? Ja...beveiligingszaken maar ik heb klanten die nog een oeroude versie van Laravel draaien en prima. 'Never touch a running system.'. Die ga ik echt niet bijwerken naar 12.x nu. En dus heb ik al die kosten ook niet...
Daarom gaat de ballon 'lage draaikosten en weinig tot geen onderhoud' bij mij niet op.

Sterk punt — en het is inderdaad tweezijdig. Wat ik nu zeg is dus deels een tegenspraak:
Waarom wij wél altijd updaten
In ons geval gaat het om evoluerende enterprise-level producten. We ontwikkelen continu door: nieuwe features, herschreven componenten, verbeteringen. Voor ons is het dus de norm dat applicaties constant up-to-date blijven.

We hechten bovendien veel waarde aan het werken met moderne technieken. Dat stelt ons in staat om onze infrastructuur uniform te houden: servers, pakketten, versies, configuraties — alles gestroomlijnd.
Het resultaat: nagenoeg geen overhead qua systeembeheer.

Praktijkvoorbeeld: servermigratie onder druk:
Een paar jaar geleden ging een van onze serverleveranciers failliet. De melding kwam véél te laat: we zouden binnen een week automatisch overgezet worden naar een andere partij — midden op de werkdag, terwijl onze software 24/7 cruciaal draait.

We hebben de overstap naar een andere provider direct zelf in gang gezet én de situatie benut om onze volledige stack te updaten: OS, database, PHP-versies, alles. Mijn lead developer en ik hebben dat binnen 12 uur gerealiseerd (terwijl ik zelf overigens strontziek was, dus dat met veel pauzes tussendoor).

Ter vergelijking: een ex-werkgever van mij, die bij dezelfde partij zat, had een extreem gefragmenteerde codebase — verschillende versies, stacks, afhankelijkheden. Gevolg:

• 8 klanten raakten data kwijt.
• Websites lagen wekenlang plat.
• Voor sommige klanten moesten nieuwe sites worden gebouwd, tegen verlies, omdat upgraden meer zou kosten dan opnieuw beginnen.

Ironisch genoeg: de projecten die ik daar destijds had opgezet, zijn probleemloos gemigreerd.

(Terzijde: voor PHP 5.x zijn officiële packages tegenwoordig niet eens meer makkelijk te installeren.)
-- Einde voorbeeldsituatie

Doordat al onze producten dezelfde featureset en werkwijze delen, kunnen we elk project met één enkele fix updaten. Een visuele bug, een security-update, of een wijziging door een browserupdate: het maakt niet uit. Eén fix, en al onze producten worden (wel los, maar snel) gepatcht — meestal binnen een half uur. Langer is een uitzondering.
En dat is niet alleen efficiënt. Het voorkomt ook dat onze developers diep in specifieke legacy-code moeten duiken. Iedereen kan overal in werken dankzij de consistente structuur. Het voorkomt alle "maar ik ben daar niet bekend mee" situaties, want iedereen werkt hetzelfde. Daarnaast kunnen wij continu features van product A meenemen naar product B en weten we exact wat de consequenties ervan zullen zijn voor we het überhaupt doen.

Onze keuze voor vanilla JavaScript helpt daar enorm bij. We hebben nooit hoeven migreren van jQuery naar React, Angular of iets anders. Onze code is lean en helder. Veel concurrenten zitten intussen vast in verouderde libraries of frameworks, waardoor updates duur en pijnlijk zijn — of simpelweg uitblijven. En dat zie je terug in hun product. Dat kost klanten.

Praktijkvoorbeeld: wat ‘vastzitten’ echt betekent:
Een van onze concurrenten kan nog steeds geen urenboekingen over 00:00 heen verwerken. Nachtploegen moeten handmatig worden gesplitst. Toen een klant vroeg of dit opgelost kon worden, was het antwoord:
"Dat kunnen we niet — dat zit te diep in het systeem."

Dat is ons nog nooit overkomen. Alles in onze producten is aanpasbaar.
Geen technische schuld, geen verborgen magie, geen backward compatibility hacks.
Onze codebase is 100% helder en up-to-date.
En dat laatste gezegd te hebben; Ons grootste product, heeft een codebase welke volgens mij kleiner is dan React JS op zichzelf... Intussen misschien net iets groter.
---------------------------------
Maar... ‘Never touch a running system’ is óók waar
En toch ben ik het ook volledig met je eens:
We hebben projecten die al jaren stabiel draaien en nooit meer worden aangeraakt. Vooral maatwerkproducten die we niet meer actief onderhouden.
Maar zelfs díé producten ontkwamen niet aan een paar noodzakelijke upgrades. Denk aan de overgang van PHP 4.x of 5.x naar 8.3. In onze eigen producten was dat letterlijk 5 minuten werk — warnings, wat deprecations fixen, en door.

Bij projecten die gebouwd zijn op zware frameworks? Een nachtmerrie. Wat bij ons een upgrade is van een paar minuten, kan daar weken duren of onmogelijk zijn.

Moraal van het verhaal:
Je kunt een draaiend systeem lang met rust laten, maar op een gegeven moment komt er altijd een moment waarop je tóch moet upgraden. Alleen al vanwege zero-days of technische afhankelijkheden die gewoon verdwijnen.
De producten welke ik maak zijn bedoeld om nog zeker 20, als niet 50 jaar een rol te hebben in onze samenleving. Het zijn geen producten met een "houdbaar t/m" datum.

[Reactie gewijzigd door CapnCrinkle op 22 april 2025 17:36]

[Andy1562]

Ben het met u eens vooral wanneer het aankomt tot react, de lightweight coole maar overbodige reconciliatie waardoor je steeds useMemo moet gebruiken die “eigenlijk” niet zo goed werkt. Hoewel we nu react19 hebben. Is er ook een crisis ontstaan waar en wat je met je code doet. De blending van fte bke is misselijk en amper te lezen. Hoewel ik toch zeer verrast van van frameworks zoals svelte(kit) en htmx die prima draaien

[Sponge]

Alsof ik in een spiegel kijk! Ik gebruik ook gewoon bijna puur vanilla javascript voor alles, en maak zelf dan een paar eenvoudige wrapper functies voor GetElementById e.d - puur om het wat compacter te krijgen. Ik ben zelf ook afgeknapt op alle build tools (gulp, grunt, webpack, ...). en alle NPM packages die je nodig hebt voor de zelfs meest eenvoudige sites.

Ik zie ook vaak (tsja, toch jongere) programmeurs die alleen maar met functies en ChatGPT alles kunnen oplossen (maar daardoor zelf geen probleemoplossend vermogen ontwikkelen). Dus doen van alles met bijvoorbeeld een SQL gebaseerde database. Maar ze kunnen letterlijk geen regel SQL schrijven...

Volgens mij heb ik het al eerder genoemd maar ontwikkelaars zijn wat 'verwend' geraakt met een overvloed aan bandbreedte/geheugen/opslag/Ghz. Uiteraard is er iets zoals te vroeg beginnen met optimalisaties, maar de hoeveelheid onnodige MB's die de lijn overgaan (of CPU cycles die 'verbrand' worden) is tegenwoordig echt wel erg wat mij betreft.

[Nark0tiX]

Lekker kort door de bocht, leuk voor kleine applicaties misschien. Maar ik zal geen boekhoud pakket met vanilla js in elkaar hacken. React crasht? Wat een onzin allemaal. Klinkt meer als gebrek aan skills.

[Coolstart]

Ik, persoonlijk, ben een echte maatwerkprogrammeur en vermijd frameworks zoals Django, Magento, Wordpress, React, Angular etc als de ziekte en moet bekennen dat ik me ook niet enorm herken in de bovengenoemde problematiek. Mogelijk omdat ik gewoon altijd al heb gecodeerd op de manier die frameworks proberen te verbergen om het rendabel te maken voor de slechtste developers onder ons. (Hoop dat dit laatste zinnetje geen flamewars gaat veroorzaken, maar feit is dat frameworks een manier zijn om te zorgen voor "idiot proofing")

Wordpress en Magento zijn beide een CMS, eerder backend dus. Je kan dan React.js gebruiken in combinatie in de front-end. (Headless) Dus ik begrijp uw reactie niet helemaal.

Angular en React.js zijn idd frameworks ik zie niet echt nadelen. Wat jij dan doet is uw eigen ‘framework’ bouwen in javascript? Je zou ook node.js kunnen vermijden door uw eigen backend tools te bouwen. Maar dat is toch enkel maar extra werk? Of enkel toepasbaar voor kleine projectjes die 0,01% van de Wordpress of Magento features gebruiken?

Los van dat, Wat Figma van plan is, is waarschijnlijk een concurrent op Angular en React. Dus visualiseren en connecteren met data uit een API. Dan gaan ze sowieso moeten samenwerken met headless CMS systemen. Want waar ga je bijv uw producten inladen? (Cms)

Of ze zouden de concurrentie aangaan met services die zonder CMS werken. Gewoon alles zelf inladen zoals Unbounce. Die worden gebruikt om snelle ‘no code’ landingpagina’s te bouwen. Ook daar kan je als maatwerk-coder niet tegen concurreren.

Misschien begrijp ik je verkeerd, reageer maar als dat zo is

[Reactie gewijzigd door Coolstart op 21 april 2025 22:14]

[stefanhendriks]

Voor een hoop dingen in websites hoef je geen js framework te gebruiken. Vroegah deden we het ook met jquery of vanilla. Tegenwoordig is vanilla js nog beter. En je hoeft ook niet een SPA te bouwen.

[Coolstart]

Om je te begrijpen: Je bedoelt dat gewoon een html/css website voldoende is? Hard coded, geen CMS?

In dat geval, ja dat is zo. Plain simple, super snel. Heb ook nog zo websites gebouwd. Zeeer snelle laadtijden Maar dat doe je toch enkel voor zeer kleine (eigen) projecten waar een CMS overkill is? Lokaal draaien en pushen.

[stefanhendriks]

ik bedoel de website, of er een CMS achter zit is nog daar aan toe. Maar ook een CMS hoeft niet super ingewikkeld te worden gemaakt. Al kun je off-the-shelf CMS'n gebruiken natuurlijk.

Bedoel meer te zeggen dat niets 'hoeft' . Als je de tech snapt dan zie je ook dat er een hoop fluff is.

En idd je kunt je afvragen of een CMS overkill is als 1x per jaar bijv een wijziging nodig is ;-)

[CapnCrinkle]

Nou, ja en nee.

Wordpress en Magento zijn beide een CMS, eerder backend dus.

WordPress is discutabel — hoewel het technisch een CMS is, vindt er binnen WordPress vaak zóveel maatwerk plaats dat het bijna als framework fungeert.

Magento daarentegen is zonder twijfel wél een framework — en dan ook nog één van de meest complexe en frustrerende die ik ooit heb gebruikt. Het heeft zelfs z’n eigen file extensions bedacht (!), en voelt als een vreemde hybride tussen PHP en iets dat C-achtig probeert te zijn.

Maar even fundamenteel:
Is iets niet een framework zodra je gedwongen wordt om binnen vooraf gedefinieerde structuren en patronen te werken?

Als je afhankelijk bent van bepaalde functies, bepaalde folderstructuren en specifieke methodes om je functionaliteit te bouwen — dan heb je een framework. En op die basis is Magento keihard een framework, of je dat nou zo wil noemen of niet. Je moet er een leertraject voor volgen. Er zijn zelfs certificeringen voor "Magento Specialist". Dat zegt genoeg.

En ja — React is dan “technisch” een library, maar als we zo gaan mierenneuken kan ik elk framework wel een “uitgebreide lib” noemen. In de praktijk functioneert React als een framework: het dwingt je in een bepaalde architectuur, met bepaalde conventies, en daar zit exact mijn kritiek. (Zie mijn kritiek een stukje boven jouw comment, naar iemand anders met de vraag 'waarom')

Je zou ook node.js kunnen vermijden door uw eigen backend tools te bouwen. Maar dat is toch enkel maar extra werk?

Appels en aardappels...
NodeJS noem ik geen framework, maar een runtime.
En dat is precies het verschil: in Node ben je nog steeds vrij om je eigen structuren, libraries en logica te kiezen. Dat is wat het aantrekkelijk maakt. Het legt je niks op. Een framework, daarentegen, doet dat wel.

Angular en React.js zijn idd frameworks ik zie niet echt nadelen.

Alles heeft nadelen.
Natuurlijk hebben ze ook voordelen — maar het feit dat beide bestaan (en dat er nog tientallen andere front-end frameworks in omloop zijn) bewijst al dat geen van beiden een perfecte oplossing is. Het is altijd een trade-off, en die afweging verschilt per project, per team en per context.

Wat jij dan doet is uw eigen ‘framework’ bouwen in javascript?

Mijn hele punt is dat dit niet nodig is
Moderne JavaScript is zó krachtig geworden, dat je vrijwel alles out of the box kunt doen:
async/await, modules, classes, querySelector, observer APIs...
Je hébt geen framework meer nodig. Echt niet. Ik beheer een gigantische superapp zonder framework... Ja, er zit een heel minimalistisch framework in... alleen een lichte loader en module-splitter. Meer niet...

Los van dat, Wat Figma van plan is, is waarschijnlijk een concurrent op Angular en React.

Ben benieuwd! Maar ik zie juist een trend richting minder afhankelijkheid van zware frameworks.
Waar ik wél toekomst in zie: slimme AI-hulpen die het werken met zo’n framework sneller en intuïtiever maken. Dat kan frameworks nieuw leven inblazen — maar ze lossen dan alsnog het onderliggende probleem (complexiteit) niet op.

Misschien begrijp ik je verkeerd, reageer maar als dat zo is

Geen probleem — hopelijk is het nu wat duidelijker!

[Andy1562]

Ik ben het hier ook mee eens alleen praktisch in de job wereld gebeurd het weinig. Heel veel features en de manier van js schrijven is duidelijk vooral als t een kleine mvc is🫨

[Tintel]

frameworks een manier zijn om te zorgen voor "idiot proofing"

Nope. Dat is niet waarvoor frameworks zijn bedacht. Ik vermoed dat je code-generators bedoelt.
Een framework is een set van veel gebruikte 'brokken' software.

[CapnCrinkle]

Dat is incorrect. Een set van veelgebruikte functies is een library, zoals b.v. jQuery was.

Ik bedoelde zeer zeker geen code-generators.

Frameworks zijn bedoeld om:

• Minder ervaren ontwikkelaars binnen veilige perken te houden.
• Complexe details te verbergen achter abstracties.
• Een standaardmanier van werken af te dwingen om wildgroei of slechte code te voorkomen.

Wel kun je het ook van een andere kant bekijken

• Beperk fouten door conventies
• Boilerplate en valkuilen vermijden
• Onboarding wordt makkelijker

Het één sluit het ander niet uit. Wij kunnen in dit geval beiden goed zitten. Het is maar net vanuit welk perspectief je kiest om te kijken.

[Tintel]

Naar mijn idee is een library niets meer dan een manier om een framework aan te bieden.

Minder ervaren ontwikkelaars binnen veilige perken te houden.

Binnen de perken van wat? Elk framework biedt toch de mogelijkheid om een 'uitstapje' te maken [naar bijv. het OS o.i.d.]

Complexe details te verbergen achter abstracties.

Of te wel een standaard implementatie van bijv. een linked list zodat een set van waarden kan worden gemanupileerd.

Een standaardmanier van werken af te dwingen om wildgroei of slechte code te voorkomen.

Hoe dan? Hoe zou een framework dat moeten doen?

Wij kunnen in dit geval beiden goed zitten.

Vermoedelijk....

[CapnCrinkle]

Ik ben eigenlijk niet iemand die graag struikelt over semantiek en terminologie, omdat teveel developers dit teveel doen in mijn ogen, maar het verschil tussen een library en een framework vind ik toch nog wel een hele grote hoor

Een library zoals jQuery biedt handige functies om bijvoorbeeld DOM-elementen te selecteren, animaties toe te voegen of AJAX-verzoeken te doen.
Je blijft zelf bepalen wanneer en hoe je die functies gebruikt.

Een framework zoals Angular of React dwingt een bepaalde manier van werken af.
Je volgt hun structuur voor dingen als routing, componenten, lifecycle hooks, enz.

Dus in het kort:
Library: losse tools, jij hebt de regie (bv. jQuery).
Framework: opgelegd raamwerk, het bepaalt de flow (React)

Elk framework biedt toch de mogelijkheid om een 'uitstapje' te maken

Iets als React houdt een 'virtual DOM' bij. Als jij iets gaat wijzigen dmv een "uitstapje" buiten React, wijkt jouw actieve staat af van de virtuele staat van React.
Vanaf dit moment kunnen er werkelijk de gekste dingen gebeuren bij React, met het complete crashen van je applicatie als gevolg.

Dus, nee. Dat kan niet altijd zomaar

[Tintel]

Het punt is dat de term framework niet is voorbehouden aan web development; Het .NET framework legt niet vast hoe de flow verloopt.

En dat een React zelf bijhoudt wat zijn state is en dat je dat kan wijzigen buiten hem om is toch precies mijn bezwaar tegen de opmerking "het framework beschermt de developer tegen fouten"?
Dat probeert deze te doen maar omdat omdat uitzonderingen nu eenmaal voorkomen, is het nooit 100%.

Dat het niet de bedoeling is, dat klopt wel. Maar het gaat erom dat die 'bescherming' nooit waterdicht is.

Eigenlijk hebben de web-development kits(?) de term framework 'ge-high-jacked' cq. re-purposed.

[Reactie gewijzigd door Tintel op 22 april 2025 17:12]

[AOC]

Homestead zullen de websites nog steeds online staan?

[deadinspace]

Ik ben de laatste tijd erg gecharmeerd van htmx (heel makkelijk html-componenten updaten met server-side gerenderde fragmenten). Het is geen vervanging van je huidige stack, meer een aanvulling.

Het werkt sowieso goed samen met Django, en het schijnt ook prima te combineren met Alpine (met die laatste heb ik zelf weinig ervaring).

[fenrirs]

Ehm, ja, dat bedoelde ik ook (autocorrectie fuckup)

Ik heb her en der intussen een bergje componenten ism django restframework, maar zoiets simpels als dubbele multiselect op basis van een paar database queries was in 4D echt max 5 minuten werk. Nu ben ik toch wat langer zoet….24 jaar later

[Ed Vertijsment]

In het Django ecosystem is het vooral gebrek aan beter naar mijn mening, Django template engine beschouw ik (tot mijn spijt) als abandonware en de Django gemeenschap lijkt htmx aan te grijpen om niets te hoeven doen daar aan (want er kan single page style gerefreshed worden), terwijl het echte probleem (weinig moderne mogelijkheden, waaronder composition) niet opgelost wordt.

Wat @fenrirs beschrijft kunnen moderne tools zoals React (maar ook andere) prima (al dan niet met een drag and drop editor) maar is super lastig te implementeren in Django built in templates.

[deadinspace]

Wat versta je precies onder composition in deze context? (ik ben niet echt een front-ender)

Overigens vind ik de Django template language een beetje matig, dus ik gebruik meestal jinja2. Maar die is niet fundamenteel anders. Wel beter uitgevoerd naar mijn mening.

[Ed Vertijsment]

Composition is wat o.a. react doet, die verschillende “blokjes” (componenten) waarmee je een “toren” (app/pagina) kan maken.

Django implementeert inheritance, je pakt dus een “base” template, en vult later de gaatjes (blocks) in.

Het laatste is een stuk minder flexibel en bied minder voordelen dan composition, om maar iets te noemen: componenten kunnen makkelijker in isolatie gebouwd en getest worden.

Morgen zit ik toevallig in Dublin voor DjangoCon, misschien dat ik overtuigd wordt van htmx, maar ik heb er een hard hoofd in.

[Reactie gewijzigd door Ed Vertijsment op 22 april 2025 11:36]

[theduke1989]

Nu kan je dat met powerApps

[Woodsnaps]

Ik verlang ook echt naar 1826, nog lekker met de paard en wagen over de toekomstige snelwegen…

Ik begrijp zeker wat je bedoeld, maar helaas bestaat onze huidige civilisatie niet zonder voorruitgang.

[fenrirs]

Vooruitgang noem je dat? Het voelt eerder als achteruitgang.

Waar je eerst het comfort van een moderne EV had, mag je nu in hand aangeslingerde auto en een double clutch versnellingsbak rijden.

[Zakaria89]

Frontend dev hier: Met v0.dev ben ik best ver gekomen met het scafollden van een landing pagina voor een klant, waarna ik vervolgens wel wat tijd kwijt was met het fixen van de moeilijkere gedeeltes. Maar het heeft me veel tijd gescheeld, vooral omdat de componenten en bestanden al klaar worden gezet.

[Jermaine]

Maar was het code-wise ook goed te doen?

[Zakaria89]

Zeker, zolang je niet te complexe dingen vraagt kwa layout.

Zo had ik een card grid van 2 rijen, met de eerste rij 2 kolommen en de tweede rij 3 kolommen. Op desktop ging dat prima maar toen het responsive moest worden waarbij de tweede kolom scrollable moest zijn (zo was het deign nu eenmaal) werd het wel wat lastiger.

[cracking cloud]

bolt.new is iets soortgelijks. En lovable.dev (die laatst een cease-and-desist van figma kregen voor het gebruik van de term Dev Mode)

[Reactie gewijzigd door cracking cloud op 22 april 2025 10:59]

[joldemans]

Ik zie de bui alweer hangen. Straks komen er weer mensen naar me toe met de vraag vraagt of ik dit of dit kan fixen/repareren omdat iemand die zich een webdeveloper durft te noemen hier een site mee heeft gebouwd. Maar ach, het is wel lekker uurtjes schrijven altijd

Laats ook nog een "webdveloper" van een jaar of 22 ontmoet, zou een ontwerp voor me gaan maken die ik vervolgens zou gaan bouwen. Bij de vraag of ik dan een PS of Figma oid van hem kreeg, keek ie me aan alsof ie water zag branden. Ohw nee ik ontwerp altijd gelijk in Elementor...

Een jaartje of 10 geleden (ben nu net 40) dacht ik nog wel eens hm, dalijk allemaal die jonge gasten, kennen de nieuwst technieken etc.. dat wordt flinke concurrentie, maar verder dan blokjes stapelen en plugins installeren komen ze tegenwoordig haast niet meer.

[MrMarcie]

"maar verder dan blokjes stapelen en plugins installeren komen ze tegenwoordig haast niet meer. "

Ik zie dat al meer dan 10 jaar met o.a. Wordpress sites (bouw zelf voornamelijk templates voor Joomla). Er zijn maar weinig echte developers die wat kunnen. Komt ook omdat de meeste klanten geen budget willen uitgeven. En de grote bedrijven die weer andere 'gerenommeerde' bedrijven inhuren maken ook vaak bagger. Eigenlijk is het best wel triest wat je allemaal om je heen ziet. Ik ben er dan ook voor grootste gedeelte mee gestopt, ben dat zitten achter een scherm ook wel zat. Ben nu al een jaartje een bus aan het besturen. Gelukkig heb ik niet zoveel geld nodig anders moet je dat zeker niet doen , maar leuk is het zeker wel. Heb weer plezier in mijn werk. En geniet daarnaast van mijn vele vrije tijd. Aanrader als het kan.

PS: Kijk even naar je site, zie daar helemaal onderaan 'code' staan.

[Reactie gewijzigd door MrMarcie op 21 april 2025 19:35]

[cricque]

Ik ben ook gestopt met custom dingen te maken. Dikwijls was mijn prijs te hoog ... Ik heb nu een eigen saas app. En daar kan ik meer dan comfortabel van leven, geen ratrace meer, en qua inkomsten hoger dan ik ging freelancen. Maar als ik mijn klanten dan bekijk dan betalen ze oftewel belachelijk veel voor een "custom" website dat dan gewoon wordpress is of iemand die ze kenden heeft het gemaakt en het is gewoon bagger van het hoogste niveau. En dan willen ze iets van integratie ofzo ... en dan stuur ik API gegevens door en daar stopt het dan ... kan jij dat niet doen .... Maar dat is een dikke nee. Nuja het zal mij worst wezen om het zo te zeggen.

Ik geef ook nog een cursus in avondschool programmeren in avondschool bijvoorbeeld. Maar daar zie ik dikwijls het probleem van dat de basiskennis van alles IT gerelateerd zogoed als nihil is. Netwerk ... of wat is 127.0.0.1 .. een poort ... een service ... nee dat weten we allemaal niet. En dan hebben we het nog niet over een reverse proxy ofzo. Command line ... watte ? Owja dat archaïsch gedoe, waarom kan ik niet klikken.

Alle tools zijn mooi, maar als het er dan op aan komt ... ow ja maar dat kan niet hoor, daar bestaat geen plugin voor. Of kan je geen plugin maken voor Wordpress ... want verder dan een file aanpassen en wat klikken lukt dus niet.

Ik moet wel zeggen ben nu 45 en werk al sinds eind jaren 80 met een computer. Ik gebruik sinds eind jaren 90 linux en ken wel wat van alles om het zo te zeggen. En dat kan een plus zijn. Ik heb genoeg collega's gehad die slechts 1 ding kennen of met moeite 2 dingen. Ieder zijn ding uiteraard. Maar bij velen gaat het gewoon om het loonstrookje. Ik zeg niet dat je daarvoor alles moet weten. Maar iets buiten taal x of framework Y kennen is toch altijd handig. Onlangs vertelde een ex student me dat op zijn werkplek niemand een query kan schrijven. Ze gebruiken altijd een orm ... Tsja het werkt en dat is alles wat je daar kan van zeggen.

Als ik de hele dag hetzelfde zou doen, zou ik gek worden. Ik gebruik python, go, node, react & gewoon vanilla javascript. En nu gaan we eens iets maken met rust, gewoon puur uit interesse. En ik heb vroeger ook nog wel eens C/C++, VB, Delphi, assembler, .NET gedaan en nog een hele hoop andere dingen. Ik vind dingen bouwen gewoon leuk en programmeren is voor mij zoals met Lego spelen. Enja er komt veel bij kijken, maar zonder enige basiskennis is het onmogelijk om de dag van vandaag iets deftig alleen op poten te zetten. Ja er zijn tutorials genoeg, maar ga jij maar eens effe iets op AWS zetten (of ergens anders) en dan alles toetimmeren etc zonder dat je enige kennis hebt buiten programmeertaal x.

[Zorg]

Zeer interessante discussie van ervaren (web)developers waarbij voldoende argumentatie wordt gegeven waarom het niet aan te raden is. Zeker in complexe bedrijfsomgevingen. Maar ligt dit misschien ook niet aan maturiteit?

Hoe ik het zie zijn LLMs op dit moment een toevoeging voor die die het niet kennen. Geen concurrent voor zij die het heel goed beheersen. Ook ik ga al eventjes mee in de computerwereld maar professioneel nooit in de dev hoek terecht gekomen. Ik kan vrijwel alle code wel lezen en begrijpen wat er gebeurd maar zou zelf nooit van scratch iets kunnen beginnen. Voor mij, met noden die dus niet hoeven te draaien in een corporate omgeving, werkt het wel degelijk. Verre van perfect, moet ook zeker nog wat debuggen maar dat gaat me prima af. Heb afgelopen weekend een webomgeving gebouwd om mijn video's op te laden naar een s3 bucket, displayen op een pagina, tangen van video's, databaseje erachter, user login etc. Prima voor mijn noden. Maar nog belangrijker, dit had ik nooit zonder gpt kunnen bouwen!

En dat binnen een paar jaar (zo oud zijn de LLMs nog niet) van ontwikkeling. Vanuitgaande dat het alleen maar verbeterd zal de code ed dan ook niet op een hoger niveau komen? Kan ik net als @cricque dan ook niet mijn eigen SaaS appje maken? Iets wat ik nooit heb kunnen doen wegens geen/weinig kennis van programmeren? Wellicht komt er nu een era voor de creatievelingen

[cricque]

Iedereen kan een saas app maken, maar het gaat niet alleen maar om wat code produceren. Je moet dit online zetten, je moet dit veilig maken. En dan komt de app uit de mouw ... je gaat wat groeien en dan loop je tegen performance problemen aan door allerhande keuzes die je moest maken. En dan begint het pas echt. Je kan gaan scalen, cachen etc. Maar dan heb je keuzes moeten maken in het begin, die je dus nu tegenhouden. Scalen .. ja dan betaal ik wat meer. Dat kan ook snel oplopen, dus je klanten tevreden en jij heb minder op het einde over. Personeel kost een bak met geld. Uiteraard kan je wel eens een freelancer inhuren, maar dan moet je er eentje vinden die dat ook nog wel wilt doen.

Er is een groot verschil tussen iets maken voor je zelf en iets dat je wilt verkopen. Je zal ook op een gegeven moment moeten denken aan automatisaties bijvoorbeeld. Hoe ga je een signup laten doen ? Ga je dat door de klant zelf doen of ga jij dat zelf doen. Voor welke "tenant" structuur ga je gaan ? Alles in 1 db, iedereen een verschillende db. Je zal ook wat moeten denken aan security en betalingen

En er komt heus nog wel wat bij een saas appje kijken ... het is niet dat je klanten aantal zomaar gaat groeien. Je zal ook moeten "verkopen" en je toonbaar maken, documentatie schrijven, video's, webinars etc. Er is altijd wel support dat je moet geven. Je prijs bepalen, facturatie, boekhouding etc. Ga je ook een trial bouwen of niet ? Want dat is dan ook weer complexer en wat gaat je dat kosten als maandelijks 3-4 (of een pak meer klanten) je applicatie gaan gebruiken. Want jij draagt de kosten en het brengt niks op. Omgaan met klanten, en zo zijn er nog heel veel dingen. Er zijn veel mensen die hier dus tegenop kijken.

En stel dat je iets kan maken na je gewone uren op een gegeven moment komt er een kantelpunt. Ga je voor de app, of ga je voor de zekerheid. Als je voor de app gaat, dan moet je ook kijken als je hiermee je levensstijl kan aanhouden (bijvoorbeeld je moet je huis afbetalen etc). Dit is uiteraard als je gestaag gaat groeien. Als je van 1 naar 1000 klanten gaat op een week is het helemaal anders uiteraard, maar dat zal niet zomaar gebeuren. Je kan ook investeerders zoeken, maar dan ben je een deel van je bedrijf kwijt.

Ook kan je nog te maken krijgen met wetgeving afhankelijk van je domein maar zowieso moet je ook rekening houden met gdpr. Licenties is nog zoiets... het is niet omdat het opensource is dat je dit commerciëel mag gaan gebruiken. Dat moet je dus ook allemaal liggen uitpluizen. Er zijn er uiteraard genoeg die daar bewust niet naar kijken. Maar het is wel iets waar je rekening moet mee houden.

Dan is er nog het feit ... jij doet alles zelf (tot op een bepaald punt). Jij bent dus voor alles verantwoordelijk, is er een bug -> jij kan het oplossen. Je systeem gaat offline om godweet ik welke reden of dit nu om 3u in de nacht is of om 14 u op zondagnamiddag tijdens het verjaardagfeestje van je zoon/dochter, jij zal het moeten fixen. Uiteraard kan je dan beter Paas gebruiken ipv gewoon een eigen servertje ergens, maar dat komt aan een (serieuze) kost.

Ook het domein waar je in iets wilt bouwen ... Stel je hebt een super idee voor de volgende todo app ... spijtig genoeg bestaan er zovelen. Het is ook niet dat jij denkt dat dit super is, dat je klanten of mogelijke klanten dit zo gaan bekijken. Iedereen heeft zijn eigen idee en eigen wensen. Er zijn genoeg bedrijven die ook tegen elke klant "ja" zeggen en dan krijg je een wirwar van features die totaal niet logisch zijn, omdat persoon/bedrijf X dit zo wil maar Y doet dat zo. Je zal ook moeten leren "nee" zeggen.


Hier heb ik dus bijlange nog niet alles opgegeven waar je rekening moet mee houden. Het is allemaal zeker mogelijk, maar hier in vlaanderen zegt met dikwijls "bezint eer ge begint". Maar veel van deze dingen houden dus het gros tegen om zelf iets te maken.

[Reactie gewijzigd door cricque op 22 april 2025 09:28]

[Zorg]

Je mistte een beetje de essentie van mijn post ik weet hoe veel er bij komt omdat ik voor meerdere bedrijven iets van SaaS apps heb gemaakt. Dus qua support, productmanagement, standaardisatie & servers weet ik wel een beetje af. Ik doelde ook zeker niet op even simpel een app maken en het geld loopt binnen. Waar ik op doelde is dat het coding aspect minder relevant wordt. En nu op dit moment kan je hobby projects perfect maken zonder één regel code te schrijven welke meer dan goed werken. Ik denk dat de techniek zich verder zal evalueren waarbij het ook de meer complexere taken kan overnemen. Waarbij dus complete programmeerkennis minder relevant gaat worden. Als ik zie wat ik heb gebouwd in een weekendje dat is al zeker op het niveau van een MBO opdracht.... dit gaat alleen maar beter worden waarbij juist de zaken die jij beschrijft belangrijker gaan worden.

[cricque]

Ik vind dat de code toch nog belangrijk blijft hoor, zeker qua optimalisaties. Een standaard orm gebruiken etc is allemaal niet zo moeilijk en dat lukt meestal wel. Maar efficiënt zijn is toch wel iets anders en een dingetje. Zeker als je de rekening zelf mag betalen. Enja je kan altijd wel een trapje hoger en scalen, maar dat zou last resort moeten zijn. Je moet eens gaan kijken naar je eigen code. Bijvoorbeeld in veel frameworks zal de huidige gebruiker bij elke request opgehaald worden. Dat moet je echt wel gaan cachen. Als je daar nog nooit van gehoord hebt, of je hebt niet echt kennis van wat er onderliggend aan het gebeuren is, dan ben je in mijn eigen niet goed bezig. En dan is er ook nog user interface. Wat voor jou logisch lijkt is misschien voor veel gebruikers te ingewikkeld. Ik zeg tegen mijn studenten ook altijd, ga eens een cursus pc voor beginners volgen dan zie je pas waar mensen moeite mee hebben. Maar je hebt voor bepaalde dingen geen uitgebreide programmeerkennis nodig. Maar dat is goed voor een eigen projectje, en dan maakt caching of slimme structuren veel minder uit. Maar als ik mijn applicatie bekijk zonder goede keuzes had ik nu al lang vast gezeten. En als je zoiets door AI zou laten genereren zat ik al lang vast of betaalde ik een veelvoud en had ik er misschien al lang mee gestopt.

Ik vind AI "leuk" voor als ik les aan het geven, omdat dit dus triviale code is. Maar eenmaal het zwaardere werk komt er echt wel zogoed als niks uit. Het enige leuke is om doc strings te schrijven of een klein stukje autocomplete van een lijntje. Het ding waar je wel tijd mee kan besparen is ipv google te openen, gewoon in je editor iets te vragen. Ik ken ook niet elke functie in elk framework dat ik gebruik, maar weet wel +- hoe het heet of wat het moet doen. En daar kan je wel een beetje tijd mee besparen. Maar ik zie het helemaal anders: ik moet nog zo een 17 jaar werken. Op die 17 jaar ga ik niet blijven stilstaan en wil ik nog wel dingen bijleren. Door copy & paste te doen ga je er echt niet slimmer van worden. Dat is trouwens ook iets wat ik uitleg aan mijn studenten. Ik ben niet tegen copy & paste ... maar als je niet weet wat het doet, dan doe je dat niet. Als je het ooit moet fixen, dan ben je gezien. Je moet altijd de code proberen te begrijpen, doe je dat niet, dan ga je achteruit. Je kan er dus wel iets van bijleren. Maar dan moet het ook goede code zijn en dat zie ik soms bij AI toch helemaal niet. Het zal werken en daar stopt het. Kan dat beter worden, misschien, we zullen wel zien.

[joldemans]

Mooi dat je die stap hebt durven/kunnen zetten 👍
Ik heb nog wel plezier in m’n werk, afgelopen 5 jaar ben ik met ACF zelf een soort elementor achtige theme aan het (door)ontwikkelen in combinatie met een wp multisite omgeving. Veel van geleerd programmeer wise.

Thanks voor de melding van m’n site. Gevalletje de bakker eet ook droog brood 😅 inmiddels bezig met wat nieuws, maar dit moet ik wel ff fixen

[Andy1562]

Grappig dat u dit zegt ik had een designer en de stakeholder die hier ook mee aankwam. Die zeiden tegen mij. Hier heb je 5 paginas ( geen mobiele en tablet ) versie, do your thing. Het waren 66 paginas ( 43 dynamisch ). En toen ik vroeg van of de mobiele versie kwam en of ik elementor moesten gebruiken zagen ze water branden.

[Martinspire]

Ik wens ze veel succes.

Voor simpele websites zal het vast kunnen, maar zodra je met iets complexers aan de slag moet of voor hetgeen waar figma toch vooral veel voor gebruikt wordt: diepgaande interactie, zal je toch echt wel wat meer moeten hebben dan wat gegenereerde code, lijkt mij. En dat het werkt, wil nog niet zeggen dat het lekker werkt. Al is die lat de laatste jaren ook niet echt hoog bij de fortune-500 bedrijven...

[SPee]

Er zijn genoeg low-code/no-code tools die gebruikt worden. Daar zal dit ook wel ook op gaan lijken. Dus voor 90% goed genoeg.

[H.Boss]

Ben benieuwd!
Ik gebruik zelf Figma in combinatie met Bolt.new(werkt ook met Claude). Er is een integratie tussen die twee.

Leuk dat ze nu een volledige eigen AI-tool gaan ontwikkelen.

[Andy1562]

Nice een echte integratie of een ondersteunde plugin ? En word hier redux voor gebruikt ? Ik zag dat bolt.new dat graag doet 🫨

[Zorg]

Het er mooi uit laten zien en wat flashy front-end werk kan al met de huidige tools.... vraag om een simpele backend & frontend wil met een user registratie en sqlite database en het is al te moeilijk, tokens verbranden dan snel in bijvoorbeeld bolt als er al een werkende oplossing komt.

Ik vind momenteel github agent icm vs studio en dat werkt (voor mij) toch nog het beste

[MightyFool]

Schandalig hoe ze eerst je designs jatten met AI training die je alleen kunt uitzetten met een opt-out om je vervolgens overbodig te maken. Leuke club.

[Ed Vertijsment]

Volgens mij is de design industrie vooral bezig met vernieuwen (of dat nu fijn is of niet), een ai kijkt af en doet dus niet vernieuwen, of je baan op de tocht staat betwijfel ik?

[Banix]

Het is niet duidelijk wanneer Figma de functies wil introduceren.

Ze hebben hun Config Global conferentie op 7 en 8 mei dus ik verwacht dat ze rond die dagen wel wat officieel gaan aankondigen.

[Svrooij86]

Wat een verschrikkelijke tool....

Designer: Kijk heel de app werkt al.
Developer: ok geef mij maar de css code, nee dan moet je los op elke knopje naar de details gaan.

Om nog maar niet te spreken over het feit dat ze andere bedrijven sommeren om "dev mode" niet meer te gebruiken.

Van mij mag dit onding zo snel mogelijk verdwijnen

[Andy1562]

Grappig. Ik gebruik figma om supersnel een landingspagina te maken en meteen door naar development. Het wordt al gauw complex als ze over gaan naar animaties componenten met variabelen