Le piattaforme runtime iniziano a competere per l'ingresso nella catena di strumenti full-stack

Non appena un progetto inizia a toccare contemporaneamente SSR, attività in background, archiviazione di oggetti e distribuzione in anteprima, lo strumento di creazione rivelerà presto i suoi confini originali. vite dev è responsabile dell’esecuzione della pagina, della restituzione della gestione del framework di test, della distribuzione della CLI per andare online e dell’aggiunta di un livello di collante al livello di adattamento del runtime. All’inizio, questo insieme di cose era tollerabile, ma una volta che il progetto ha separato il debug locale e il runtime di produzione, hanno cominciato a sorgere problemi: poteva essere eseguito localmente, ma l’anteprima non è riuscita; quando la versione dell’adattatore veniva aggiornata, i collegamenti di coda e di archiviazione non erano più compatibili; i comandi erano sempre gli stessi e sapevo già che ogni livello avrebbe potuto avere problemi in modo indipendente.

Il cambiamento più evidente nella catena degli strumenti negli ultimi due anni è che la piattaforma non è più soddisfatta dell '“ultimo passaggio dell’implementazione”. Hanno iniziato ad andare avanti, riunendo lo sviluppo locale, la simulazione runtime, il feedback dei test e il rilascio dei comandi nello stesso collegamento. Con la recente fusione di VoidZero in Cloudflare, ciò che vale davvero la pena guardare non è la notizia dell’acquisizione in sé, ma un segnale più chiaro: le piattaforme runtime stanno iniziando a competere direttamente per l’ingresso nella catena di strumenti full-stack.

Una volta che lo strumento di creazione raggiunge il runtime, il confine della piattaforma si sposta in avanti

Nel senso tradizionale, le responsabilità di uno strumento di compilazione sono molto chiare: leggere il codice sorgente, generare il bundle e consegnarlo al sistema successivo per l’elaborazione. Questa divisione del lavoro non è più sufficiente. Finché l’applicazione dispone di routing lato server, database, code, archiviazione di oggetti e funzioni edge, il completamento della costruzione non significa il completamento della consegna. C’è ancora un’intera sezione della semantica di runtime da allineare.

Il punto in cui questo tipo di progetto può facilmente bloccarsi non è se il bundler sia abbastanza veloce, ma se ciò che è in esecuzione localmente questa volta sia lo stesso runtime impostato online. Finché la risposta sarà no, il ciclo di sviluppo diventerà sempre più pesante. Per colmare questa lacuna, la piattaforma troverà sicuramente un modo per inserire il server di sviluppo nel proprio runtime e fare “scrivere il codice localmente” ed “eseguirlo online” nello stesso modello.

Quindi i cambiamenti che vediamo ora non riguardano più solo il fatto che la piattaforma fornisce un adattatore per un determinato framework, ma a loro volta la CLI della piattaforma, i plug-in di runtime e l’ambiente locale vengono trasformati in modo proattivo in una forma di catena di strumenti con cui gli sviluppatori hanno già familiarità. In questo modo l’ingresso cambia. La piattaforma non attende più la visualizzazione del passaggio deploy. È già entrato nel mercato a partire da dev, build, test e persino il formato della richiesta di errore.

L’agente ha amplificato tutti i piccoli attriti nella catena degli strumenti che potevano essere tollerati.

Quando questa questione viene posta nella fase di sviluppo puramente manuale, il ritmo non è così urgente. Le persone ricorderanno quali comandi devono essere eseguiti più di una volta, quali errori sono solo problemi ambientali e quali adattatori occasionalmente hanno convulsioni. Dopo l’arrivo dell’agente, queste ambiguità diventano sostanzialmente costi.

L’agente aprirà ripetutamente il server di sviluppo, eseguirà nuovamente il test, leggerà gli errori, modificherà il codice e verificherà nuovamente. Comandi incoerenti, registri irregolari e comportamento di runtime incoerente. Questi piccoli problemi precedentemente risolti dall’esperienza diventeranno direttamente un ciclo infinito nel ciclo di esecuzione. Naturalmente, anche la velocità di creazione, la velocità di test e la velocità di lint sono importanti, ma ciò che è più prezioso è se l’intero collegamento ha vincoli unificati: lo stesso insieme di CLI, lo stesso insieme di modelli di configurazione, lo stesso tipo di output di errore e la stessa relazione di mappatura locale e di produzione.

