Esiste una tendenza per i toolkit della GUI multipiattaforma? [chiuso]

Sembra quasi che ci sia una tendenza contro i kit multipiattaforma. Se le persone vogliono scrivere una volta, correre ovunque, tendono ad usare l'HTML - creare un sito web. Le persone usano solo i toolkit della piattaforma quando un aspetto nativo è molto richiesto, ad esempio su iPhone. Quindi, se l'intera ragione per cui ti stai preoccupando con l'app non Web è avere un aspetto nativo, non ha senso usare un kit multipiattaforma.

I toolkit cross-platform non hanno mai funzionato così bene; le piattaforme desktop non sono così simili ed è difficile astrarle davvero. L'aggiunta di telefoni e tablet al mix rende ancora più difficile. Si finisce con un'astrazione molto leaky (vedi link ). Spesso è più facile separare semplicemente il tuo "motore" dall'interfaccia utente e scrivere l'interfaccia utente separatamente per piattaforma.

La tendenza per il Mac ad essere più popolare potrebbe rendere i kit multipiattaforma meno popolari piuttosto che più. Penso che spesso le persone usassero un kit multipiattaforma per controllare in teoria la casella di controllo multipiattaforma piuttosto che ottenere risultati veramente buoni su tutte le piattaforme. Una volta che tieni veramente a più piattaforme ... inizi a vedere come i kit cross-platform hanno aspetti negativi.

Ecco un post sul blog di Alex Payne su quegli aspetti negativi: link

Penso che stia dicendo che molte delle grandi e popolari app multipiattaforma inventano il loro approccio proprio multipiattaforma (Firefox, Chrome, Eclipse, OpenOffice.org sono esempi che vengono in mente). Possedendo il quadro, è possibile eseguire il punch down attraverso l'astrazione quando richiesto. Anche queste app hanno tutte la tendenza ad apparire uguali (e non particolarmente native) su tutte le piattaforme.

Tutto ciò detto, non ho statistiche effettive o altro. Ma ho lavorato molto su GTK +, e ho una certa dimestichezza con le codebase tra cui Firefox, Chrome ed Eclipse. Quindi ho visto le sfide tecniche qui in prima persona.

In effetti, negli ultimi anni c'è stata una tendenza verso un toolkit di interfaccia utente multipiattaforma. Quel toolkit è HTML / CSS / JavaScript.

È ancora più semplice svilupparsi una volta e vederlo correre praticamente identico ovunque.

E sì, gli sviluppi si stanno spostando massicciamente dal desktop al web. Lo vedi tu stesso.

Tendo a utilizzare toolkit multipiattaforma perché hanno un design migliore, non perché sto cercando di essere multipiattaforma. Ad esempio, lavoro su progetti scritti in C ++ indirizzati solo alla piattaforma Windows. Uso win32 o MFC, praticamente le sole opzioni disponibili per il toolkit nativo?

Santo fsck no! Sono praticamente i peggiori cumuli di spazzatura per spaghetti che abbia mai visto! L'accoppiamento diretto del sistema degli eventi con il sistema dei "messaggi" del sistema operativo sottostante è incredibilmente poco intuitivo e privo di espressività necessaria per creare rapidamente programmi di interfaccia utente. Le astrazioni di livello superiore, attualmente fornite solo da toolkit multipiattaforma, sono assolutamente essenziali per l'attività.

Questo è solo un esempio. Potrei tirare avanti e avanti sulla lista delle cose che sono fatte meglio dai toolkit cross-platform. Il fatto è che le interfacce grafiche sono più simili tra loro che distinte. Ad esempio, c'è un po 'di differenza tra un programma di Windows su Windows e uno su Linux. Il tipo di cose che fai quando fai i programmi di interfaccia utente sono quasi sempre le stesse, indipendentemente dal sistema operativo che stai prendendo di mira ... e solo piccole differenze tra architetture come telefono / palm o desktop. Il campo si è semplicemente concentrato su metodologie multipiattaforma perché a) è necessario per molte persone eb) è sempre lo stesso sh! T.

Un argomento contro la produzione di un framework multipiattaforma è che sarà sempre mirato al minimo comune denominatore - i clienti del framework vogliono scrivere codice solo una volta e funzionano "ovunque" supportati. Quindi una fantastica piattaforma hardware assomiglierebbe a qualsiasi altra piattaforma che esegue quel framework, in quanto non è possibile sfruttare le funzionalità specifiche della piattaforma.

Nel corso del tempo, sfortunatamente questo si traduce in strutture che si appoggiano alla loro piattaforma più popolare e che intrattengono insieme il supporto per le altre piattaforme, o semplicemente le interrompono quando il budget / la popolarità si esauriscono.

Un modo per capitalizzare le abilità specifiche della piattaforma è di avere qualcosa come un #if PLATFORM_FEATURE_X di costruire attorno a tutto il codice specifico o controlli equivalenti di runtime che si traducono in codice gonfiato. Questo diventa tedioso abbastanza rapidamente, poiché le varianti della stessa piattaforma necessitano di una gestione specifica. Ad esempio, alcune XBox v1 non avevano un disco rigido, quindi i giochi che utilizzano strumenti multipiattaforma non potevano usarlo per la cache, rispetto a una versione per PC in cui è possibile garantire un disco rigido.

Per le applicazioni desktop / produttive, l'aspetto della piattaforma sembra essere importante, ma molte applicazioni hanno il proprio stile quindi non è un problema avere lo stesso aspetto su tutte le piattaforme, ad es. app create con AIR.

I produttori di hardware come Apple, Sony, Nintendo e Toshiba vorranno assicurarsi che i loro prodotti facciano qualcosa per differenziarsi dalla concorrenza, ad es. Touch, Accelerometri / Gryoscopes, Blu-Ray, display 3D. È improbabile che ci sia mai una piattaforma con tutte le caratteristiche di tutti i concorrenti riunite in una (a causa dei costi e della complessità), quindi si vincerà.