Newsgroup: it.lavoro.informatica
Titolo: Is HTML5 the new Windows?

https://techcrunch.com/2016/06/08/is-html5-the-new-windows/
 
 
 

 
https://techcrunch.com/2016/06/08/is-html5-the-new-windows/
 
 
Cioe` ci stai veramente dicendo che hai scoperto solo ora che si possono scrivere applicazioni web con HTML5/JavaScript che emulano il funzionamento a finestre delle normali applicazioni desktop?


In realtà tutto nasce dalla possibilità di rilanciare l'hw, visto che a 
parità di funzionalità e user experience (compresi i tempi di risposta 
quindi), per avere l'app in versione "webbe" tocca avere risorse hw 
almeno pari al doppio, grazie a quelle tonnellate di js continuamente 
interpretate da browser scritti con i piedi e alla modalità di stuprare 
ogni ms il dom della pagina.
Roba da matti.
Però funziona, per usare una app di contabilità in contesto reale, tocca 
avere minino un i7 con 8 core e 16 gb di ram, ma vuoi mettere? E' 
"webbe", è moderna, è al passo con i tempi!
Praticamente il mio PC di sviluppo è meno potente.
 

 ha scritto:

E il che è assurdo se si considera che gran parte della business
 logic e dei calcoli pesanti sono server side. In pratica un
 baraccone pesantissimo che richiede enormi risorse per muove due
 finestre fighette in croce. Ma è "alla moda" e allora tutti in
 quella direzione.
 
-- 
Soprano
 
 
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
 

  fighette in croce. Ma è "alla moda" e allora tutti in quella direzione.
 
in effetti *sarebbe* assurdo se fosse vero. sfortunatamente non è vero.
 
nei giorni scorsi ho installato su virtualbox win10 per testare la 
compatibilità di un applicativo con edge, gli ho assegnato 2 g di ram e 
un processore. va che è una bellezza.
 
anche le "tonnellate di js" a cui si riferisce l'amico sai quanto cubano 
nel suddetto applicativo? 3,5 mega. tre virgola cinque mega. tutto 
compreso, angularjs, bootstrap, librerie varie e codice dell'applicativo, 
senza minificazione quindi compresi commenti e nomi human-readable. 
 
anche che "a parità di funzionalità e user experience" l'applicazione web 
abbia bisogno di "stuprare ogni ms il dom della pagina" evidenzia solo 
poca confidenza (eufemismo) unita a luoghi comuni buttati a casaccio. la 
programmazione in javascript è event-driven su singolo thread esattamente 
come qualsiasi altra gui, modificare il dom altro non è che l'equivalente 
di modificare dinamicamente l'interfaccia (aggiungere o rimuovere 
elementi o modificarne attributi) di una qualsiasi gui.  
 
quanto al discorso della moda, è una provocazione che dopo 15 anni che la 
sento mi fa sorridere e basta :-)

 ogni ms il dom della pagina.
 
Stupidaggini. Non e` affatto vero. Safari e Chrome, per esempio, compilano JavaScript Just In Time. Le performance sono esattamente le stesse di un'applicazione desktop classica. Non serve affatto avere hw particolarmente potente.

 E il che è assurdo 
 
Ha scritto una stupidaggine.


Ti farà sorridere, ma che in fase di design nell'IT si seguano mode è un 
fatto noto e oggettivamente vero. In molti casi è normale che sia così 
perchè una certa tecnologia evolve naturalmente verso qualcosa di 
migliore che viene poi adottato da tutti, ma non sempre questo vale, e 
comunque nessuna soluzione è buona per qualsiasi requisito. Mi dirai che 
chi opera così è poco professionale e sono d'accordo, ma ho visto questo 
tipo di trend innumerevoli volte. Qualche anno fa tutti si erano buttati 
a capofitto sul non-sql, per dire, oggi se ne parla già molto meno.
 
Ad esempio la presenza pesante di javascript di molti siti "aggiornati" 
ha reso il loro utilizzo su mobile complicato e pesante, mentre gli 
stessi siti erano precedentemente utilizzabili su mobile senza problemi. 
E si parla spesso di siti importanti, ferrovie, banche, quant'altro 
(parlo da utente, non sviluppando, grazie a dio, gui da decenni). Ditemi 
che non avete mai provato l'ebbrezza di cliccare (col dito) su un menu a 
tendina e vederlo apparire dopo 5 secondi. Eppure si parla di dispositivi 
mobili che hanno discreti processori e vari gb di ram.
 
-- 
Soprano