Questo è il motivo per cui lo stato di strumenti come Vite sta cambiando. Originariamente erano solo l’attrezzatura più utile nel livello di costruzione front-end, ma ora sono gradualmente diventati la base predefinita per l’Agente che è più facile da guidare in modo stabile. Veloce, semplice e ampiamente compatibile. Questi vantaggi servivano principalmente all’esperienza di sviluppo, ma ora servono direttamente all’affidabilità dell’esecuzione. Finché la piattaforma collega le sue funzionalità di runtime a questo ciclo predefinito, non solo otterrà un obiettivo di distribuzione, ma tutta una serie di abitudini di generazione e verifica delle applicazioni.

Ciò che è veramente prezioso non è l’allineamento del framework, ma chi elimina il flusso di lavoro predefinito.

Basta guardare i titoli delle notizie, è facile interpretare tali azioni come investimenti ecologici o come una piattaforma che vuole deviare il traffico verso i propri servizi di hosting. I cambiamenti più sensibili nell’ingegneria sono in realtà su un altro livello: una volta che l’impalcatura predefinita del progetto, il runtime locale predefinito, il ciclo di test predefinito e i comandi di rilascio predefiniti ricadono tutti sulla stessa catena di strumenti, l’unità di competizione della piattaforma cambierà da “quale macchina è più economica” a “chi per primo definisce come viene realizzata l’applicazione”.

Questa differenza non è piccola. I prezzi possono essere confrontati orizzontalmente. Una volta che il flusso di lavoro è stato scritto nel magazzino, negli script, nell’IC e nelle abitudini del team, raramente è facile modificarlo. Se la piattaforma può occuparsi solo dell’ultima fase della distribuzione, la soglia di migrazione non è elevata; se la piattaforma ha rilevato l’intero percorso da dev a deploy, la migrazione influenzerà l’ambiente locale, le abitudini di comando, i collegamenti di anteprima, i metodi di debug e gli script di esecuzione dell’agente. Spesso è proprio questo strato a formare realmente la viscosità.

Questa recente ondata di movimenti mette in luce anche un’altra cosa: la catena di strumenti full-stack sta ridefinendo il concetto di “neutrale”. In passato, la neutralità significava piuttosto che era indipendente dal quadro normativo e funzionava su bundle diversi. Oggi i requisiti di neutralità sono più severi. Le funzionalità della piattaforma devono essere collegate, ma la catena di strumenti stessa non può essere trasformata in un protocollo privato della piattaforma. Chiunque riesca a mantenere il livello di astrazione indipendente dal fornitore pur rendendo la propria implementazione l’esperienza predefinita avrà maggiori probabilità di ottenere il turno successivo di bonus di ingresso.

Questo percorso è adatto solo ai team che sono stati frenati dalla complessità della consegna

Non tutti i progetti devono preoccuparsi di questo tipo di contesa all’ingresso. Per i siti statici, i backend di piccole dimensioni o i servizi con un unico modulo di distribuzione, potrebbe non essere dannoso continuare a separare costruzione, test e distribuzione. Quando la scala del progetto è ampia, si presentano rapidamente questi tipi di problemi:

• Le differenze tra lo sviluppo locale e il runtime online hanno iniziato a consumare ripetutamente tempo per la risoluzione dei problemi
• SSR, coda di attività, archiviazione di oggetti e associazione al database vengono visualizzati tutti nello stesso warehouse
• I team si affidano già ad ambienti di anteprima, comandi di scaffolding e modelli CI per la consegna collaborativa
• Gli agenti partecipano alla codifica, alla correzione dei bug e ai test e la stabilità della catena di strumenti inizia a influenzare direttamente l’output.

In questa fase è un po’ tardi per trattare lo strumento di costruzione come un puro componente del livello front-end. Sta già diventando parte del punto di ingresso dell’applicazione, connesso al runtime, al lato di distribuzione e al lato di esecuzione. La fusione di VoidZero e Cloudflare non fa altro che rendere la questione più chiara: il prossimo round di competizione tra piattaforme diventerà sempre più simile a una competizione per il flusso di lavoro predefinito. Chi chiude questa catena nel modo più fluido avrà maggiori possibilità di decidere su quale base si svilupperà per prima l’applicazione.