95 messaggi dal 28 ottobre 2006
Pur "ammirando" quello che si può fare e si potrà fare con HTML5, sinceramente mi sembra una tecnologia molto poco matura. Lo standard non è ancora completo, la compatibilità nella zone di frontiera delle specifiche è a macchia di leopardo, e a parità di risultato la skill minima per creare una certa applicazione è altissima.

Spero in un futuro venga istituito un bollino "HTML5-compliant" per i browser. :)
IMHO quello che "lo standard non è ancora completo" è un problema non problema. In altri casi (tecnologie) dove non esiste uno standard (perché tecnologia proprietaria) va tutto bene? Io non direi proprio...
Sulle competenze richieste invece non concordo; il markup è - volendo - addirittura più semplice di quello di HTML4/XHTML, le API e ECMAScript5 mi sembrano semplici se hai dimestichezza con JavaScript e jQuery...
Veniamo ai vantaggi, dove a mio avviso ce n'è uno su tutti: scrivi la tua applicazione, una sola volta ed in un solo modo e gira su Windows, OSX, Linux, iQualcosa, Android, BlackBerry, WP7, Nokia (pace all'anima sua)... Se vuoi la compatibilità è l'unica soluzione praticabile.
My Two Cents.

Matteo Casati
GURU4.net
Questo articolo (in inglese) mostra 10 buoni motivi per evitare l'uso di plug-in
http://kevinlawry.wordpress.com/2011/03/01/top-10-reasons-web-developers-should-avoid-flash/
PS: sostituendo "Flash" con "Silverlight" o quant'altro il risultato non cambia :-)

Matteo Casati
GURU4.net
95 messaggi dal 28 ottobre 2006
L'argomento è interessante. Provo a spiegare meglio la mia posizione.

Che lo standard non sia ancora completo è chiaro, però concordo ovviamente con l'intenzione di promuoverne l'adozione. Quanto all'adozione, vengono i numeri dolenti, dato che è molto frammentaria e comunque limitata alle ultimissime versioni dei browsers. (non scordiamoci che ancora oggi quasi il 12% di tutti i visitatori internet usa IE6, fonte arstechnica.com). Con i plugin quegli utenti sono raggiungibili.

Per skill non intendevo il markup o lo scripting in generale, mi riferivo ad esempio all' uso performance-oriented del canvas (tipo per giochi con animazioni) o all'uso della cache locale (per le offline webapps).

Dati aggiornati sulla conformità allo standard si trovano un po' ovunque, qua ad esempio c'è una tabella che mostra anche passato e futuro. La macchia di leopardo di cui parlavo in merito alla situazione attuale. http://caniuse.com/#cats=HTML5
Ma la cosa più buffa è che le pagine dedicate a HTML5 da parte dei vari browser-vendor (Apple, Google, MS, Mozilla) spesso funzionano completamente solo nel browser del vendor stesso. Questo perchè sono state sviluppate per uno specifico browser... eppure dovrebbe essere uno standard... :)

Riguardo ai 10 buoni motivi citati sopra il primo commentatore del post dice punto per punto le cose che stavo per scrivere io stesso in questo reply. In generale la mia posizione è che in questo momento le due tecnologie stanno occupando segmenti solo marginalmente comuni.
A quanto pare abbiamo punti di vista differenti, che poi è quello che rende interessante una discussione, no? :-)
Io continuo a pensare che Flash & Co. siano il passato e HTML5 il futuro (almeno per quanta riguarda il Web in senso stretto). Sul presente, come sempre, la ragione sta nel mezzo (diciamo fifty-fifty)

Sono convinto che sia il futuro perché ci sono 3 nomi che stanno spingendo questo standard e sono Microsoft (ovvero la stragrande maggioranza del software, sia domestico che business), Google (che praticamente è sinonimo di Internet oltre che del 50% dei device non PC con il suo Android) e Apple (secondo player per gli OS e da cui dipende l'altra metà di device smart/tablet).

A livello tecnico le limitazioni di HTML5 nella maggior parte degli scenari sono pressoché inesistenti (ed il concorso citato nel post vuole dimostrarlo). Per quanto riguarda lo sviluppo e gli esempi di skill da te citati direi che il canvas non è nulla di sconvolgente per chi ha dimestichezza con oggetti grafici e che le api di caching sono costituite da 3 metodi per gestire le coppie chiave/valore di un dictionary (decisamente più semplice che non scrivere e leggere un cookie!) E la stessa cosa vale per tutte le altre nuove API JS (geolocalizzazione, drag&drop, history, file, messaging/sockets/workers, ecc. La curva di apprendimento è prossima allo zero!)

In merito all'adozione uniforme delle specifiche da parte dei vendors credo sia solo questione di tempo: a nessuno di loro mancano le competenze per adottare gli standard e spesso il mancato supporto a qualche specifica è una scelta più che sensata (ad esempio IE9 non supporta le nuove features dei form perché le specifiche sono ancora palesemente incomplete, mancando ad esempio il supporto per la localizzazione)

L'ultima obiezione è la diffusione dei browser di ultima generazione; anche questo è un problema che, volendo applicare un po' di forza bruta, risolverebbero in pochissimo tempo: come lo vedresti un bel messaggio a caratteri cubitali sulla home di Google che dice "Ehi, con IE6 le ricerche non le puoi fare" (non è uno scenario tanto assurdo, succede così se cerchi di guardare un video su YouTube); lato MS leggevo giusto oggi di questa iniziative perché IE6 riposi finalmente in pace: http://www.ie6countdown.com/

Matteo Casati
GURU4.net
m.casati [Staff] wrote:
Io continuo a pensare che Flash & Co. siano il passato e HTML5 il futuro (almeno per quanta riguarda il Web in senso stretto). Sul presente, come sempre, la ragione sta nel mezzo (diciamo fifty-fifty)

io sono convinto che HTML5 sia ottimo per il web, un massacro per le app che girano nel web, per cui Silverlight o Flash o qualsiasi altra cosa hanno ancora un vantaggio, derivante dal fatto che le "specifiche" sono fissate (e ci credo  ) e che i tool di sviluppo siano più maturi. poi, magari, nel 2014 questo mio messaggio sarà del tutto inutile e ne sarò felice
.

Daniele Bochicchio | ASPItalia.com | Libri
Chief Operating Officer@iCubed
Microsoft Regional Director & MVP
95 messaggi dal 28 ottobre 2006
Certo, fa sempre piacere discorrere di queste cose, avere idee diverse è interessante per vedere le cose da punti di vista diversi. :)