Ho visto che l'altro pistola cita il js compilato al volo dal browser.
Bene, questo è ancora più angosciante, non per l'approccio in se, ma per 
il risultato che comunque è deprimente. Vuol dire che il freeze delle 
schede oppure il collapse/expand in ritardo di pezzi di UI mentre uno 
sta per cliccare su un elemento accadono con tutto un popo' di 
ottimizzazioni in piedi? WOW.
Ammetto di avere solo un i7 4700HQ @2,4GHz con 16GB di ram e dischi non 
ssd, ma quando tengo aperte 4 schede del browser sentire le ventole che 
partono a manetta mi fa più piangere che ridere.
 

 classica.
 
Questo è molto discutibile. 
 
Su mobile è ancora un dato di fatto che le app native siano più 
performanti che le stesse identiche app in formato html5. 
 
Su desktop forse questo divario è ancora maggiore.
 
-- 
Soprano


Esempi di questi siti che fanno partire la ventola?


Forse non sai che anche le app native fanno uso preponderante di 
javascript. Una fra tutte quella di FB.
 
 
 
 


Sono quelle ibride, giusto ? Da tutti i benchmark e confronti che si 
trovano in giro le app native pure hanno come vantaggio la performance 
rispetto alle ibride o alle html5. Hanno ovviamente altri svantaggi, ma 
in termini di performance non credo ci siano dubbi.
 
La app di FB non la conosco, non avendo account FB.
 
-- 
Soprano

 La app di FB non la conosco, non avendo account FB.
 
Nemmeno io. Ma immagino non paghi alcuno scotto rispetto ad una native 
senza javascript. Non pagano i migliori programmatori del mondo per 
produrre carrozzoni.

 Esempi di questi siti che fanno partire la ventola?
 >
Accomodati con l'ansa per esempio
 

 produrre carrozzoni.
 
Potrebbero avere tutti i buoni motivi del mondo per aver scelto 
javascript, e avere la miglior performance possibile potrebbe non essere 
il loro requisito nr. 1 in ordine di priorità.
 
-- 
Soprano

 il loro requisito nr. 1 in ordine di priorità.
 
Ti ripeto che e' un app nativa. La differenza sta che non usa il 
browser, non usa html e non usa css. Penso sia questo che faccia la 
differenza.
 
Se usi React Native, hai le stesse performance di una app native senza 
javascript, ne' piu' ne' meno.
 


E' un sito per lo piu' statico, come diavolo fa a piantarti il browser?
 
Non starai parlando dei video in flash spero.
 

 dispositivi mobili che hanno discreti processori e vari gb di ram.
 
si ma se da altre parti vedi siti reattivi e responsivi vorrà pur dire 
qualcosa, no? 

 performanti che le stesse identiche app in formato html5.
 
a parte che non è più neanche tanto vero e lo è sempre di meno, ad ogni 
modo non sottovaluterei il vantaggio primo di sviluppare la ui in questo 
modo: è multipiattaforma. mi verrebbe da dire "scusa se è poco".
 

 modo: è multipiattaforma. mi verrebbe da dire "scusa se è poco".
 
Sulla 'multipiattaformità' purtroppo c'è ancora parecchio da dire: ancora oggi mi capita di usare applicazioni web che funzionano bene con un browser e male (o non funzionano) con un altro. Comunque, concordo con te, se finalmente si raggiungerà uno standard comune e condiviso da tutti, allora avere una UI 'sviluppa una volta e fa girare ovunque' si cosoliderà come plus non da poco.
Ciò non toglie - e qui prendo spunto da altri interventi - che esistono ed esisteranno sempre situazioni in cui la scelta di questa UI non sia quella giusta. Quanto dico vale per i DBMS SQL vs. NoSQL. Intendo: come sempre si tratta di strumenti, ed è compito di chi fa il tecnico (leggi: nostro) impiegare sempre lo strumento migliore per la situazione che si affronta; cosa che ha, come effetto collaterale stimolante, la necessità di conoscere più strumenti differenti.
 
-- 
Ciao!
Luca
 
 

 versatilità.
 
Probabile misunderstanding, col mio post intendevo il senso della tua 
prima frase, non lo sviluppo web in toto.
 
Comunque, parlando dello sviluppo web in toto (o meglio di gui che girano 
in un browser), è interessante notare che a oggi moltissimi utenti 
preferiscono ancora una app ad-hoc al corrispondente sito mobile. 
 
-- 
Soprano


Certo, è il grande vantaggio delle gui web, ma qua si discuteva di 
performance che non sono "esattamente le stesse".
 
-- 
Soprano


  Sicuro?
 
http://time.com/3158893/smartphone-apps-apple/
 
Aug. 22, 2014
«Most of Us Don’t Download Any Smartphone Apps at All»
 
And most people spend a huge chunk of time on just one app
 
[...]
 
Only about 35% of smartphone users download any apps at all in an
average month, says Comscore’s Mobile App Report—put another way, 65% of
smartphone users don’t download a single app in any given month.
 
