[Vari]Quake 2 in una pagina web

Originariamente inviato da cdimauro

Concettualmente ha ragione: HTML è nato per "descrivere" un insieme di informazioni, dando loro dei significati semantici.

E' con roba come i CSS che s'è cercato di fissare anche la loro resa a video, ma che io sappia non esiste ancora una perfetta corrispondenza fra ciò che viene definito e ciò che viene reso a video.

I CSS sono nati nel 1996, il fatto che ad oggi non si possa, ad esempio, sfruttare appieno le potenzialità di CSS3 dipende del tutto dai motori di rendering dei vari browser.

Diciamo che da questo punto di vista M$ ha le sue gravi colpe con quell'aborto di IE.

In generale, visto che mi occupo di sviluppo web, ritengo che le interfacce web abbiano conosciuto un notevole sviluppo in questi ultimi anni sostituendosi spesso alle più classiche applicazioni desktop.

Questo appunto perchè si è passati in molti casi da N singole applicazioni su computer client ad un'architettura centralizzata con il software che gira su server e poi "in periferia" i vari dumb terminal che accedono alle risorse e alle funzionalità della macchina remota.

Il PC in epoca moderna è chiaramente passato da esser "elaboratore" a "comunicatore" con tutto quello che implica tale tipo di cambiamento.

Poi ovviamente se ho bisogno di utilizzare Photoshop è MOLTO meglio averlo installato in locale, ad oggi sarebbe improponibile un suo equivalente server side.

Per mille altre applicazioni invece il web è sicuramente meglio: tutto ciò che è legato all'editoria, software gestionali, e-commerce, applicazioni "social", Virtual/Personal Learning Environment ecc.

Non esiste un buono ed un cattivo ma un meglio e un peggio a seconda delle necessità.

[cdimauro]

Originariamente inviato da Sgurbat

I CSS sono nati nel 1996, il fatto che ad oggi non si possa, ad esempio, sfruttare appieno le potenzialità di CSS3 dipende del tutto dai motori di rendering dei vari browser.

Diciamo che da questo punto di vista M$ ha le sue gravi colpe con quell'aborto di IE.

Che io sappia IE8 è perfettamente compliant con l'ultima versione dello standard W3C.

Fino a IE7 non lo era. Peggio ancora con IE6. Ma:
- erano altri tempi (parlo di quando è stato commercializzato IE6);
- Microsoft aveva altre priorità (la sicurezza).

Per il resto concordo che bisogna sempre vedere il contesto per scegliere lo strumento adatto (ne avevo accennato qualche messaggio fa).

Originariamente inviato da cdimauro

Che io sappia IE8 è perfettamente compliant con l'ultima versione dello standard W3C.

Fino a IE7 non lo era. Peggio ancora con IE6. Ma:
- erano altri tempi (parlo di quando è stato commercializzato IE6);
- Microsoft aveva altre priorità (la sicurezza).

Per il resto concordo che bisogna sempre vedere il contesto per scegliere lo strumento adatto (ne avevo accennato qualche messaggio fa).

Non ho avuto ancora modo di analizzare nel dettaglio il supporto CSS da parte di IE8, certo mi immagino sicuramente un miglioramento rispetto a IE7 circa il rispetto degli standard W3C.

Uno dei problemi delle applicazioni web "aperte" è appunto che spesso si è costretti a realizzare software che (per la parte di frontend e quindi di interfaccia) devono giocoforza "abbassarsi" allo standard tecnologico inferiore usato (es: IE6).

Che ci si creda o no IE6 è ancora molto usato, in molti ambienti in Italia l'aggiornamento hardware e software è una pura barzelletta.
Nel 2002 quando ho fatto il servizio civile ho scoperto la "gioia" di dover usare Win 3.11

Discorso diverso per applicazioni come gestionali web based interni ad un'azienda dove viene sicuramente più facile e comodo definire uno standard tecnologico più omogeneo ed elevato rispetto al marasma di internet.

[cdimauro]

Originariamente inviato da Sgurbat