E' vero HTML5 è salito recentemente alla ribalta, perchè particolarmente "spinto" dai tre vendor che hai citato. Però in tutta onestà penso che lo facciano per motivi diversi da quello nobile dello standard aperto. Apple lo fa per giustificare l'assenza di Flash&Co sui suoi device, Google lo fa per spingere sempre di più le sue web apps a soppiantare i vari Office&Co, Microsoft per fermare l'emorragia di utilizzatori di IE (motivazione che tra l'altro fa onore a MS).

La mia posizione è identica a quella di Daniele perchè secondo me le limitazioni pratiche dell'uso di HTML5 sono enormi. Senza stare a scomodare casi semi-politici come il formato video (che non sarà mai definito per HTML5), non si può minimamente paragonare i tool di sviluppo per Flash/Silverlight con quelli per HTML5, ne' lo scenario di test e validazione di una app.

L'adozione uniforme da parte dei browser è qualcosa che auspico fortemente, e un modo per spingere i vendor ad arrivarci è un vero e proprio bollino di cui fregiarsi. Un HTML-5 compliant dato da un ente terzo. Senza il supporto completo, non prendi il bollino.

Comprendo anche la cattiveria verso gli IE6 users :), sappi che sono quasi esclusivamente grandi corporate dove per mantenere l'intranet funzionante, IE6 rimane il browser di default e all'utente NON è permesso upgradarlo. Ti chiederai anche: ma dove prendono ancora IE6? Ebbene, anche questa settimana ho visto arrivare una decina di quad-core, comprati con licenza Windows 7 pro e immediatamente downgradati a XP-SP2.
1 messaggio dal 28 marzo 2011
Salve a tutti, il discorso è molto interessante. Ovviamente allo stato attuale non possiamo che lavorare di intuizione ma è quasi un dovere farlo da parte nostra non fosse altro che per non rischiare di rimanere indietro quando i tempi saranno maturi.
Secondo me questo discorso va a braccetto con un altro tema: come verrà fruito il web nei prossimi anni?
Fino a qualche mese fa ero convinto che la fruizione via browser del web sarebbe stata presto soppiantata dall'uso di app e mobile device e di conseguenza la creaione di applicazioni web per il browser avrebbe ceduto il passo alla creazione di app piu strutturate e complesse in silverlight, objective-c, ecc.. Ora invece sembra che la tendenza si sia invertita anche per i dispositivi mobili e che html5 & co. saranno "sufficienti" a scrivere "browser app" degne di nota. Tecnicamente non so se è possibile con ecmascript interfacciarsi a dispositivi hardware come il gps, il livello, accelerometro, ecc. o se le case produttrici supporteranno gli sviluppatori con delle api ad hoc (sarebbe importante saperlo). Credo che la chiave del successo di html5 & co. sia tutta qui: programmi una browser app una volta (con una tecnologia server side alle spalle, lo metto tra parentese non vorrei che mi si fraintenda) invece di tre volte (android, apple, wp7).
Per quanto riguarda la compatibilità dei browser io nel mio piccolo credo che sia un problema meno grande di quello che si vuol far credere. Un conto è creare dei meccanismi di fall back per quanto riguarda l'aspetto visuale e questo dipende dal limite di compatibilità che ci imponiamo (o che ci impongono i clienti). Il discorso cambia se si sta programmando un'applicazione RIA: es. Oggi se non hai javascript abilitato semplicemente ti avviso che non puoi usare l'applicazione, punto. Se non hai silverlight ti propongo di installartelo ma difficilmente ci riscriviamo l'intera applicazione RIA in asp.net + ajax...

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.