http://guardianlv.com/2014/08/apps-no-longer-popular-for-smartphone-users/
 
August 19, 2014
«Apps No Longer Popular for Smartphone Users?»
 
It appears that apps are no longer as popular for smartphone users as
they once were. New research shows that a third of all users within the
UK are no longer bothering with new software placed on the app stores,
including the Google Play Store and Apple iTunes Store. It begs the
question as to whether there is any use in creating them anymore.
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.


Atom è JS 
https://github.com/atom/atom
 
Ce ne sono molte altre: 
http://electron.atom.io/apps/
 (esempio: electron è un framework)
 
  ngw


Guarda, faccio due appunti due, io che vengo da anni e anni di sbalordimento e sospensione di credulità costante causate dalla lettura di questo NG.
1) Non c'è una tecnologia che non venga bollata da una percentuale importante di questo NG come moda. Non una, seriamente. O pratica. O applicazione/startup.
Negli anni, ricordo con grandissima chiarezza Linux, Python, Cloud Computing, XP, Pair Programming, Ruby, il web 2.0, Twitter, Java, lo scibile umano fatto da Apple, iPhone in prima fila. Insomma, l'informatica oggi.
Spesso, con motivazioni assolutamente risibili. Linux non sarà mai alla pari degli Unix a pagamento. Java? Ma abbiamo C++, è lento. Il Cloud Computing farà perdere il lavoro ai sistemisti e non è sicuro. Twitter è per bimbominchia, come la Apple e l'iPhone e il web 2.0. Il Pair Programming serve ai più giovani per copiare e farti perdere il posto. l'iPhone non permette di mandare videomessaggi. Molte di queste credenze (non c'è verso di chiamarle in altro modo) sono qui ancora oggi, nonostante l'evidenza sia francamente schiacciante.
Ma dopo anni, un mezzo dubbio non viene? A forza di etichettare di ogni come moda che non serve ad un cazzo, e non prenderci a ripetizione, non viene voglia di guardare le cose un po' piu' a fondo, o quantomeno di evitare pareri così "tranchant"?
Insomma, senza saper ne leggere ne scrivere, non viene in mente che 'sta tendina che non carica potrebbe farlo perché fa una chiamata asincrona (in un sito di ferrovie, per dire, è abbastanza ovvio - mica si tiene tutte le destinazioni in memoria, no?) e magari c'è qualche problema di banda?
2) Ha perfettamente ragione quando dici che non tutte le soluzioni sono buone per qualsiasi requisito, "if all you have is a hammer everything looks like a nail", certamente. A me pare però che la tua proposta è l'eliminazione in toto di Javascript e delle UI in HTML5/Javascript, o al limite di usarlo per cose molto vicine alle stronzate? Boh.
 
  ngw


Se usi una tecnologia a CDC però non puoi dare la colpa alla tecnologia. Per quanto riguarda i DB NoSQL il problema è che difficilmente sono in concorrenza con i DB SQL, tutt'altro. 
Tra l'altro fare UI in HTML5/JS non crossbrowser è di una difficoltà, che davvero non saprei dove cominciare, usando una libreria esterna (e non scrivendo JS a CDC io). Ma dove li trovate 'sti mostri?
 
  ngw


Sicuro no, mi baso su cosa leggo in giro, tipo questo:
 
https://www.mobilesmith.com/html5-vs-native-debate-is-over/
 
 
Io stesso non ho dubbi e nella maggior parte dei casi tra una app nativa 
e una web-app preferisco la prima.
 
-- 
Soprano

 performanti che le stesse identiche app in formato html5. 
 
Non sto parlando del mobile. Le applicazioni mobile le sviluppo in Java perche` lo trovo piu` comodo. Sto parlando di cio` di cui parla quell'articolo, ovvero di applicazioni HTML5/JavaScript che usano browser come piattaforma. La differenza tra un'applicazione del genere (il cui codice, come detto, e` compilato JIT) e un'applicazione desktop classica non esiste.

 performance che non sono "esattamente le stesse".
 
Sono esattamente le stesse nel contesto da me considerato. Se le sposti di contesto, e` chiaro che le cose cambiano. Il mobile NON e` quello di cui io stavo parlando.

 Ciò non toglie - e qui prendo spunto da altri interventi - che esistono ed esisteranno sempre situazioni in cui la scelta di questa UI non sia quella giusta. 
 
Tipo?

 a capofitto sul non-sql, per dire, oggi se ne parla già molto meno.
 
Ma cosa stai dicendo? :) Forse se ne senti parlare molto meno tu perche` hai deciso di non volerne sentire. A parte, poi, che e` NoSQL, non "non-sql". I database NoSQL sono ormai la regola in molti contesti in cui e` prevista High Availability e scalabilita`.

 Guarda, faccio due appunti due, io che vengo da anni e anni di sbalordimento e sospensione di credulità costante causate dalla lettura di questo NG.
 