Non ho avuto ancora modo di analizzare nel dettaglio il supporto CSS da parte di IE8, certo mi immagino sicuramente un miglioramento rispetto a IE7 circa il rispetto degli standard W3C.

Lo è, lo è.

E considera che saranno un paio d'anni che tutti i browser più famosi sono aderenti all'ultimo standard pubblicato dal W3C.

Quindi anche prima, IE è stato sicuramente la cenerentola perché era messo male, ma gli altri non erano dei cigni perfetti.

Uno dei problemi delle applicazioni web "aperte" è appunto che spesso si è costretti a realizzare software che (per la parte di frontend e quindi di interfaccia) devono giocoforza "abbassarsi" allo standard tecnologico inferiore usato (es: IE6).

Che ci si creda o no IE6 è ancora molto usato, in molti ambienti in Italia l'aggiornamento hardware e software è una pura barzelletta.
Nel 2002 quando ho fatto il servizio civile ho scoperto la "gioia" di dover usare Win 3.11

C'è da dire che l'HTML in teoria sarebbe nato proprio per garantire una miglior fruizione di documenti. Quindi perché non usare un minimo comune denominatore in questi casi? O, al più, code path diversi che coprono la maggioranza del mercato (come si fa coi giochi, in sostanza).

Discorso diverso per applicazioni come gestionali web based interni ad un'azienda dove viene sicuramente più facile e comodo definire uno standard tecnologico più omogeneo ed elevato rispetto al marasma di internet.

Il problema non è soltanto avere lo standard, ma la sua adozione.

