Parliamo di software 2: Dudeswave
-
mm, si.. ni. Una CDN ha dei costi eh. Non e' detto che vuoi cachare tutto tutto. Pero' vero in ogni caso tutto quello che dici.
Cosi' come e' vero che ad oggi, anno del signore 2025, il risultato di un qualsiasi "sito" (mi limito solo al web) fatto con un qualsiasi framework moderno (spoiler: sono tutti framework javascript), ha una resa decisamente superiore ai suoi competitor anni 2000 (php & co ... o qualsiasi voglia scegliate voi). In fatto di resa finale all'utente, in fatto di sviluppo, ed anche per quanto discusso prima (ma mettiamo che NON SIA VERA QUESTA ULTIMA AFFERMAZIONE!)Netflix
Ferrari
Zalando
Asos
e potrei andare avanti, ma sarebbe parlare dell'ovvio.
Persino pornhub, che di base fu fatto in php, ci hanno messo sopra vue.js, e' rimasto ancora vecchio codice legacy, che da quello che mi avevan detto alcuni ragazzi che ci lavorano, doveva essere rimosso anni fa, ma vedo e' ancora la'.
Il mondo e' tutto scemo (ok, battute facili) ? O forse c'e' un perche' sui siti moderni si sviluppa con determinate tecnologie ?
@Aethiss said in Parliamo di software 2: Dudeswave:
O forse c'e' un perche' sui siti moderni si sviluppa con determinate tecnologie ?
o forse perche' si tratta dei sistemi consigliati dai maggiori produttori di telefoni, social network, eccetera?
Per diventare "industry standard" non servono dei razionali.
Ma ti sfido a misurare qualsiasi impatto sulla CPU dei backend, passando con milioni di utenti da browser puro a Vue, o React.
Uno standard di fatto puo' vivere anche semplicemente perche' e' quello che conoscono tutti i programmatori che si trovano sul mercato. Nessuno vuole aspettare mesi per trovare programmatori esperti in Erlang.Non ho negato che esistano motivi per usare vue o react, ho solo detto che non sono quelli che dici tu. Tutto qui.
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
@Aethiss said in Parliamo di software 2: Dudeswave:
O forse c'e' un perche' sui siti moderni si sviluppa con determinate tecnologie ?
o forse perche' si tratta dei sistemi consigliati dai maggiori produttori di telefoni, social network, eccetera?
Per diventare "industry standard" non servono dei razionali.
Ma ti sfido a misurare qualsiasi impatto sulla CPU dei backend, passando con milioni di utenti da browser puro a Vue, o React.
Uno standard di fatto puo' vivere anche semplicemente perche' e' quello che conoscono tutti i programmatori che si trovano sul mercato. Nessuno vuole aspettare mesi per trovare programmatori esperti in Erlang.Non ho negato che esistano motivi per usare vue o react, ho solo detto che non sono quelli che dici tu. Tutto qui.
@amigaunicorn said in Parliamo di software 2: Dudeswave:
Non ho negato che esistano motivi per usare vue o react, ho solo detto che non sono quelli che dici tu. Tutto qui.
Rispetto la tua opinione, ma non la condivido (appieno).
-
mm, si.. ni. Una CDN ha dei costi eh. Non e' detto che vuoi cachare tutto tutto. Pero' vero in ogni caso tutto quello che dici.
Cosi' come e' vero che ad oggi, anno del signore 2025, il risultato di un qualsiasi "sito" (mi limito solo al web) fatto con un qualsiasi framework moderno (spoiler: sono tutti framework javascript), ha una resa decisamente superiore ai suoi competitor anni 2000 (php & co ... o qualsiasi voglia scegliate voi). In fatto di resa finale all'utente, in fatto di sviluppo, ed anche per quanto discusso prima (ma mettiamo che NON SIA VERA QUESTA ULTIMA AFFERMAZIONE!)Netflix
Ferrari
Zalando
Asos
e potrei andare avanti, ma sarebbe parlare dell'ovvio.
Persino pornhub, che di base fu fatto in php, ci hanno messo sopra vue.js, e' rimasto ancora vecchio codice legacy, che da quello che mi avevan detto alcuni ragazzi che ci lavorano, doveva essere rimosso anni fa, ma vedo e' ancora la'.
Il mondo e' tutto scemo (ok, battute facili) ? O forse c'e' un perche' sui siti moderni si sviluppa con determinate tecnologie ?
Te l'ho scritto prima: un browser web è in grado di eseguire codice php?
No. Un browser web conosce solo javascript e di conseguenza, se tu vuoi fare "cose" sul client, dovrai usare Javascript.
Ma tu stai mescolando framework front-end con il back-end e ti ripeto. Il mio pc di 10 anni fa, con una SPA "moderna", si caga addosso.
E sí, l'informatica è moda, e tutti usano Javascript non perché è intrinsecamente una scelta migliore, ma perché facebook dice che è fico fare tutto in Javascript.
Cosa dici che succede alla tua SPA se togliamo V8 da chrome, dove google ha speso miliardi per far sí che Javascript fosse gestito in maniera passabile?
La storia del "eh tutti fanno cosí" ha stancato. L'informatica è peggio del fashion e quando chiedi motivazioni tecniche VERE, quasi tutti i programmatori ti rispondono "ma Guggle fa cosí, quindi DEVE essere buono" e si segue l'hype per gonfiare il CV. Non ci sono motivazioni tecniche.
Dire che ub framework Javascript è "moderno", è stupido e insensato, dato che sul client puoi usare solo javascript.
E sí, le web app devono morire, sono lente, farragginose, inconsistenti e non ne ho trovata una che non richiedesse una centrale nucleare per funzionare, soprattutto quando scritte con framework "moderni".
Un'ascia e' per sempre
-
Te l'ho scritto prima: un browser web è in grado di eseguire codice php?
No. Un browser web conosce solo javascript e di conseguenza, se tu vuoi fare "cose" sul client, dovrai usare Javascript.
Ma tu stai mescolando framework front-end con il back-end e ti ripeto. Il mio pc di 10 anni fa, con una SPA "moderna", si caga addosso.
E sí, l'informatica è moda, e tutti usano Javascript non perché è intrinsecamente una scelta migliore, ma perché facebook dice che è fico fare tutto in Javascript.
Cosa dici che succede alla tua SPA se togliamo V8 da chrome, dove google ha speso miliardi per far sí che Javascript fosse gestito in maniera passabile?
La storia del "eh tutti fanno cosí" ha stancato. L'informatica è peggio del fashion e quando chiedi motivazioni tecniche VERE, quasi tutti i programmatori ti rispondono "ma Guggle fa cosí, quindi DEVE essere buono" e si segue l'hype per gonfiare il CV. Non ci sono motivazioni tecniche.
Dire che ub framework Javascript è "moderno", è stupido e insensato, dato che sul client puoi usare solo javascript.
E sí, le web app devono morire, sono lente, farragginose, inconsistenti e non ne ho trovata una che non richiedesse una centrale nucleare per funzionare, soprattutto quando scritte con framework "moderni".
@absc said in Parliamo di software 2: Dudeswave:
E sí, l'informatica è moda, e tutti usano Javascript non perché è intrinsecamente una scelta migliore, ma perché facebook dice che è fico fare tutto in Javascript.
@absc said in Parliamo di software 2: Dudeswave:
La storia del "eh tutti fanno cosí" ha stancato. L'informatica è peggio del fashion e quando chiedi motivazioni tecniche VERE, quasi tutti i programmatori ti rispondono "ma Guggle fa cosí, quindi DEVE essere buono" e si segue l'hype per gonfiare il CV. Non ci sono motivazioni tecniche.
Bho, sinceramente non mi trovate d'accordo. Per alcuni puo' essere anche cosi'. Ma mediamente, si tende a virare verso le soluzioni tecniche migliori (non tutti, per carita'), ci sono soldi dietro eh.
Se poi mi dici e dimostri che, senza javascript, puoi offrire un sito come (esempio) ferrari.com, a costi minori, ed uguale resa finale, cospargo il capo di cenere e ti daro' ragione da oggi fino all'eternita' .
-
@absc said in Parliamo di software 2: Dudeswave:
E sí, l'informatica è moda, e tutti usano Javascript non perché è intrinsecamente una scelta migliore, ma perché facebook dice che è fico fare tutto in Javascript.
@absc said in Parliamo di software 2: Dudeswave:
La storia del "eh tutti fanno cosí" ha stancato. L'informatica è peggio del fashion e quando chiedi motivazioni tecniche VERE, quasi tutti i programmatori ti rispondono "ma Guggle fa cosí, quindi DEVE essere buono" e si segue l'hype per gonfiare il CV. Non ci sono motivazioni tecniche.
Bho, sinceramente non mi trovate d'accordo. Per alcuni puo' essere anche cosi'. Ma mediamente, si tende a virare verso le soluzioni tecniche migliori (non tutti, per carita'), ci sono soldi dietro eh.
Se poi mi dici e dimostri che, senza javascript, puoi offrire un sito come (esempio) ferrari.com, a costi minori, ed uguale resa finale, cospargo il capo di cenere e ti daro' ragione da oggi fino all'eternita' .
@Aethiss said in Parliamo di software 2: Dudeswave:
Se poi mi dici e dimostri che, senza javascript, puoi offrire un sito come (esempio) ferrari.com , a costi minori, ed uguale resa finale, cospargo il capo di cenere e ti daro' ragione da oggi fino all'eternita' .
aspetta, stai chiedendo di sapere quanto cala il consumo della CPU dei server se io metto il javascript sul server, con CDN e acceleratori, o sul client come app?
La differenza e' nemmeno misurabile. Se anche metti il javascript sui server, o altri contenuti statici, un'azienda come il gruppo fiat avra' i suoi netscaler direttamente nel DC dell' ISP telefonico, dove termina il tunnel GPT, e non passi nemmeno da internet per scaricarli. Cosi' come li ha BMW, o Porsche, o chiunque altro. Si chiama edge computing.
Tutto quello di cui non fai cache sara' al massimo qualche chiamata ad un API gateway, che non e' possibile mettere in cache, ma appunto, facendo edge computing, non mi raccontare che hai tolto carico sui server se metti il javascript sul client anziche' sul server.
In linea astratta, puoi generare lo stesso javascript del sito usando unbackend erlang: lo fa per esempio Discord, che e' scritta in Elixir, che gira sulla VM di Erlang, come Scala gira su quella Java. E ha una signora UI.
Non capisco davvero questo tuo ignorare l'infrastruttura e concentrarsi sul linguaggio... sei tu, quello che sosteneva che mettere il JS sul client risparmiasse CPU sui server. Che non e' assolutamente vero.
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
@absc said in Parliamo di software 2: Dudeswave:
E sí, l'informatica è moda, e tutti usano Javascript non perché è intrinsecamente una scelta migliore, ma perché facebook dice che è fico fare tutto in Javascript.
@absc said in Parliamo di software 2: Dudeswave:
La storia del "eh tutti fanno cosí" ha stancato. L'informatica è peggio del fashion e quando chiedi motivazioni tecniche VERE, quasi tutti i programmatori ti rispondono "ma Guggle fa cosí, quindi DEVE essere buono" e si segue l'hype per gonfiare il CV. Non ci sono motivazioni tecniche.
Bho, sinceramente non mi trovate d'accordo. Per alcuni puo' essere anche cosi'. Ma mediamente, si tende a virare verso le soluzioni tecniche migliori (non tutti, per carita'), ci sono soldi dietro eh.
Se poi mi dici e dimostri che, senza javascript, puoi offrire un sito come (esempio) ferrari.com, a costi minori, ed uguale resa finale, cospargo il capo di cenere e ti daro' ragione da oggi fino all'eternita' .
Non puoi rispondere a questa domanda, per lo stesso motivo che ti dissi prima.
Che alternative ho a Javascript sul client?
Posso usare altri linguaggi di programmazione su un browser web per fare "cose"? No, non posso.
Quindi la domanda che hai posto non ha senso.
È questo che intendo quando ti dico che confondi tecnologie di back-end con tecnologie di front-end.
P.S: il sito di ferrari fa diventare il mio pc caldo come una stufa e lento come la morte!
Un'ascia e' per sempre
-
Non puoi rispondere a questa domanda, per lo stesso motivo che ti dissi prima.
Che alternative ho a Javascript sul client?
Posso usare altri linguaggi di programmazione su un browser web per fare "cose"? No, non posso.
Quindi la domanda che hai posto non ha senso.
È questo che intendo quando ti dico che confondi tecnologie di back-end con tecnologie di front-end.
P.S: il sito di ferrari fa diventare il mio pc caldo come una stufa e lento come la morte!
@absc un tempo i siti come quello di ferrari li facevano in Flash. Il concetto era lo stesso, ma anziche' scaricare un pezzo di javascript scaricavi un pezzo di flash. Il guaio era che a livello di sicurezza flash era penoso, altrimenti avrebbe probabilmente vinto su javascript.
Perche'?
Perche' a quei tempi tutti sapevano usare flash, e nessuno javascript.
Puoi sempre scrivere questo:
<script type="application/javascript" src="https://example.com/script.js"></script>e girera' uno script in javascript. Ma se scrivi:
<script type="text/html" src="https://example.com/myrest"></script>al posto del pulsante ti compare il codice html che vuoi, compreso se serve un altro pulsante.
Ci sono tanti modi per fare quel sito, anche usando object e flash.
Ha vinto javascript perche' i programmatori lo amano di piu', tutto qui.
O meglio, perche' non sanno fare nient'altro. -
Non puoi rispondere a questa domanda, per lo stesso motivo che ti dissi prima.
Che alternative ho a Javascript sul client?
Posso usare altri linguaggi di programmazione su un browser web per fare "cose"? No, non posso.
Quindi la domanda che hai posto non ha senso.
È questo che intendo quando ti dico che confondi tecnologie di back-end con tecnologie di front-end.
P.S: il sito di ferrari fa diventare il mio pc caldo come una stufa e lento come la morte!
@amigaunicorn
no, non intendevo quello. Seppure rimango della mia idea che con una web (progressive) app full client, si possano strutturare meglio i micro-servizi ed ottimizzare i consumi di questi lato server, comunque no. Era una risposta puramente di chi fa cosa. Se mi dici che puoi mettere il Javascript nel back-end, che poi cosi' una volta arrivato al browser fa il suo lavoro... bhe, che posso dire, in linea mooolto astratta si. Ti vuoi male ma si
@absc
Io sono partito dal presupposto che hai scritto tu, riguardo il tuo progetto. Se mi dici che stai implementando una parte back-end che fa quello che hai scritto, ok. Io non userei Erlang, ma queste sono solo opinioni. Se avevo capito male, e cioe' che faceva anche la parte di sputare l'html del blog (o qualsiasi altra cosa debba fare sul web), ci siamo semplicemente non capiti (io non ho capito).
Se invece lo vuoi fare.. meh, per me e' un no ! (cit
) -
@Aethiss said in Parliamo di software 2: Dudeswave:
Se poi mi dici e dimostri che, senza javascript, puoi offrire un sito come (esempio) ferrari.com , a costi minori, ed uguale resa finale, cospargo il capo di cenere e ti daro' ragione da oggi fino all'eternita' .
aspetta, stai chiedendo di sapere quanto cala il consumo della CPU dei server se io metto il javascript sul server, con CDN e acceleratori, o sul client come app?
La differenza e' nemmeno misurabile. Se anche metti il javascript sui server, o altri contenuti statici, un'azienda come il gruppo fiat avra' i suoi netscaler direttamente nel DC dell' ISP telefonico, dove termina il tunnel GPT, e non passi nemmeno da internet per scaricarli. Cosi' come li ha BMW, o Porsche, o chiunque altro. Si chiama edge computing.
Tutto quello di cui non fai cache sara' al massimo qualche chiamata ad un API gateway, che non e' possibile mettere in cache, ma appunto, facendo edge computing, non mi raccontare che hai tolto carico sui server se metti il javascript sul client anziche' sul server.
In linea astratta, puoi generare lo stesso javascript del sito usando unbackend erlang: lo fa per esempio Discord, che e' scritta in Elixir, che gira sulla VM di Erlang, come Scala gira su quella Java. E ha una signora UI.
Non capisco davvero questo tuo ignorare l'infrastruttura e concentrarsi sul linguaggio... sei tu, quello che sosteneva che mettere il JS sul client risparmiasse CPU sui server. Che non e' assolutamente vero.
Non capisco davvero questo tuo ignorare l'infrastruttura e concentrarsi sul linguaggio... sei tu, quello che sosteneva che mettere il JS sul client risparmiasse CPU sui server. Che non e' assolutamente vero.
Probabilmente è solo un programmatore... (dai, ci si sfotte).
-
@amigaunicorn
no, non intendevo quello. Seppure rimango della mia idea che con una web (progressive) app full client, si possano strutturare meglio i micro-servizi ed ottimizzare i consumi di questi lato server, comunque no. Era una risposta puramente di chi fa cosa. Se mi dici che puoi mettere il Javascript nel back-end, che poi cosi' una volta arrivato al browser fa il suo lavoro... bhe, che posso dire, in linea mooolto astratta si. Ti vuoi male ma si@absc
Io sono partito dal presupposto che hai scritto tu, riguardo il tuo progetto. Se mi dici che stai implementando una parte back-end che fa quello che hai scritto, ok. Io non userei Erlang, ma queste sono solo opinioni. Se avevo capito male, e cioe' che faceva anche la parte di sputare l'html del blog (o qualsiasi altra cosa debba fare sul web), ci siamo semplicemente non capiti (io non ho capito).
Se invece lo vuoi fare.. meh, per me e' un no ! (cit )@Aethiss said in Parliamo di software 2: Dudeswave:
Seppure rimango della mia idea che con una web (progressive) app full client, si possano strutturare meglio i micro-servizi ed ottimizzare i consumi di questi lato server,
come se fosse antani. Il punto e' che hai un client e un server. Il resto della supercazzola non serve a nulla. Se mi metto sulla rete e sniffo il traffico, non vedo passare niente di tutto questo. Vedo passare traffico. Vedo passare il tuo javascript, come potrei veder passare flash, e come un tempo vedevo passare applet java, e altro e altro e altro.
Se mi dici che puoi mettere il Javascript nel back-end, che poi cosi' una volta arrivato al browser fa il suo lavoro... bhe, che posso dire, in linea mooolto astratta si. Ti vuoi male ma si
non mi voglio affatto male, perche' alla fine anche sul tuo cellulare e' sempre un client che lo fa girare. E ho migliaia di tool a disposizione per fare in modo che la latenza che conta in realta' sia quella del tuo lentissimo schermo da cellulare. Te lo ripeto: se ho un accordo con la telco, metto un netscaler a fare cache direttamente nell'infrastruttura dell' ISP, dove termina il tunnel GPT del tuo cellulare. E praticamente, hai il javascript al massimo della banda.
Cosa mi cambia, alla fine? Quasi il 100% delle automobili "connected mobility" funzionano cosi'. Mica in Javascript.
Il carico sui server cala di pochissimo. Conosco un'azienda di auto che gestisce otto milioni di auto continuamente connesse, ogni volta che sono accese, e non usa javascript, al massimo fa passare del json. E per 8 milioni di auto paga circa 50K/mese al suo cloud.
Davvero pensi che risparmierebbe molto se mettesse il javascript sull'auto, sotto forma di app?
Molti ci hanno provato. Ci hanno provato e hanno fallito? Ci hanno provato e sono morti. (cit. Reverenda Madre bene Gesserit, dune)Perche'? Perche' la distribuzione di software su dispositivi embedded e' un casino. L'auto parte, scarica il JS , lo esegue in locale comincia la magia.
Del resto, Whatsapp e' scritto in Erlang sul backend, e non mi sembra che abbia particolari problemi di performance.
Ma alla fine, per esempio, il JS di cui parlo nelle auto non e' certo scaricato da un server con node.js, nel caso delle auto e' in Java.
Davvero, non capisco la tua attenzione verso il particolare linguaggio.
-
@amigaunicorn
no, non intendevo quello. Seppure rimango della mia idea che con una web (progressive) app full client, si possano strutturare meglio i micro-servizi ed ottimizzare i consumi di questi lato server, comunque no. Era una risposta puramente di chi fa cosa. Se mi dici che puoi mettere il Javascript nel back-end, che poi cosi' una volta arrivato al browser fa il suo lavoro... bhe, che posso dire, in linea mooolto astratta si. Ti vuoi male ma si@absc
Io sono partito dal presupposto che hai scritto tu, riguardo il tuo progetto. Se mi dici che stai implementando una parte back-end che fa quello che hai scritto, ok. Io non userei Erlang, ma queste sono solo opinioni. Se avevo capito male, e cioe' che faceva anche la parte di sputare l'html del blog (o qualsiasi altra cosa debba fare sul web), ci siamo semplicemente non capiti (io non ho capito).
Se invece lo vuoi fare.. meh, per me e' un no ! (cit )Se fossi un programmatore web esperto, magari farei come faresti tu. Servirei dal back-end un bundle Javascript, che poi farebbe chiamate XMLHttpRequest al back-end in erlang. Userei forse delle API Json. ok.
Ma io non sono un programmatore web.
Renderizzare del banale HTML lato server ed inviarlo al browser è facile. Templating engines ne esistono a iosa e quella parte addirittura l'ho già fatta.
Nessuno mi impedirà di migrare verso un modello piú evoluto sul client in futuro, ma al momento non ne ho bisogno, anche se ci avevo pensato.
Un'ascia e' per sempre
-
Se fossi un programmatore web esperto, magari farei come faresti tu. Servirei dal back-end un bundle Javascript, che poi farebbe chiamate XMLHttpRequest al back-end in erlang. Userei forse delle API Json. ok.
Ma io non sono un programmatore web.
Renderizzare del banale HTML lato server ed inviarlo al browser è facile. Templating engines ne esistono a iosa e quella parte addirittura l'ho già fatta.
Nessuno mi impedirà di migrare verso un modello piú evoluto sul client in futuro, ma al momento non ne ho bisogno, anche se ci avevo pensato.
@absc Rinnovo quello che ho gia' detto. Compatibilmente con i miei tempi a disposizione, si, e volentieri. Davvero.
@amigaunicorn
sti cercando di convincermi di una cosa sul quale sono gia' d'accordo.
pero' io punto la luna e tu guardi il dito.Parlando solo di "web", perche' altrimenti cade il discorso. Posso "scaricare" la mia "macchina" dove c'e' il web-server dal lavoro di fornire html ad ogni richiesta ? Si.
Aiuta nel strutturare i miei micro-servizi (login, categorie-dei-mondi-degli-arkonnen, pagamenti o quello che vuoi). Si.
Posso ovviare al carico del lavoro del web-server e del linguaggio che gira sulla macchina (php o chi vuoi) con una CDN. Si. Sarebbe uguale, no. Dipende da cosa fa il "sito", avra' dei costi differenti.
Posso ammortizzare tali costi. Si.Eh no, seppur programmo ancora (mi piace sempre tanto), qualche infrastruttura medio-grande (tipo 40 milioni di sterline al black-friday, 80 milioni di accessi unici in 3 gg [lo so che per quelli grossi davvero sono numeretti eh]) ci ho lavorato. E non per mettere su i css
-
@absc Rinnovo quello che ho gia' detto. Compatibilmente con i miei tempi a disposizione, si, e volentieri. Davvero.
@amigaunicorn
sti cercando di convincermi di una cosa sul quale sono gia' d'accordo.
pero' io punto la luna e tu guardi il dito.Parlando solo di "web", perche' altrimenti cade il discorso. Posso "scaricare" la mia "macchina" dove c'e' il web-server dal lavoro di fornire html ad ogni richiesta ? Si.
Aiuta nel strutturare i miei micro-servizi (login, categorie-dei-mondi-degli-arkonnen, pagamenti o quello che vuoi). Si.
Posso ovviare al carico del lavoro del web-server e del linguaggio che gira sulla macchina (php o chi vuoi) con una CDN. Si. Sarebbe uguale, no. Dipende da cosa fa il "sito", avra' dei costi differenti.
Posso ammortizzare tali costi. Si.Eh no, seppur programmo ancora (mi piace sempre tanto), qualche infrastruttura medio-grande (tipo 40 milioni di sterline al black-friday, 80 milioni di accessi unici in 3 gg [lo so che per quelli grossi davvero sono numeretti eh]) ci ho lavorato. E non per mettere su i css
@Aethiss said in Parliamo di software 2: Dudeswave:
Eh no, seppur programmo ancora (mi piace sempre tanto), qualche infrastruttura medio-grande (tipo 40 milioni di sterline al black-friday, 80 milioni di accessi unici in 3 gg [lo so che per quelli grossi davvero sono numeretti eh]) ci ho lavorato. E non per mettere su i css
non capisco, allora perche' insisti? sai benissimo che una volta fatto il backend, OGGI o spedisci javascript o spedisci JSON. Ma sai anche benissimo che non e' la cosa piu' efficente. Si sono fatte cose ben piu' belle di quel sito ferrari usando flash, ai suoi tempi.
Solo che flash ha perso.
Parlando di html, non hai bisogno di renderizzarlo ogni volta. Lo puoi renderizzare per user-agent, e a quel punto la cache non ti richiedera' di renderizzarlo ogni volta. Cosa cambia se la renderizzi con una macchina virtuale node.js o con una che lavora con erlang?
-
@absc Rinnovo quello che ho gia' detto. Compatibilmente con i miei tempi a disposizione, si, e volentieri. Davvero.
@amigaunicorn
sti cercando di convincermi di una cosa sul quale sono gia' d'accordo.
pero' io punto la luna e tu guardi il dito.Parlando solo di "web", perche' altrimenti cade il discorso. Posso "scaricare" la mia "macchina" dove c'e' il web-server dal lavoro di fornire html ad ogni richiesta ? Si.
Aiuta nel strutturare i miei micro-servizi (login, categorie-dei-mondi-degli-arkonnen, pagamenti o quello che vuoi). Si.
Posso ovviare al carico del lavoro del web-server e del linguaggio che gira sulla macchina (php o chi vuoi) con una CDN. Si. Sarebbe uguale, no. Dipende da cosa fa il "sito", avra' dei costi differenti.
Posso ammortizzare tali costi. Si.Eh no, seppur programmo ancora (mi piace sempre tanto), qualche infrastruttura medio-grande (tipo 40 milioni di sterline al black-friday, 80 milioni di accessi unici in 3 gg [lo so che per quelli grossi davvero sono numeretti eh]) ci ho lavorato. E non per mettere su i css
Posso "scaricare" la mia "macchina" dove c'e' il web-server dal lavoro di fornire html ad ogni richiesta ? Si.
Aiuta nel strutturare i miei micro-servizi (login, categorie-dei-mondi-degli-arkonnen, pagamenti o quello che vuoi). Si.
Posso ovviare al carico del lavoro del web-server e del linguaggio che gira sulla macchina (php o chi vuoi) con una CDN. Si. Sarebbe uguale, no. Dipende da cosa fa il "sito", avra' dei costi differenti.
Posso ammortizzare tali costi. Si.Io a questo punto fallisco nel capire cosa c'entri il linguaggio di programmazione usato per la parte back-end. Sul serio, non ci arrivo.
Erlang lo uso per il back-end, per servire risorse e in teoria nessuno mi vieterebbe di costruire una SPA con un back-end Erlang, usando cowboy come webserver.
Un altro punto che non comprendo: dove andrebbe a prendere il bundle del codice dell'applicazione il browser web dell'utente se non dal mio back-end? Una qualche CDN? Dove?
Un'ascia e' per sempre
-
Posso "scaricare" la mia "macchina" dove c'e' il web-server dal lavoro di fornire html ad ogni richiesta ? Si.
Aiuta nel strutturare i miei micro-servizi (login, categorie-dei-mondi-degli-arkonnen, pagamenti o quello che vuoi). Si.
Posso ovviare al carico del lavoro del web-server e del linguaggio che gira sulla macchina (php o chi vuoi) con una CDN. Si. Sarebbe uguale, no. Dipende da cosa fa il "sito", avra' dei costi differenti.
Posso ammortizzare tali costi. Si.Io a questo punto fallisco nel capire cosa c'entri il linguaggio di programmazione usato per la parte back-end. Sul serio, non ci arrivo.
Erlang lo uso per il back-end, per servire risorse e in teoria nessuno mi vieterebbe di costruire una SPA con un back-end Erlang, usando cowboy come webserver.
Un altro punto che non comprendo: dove andrebbe a prendere il bundle del codice dell'applicazione il browser web dell'utente se non dal mio back-end? Una qualche CDN? Dove?
@absc said in Parliamo di software 2: Dudeswave:
Io a questo punto fallisco nel capire cosa c'entri il linguaggio di programmazione usato per la parte back-end. Sul serio, non ci arrivo.
@amigaunicorn sostiene, che un servizio che gira (node, php o quello che vuoi) che deve fornire dell'html (ripeto questo punto eh, un servizio web, che ritorna un html bello pronto che il tuo browser ti mostra), con i dovuti "accorgimenti" (cdn) non debba essere "chiamato" dinamicamente ad ogni sezione.
Io dico che si, e' vero, ma una cdn non ha senso che cachi tutto. Io dico che un app js, una volta ricevuto il bundle js (sempre di "servizio" in un server che restituisce, un html), e' piu' performante, e non ti serve richiamare quel servizio ad ogni pagina.E' pur sempre vero, come altresi' fatto notare da @amigaunicorn , che puoi scrivere
<html> <script type='text/javascript' src='il-path-del-mio-js'></script> ....ed ottieni (se vuoi) lo stesso risultato. Io sostengo che a quel punto ci sono framework (aimhe' in quel linguaggio di merda che e' js), che gia' lo fanno, e lo fanno meglio. Tutto qui' .
-
@absc said in Parliamo di software 2: Dudeswave:
Io a questo punto fallisco nel capire cosa c'entri il linguaggio di programmazione usato per la parte back-end. Sul serio, non ci arrivo.
@amigaunicorn sostiene, che un servizio che gira (node, php o quello che vuoi) che deve fornire dell'html (ripeto questo punto eh, un servizio web, che ritorna un html bello pronto che il tuo browser ti mostra), con i dovuti "accorgimenti" (cdn) non debba essere "chiamato" dinamicamente ad ogni sezione.
Io dico che si, e' vero, ma una cdn non ha senso che cachi tutto. Io dico che un app js, una volta ricevuto il bundle js (sempre di "servizio" in un server che restituisce, un html), e' piu' performante, e non ti serve richiamare quel servizio ad ogni pagina.E' pur sempre vero, come altresi' fatto notare da @amigaunicorn , che puoi scrivere
<html> <script type='text/javascript' src='il-path-del-mio-js'></script> ....ed ottieni (se vuoi) lo stesso risultato. Io sostengo che a quel punto ci sono framework (aimhe' in quel linguaggio di merda che e' js), che gia' lo fanno, e lo fanno meglio. Tutto qui' .
no, piano con gli straw man argument. Con me non funzionano.
Sei tu che te ne sei uscito col fatto che se usi il bundle javascript, allora tutto il lavoro si sposta dalla CPU del server alla CPU del mobile.
Ed e', ripeto, una catastrofica cazzata, della quale non riuscirai MAI, per OVVIE ragioni, a produrre alcuna prova o test che lo confermi, nel caso ci sia un'infrastruttura decente, con gli acceleratori nel frontend e le CDN.Generare HTML o generare JSON, di cui la tua "bundle" si nutre, per una CPU e' uguale, in termini di sforzo, o quasi. E non voglio parlare di quando usate dei cazzo di graph database sul backend , o Jquery, e nessuno dei due gira sul frontend. Che differenza faccia, secondo te, per la CPU del server tra generarti pagine web statiche o json, lo sai solo tu.
Poi, dentro la tua stanzetta di developers puoi usare i soliti termini mai definiti, tipo 'ottimizzare". Noi di operations invece parliamo di KPI,
e no, non si e' mai vista traccia, sulle CPU dei server, di alcuna "ottimizzazione", se scarichi il bundle da una CDN, o ce l'hai che gira sul cellulare.Quella e' soltanto l'unica tecnologia che il developer moderno sa usare, sull'unico protocollo che conosce parzialmente, cioe' HTTP. Ed e' per questo che va forte.
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
undefined philotette referenced this topic
-
no, piano con gli straw man argument. Con me non funzionano.
Sei tu che te ne sei uscito col fatto che se usi il bundle javascript, allora tutto il lavoro si sposta dalla CPU del server alla CPU del mobile.
Ed e', ripeto, una catastrofica cazzata, della quale non riuscirai MAI, per OVVIE ragioni, a produrre alcuna prova o test che lo confermi, nel caso ci sia un'infrastruttura decente, con gli acceleratori nel frontend e le CDN.Generare HTML o generare JSON, di cui la tua "bundle" si nutre, per una CPU e' uguale, in termini di sforzo, o quasi. E non voglio parlare di quando usate dei cazzo di graph database sul backend , o Jquery, e nessuno dei due gira sul frontend. Che differenza faccia, secondo te, per la CPU del server tra generarti pagine web statiche o json, lo sai solo tu.
Poi, dentro la tua stanzetta di developers puoi usare i soliti termini mai definiti, tipo 'ottimizzare". Noi di operations invece parliamo di KPI,
e no, non si e' mai vista traccia, sulle CPU dei server, di alcuna "ottimizzazione", se scarichi il bundle da una CDN, o ce l'hai che gira sul cellulare.Quella e' soltanto l'unica tecnologia che il developer moderno sa usare, sull'unico protocollo che conosce parzialmente, cioe' HTTP. Ed e' per questo che va forte.
@amigaunicorn said in Parliamo di software 2: Dudeswave:
. E non voglio parlare di quando usate dei cazzo di graph database sul backend , o Jquery, e nessuno dei due gira sul frontend.
Sinceramente non so che intendi. Forse graphql? JQuery, se intendiamo la stessa cosa, cosa centri con il back-end non lo so. Forse intendiamo cose diverse.
Sul resto…Bho, come ho detto qualche post fa, non sono d’accordo, ma rispetto la tua competenza e le tue posizioni.
Io dovevo “gestire” un e-commerce con migliaia di items.
Ho sbattuto la testa sui costi/configurazione della cdn (Akamai). Io ero un supervisore, gli esperti ci mettevano le mani. Il sito mobile era un app in react, il desktop era ancora un vecchio mix di php e amenie varie.
Diciamo che 2 o 3 cose le ho viste su come dovevano scalare i server a seconda del carico.
Forse eravamo scarsi noi, tutto può essere. -
@amigaunicorn said in Parliamo di software 2: Dudeswave:
. E non voglio parlare di quando usate dei cazzo di graph database sul backend , o Jquery, e nessuno dei due gira sul frontend.
Sinceramente non so che intendi. Forse graphql? JQuery, se intendiamo la stessa cosa, cosa centri con il back-end non lo so. Forse intendiamo cose diverse.
Sul resto…Bho, come ho detto qualche post fa, non sono d’accordo, ma rispetto la tua competenza e le tue posizioni.
Io dovevo “gestire” un e-commerce con migliaia di items.
Ho sbattuto la testa sui costi/configurazione della cdn (Akamai). Io ero un supervisore, gli esperti ci mettevano le mani. Il sito mobile era un app in react, il desktop era ancora un vecchio mix di php e amenie varie.
Diciamo che 2 o 3 cose le ho viste su come dovevano scalare i server a seconda del carico.
Forse eravamo scarsi noi, tutto può essere.stai mescolando cose che non c'entrano niente. Il database di backend di un sito di e-commerce di certo non gira sul tuo cellulare. gira sul backend. qualsiasi cosa tu metti sul cellulare chiamera' indietro per avere dei dati. Il punto e' molto semplice: alla fine il server consuma CPU solo per dare dei dati a qualsiasi cosa giri sul cellulare. E non c'e' modo di fuggire da questo.
Ma a questo punto ho un dubbio: secondo te, cosa gira sul cellulare, di preciso, e cosa gira sui backend? Che cosa, secondo te, consuma CPU sui server, e che cosa sul client?
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
stai mescolando cose che non c'entrano niente. Il database di backend di un sito di e-commerce di certo non gira sul tuo cellulare. gira sul backend. qualsiasi cosa tu metti sul cellulare chiamera' indietro per avere dei dati. Il punto e' molto semplice: alla fine il server consuma CPU solo per dare dei dati a qualsiasi cosa giri sul cellulare. E non c'e' modo di fuggire da questo.
Ma a questo punto ho un dubbio: secondo te, cosa gira sul cellulare, di preciso, e cosa gira sui backend? Che cosa, secondo te, consuma CPU sui server, e che cosa sul client?
@amigaunicorn said in Parliamo di software 2: Dudeswave:
stai mescolando cose che non c'entrano niente. Il database di backend di un sito di e-commerce di certo non gira sul tuo cellulare. gira sul backend.
Scusa, mi trovi dove mai ho scritto questo ?
@amigaunicorn said in Parliamo di software 2: Dudeswave:
Ma a questo punto ho un dubbio: secondo te, cosa gira sul cellulare, di preciso, e cosa gira sui backend? Che cosa, secondo te, consuma CPU sui server, e che cosa sul client?
sul cellulare, ma sarebbe piu' appropriato dire sul browser, e' indifferente mobile o desktop. (sempre web eh, non stavo parlando di app native), gira solo html & javascript. Niente altro.
forse ha tratto in inganno quando ho scritto "sito mobile". Spiego meglio, quando un browser accedeva sul sito, veniva intercettata la richiesta, se era un dispositivo mobile, gli si dava in pasto un app in react, ottimizzata per l'uso in un browser di un cellulare, altrimenti andava sulla versione legacy.
-
@amigaunicorn said in Parliamo di software 2: Dudeswave:
stai mescolando cose che non c'entrano niente. Il database di backend di un sito di e-commerce di certo non gira sul tuo cellulare. gira sul backend.
Scusa, mi trovi dove mai ho scritto questo ?
@amigaunicorn said in Parliamo di software 2: Dudeswave:
Ma a questo punto ho un dubbio: secondo te, cosa gira sul cellulare, di preciso, e cosa gira sui backend? Che cosa, secondo te, consuma CPU sui server, e che cosa sul client?
sul cellulare, ma sarebbe piu' appropriato dire sul browser, e' indifferente mobile o desktop. (sempre web eh, non stavo parlando di app native), gira solo html & javascript. Niente altro.
forse ha tratto in inganno quando ho scritto "sito mobile". Spiego meglio, quando un browser accedeva sul sito, veniva intercettata la richiesta, se era un dispositivo mobile, gli si dava in pasto un app in react, ottimizzata per l'uso in un browser di un cellulare, altrimenti andava sulla versione legacy.
@Aethiss ma non hai risposto alla domanda. cosa fa la app, di preciso, per consumare la CPU sul cellulare?
Perche' sinora stai descrivendo quello che IO ho cercato di dire, ovvero che qualcuno legge il tuo user-agent della chiamata http, e gli fornisce un contenuto statico. Va bene ma in che modo questo ti ha salvato CPU sui server? Nel senso che, cosa fanno i server, di preciso, per consumare CPU, che adesso non consumano piu' perche' hai il javascript sul client?
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