Il problema e` che gran parte della gente che scrive in questo gruppo ha una competenza molto bassa, e le piace crogiolarsi nell'idea che ogni tecnologia che non ha voglia (o non ha la capacita`) di imparare sia solo una moda del momento. Sono quelle stesse persone che ritengono che, per essere veramente in gamba, basta appiattire tutto al loro (basso) livello di competenza, e che quindi in informatica ti basti conoscere l'aritmetica binaria per poter fare qualunque cosa.

 Bene, questo è ancora più angosciante,
 
Ma smettila, idiota. Continui a parlare di cose che non conosci e a pestare merde colossali. Quando la smetterai di renderti ridicolo?

 Non starai parlando dei video in flash spero.
 
Perdi anche tempo a rispondergli?


Non sto dicendo che sono scomparsi, ma che sono meno "trendy". Forse 
proprio perchè hanno smesso di essere la novità e sono diventati regola, 
come dici tu.
 
-- 
Soprano

 Il problema e` che gran parte della gente che scrive in questo gruppo ha una competenza molto bassa
 
La cosa che mi lascia perplesso e' che una delle "mode" che davvero 
ritengo pericolose del momento, i microservices, non vengono neppure 
menzionate. E non parlo solamente di questo thread.
 
Praticamente ciccio e co non ne hanno mai sentito parlare.

  Ma dove li trovate 'sti mostri?
 
Guarda, ho appena finito di baruffare con un HoBa che funziona perfettamente con Firefox, ma che ha qualche problema (prego di apprezzare l'understatement) con Chrome.
 
Purtroppo, i mostri esistono...
 
-- 
Ciao!
Luca


I supervisori di impianto con cui continuo ad ammorbarvi.
 
-- 
Ciao!
Luca

 menzionate. E non parlo solamente di questo thread.
 
Quindi confermi il mio punto iniziale, che le "mode" esistono eccome. :)
 
Vero che adesso sono tutti sui microservice.
 
-- 
Soprano

 I supervisori di impianto con cui continuo ad ammorbarvi.
 
Ho un PS obbligatorio. Io spero vivamente in un prossimo futuro di essere smentito. Preferirei un'unica UI e potermi concentrare solo sulla meccanica del software.
 
-- 
Ciao!
Luca

 e una web-app preferisco la prima.
 
Anche io ragionavo cosí prima di interessarmi alla privacy. Ad esempio
perché le app del meteo devono per forza restare attive in background e
richiedere n-mila permessi? In questo caso a mio avviso é piú che
sufficiente la versione mobile.
Idem per quel che riguarda facebook, se vuoi solo lurkare versione
browser + ghostery (o simili) é piú che sufficiente e ti garantisce un
livello di privacy accettabile.
 
-- 
g4b0, linux user n. 369000
http://brosulo.net
 


+1


 come la Apple e l'iPhone e il web 2.0. Il Pair Programming serve ai più
giovani per copiare e farti perdere il posto.
 
Ti sei dimenticato che il Pair Programming fa la felicità dei gay... ;-D
 
 

  Sono quelle stesse persone che ritengono che, per essere veramente in gamba,
basta appiattire tutto al loro (basso) livello di competenza, e che quindi in
informatica ti basti conoscere l'aritmetica binaria per poter fare qualunque cosa.
 
Infatti ecco chi è un Vero Programmatore:
 
http://www.notjustcode.it/dblog/resize.aspx?img=/public/umorismo_progBinario.jpg&opx=450
 
 
 


Ti invio una sessione di performance counter per vedere quanto cagare 
facciano le web app che circolano?
 
 > Quando la smetterai di renderti ridicolo?
 >
1 ms dopo che sarai schiattato.
 


Se vuoi c'è anche il sito per l'internet banking, o anche infojobs.
E' splendido come user experience avere un feedback nullo sulle chiamate 
asincrone che ci mettono più di qualche secondo. Almeno nei full post 
back uno vedeva lo spinner in cime alla tab della scheda, ora manco più 
quello, e uno non sa se i click vanno a vuoto o no.
Bah.
 

 affronta; 
 
yawn...
 
ma non vi annoiate a ripetere sempre le stesse banalità, peraltro 
inutilmente perché nessuno mette in discussione questi concetti? io sono 
intervenuto con questi argomenti perché si sosteneva che lo sviluppo web 
fosse una "moda", non per dire che svilupperei una webapp anche per 
controllare la tazza del cesso. 
anche la presunta disputa fra database sql vs. nosql, ma dove la vedi? 
per me è perfettamente chiaro che i db document oriented hanno un 
impiego, quelli a grafo ne hanno un altro entrambi diverso da quelli 
relazionali. che poi, se permetti, è infinitamente più facile trovare a 
giro usi impropri di database relazionali che non viceversa, perché 
praticamente la gente conosce solo quelli. 


ma il presente già ti smentisce. tutto il resto del mondo in casi 
analoghi sviluppa delle api (rest, ad esempio), disaccoppia l'interfaccia 
utente per concentrarsi sulla meccanica del software. la ui non è che 
viene messa in subordine, ma essendo disaccoppiata hai facoltà di 
agganciarci tutte quelle che ti pare, dalla cli alla app mobile passando 
da una console web. 
 

 utente per concentrarsi sulla meccanica del software. 
 
OK, sono stato troppo sintetico e non mi sono ben spiegato.
Ed è normalmente la strada maestra. MA, in alcuni ambiti, hai bisogno di risposte molto veloci, per cui - ancora, ma non si sa mai - l'aggancio di una applicazione JavaScript da far girare in un browser non è una soluzione efficace. Ciò che sottointendo è: a me piacerebbe che TUTTO quel che è UI potesse essere fatto con una bella applicazione JavaScript e passando da un browser, in modo da relegare altri tipi di UI a nicchie da usare solo sporadicamente.
 
 
-- 
Ciao!
Luca


Il problema non é la tecnologia, ma chi la implementa. Sto lavorando a
progetti con 5 o 6 livelli di body rental, la qualitá del codice é
inversamente proporzionale alla quantitá di burocrazia.
Prova ad usare un progetto open source scritto come si deve, vedrai che
le tue ventole staranno a riposo.


 l'aggancio di una applicazione JavaScript da far girare in un browser non è una soluzione efficace
 
Ancora con questa storia? Dimmi per quale motivo non dovrebbe soddisfare 
le tempistiche.

 Bah.
 
I siti che non danno feedback sono fatti col culo. Punto. Cosi' come si 
possono trovare applicativi desktop fatti con il culo. Che cavolo 
c'entrano javascript, l'html e il browser?
 

>>>>  
http://www.bb2002.it
 :)  <<<<<
........... [ al lavoro ] ...........

 le tempistiche.
 
Ti rimando alla spiegazione che ti ho dato qualche mese fa.
 
-- 
Ciao!
Luca


Se ti riferisci alla questione dei millisecondi, come ti era gia' stato 
spiegato e' prima di senso. Puoi quindi gia' adottare un interfaccia web 
html 5, non devi aspettare alcunche'.
 
 
 

 pagina!
 
Un sito web *non* pianta un PC. Detta così è una fandonia di rarissime proporzioni. Il browser è da sempre una sandbox, dopo Chrome ancora di più (i singoli tab vengono lanciati in processi sandboxati, quindi... 
https://www.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ
). Le risorse che possono i singoli processi sono CPU e memoria (ovviamente), quindi mal che vada, nel raro caso in cui non sia il browser stesso ad avvertire che qualche script sta facendo casino, basta uccidere il processo del browser.
Gli altri browser fungono anch'essi da sandbox, dove nel peggiore dei casi esplode il browser stesso piuttosto che il singolo tab, quindi anche qui, nessun "piantamento".
 
  ngw

 html 5, non devi aspettare alcunche'.
 
I test finora svolti dicono il contrario (perdona, mi fido più dei test che delle spiegazioni in un NG). 
Quando i test saranno aderenti a quanto dici, adotterò con estrema gioia l'interfaccia in HTML5.
 
-- 
Ciao!
Luca
 


Non ne dubito, ma sarebbe interessante sapere che test hai fatto, come 
aggiorni il DOM, come ricevi i dati, eccetera.

 I supervisori di impianto con cui continuo ad ammorbarvi.
 
I supervisori di impianto possono benissimo avere un'interfaccia web. Tu sei rimasto ancorato all'idea che l'interfaccia debba stare dove sta la logica applicativa.
 
 

Ciò che sottointendo è: a me piacerebbe che TUTTO quel che è UI potesse essere fatto con una bella applicazione JavaScript e passando da un browser, in modo da relegare altri tipi di UI a nicchie da usare solo sporadicamente.
 
Puoi farlo. Non c'e` alcun problema. Il problema, secondo me, e` che non hai capito bene cos'e` "TUTTO quel che e` UI".

 I test finora svolti dicono il contrario (perdona, mi fido più dei test che delle spiegazioni in un NG). 
 