Poi ci si mette anche il W3C che è lento da far paura. HTML 5 & annessi sarà pronto soltanto nel 2022 (non, non dev'esserci un 1 al posto del penultimo 2).

[nucarote]

Originariamente inviato da cdimauro

....

Poi ci si mette anche il W3C che è lento da far paura. HTML 5 & annessi sarà pronto soltanto nel 2022 (non, non dev'esserci un 1 al posto del penultimo 2).

Forse anche prima almeno come adozione, visto che Google e Apple pare che vogliano puntare su HTML 5.

[cdimauro]

Il web ha bisogno di standard finalizzati, non di bozze.

Che Google ed Apple adottino quanto di pronto ci sia già adesso, mi pare normale perché riguarda i loro precisi obiettivi, che in questo caso coincidono: far fuori Flash.

Ma non ci sarà da biasimare gli altri browser se non faranno lo stesso, o lo faranno in ritardo. Proprio perché lo standard non è ancora finalizzato.

[nucarote]

Originariamente inviato da cdimauro

Il web ha bisogno di standard finalizzati, non di bozze.

Che Google ed Apple adottino quanto di pronto ci sia già adesso, mi pare normale perché riguarda i loro precisi obiettivi, che in questo caso coincidono: far fuori Flash.

Ma non ci sarà da biasimare gli altri browser se non faranno lo stesso, o lo faranno in ritardo. Proprio perché lo standard non è ancora finalizzato.

Concordo, anche se comunque alla fine si finirà col rispettare lo standard de facto che lo standard W3C. Comunque se non mi sbaglio nella stesura di HTML 5 è direttamente coinvolta anche Google, e pertanto faccio "affidamento" sul suo peso politico per finalizzarlo in tempi ragionevoli.

[cdimauro]

Veramente le date sono state già snocciolate. Ecco perché non sono molto ottimista, e pensare che ci vogliano 12 anni per srotolare un documento mi manda in bestia.

[nico159]

il browser è un "renderer" di file di markup, è ovvio che ogni browser lo faccia in modo diverso

E' un ragionamento assurdo

Originariamente inviato da PGI-Bis

Le applicazioni web hanno portato il mondo delle interfacce grafiche utente indietro di 20 anni.

Ebbene, è ora che anche i videogiochi subiscano la medesima sorte!!!

Forza Google! Riportaci nel medioevo!

Grazie Google? Mi pare ipocrisia
Ciò che decreta il successo di qualcosa è quando essa venga accettata dalle persone

Il web ha bisogno di standard finalizzati, non di bozze.

Finalizzati da anni
HTML 4.01 Specification - W3C Recommendation 24 December 1999

XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition)
A Reformulation of HTML 4 in XML 1.0
W3C Recommendation 26 January 2000, revised 1 August 2002

Scalable Vector Graphics (SVG) 1.1 Specification
W3C Recommendation 14 January 2003

Document Object Model (DOM) Level 2 Core Specification
Version 1.0
W3C Recommendation 13 November, 2000

RFC 2068 HTTP/1.1 January 1997


Se invece si parla di html5, css3, lostal storage, web socket...sono ancora in sviluppo, com'è giusto che sia in quanto nuovi e per lo sviluppo web rivoluzionari.
Io trovo che le stime tipo 2022 e così via siano assurde. IE9 già coprirà gran parte di questi futuri standard, così come tutti gli attuali browser lo fanno già in parte. Così come già è possibile oggi tramite accorgimenti giocare ad un videogioco in 3D. Non trovo fantascienza pensare a tra due anni siti in html5

E' con roba come i CSS che s'è cercato di fissare anche la loro resa a video, ma che io sappia non esiste ancora una perfetta corrispondenza fra ciò che viene definito e ciò che viene reso a video.

Perchè no? E' possibile

il solo modo per far rendere a tutti i browser la stessa pagina nello stesso modo è usare un CSS che copra TUTTI gli elementi contenuti nella pagina (X)HTML, e per ogni elemento definisca TUTTI i possibili attributi, avendo l'accortezza di usare i font di default (serif-sans serif) o i font non proprietari che sono presenti su qualsiasi macchina..

Il css reset non è affatto una tecnica necessaria

percui se scrivessi una pagina web con questi font, un visitatore windows/linux vedrebbe qualcosa di diverso da me...

A meno che tu non abbia la licenza per distribuire quel set di font, non vedo di che ti lamenti
Se invece hai dei font liberi/free/di cui hai la possibilità di distribuire, cosa non così comune, tempo al tempo
https://developer.mozilla.org/en/CSS/@font-face

sfruttare appieno le potenzialità di CSS3 dipende del tutto dai motori di rendering dei vari browser.

C'è sempre da considerare la complessità nell'implementare nuovi standard, e sopratutto come questi non siano standard (html5, css3---) ma bozze che vengono aggiornate quasi giornalmente http://html5.org/tools/web-apps-tracker

[lupoxxx87]

rispondo sulle argomentazioni personali...

1. ragionamento assurdo ? se lo fanno programmi come Word, Pages, Openoffice o altri però nessuno dice nulla (non mi sto riferendo ai formati ™, ma a rtf)

1e mezzo. finalizzare uno standard, nel mondo informatico, non coincide con obbligare tutti a seguirli, soprattutto se questi che tu dici "standard" non sono standard veri e propri ma raccomandazioni all'uniformità del linguaggio (ndr..qui da me si usano ancora oncie e pinte, sebbene il SImetrico sia uno standard IMPOSTO da tempo....La cultura è più lenta di quello in cui è immersa... forse quando da internet verranno eliminate a forza tutte le pagine web fuori standard, qualcosa si muoverà)

2. forse il css reset non sarà una tecnica necessaria come dici, ma da quello che ho letto e studiato è il solo modo per obbligare tutti i browser a mostrare quello che tu vuoi e non quello che loro ottimizzano

3. non mi sto lamentando, sto solo dicendo che se faccio un sito sulla mia macchina, non posso essere sicuro che tutti lo vedano allo stesso modo in cui lo vedo io se sto utilizzando font proprietari (cosa che ad esempio iweb fa..) ps. definire uno style css che preveda l'uso di un font proprietario non vuol dire distribuirlo...vuol solo dire che se quello che visita la pagina dispone di quel font la visualizzerà, altrimenti sarà il browser a decidere con il suo font di default

[nico159]

1. ragionamento assurdo ? se lo fanno programmi come Word, Pages, Openoffice o altri però nessuno dice nulla (non mi sto riferendo ai formati ™, ma a rtf)

Perchè in una pagina web viene definita anche la presentazione

1e mezzo. finalizzare uno standard, nel mondo informatico, non coincide con obbligare tutti a seguirli, soprattutto se questi che tu dici "standard" non sono standard veri e propri ma raccomandazioni all'uniformità del linguaggio

Hai ragione, quei documenti sono standard de facto

(ndr..qui da me si usano ancora oncie e pinte, sebbene il SImetrico sia uno standard IMPOSTO da tempo....La cultura è più lenta di quello in cui è immersa... forse quando da internet verranno eliminate a forza tutte le pagine web fuori standard, qualcosa si muoverà)

Tutto è possibile ma è il risultato finale a fare la differenza. Si è costretti a seguire gli standard W3C per creare pagine usufruibili da chiunque

ps. definire uno style css che preveda l'uso di un font proprietario non vuol dire distribuirlo...vuol solo dire che se quello che visita la pagina dispone di quel font la visualizzerà, altrimenti sarà il browser a decidere con il suo font di default

Non hai letto il mio reply

[cdimauro]

Originariamente inviato da nico159

E' un ragionamento assurdo

Eppure l'HTML è nato con quelle finalità: descrivere e non presentare.

Finalizzati da anni
HTML 4.01 Specification - W3C Recommendation 24 December 1999

XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition)
A Reformulation of HTML 4 in XML 1.0
W3C Recommendation 26 January 2000, revised 1 August 2002

