Per creare un'app, la prima domanda non è quale linguaggio vada di moda. È che cosa deve fare il progetto, per chi e su quali dispositivi dovrà funzionare. Nel video parto da questa scelta per spiegare il rapporto tra interfaccia, elaborazione e dati.

Il tema nasce anche dall'interesse per il software che ho pubblicato. Il mio lavoro comprende sviluppo e verifica dei programmi, e vorrei rendere visibile ciò che c'è dietro una schermata apparentemente semplice.

Definire dove e come verrà usata

Un programma personale e un servizio destinato ad altre persone hanno esigenze differenti. Conta sapere se deve funzionare nel browser, sul telefono, su un computer o su un dispositivo con risorse limitate.

Conta anche capire se debba funzionare senza connessione, conservare dati, accedere al microfono o condividere informazioni tra utenti. Queste risposte restringono le scelte tecniche molto più di una classifica dei linguaggi.

Un primo obiettivo piccolo e verificabile permette di esplorare il progetto senza costruire subito ogni funzione immaginata.

Frontend: ciò con cui la persona interagisce

Nell'esempio di applicazione web, il frontend comprende schermate, campi, pulsanti e comportamenti con cui l'utente completa le attività.

Richiamo HTML per la struttura, CSS per la presentazione e JavaScript per l'interazione e l'elaborazione nel browser. Il frontend non è quindi soltanto decorazione: deve mostrare informazioni e rendere comprensibili azioni, attese ed errori.

L'aspetto grafico è una parte dell'esperienza. Servono anche percorsi utilizzabili con diversi dispositivi e modalità di interazione.

Backend e dati: quando servono davvero

Il backend può applicare regole, coordinare accessi e lavorare su dati condivisi. Un database può conservare informazioni che devono essere ritrovate e aggiornate nel tempo.

Non ogni app richiede però un server o un database remoto. Alcuni strumenti possono elaborare dati localmente, e non tutti i database organizzano le informazioni attraverso tabelle relazionali.

La scelta deve seguire i requisiti: quali dati esistono, chi può leggerli, come vengono modificati e che cosa accade se qualcosa fallisce.

API e MVC non sono la stessa cosa

Nel video collego più interfacce a un servizio comune: un sito e un'app mobile possono comunicare con lo stesso backend tramite API definite per quello scopo.

Questo non equivale automaticamente al pattern MVC. Model, View e Controller descrivono una separazione di responsabilità all'interno di un'architettura; la comunicazione tra client e server è un altro piano del progetto.

Un'applicazione può usare entrambi gli approcci, uno solo o soluzioni differenti. Distinguere i concetti evita di scambiare un esempio introduttivo per un'architettura obbligatoria.

Applicazioni native e multipiattaforma

Cito linguaggi come C, C++, Go, Rust e Java, insieme a framework come Flutter. Ognuno offre possibilità e compromessi che dipendono da librerie, piattaforme e progetto.

Non esiste una graduatoria universale di velocità: algoritmo, implementazione e carico possono contare più dell'etichetta del linguaggio. La gestione manuale della memoria non rende automaticamente migliore un programma.

Anche la portabilità richiede attenzione. Compilare per più sistemi può richiedere strumenti e dipendenze specifiche; usare una macchina virtuale non elimina ogni differenza dell'ambiente.

Connessione e tipo di app sono questioni distinte

Nel parlato associo molte app connesse alle web app. È una semplificazione da correggere: un'app nativa può comunicare con servizi remoti e una web app può offrire alcune funzioni offline.

Conviene quindi decidere separatamente dove viene eseguito il programma e quali attività richiedano rete. Così diventa più chiaro che cosa succederà quando la connessione manca.

Per i dati locali, nel video faccio esempi che vanno da un semplice file a SQLite. Non sono opzioni intercambiabili: struttura, concorrenza e recupero degli errori cambiano le esigenze.

Il codice generato non chiude il progetto

Un assistente IA può aiutare a esplorare o scrivere parti del lavoro. Chi sviluppa deve comunque verificare che funzionino insieme, rispettino i requisiti e siano mantenibili.

La pubblicazione richiede inoltre considerare dipendenze, licenze e modalità di distribuzione. La sola scelta di una licenza non risolve automaticamente tutti questi aspetti.

Il percorso che propongo è partire dal problema, costruire una prima funzione completa e provarla nel contesto previsto. La tecnologia viene scelta per sostenere questo percorso, non per sostituirlo.