Quali test? Se vuoi essere perdonato, almeno dai delle fonti.


Parto dal fondo. Non ho alcuna necessità ne voglia di essere perdonato. Sono test interni che periodicamente facciamo per verificare se nuove tecnologie possono essere impiegate proprio con l'idea di superare il legame con singoli OS. Io godrò quando potrò scrivere un supervisore qualunque in Python, così lo porto dove diavolo mi gira, e usare solo i browser (magari scegliendoli, mi posso adattare per il momento) come interfacce. Che poi è l'architettura che uso per altre applicazioni.
Poi: ho separato interfaccia utente e logica applcativa più di qualche anno fa (e l'avevo pure sottointeso: ricordi? campi fotovoltaici, container non presidiati...); e d'altra parte io sono un fautore di MVC (mentre non mi convince troppo MVVM). In questo caso la velocità di risposta non era rilevante, per cui tempi di latenza di secondi erano assolutamente accettabili. Ci sono ambiti però in cui tempi di latenza di un secondo, o anche mezzo, non sono accettabili.
Poi. Ovvio che la logica applicativa sta lato server e la presentazione avviene su client. Perché alla fine stiamo dicendo le stesse cose (quando parlo di 'sviluppo web' intendo sia la parte server che l'UI lato client). E quando parlo di 'applicazione JavaScript' intendo tutta quella parte che finisce, interpretata o no, in pasto al browser a costituire l'UI. Lato server, ovvio, puoi usare quel che vuoi (io uso Python e CherryPy).
Per il resto. NON HO INTRODOTTO IO LA QUESTIONE DB! Però, visto che qualcuno l'ha fatto (dicendo che quelli NoSQL sono una moda superata), mi son permesso di dire: 'son strumenti di diverso tipo: si usano se opportuno, non si usano se non opportuno'.
 
-- 
Ciao!
Luca
 
 

 Per il resto. NON HO INTRODOTTO IO LA QUESTIONE DB! Però, visto che qualcuno l'ha fatto (dicendo che quelli NoSQL sono una moda superata), mi son permesso di dire: 'son strumenti di diverso tipo: si usano se opportuno, non si usano se non opportuno'.
 
Stai usando l'esempio dei db per giustificare il fatto che tecnologie diverse in campo UI si usano in contesti diversi. L'analogia non calza.

 Ci sono ambiti però in cui tempi di latenza di un secondo, o anche mezzo, non sono accettabili.
 
Non mi verrai a dire adesso che un browser risponde dopo mezzo secondo, 
vero?
 
Inoltre se e' un problema di latenza di rete, cosa cambia che il client 
sia il browser, cli o un applicativo desktop?

 facciano le web app che circolano?
 
Ti invito a darti all'ippica. Evita di renderti ridicolo, imbecille. Come sempre, non sai quel che dici. 
 
 

 Stai usando l'esempio dei db per giustificare il fatto che tecnologie diverse in campo UI si usano in contesti diversi. 
 
No, ma se ti piace crederlo e ti fa star meglio, come si dice dalle tue parti, be my guest.
 
-- 
Ciao!
Luca
 
 

 vero?
 
Si, e per un motivo semplice. I computer industriali su cui si lavora spesso non hanno 'sto gran che di risorse disponibili; in quest'ambito un'UI differente da prestazioni migliori.
Per dire, all'epoca ho baruffato anche con un'UI scritta in .NET; scoprii che è più usabile, a patto che usi un simpatico trucco per far si che il JITter compili tutto all'inizio.
 
-- 
Ciao!
Luca

 Si, e per un motivo semplice. I computer industriali su cui si lavora spesso non hanno 'sto gran che di risorse disponibili;
 > in quest'ambito un'UI differente da prestazioni migliori.
 
A meno che non sei costretto a farlo girare su IE6, non mi tornano i 
conti. O meglio mi suona strano.
 
I dati come li ricevevi in tempo reale? Polling, long polling o che altro?
 
 

 Se vuoi c'è anche il sito per l'internet banking, o anche infojobs.
 
ogni tanto levagli la morchia da codeste ventole.

 No, ma se 
 
Certo che si`, invece. 
 

 Per dire, all'epoca ho baruffato anche con un'UI scritta in .NET
 
Che non significa una ceppa.
 

 Io so benissimo di cosa sto parlando e rimando *TE* a quel famoso thread in cui ti ho ampiamente spiegato che quel che affermavi, e che ribadisci ora, e` sbagliato
 
Partendo da una premessa non corretta. Ascolta me, riguarda la mia risposta a Cicap in quel thread, ti farà bene.
 
-- 
Ciao!
Luca
 

 I dati come li ricevevi in tempo reale? Polling, long polling o che altro?
 
No, il polling viene usato solo se non se ne può fare a meno; l'impiego tipico è se devo documentare trend di lungo periodo. Un esempio: in un campo fotovoltaico, voglio capire come va la produzione durante una giornata, allora a campione ogni x secondi prendo i dati dall'impianto.
Diciamo che ci sono bus di campo - mi viene in mente Modbus/TCP, ma circa questo bus devo ampliare un po' il discorso (*) - in cui viene impiegato un polling serrato; ci sono altri bus - uno di quelli proprietari di una delle aziende con cui collaboro ne è un esempio - in cui si dice all'apparecchiatura 'mandami eventuali variazioni' e rimani li in ascolto di un evento con un apposito message handler, di fatto realizzando una modalità push (si impiega soprattutto se le variazioni sono frequenti, vedi i famosi indicatori di velocità o i provamolle che citavo nell'altro thread).
 
(*) Io a suo tempo ho trovato più efficiente dedicare un thread ad ogni apparecchiatura, un po' superando la modalità standard di gestione di ModBUS, per cui l'applicazione vera e propria registra message handlers presso ciascun thread, giungendo dunque a simulare quella modalità push che citavo sopra.
 
-- 
Ciao!
Luca

 Non e` vero. Ed e` dimostrabile.
 
OK. Dimostralo.
 
-- 
Ciao!
Luca


Per dare una user experience fatta male col dekstop ti ci devi 
impegnare, in modalità web è garantita come default.
 


Puoi sempre andare a prendere i calci in culo alle giostre alle sagre di 
paese, testa di cazzo.
 
 


Oh grullo, che mica mi partono quando faccio altro, che l'è allora?
 

On 05/07/2016 13:02, 
n...@nofeed.org
 wrote:
 
 > Un sito web *non* pianta un PC. Detta così è una fandonia di
 > rarissime proporzioni. Il browser è da sempre una sandbox, dopo
 > Chrome ancora di più
 >
Wow, che precisazione. Che ti credevi intendessi con "pianta"? L'ho ha 
anche chiarito. Ti aspettavi schermata blu o riavvio del pc?
 
 > quindi mal che vada, nel raro caso in cui non sia il browser stesso
 > ad avvertire che qualche script sta facendo casino, basta uccidere il
 > processo del browser.
 > Gli altri browser fungono anch'essi da sandbox, dove nel peggiore dei 
casi esplode il browser stesso piuttosto che il singolo tab,
 >
Bravo, così arrivi anche a chiudere tutto quello che c'era di aperto.
 


Facile, gli chiedi una consulenza, lui te la fa dicendoti che sono cazzi 
tuoi se non sei capace di fare quello che lui ti sta spiegando con 
dovizia di particolari e in modo non intrepretabile.
Lo paghi, parti con la rivoluzione tecnologica, finisci nella merda (o 
epic fail se preferisci il francese...) e lui sostiene che c'entra una 
sega perché tu sei incapace.
Imbecilli del genere ce ne sono a manetta, sono da impallinare a distanza.
Ma è facile sgamarli, gli proponi un progetto chiavi in mano con penale 
allegata e vedi come spariscono senza aprire bocca.
 

 di un secondo, o anche mezzo, non sono accettabili.
 
vero, vedi i giochi multiplayer online per esempio.
 
hai presente websocket? questo è una semplice demo:
 
http://demo.kaazing.com/forex/
 
 
sei sicuro che questo perda nel tuo test comparativo di interfacce? io ho 
dei seri dubbi.

 dei seri dubbi.
 
Questa è una cosa che non conoscevo e che val la pena di provare. Grazie.
Nel demo, se guardi il singolo dato, la frequenza di rinfresco non è così elevata. Però potrebbe essere il come è disegnata l'applicazione (deve fare così).
 
-- 
Ciao!
Luca

 Oh grullo, che mica mi partono quando faccio altro, che l'è allora?
 
è che spari cazzate, per esempio.
 


Cioè quando sparo cazzate partono le ventole?
 

 No, il polling viene usato solo se non se ne può fare a meno; l'impiego tipico è se devo documentare trend di lungo periodo. Un esempio: in un campo fotovoltaico, voglio capire come va la produzione durante una giornata, allora a campione ogni x secondi prendo i dati dall'impianto.
 
Qui stai parlando di server pero'. Ci vedo tre componenti nel tuo contesto: impianti, server, ui. Qui stai parlando di polling tra il server e l'impianto, quindi non e' quello che ti stavo chiedendo.
 
Per sparare questi dati al browser, puoi usare anche websocket senza problemi. Sempre che i browser che girano sulle tue macchine clienti siano abbastanza aggiornati.

 Nel demo, se guardi il singolo dato, la frequenza di rinfresco non è così elevata.
 
Dubito tu abbia alcun problema di latenza. Come sono connessi server e 
client nel tuo caso?

 impegnare, in modalità web è garantita come default.
 
Eh come no. Ad esempio nel desktop lo spinner di cui parlavi viene 
gratis, nevvero?
 
 


se le ventole andassero a cazzate te c'avresti gli uragani nel pc.
 
no è che sono cazzate queste che ci racconti. 
mi sono permesso di campionare la cpu mentre su chrome cliccavo a manetta 
su uno dei siti (infojobs) che a te farebbe partire le ventole. si tratta 
di un i7-5500U CPU @ 2.40GHz con 16g di ram e disco ssd.
 
 
Linux 4.5.7-200.fc23.x86_64   05/07/2016      _x86_64_        (4 CPU)
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8,94    0,04    3,45    0,11    0,00   87,46
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1,44    0,00    0,56    0,06    0,00   97,93
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1,88    0,00    0,94    0,00    0,00   97,18
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5,02    0,00    2,51    0,06    0,00   92,41
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20,47    0,00    4,61    0,13    0,00   74,79
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9,77    0,00    1,75    0,00    0,00   88,48
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8,87    0,04    3,41    0,11    0,00   87,57
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4,27    0,00    2,01    0,06    0,00   93,66
 
 
qui le chiacchiere stanno a zero, è scientifico che dici cazzate.


nel protocollo il flusso dati è continuo, mentre se ti riferisci alla 
frequenza di aggiornamento video le prestazioni non possono essere 
diverse da qualsiasi altra gui ovvero assolutamente un non-problema.
se ti sei focalizzato su questo pensando che sia un collo di bottiglia 
sei fuori strada e parecchio: nel caso ipotetico di quella demo è 
evidente i problemi sono molto più nel campionamento di tutta quella 
quantità di dati che non sulla loro rappresentazione.

On 05/07/2016 23:47, rootkit wrote:
 
 > mi sono permesso di campionare la cpu mentre su chrome cliccavo a manetta
 > su uno dei siti (infojobs) che a te farebbe partire le ventole.
 >
Cliccavi a manetta, interessante.
Cliccavi a menetta dove? Io stavo costruendo un nuovo profilo.
Se/quando mi ricapita posterò uno snapshot.
 
 >
 > qui le chiacchiere stanno a zero, è scientifico che dici cazzate.
 >
WOW, le modalità delle prove mi lasciato basito.
 

 Qui stai parlando di server pero'. Ci vedo tre componenti nel tuo contesto: impianti, server, ui. Qui stai parlando di polling tra il server e l'impianto, quindi non e' quello che ti stavo chiedendo.
 
Mi sono evidentemente spiegato male.
La parte server colleziona i dati e li invia alla UI. Non è la UI che si va a prendere i dati. Il socket ha flusso server -> UI, per cui su evento 'dato ricevuto' la applicazione UI smista adeguatamente.
 
-- 
Ciao!
Luca

 diverse da qualsiasi altra gui 
 
E' questa affermazione che mi sento di smentire. Se disegno un'interfaccia compilata che si basa  QT - a meno che non si parli degli ultimi browsers, ho letto in questo thread che hanno un JITter proprio - inevitabilmente la presentazione è più lenta.
Aggiungo, per completezza: non pensare che quelli che vedi siano chissà che quantità di dati (a te sembrano tanti, a me sembrano pochini...)
 
-- 
Ciao!
Luca

 Cliccavi a manetta, interessante.
 
questo è mentre compilo il form di registrazione. 
tieni conto che ho plasma di kde che tiene la cpu al 2/3% anche senza far 
niente.
 
ps: fava.
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4,16    0,20    1,14    0,28    0,00   94,22
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4,91    0,00    1,38    0,44    0,00   93,27
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5,84    0,00    1,70    0,82    0,00   91,65
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6,10    0,00    1,38    0,63    0,00   91,89
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8,51    0,00    1,89    1,01    0,00   88,59
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3,57    0,00    1,07    0,50    0,00   94,86
 
avg-cpu: %user    %nice %system %iowait  %steal   %
idle                                                                                                                                   
           4,13    0,00    1,31    0,44    0,00   
94,12                                                                                                                                       
 
avg-cpu:  %user   %nice %system %iowait  %steal   %
idle                                                                                                                                       
           5,01    0,00    1,81    1,00    0,00   
92,18                                                                                                                                       
 
avg-cpu:  %user   %nice %system %iowait  %steal   %
idle                                                                                                                                       
           5,20    0,00    1,57    0,13    0,00   
93,11                                                                                                                                       
 
avg-cpu:  %user   %nice %system %iowait  %steal   %
idle                                                                                                                                       
           4,39    0,00    1,51    0,00    0,00   94,10     
 
 

 che quantità di dati (a te sembrano tanti, a me sembrano pochini...)
 
a me non sembrano ne tanti ne pochi, dico solo che se hai 50 valori che 
provengono da 50 fonti dati diverse penso ti ci voglia più tempo a fare 
50 polling che a stampare 50 numeri a video. e penso anche che più sono i 
valori e più il divario aumenta. 


Che razza di alias hai dato ai comandi???