Scalable Vector Graphics (SVG) 1.1 Specification
W3C Recommendation 14 January 2003

Document Object Model (DOM) Level 2 Core Specification
Version 1.0
W3C Recommendation 13 November, 2000

RFC 2068 HTTP/1.1 January 1997

Finalizzati da anni, ma in anni diversi. Poi serve il tempo per la loro valutazione e adozione.

Inoltre perché si dovrebbe supportare HTML e XHTML? E perché si dovrebbe supportare SVG (un altro mostro partorito dal W3C)?

Se invece si parla di html5, css3, lostal storage, web socket...sono ancora in sviluppo, com'è giusto che sia in quanto nuovi e per lo sviluppo web rivoluzionari.

Esatto.

Io trovo che le stime tipo 2022 e così via siano assurde. IE9 già coprirà gran parte di questi futuri standard, così come tutti gli attuali browser lo fanno già in parte. Così come già è possibile oggi tramite accorgimenti giocare ad un videogioco in 3D. Non trovo fantascienza pensare a tra due anni siti in html5

Eppure il 2022 è la data fissata dal W3C...

Perchè no? E' possibile

E' passato parecchio tempo, ma se non ricordo male ci sono delle funzionalità dei CSS che si prestano ad ambiguità e che, quindi, le implementazioni dei browser rendono o possono rendere in maniera diversa.

C'è sempre da considerare la complessità nell'implementare nuovi standard, e sopratutto come questi non siano standard (html5, css3---) ma bozze che vengono aggiornate quasi giornalmente http://html5.org/tools/web-apps-tracker

Ecco, un'altra cosa da sottolineare è che ormai HTML, con CSS e DOM annessi, sta diventando un pachiderma.

Forse era meglio fermarsi un attimo e pensare a un nuovo standard più semplice e razionale.

[nico159]

Eppure l'HTML è nato con quelle finalità: descrivere e non presentare.

Anche con html5 continuerà a svolgere il suo ruolo di definire uno significato semantico ad ogni blocco di informazione.
Ma ciò non toglie che in una pagina web l'html è solo una delle tante tecnologie usate. Considerare una pagina web solo markup è sbagliato.

Inoltre perché si dovrebbe supportare HTML e XHTML?

Perchè sono standard universalmente riconosciuti come standard web
Tutti possono creare una pagina html usandone a pieno le funzionalità, senza pagare nessuna licenza, senza essere costretti ad acquistare alcun ambiente di sviluppo.

E perché si dovrebbe supportare SVG (un altro mostro partorito dal W3C)?

Che sia un mostro è una affermazione fuori luogo e non so su quali basi ed esperienza affermi ciò.
Il perchè è esemplice: animazioni e grafica vettoriale integrate nell'ambiente (svg è basato su xml, quindi facilmente accessibile tramite dom, inoltre è possibile applicare regole css e così via)

Ecco, un'altra cosa da sottolineare è che ormai HTML, con CSS e DOM annessi, sta diventando un pachiderma.

Creare una pagina html è qualcosa che anche un ragazzino sa fare, lo si insegna anche in molte scuole.
Ovviamente non tutti lo usano a pieno nè tanto meno sanno quanto sia potente, ma questo non preclude nessuno dall'usarlo in base alle proprie capacità.
A me pare qualcosa di stupendo ciò.

Forse era meglio fermarsi un attimo e pensare a un nuovo standard più semplice e razionale.

A patto di non perdere funzionalità però.
Io sono soddisfatto di come sta procedendo il web

Se c'è qualcosa che deve aggiornarsi invece, è tutto ciò che c'è dietro, lato server, primi in assoluto i database in quanto costituiscono il collo di bottiglia principale di qualsiasi sito web
http://www.yafla.com/dforbes/Getting..._Scalable_Lie/
E "opposto"
http://adamblog.heroku.com/past/2009...es_dont_scale/

[cdimauro]

Originariamente inviato da nico159

Anche con html5 continuerà a svolgere il suo ruolo di definire uno significato semantico ad ogni blocco di informazione.
Ma ciò non toglie che in una pagina web l'html è solo una delle tante tecnologie usate. Considerare una pagina web solo markup è sbagliato.

In quel contesto parlavo solo di HTML.

Comunque, sì, una pagina web è composta da diversi elementi eterogenei, e l'HTML è soltanto uno di essi.

Perchè sono standard universalmente riconosciuti come standard web

Se parliamo di standard, bisogna precisare che lo sono diventati soltanto dopo molto tempo.

Prima erano, appunto, standard "di fatto".

Tutti possono creare una pagina html usandone a pieno le funzionalità, senza pagare nessuna licenza, senza essere costretti ad acquistare alcun ambiente di sviluppo.

Vero, ma nello specifico forse non sono stato abbastanza chiaro: mi riferivo al fatto che HTML e XHTML sono due strumenti che si sovrappongono. Quindi basterebbe implementarne soltanto uno, e invece il W3C non soltanto ha creato l'XHTML, ma anche con HTML 5 sta proseguendo con la relativa estensione XHTML.

Per non parlare poi dei continui cambiamenti che portano a parti deprecate o addirittura incompatibili.

Sembra che in quel consorzio non sappiano nemmeno loro cosa vogliono veramente.

Che sia un mostro è una affermazione fuori luogo e non so su quali basi ed esperienza affermi ciò.
Il perchè è esemplice: animazioni e grafica vettoriale integrate nell'ambiente (svg è basato su xml, quindi facilmente accessibile tramite dom, inoltre è possibile applicare regole css e così via)

Ecco, la prima cosa che mi dà fastidio è il fatto che abbiano usato XML anche per definire l'SVG: di linguaggi / protocolli molto meno complessi e più parsimoniosi in termini di risorse per definire una struttura "complicata" ne esistevano già.

Come esistevano già dei formati vettoriali, tra l'altro.

Ma si vede che al W3C hanno voglia di complicarsi inutilmente la vita, oltre che, purtroppo, complicarla a chi dovrà implementare e/o usare i loro progetti. Voglio vedere chi si divertirebbe a creare SVG "a manina".

Creare una pagina html è qualcosa che anche un ragazzino sa fare, lo si insegna anche in molte scuole.
Ovviamente non tutti lo usano a pieno nè tanto meno sanno quanto sia potente, ma questo non preclude nessuno dall'usarlo in base alle proprie capacità.
A me pare qualcosa di stupendo ciò.

Lo è come quando uno prova il classico "Hello, world!" e si sente già mezzo programmatore.

Per cose semplici non v'è dubbio che l'HTML abbia il suo fascino, ma per realizzare cose non banali è molto più pratico / produttivo affidarsi a strumenti che provvedono a generarlo automaticamente, e quel fascino di conseguenza viene meno (o, al limite, viene pesantemente ridimensionato).

A patto di non perdere funzionalità però.

Chiaro.

Io sono soddisfatto di come sta procedendo il web

Io no. Lo vedo come un calderone di tecnologie eterogenee che sono state messe assieme per coprire con delle pezze dei buchi che s'erano creati.

Quando penso al web, penso a un patchwork. Il risultato può essere anche gradevole, ma strutturalmente non m'aggrada proprio.

Se c'è qualcosa che deve aggiornarsi invece, è tutto ciò che c'è dietro, lato server, primi in assoluto i database in quanto costituiscono il collo di bottiglia principale di qualsiasi sito web
http://www.yafla.com/dforbes/Getting..._Scalable_Lie/
E "opposto"
http://adamblog.heroku.com/past/2009...es_dont_scale/

Condivisibile (il secondo un po' meno). E' da un pezzo che lo dico: si tratta di strumenti, coi loro pregi e loro difetti, e io come professionista non devo farmi condizionar dalle mode del momento e scegliere quello "migliore" per risolvere il problema che mi si pone davanti.

Al momento, e per quello a cui lavoro, trovo che un RDBMS sia lo strumento "migliore", ma sto valutando l'uso di DB come MongoDB e Redis per particolari aspetti (logging su db, gestione di dati "destrutturati").

[nico159]

In quel contesto parlavo solo di HTML.

Comunque, sì, una pagina web è composta da diversi elementi eterogenei, e l'HTML è soltanto uno di essi.

Scusa, si sta facendo evidentemente un pò di confusione
Io mi riferivo come fosse assurdo che un browser visualizzi una pagina web in maniera diversa dalla sua presentazione

Se parliamo di standard, bisogna precisare che lo sono diventati soltanto dopo molto tempo.

Prima erano, appunto, standard "di fatto".

Tutto è mutabile nel tempo, adesso va anche di moda controllare per gioco i siti web con il validatone W3C, così come pubblicizzare il proprio sito come conforme agli standard

Vero, ma nello specifico forse non sono stato abbastanza chiaro: mi riferivo al fatto che HTML e XHTML sono due strumenti che si sovrappongono. Quindi basterebbe implementarne soltanto uno, e invece il W3C non soltanto ha creato l'XHTML, ma anche con HTML 5 sta proseguendo con la relativa estensione XHTML.

Per non parlare poi dei continui cambiamenti che portano a parti deprecate o addirittura incompatibili.

Sembra che in quel consorzio non sappiano nemmeno loro cosa vogliono veramente.

Per tranquillizzarti, non ci sarà alcun XHTML 2

Ecco, la prima cosa che mi dà fastidio è il fatto che abbiano usato XML anche per definire l'SVG: di linguaggi / protocolli molto meno complessi e più parsimoniosi in termini di risorse per definire una struttura "complicata" ne esistevano già.

Come esistevano già dei formati vettoriali, tra l'altro.

Ma si vede che al W3C hanno voglia di complicarsi inutilmente la vita, oltre che, purtroppo, complicarla a chi dovrà implementare e/o usare i loro progetti. Voglio vedere chi si divertirebbe a creare SVG "a manina".

E' possibile creare immagini SVG anche con software sia libero come Inkscape che tramite soluzioni commerciali come Adobe Illustrator.
Adobe ha anche una sezione nel proprio sito dedicata a SVG: http://www.adobe.com/svg/main.html

Il suo essere basato su XML è un vantaggio a mio vedere, non uno svantaggio.
Se per risorse intendi la banda, il fatto che sia semplice testo, permette la compressione tramite i classici strumenti come gzip, dando vita a SVGZ
Ricordo inoltre, che anche Micorosft ha deciso di contribuire alle specifiche di SVG e IE9 offrirà un quasi totale supporto ad SVG ad esclusione dei font (i motivi abbastanza condivisibili)

Lo è come quando uno prova il classico "Hello, world!" e si sente già mezzo programmatore.

Per cose semplici non v'è dubbio che l'HTML abbia il suo fascino, ma per realizzare cose non banali è molto più pratico / produttivo affidarsi a strumenti che provvedono a generarlo automaticamente, e quel fascino di conseguenza viene meno (o, al limite, viene pesantemente ridimensionato).

Io l'unica astrazione lato web che utilizzo è jQuery, per il resto non sento questo bisogno. Se invece è una questione di comodità, ci può stare

Io no. Lo vedo come un calderone di tecnologie eterogenee che sono state messe assieme per coprire con delle pezze dei buchi che s'erano creati.

Quando penso al web, penso a un patchwork. Il risultato può essere anche gradevole, ma strutturalmente non m'aggrada proprio.

Abbiamo idee diverse
Io trovo, forse css un pò meno, molto valide tutte queste tecnologie.
HTML è molto semplice e flessibile, dato che permette di creare facilmente blocchi in un nulla, DOM è uno strumento come tanti e supporta varie carinerie, e Javascript è un ottimo linguaggio a mio avviso sottovalutato.
Manca via HTTP una soluzione semplice per ricevere aggiornamenti senza il polling, ma con i web socket e penso anche i server event, si è trovata una validissima soluzione (se sei curioso, guardati degli esempi base di web socket, il fatto che JS sia per natura event driven rende il tutto molto facile, come usare Twisted su Python senza dover imparare tutto ciò che Twisted ti costringe a sapere)

Al momento, e per quello a cui lavoro, trovo che un RDBMS sia lo strumento "migliore", ma sto valutando l'uso di DB come MongoDB e Redis per particolari aspetti (logging su db, gestione di dati "destrutturati").

Certo

[yorkeiser]

Ottimo, google ha dimostrato che i browser odierni riescono a rendere lento un applicativo che girava perfettamente 10 e passa anni fa su un pentium 200.
Al di là di questa che (mi auguro) voglia essere solo una dimostrazione, resto dell avviso che sarebbe ora di fermare la mania di scrivere qualsiasi cosa come web application.

[nico159]

Originariamente inviato da yorkeiser

Ottimo, google ha dimostrato che i browser odierni riescono a rendere lento un applicativo che girava perfettamente 10 e passa anni fa su un pentium 200.
Al di là di questa che (mi auguro) voglia essere solo una dimostrazione, resto dell avviso che sarebbe ora di fermare la mania di scrivere qualsiasi cosa come web application.

Io invece trovo tutto ciò estremamente interessante
E poi è troppo presto vedere come si evolverà tutto ciò, di sicuro per uno sviluppatore web si aprono tantissimi scenari non prevedibili da ora, non necessariamente giochi. Sono molto curioso di pensare cosa sarà internet tra 10 anni

[Tommo]

momento momento momento momento momento, momento. (cit.)

C'è una cosa che non ho capito: cosa impedisce di realizzare il cloud tramite plugins nativi che vengono scaricati/updatati dal client automaticamente con la visita del sito (con le dovute caches), invece che forzare un assurdo up/down di qualsiasi dato col server?

Esempio: VC++ cloud.
Come lo intende google è pura malattia, uppare 2 mb di codice per ricevere 140 mb di oggetti non ha senso... specie quando cl.exe è grosso una manciata di mb.

Non sarebbe possibile inviare il programma sul client, invece che i dati sul server?
Insomma, spostare la cosa che pesa meno. Sembrerebbe ovvio, a meno del web2.0
Certo non ci sarebbe il vantaggio che il peso sul proprio PC è zero spaccato (ma neanche tanto a guardare sto quake), ma imho avrebbe comunque tanti perchè!

[PGI-Bis]

Se parliamo di spostare i dati, magari i propri, sono totalmente, assolutamente contrario allo spostarli sul web.

Perchè il "web" non sta mica su giove: sta in qualche nazione ed è nella nazione dove stanno i dati che decidono come siano tutelati.

Ed è noto il bilanciamento che le aziende applicano tra utenti e denari: un centesimo pesa come un buco nero e sul piatto dove stanno i tuoi diritti è attaccata una mongolfiera.

[cdimauro]

Originariamente inviato da nico159

Scusa, si sta facendo evidentemente un pò di confusione
Io mi riferivo come fosse assurdo che un browser visualizzi una pagina web in maniera diversa dalla sua presentazione

Questo può accadere per due motivi: se lo standard è ambiguo, come dicevo, oppure se... ci sono bug nel renderer del browser.

Per tranquillizzarti, non ci sarà alcun XHTML 2

A me sembra di aver letto che XHTML sarà aggiornato con le estensioni previste da HTML 5.

E' possibile creare immagini SVG anche con software sia libero come Inkscape che tramite soluzioni commerciali come Adobe Illustrator.
Adobe ha anche una sezione nel proprio sito dedicata a SVG: http://www.adobe.com/svg/main.html

Il suo essere basato su XML è un vantaggio a mio vedere, non uno svantaggio.
Se per risorse intendi la banda, il fatto che sia semplice testo, permette la compressione tramite i classici strumenti come gzip, dando vita a SVGZ
Ricordo inoltre, che anche Micorosft ha deciso di contribuire alle specifiche di SVG e IE9 offrirà un quasi totale supporto ad SVG ad esclusione dei font (i motivi abbastanza condivisibili)

Non è questo il punto, e il problema non è il software libero o meno. Forse non sono stato chiaro. L'XML per definire un disegno "strutturato" a mio avviso è una complicazione inutile.

Ad esempio, l'IFF http://en.wikipedia.org/wiki/Interchange_File_Format mostra come sia possibile fare qualcosa di simile (dall'IFF è poi nato PNG, e da quest'ultimo MNG e altri derivati) a un costo irrisorio in termini di parsing. E con delle specifiche "libere".

Abbiamo idee diverse
Io trovo, forse css un pò meno, molto valide tutte queste tecnologie.
HTML è molto semplice e flessibile, dato che permette di creare facilmente blocchi in un nulla, DOM è uno strumento come tanti e supporta varie carinerie, e Javascript è un ottimo linguaggio a mio avviso sottovalutato.
Manca via HTTP una soluzione semplice per ricevere aggiornamenti senza il polling, ma con i web socket e penso anche i server event, si è trovata una validissima soluzione (se sei curioso, guardati degli esempi base di web socket, il fatto che JS sia per natura event driven rende il tutto molto facile, come usare Twisted su Python senza dover imparare tutto ciò che Twisted ti costringe a sapere)

In effetti la pensiamo molto diveramente. Javascript, poi, mi fa proprio schifo (e mi sembra anche ovvio il perché ).

Originariamente inviato da PGI-Bis

Se parliamo di spostare i dati, magari i propri, sono totalmente, assolutamente contrario allo spostarli sul web.

Perchè il "web" non sta mica su giove: sta in qualche nazione ed è nella nazione dove stanno i dati che decidono come siano tutelati.

Ed è noto il bilanciamento che le aziende applicano tra utenti e denari: un centesimo pesa come un buco nero e sul piatto dove stanno i tuoi diritti è attaccata una mongolfiera.

La privacy è l'ultimo dei problemi, a mio avviso: bene o male è tutelata, e in Italia particolarmente, ad esempio. Le multinazionali non possono non tenerne conto.

Personalmente, come ho detto prima, utilizzerei il "cloud" come mirror per i dati (quelli che decido io) e per il codice (idem come sopra), in quest'ultimo caso eventualmente come "repository" (non ho il codice, e me lo scarico; ma poi lo conservo in locale).

Le elaborazioni le farei quasi interamente in locale, perché CPU, RAM e storage a mio avviso ci saranno sempre, per quanto "minimale" possano essere i terminali del futuro.