vaadin - gwt

[Davide]

Ciao,

volevo chiedervi un aiuto per una piccola indagine.

Voi lavorate o conoscete persone/aziende che professionalmente usano
vaadin o gwt?

Se si, che tipo di prodotti sviluppate/no, ecc? Quali sono le vostre
esperienze?

Come li vedete in rapporto al boom javascript nell'ambito però dello
sviluppo di applicazioni medio/grandi (e non di siti web)?

[Andrea Selva]

Ma Vaadin e GWT si usano ancora?

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+unsubscribe@googlegroups.com.
To post to this group, send email to jug...@googlegroups.com.
Visit this group at https://groups.google.com/group/jugtaa.
For more options, visit https://groups.google.com/d/optout.

[Mirco Attocchi]

Belle domande Davide.

Io ho dubbio forte du JS per prodotti commerciali e/o progetti medie dimensioni (e lunga durata). 

Lavoro già in JS ma ... GWT rimane mio "dubbio" per questo tipo di progetti. Ho contattato di recente Vaadin per capire loro strategia concorrenza JS e valutare se possibile adozione per progetti - ad oggi ho ancora dubbi.

Mirco

[Luca Guadagnini]

Ho usato Vaadin per un breve periodo. Abbastanza comodo programmarci, ma un disastro a livello di prestazioni. Lo ho abbandonato quando ho avuto a che fare con tuning e corbellerie che ti suggeriscono per evitare l'overhead che lo stesso framework introduce. L'unico «pregio» che ha è che se devi sviluppare un front-end per il web e hai a disposizione solo programmatori Java che hanno sviluppato interfacce desktop, ti permette di avere lo stesso approccio di programmazione di quest'ultimi.

Altro non ci sta a mio avviso.

Con JS abbiamo sviluppato anche applicazioni di media grandezza, a far da padrone qui non è tanto il linguaggio o il framework in uso, ma il rigore nello sviluppo. JS è un linguaggio che in meno di un nano secondo ti permette di fare tutto e di mandare tutto a carciofi. Prima di adottare un qualsiasi framework chiacchierato (AngularJS, Angular 2 o 4, Aurelia, React/Redux o VueJS o altri ancora), bisogna davvero saper domare JS (domarlo è quasi più importante di impararlo), perché di fondo è un linguaggio di programmazione che non è nato per essere un linguaggio di programmazione.

On Wednesday, 6 September 2017 12:52:03 UTC+2, Mirco Attocchi wrote:

Belle domande Davide.

Io ho dubbio forte du JS per prodotti commerciali e/o progetti medie dimensioni (e lunga durata). 

Lavoro già in JS ma ... GWT rimane mio "dubbio" per questo tipo di progetti. Ho contattato di recente Vaadin per capire loro strategia concorrenza JS e valutare se possibile adozione per progetti - ad oggi ho ancora dubbi.

Mirco

Il 06 set 2017 12:34 PM, "Andrea Selva" <selva...@gmail.com> ha scritto:

Ma Vaadin e GWT si usano ancora?

2017-09-06 12:31 GMT+02:00 Davide <d...@vide.bz>:

Ciao,

volevo chiedervi un aiuto per una piccola indagine.

Voi lavorate o conoscete persone/aziende che professionalmente usano vaadin o gwt?

Se si, che tipo di prodotti sviluppate/no, ecc? Quali sono le vostre esperienze?

Come li vedete in rapporto al boom javascript nell'ambito però dello sviluppo di applicazioni medio/grandi (e non di siti web)?

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+un...@googlegroups.com.

To post to this group, send email to jug...@googlegroups.com.
Visit this group at https://groups.google.com/group/jugtaa.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+un...@googlegroups.com.

[Davide]

On 06/09/2017 14:04, Luca Guadagnini wrote:
> Ho usato Vaadin per un breve periodo. Abbastanza comodo programmarci, ma
> un disastro a livello di prestazioni. Lo ho abbandonato quando ho avuto
> a che fare con tuning e corbellerie che ti suggeriscono per evitare
> l'overhead che lo stesso framework introduce.

Ciao Luca, mi sapresti quantificare a spanne a che grandezza dell'app
avevi questi problemi? Tipo un ordine di grandezza di classi o linee di
codice?

> JS è un linguaggio che in
> meno di un nano secondo ti permette di fare tutto e di mandare tutto a
> carciofi.

E' lo stesso mio pensiero. Il fatto per esempio che se fai un "typo" nel
assegnare una variabile e invece di darti un errore ne crea una nuova a
livello globale ... non mi sembra una cosa utile al programmatore ...

Come alternativa a vaadin non avevi pensato a gwt?

[Mario Alexandro Santini]

2017-09-06 14:27 GMT+02:00 Davide <d...@vide.bz>:

E' lo stesso mio pensiero. Il fatto per esempio che se fai un "typo" nel assegnare una variabile e invece di darti un errore ne crea una nuova a livello globale ... non mi sembra una cosa utile al programmatore ...

Siamo nel 2017 e ci sono strumenti di sviluppo che aiutano a risolvere questi problemi.

E se uno non vuole proprio usare nulla, ma ha problemi di questo genere potrebbe quantomeno utilizzare:

"use strict"

in test ai propri file Javascript e vedra' un po' di errori in piu'..

--

 Mario

[Mirko Perillo]

Concordo con Mario,

Aggiungo da utilizzatore sporadico e ignorante di javascript che si puo' valutare anche di introdurre qualcosa come Typescript. Lo sto usando da poco, ma, per me che ho un background quasi esclusivamente Java, devo dire che sta allietando il mio  impatto con javascript.

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+unsubscribe@googlegroups.com.

[Davide]

On 06/09/2017 14:30, Mario Alexandro Santini wrote:
> "use strict"
>
> in test ai propri file Javascript e vedra' un po' di errori in piu'..
>

Si ma proprio in minimo ... già questo non me lo individua più

"use strict"
var abc = {}
abc.name = 'davde'
// ....
abc.nome = 'davide'
console.log(abc.name)

[Mirco Attocchi]

Classi Javascript non esistono (zucchero sintattico si dice? ;D), gli
oggetti sono Mappe "chiave-valore", quindi quello non è un errore ;D

Mirco

[Mario Alexandro Santini]

On Wed, Sep 6, 2017 at 3:01 PM, Davide <d...@vide.bz> wrote:

Si ma proprio in minimo ... già questo non me lo individua più

   "use strict"
   var abc = {}
   abc.name = 'davde'
   // ....
   abc.nome = 'davide'
   console.log(abc.name)

Per la tua incolumita' fisica non mostrare questo codice in qualche gruppo di programmatori Javascript.

:D

Questo perche' da qualche tempo c'e' un thread di sviluppo functional in Javascript e per il fatto di provare a cambiare lo stato ti concerebbero per le feste...

:)

Quello che posso dirti io e' che il codice che hai scritto, se proprio non in un banale esempio, e' considerata una pessima pratica in Javascript.

dovresti avere:

class Person {

    constructor(name) {

       this.name = name;

    }

    // Se proprio lo vuoi cambiare...

   setName(name) {

       this.name = name;

   }

   getName() {

       return this.name;

   }

}

const abc = new Person("davde");

abc.setName("davide");

puoi anche fare:

function createPerson(name) {

    const _person = {name}

    _person.setName = name => {_person.name = name}

    _person.getName = _ => _person.name

    return { ..._person }

}

const abc = createPerson("davde");

abc.setName("davide");

Ho usato es 2017 che non funziona su tutti i browser, ma e' sintassi ufficiale e quindi si capisce l'intento.

Non creare mai un oggetto 'al volo' se non in un costruttore come nell'esempio sopra.

Non usare piu' var ma const o let.

I due esempi sopra non sono solo zucchero sintattico.

Le classi hanno un vantaggio prestazionale rispetto alla creazione di oggetti.

Tuttavia questa differenza e' talmente piccola che uno puo' scegliere l'approccio che ritiene piu' leggibile e comodo per lui.

In genere in Javascript, ma non solo (anche in Java a volte), la composizione e' ritenuta migliore rispetto all'ereditarieta' fra classi.

--

 Mario

[Mario Alexandro Santini]

2017-09-06 12:31 GMT+02:00 Davide <d...@vide.bz>:

Rispondendo alla tua domanda, invece. :)

Qui usavamo: Zk, ExtJS fino alla v4.0, jQuery

ExtJS e' fuori corso.

Zk ha una licenza open source, e si puo' acquistare anche il supporto.

Ha il problema di vincolare a Java il backend e per noi non va bene.

Ma in generale e' sempre meglio essere "agnostici", nel caso si debba fare una web app su un back-end gia' esistente ad esempio.

jQuery, con le ultime specifiche Javascript ha perso molto appeal.

Ora da noi ci sono progetti con Angular 2 o 4 (non ho capito ancora).

Io, invece, uso React + Redux.

In genere vedo che Angular 2 e' piuttosto diffuso per grandi progetti.

AngulaJS (o versione 1) va bene per piccole app ma pare non scali bene.

Altro framework interessante e' Vue, ma noi non lo usiamo e non lo conosco, ne sento parlare parecchio bene.

Molti preferiscono anche il Vanilla Javascript.

--

 Mario

[Davide]

On 06/09/2017 16:23, Mario Alexandro Santini wrote:
> ExtJS e' fuori corso.

che significa fuori corso?

[Mario Alexandro Santini]

Sencha, l'azienda che lo mantiene si e' dedicata soprattutto al mobile.

Non lo vedo piu' utilizzato in giro, e non se ne parla piu'.

--

 Mario

[Chris Mair]

>> "use strict"
>>
>> in test ai propri file Javascript e vedra' un po' di errori in piu'..
>>
>
> Si ma proprio in minimo ... già questo non me lo individua più
>
>    "use strict"
>    var abc = {}
>    abc.name = 'davde'
>    // ....
>    abc.nome = 'davide'
>    console.log(abc.name)

D'accordo sulle limitazioni di "use strict", ma il tuo esempio non vale ;)

Se creai una HashMap<String,String> in Java, ci puoi pure mettere tutte le key che vuoi!
Il tuo esempio sarebbe come fare x.put("nome", ...) e x.put("name", ...)...

Bye,
Chris.

[Davide]

On 06/09/2017 16:00, Mario Alexandro Santini wrote:
> Questo perche' da qualche tempo c'e' un thread di sviluppo functional in
> Javascript e per il fatto di provare a cambiare lo stato ti concerebbero
> per le feste...

Ciao,

questo tipo di motivazioni mi fanno pensare che non si abbiano più
argomenti di confronto e si usino discorsi stile "bullismo".
A questo livello a me non interessa discutere.

Tra l'altro il mio esempio era un astrazione.

Prendiamo un esempio concreto non mio ma del w3c:

document.body.style.backgroundColore = 'red'

Qui lo stato si modifica direttamente? Quindi?

Peccato che nel comando prima il colore non viene settato per un errore
di sintassi e nessuno strumento me lo dice.

[Davide]

On 06/09/2017 18:49, Chris Mair wrote:
> D'accordo sulle limitazioni di "use strict", ma il tuo esempio non vale ;)
>
> Se creai una HashMap<String,String> in Java, ci puoi pure mettere tutte
> le key che vuoi!
> Il tuo esempio sarebbe come fare x.put("nome", ...) e x.put("name", ...)...

Ciao Chris,

certo in javascript gli oggetti sono tipo delle hashmap java.

Ma cercate di capire il mio punto di vista che non è di parte.

Questa potenza certo è bella per certi versi. Ci sono casi in cui è
molto comoda.

La mia osservazione è che io, come programmatore, nel 99% dei casi non
volevo creare una variabile implicita nel caso faccio un errore di
scrittura.

[Mario Alexandro Santini]

2017-09-06 19:44 GMT+02:00 Davide <d...@vide.bz>:

Ciao,

questo tipo di motivazioni mi fanno pensare che non si abbiano più argomenti di confronto e si usino discorsi stile "bullismo".
A questo livello a me non interessa discutere.

Ti è scappato lo smile :D che c'era in fondo alla frase.

Nessun bullismo.

Ci sono motivi molto validi per avere uno stato non modificabile ed hanno a che fare con il codice che funziona in concorrenza (non proprio il multithreading).

Peraltro anche in Java si sta introducendo come guideline di mettere tutto "final".

In rust, un nuovo linguaggio di programmazione di basso livello è tutto non modificabile per default e devi dire esplicitamente se qualcosa la vuoi modificare (il contrario rispetto a C, C++ e Java).

 

Tra l'altro il mio esempio era un astrazione.

Lo erano anche i miei sul come si fanno certe cose in javascript.

 

Prendiamo un esempio concreto non mio ma del w3c:

document.body.style.backgroundColore = 'red'

Qui lo stato si modifica direttamente? Quindi?

Peccato che nel comando prima il colore non viene settato per un errore di sintassi e nessuno strumento me lo dice.

Calma, se c'è un errore di sintassi gli editor, anche vim, con i dovuti plugin te lo segnano!

Ti ripeto:

1. se vuoi un codice più efficiente e più rigido ai dettami delle specifiche usa "use strict" in cima ai tuoi file.

2. usa un editor o IDE adatto a Javascript che ti segnala errori di sintassi e tante altre cose

3. usa strumenti come jslint che analizzano il codice e ti dicono dove c'è "puzza"

4. evita di usare assegnazioni dinamiche e usa le funzioni, sono il cuore del linguaggio.

5. test test test test test test

6. ho già parlato di test?

Di recente ho visto un bel progetto:

https://github.com/MasayoshiSugimoto/JsPong

Quando hai tempo dagli un'occhio.

E' scritto un modo vecchio stile, ma è scritto bene.

Se vuoi vederlo funzionare:

https://masayoshisugimoto.github.io/JsPong/

sinistra: w su, s giù

destra: freccia su e freccia giù.

--

 Mario

[Mario Alexandro Santini]

On Wed, Sep 6, 2017 at 6:49 PM, Chris Mair <ch...@1006.org> wrote:

D'accordo sulle limitazioni di "use strict", ma il tuo esempio non vale ;)

Se creai una HashMap<String,String> in Java, ci puoi pure mettere tutte le key che vuoi!
Il tuo esempio sarebbe come fare x.put("nome", ...) e x.put("name", ...)...

Bye,
Chris.

Interessante, non ci avevo mai pensato. :)

--

 Mario

[Chris Mair]

Ciao,

penso che il discorso static typing vs dynamic typing, implicit casting vs explicit casting sia molto piu`
vecchio di entrambi, Java e JavaScript. *Normalmente* uno sceglie il linguaggio della famiglia piu` adatta
/ conosciuta / preferita per fare quello che deve fare e la cosa muore li`.

Se interpreto il tuo pensiero correttamente, Davide, il problema che segnali qui e` che nel frontend-
programming per client web *non hai scelta*! L'unico linguaggio disponibile capita di essere della
famiglia dynamic typing / implicit cast con cui non ti trovi a tuo agio.

Ti butto due possibili idee li`:

- una e` ovvia, l'elephant in the room: e` un linguaggio di un venditore prominente di software dello stato
del Washington che inizia con "Type" e finisce in "Script" che conosci gia` (@Hejlsberg: blink "SOS" if they
keep you by force ;)

- una e` piu` radicale: notare che solo perche` adesso la moda va verso rich client / single page app, non
e` che applicativi web tradizionali non funzionano piu` (cioe` quelle che ricaricano la pagina e generano
l'HTML sul server). Se hanno fatto una legge per rendere JSP illegale mi e` sfuggita :) Ovviamente dipende
da cosa devi fare, ma qualche web app per la gestione di qualcosa da usare sul desktop d'ufficio? Che e`
che ti vieta di svilupparla server side? Se devi mantenerla per 10 anni rischi pure meno che non con l'ultimo
AngularJS/Angular che il mese prossimo sara` legacy.


Bye,
Chris.

[Mario Alexandro Santini]

2017-09-07 8:51 GMT+02:00 Chris Mair <ch...@1006.org>:

Ciao,

penso che il discorso static typing vs dynamic typing, implicit casting vs explicit casting sia molto piu`
vecchio di entrambi, Java e JavaScript. *Normalmente* uno sceglie il linguaggio della famiglia piu` adatta
/ conosciuta / preferita per fare quello che deve fare e la cosa muore li`.

[..]

- una e` piu` radicale: notare che solo perche` adesso la moda va verso rich client / single page app, non
e` che applicativi web tradizionali non funzionano piu` (cioe` quelle che ricaricano la pagina e generano
l'HTML sul server). Se hanno fatto una legge per rendere JSP illegale mi e` sfuggita :) Ovviamente dipende
da cosa devi fare, ma qualche web app per la gestione di qualcosa da usare sul desktop d'ufficio? Che e`
che ti vieta di svilupparla server side? Se devi mantenerla per 10 anni rischi pure meno che non con l'ultimo
AngularJS/Angular che il mese prossimo sara` legacy.

Mi permetto di aggiungere a questa ultima opzione anche Zk https://www.zkoss.org/

Io avrei, invece, una curiosita', visto che utilizzi GWT come mai ti trovi a lavorare in Javascript?

Considera che conosco GWT superficialmente e non ho seguito la sua evoluzione ad oggi.

Bye,
Chris.

--

 Mario

[Mirco Attocchi]

Le avevo condivise inizialmente in privato con Davide, provo a
condividere anche con voi i miei dubbi su miei casi reali (scusa
lunghezza e magari italiano non formalmente corretto):

CASI tipo A) Progetti di WebApp Java Based: in vendita da 10 anni e
vorrei vendere (implementare e mantenere) ancora per i prossimi 10 ;D
Tutti JSF Based attualmente attivi, manutenibili, e funzionanti anche
senza revisioni tecnologiche (ora però è tempo di "revisionare" per
guardare avanti)
Ambito gestionale (non fatturazione ma CRM/Gestione Attività, tante
form, viste personalizzate per utente, vari moduli software)

CASI tipo B) Mini-progetti web-bases (progetti standalone in ambito aziendale)
Scelto sempre tecnologie avanguardia, sia per formarsi, sia per
sperimentare/valutare (ma sono comunque progetti in produzione)
Negli ultimi 5 anni scritti in JavaScript + jQuery (inizialmente),
AngularJS (dalla 1.qualcosa) ora ... taac tutto obsoleto e dovrei
pensare di "revisionare" con Angular 2/4 (ed ufficialmente TypeScript)
o per restare in JS valutare alternative (vue.js, react o altri)

CASI tipo C) Ambito App Mobile
sempre scritto App Ibride (recuperando investimenti/competenze JS
dell'ambito B, es: jQueryMobile o Ionic 1), la nuova "frontiera" sono
le PWA, quindi la scelta tecnologia x Web App potrebbe ancora essere
recuperata/sfruttabile.

Analizzando qualche caso di prodotti "commerciali" in cloud vedo che
non usano JS "puro" ma usano vari FW JS, eppure Google nei suoi
prodotto più complessi (adwords, inbox, gmail?, docs?) pare ancora usare GWT.

Ecco i miei dubbi:
La veloce evoluzione dei FW JS non mi lascia sereno nel riscrivere la
webapp commerciale (frontend JS - backend Java), se scrivo oggi un
frontend in Angular 2/4 fra 5 anni cosa succede? Perchè devo investire
sul framework e/o riscrivere le stesse cose in modo diverso a
differenza di pochi anni? (o rischiare di avere un Fronted con
tecnologie miste??!)
La tendenza dei FW JS è comuque quella di non usare JS "puro" (vedi
react e angular 2), a questo punto se devo investire investo su JSX, ES6/7 o
su TypeScript? Addiritta su qualche libro JS si paragona JS all'Assembly per Web
valutazione che lascia intendere che è pià "comodo" scrivere in altri
linguaggi che "compilano" in JS (per vari motivi).
Se devo comunque passare per transpilazione (e studiare ES6/7 o TS)
perchè a quel punto non scrivere direttamente in Java (che già
conosciamo anzi si approfondisce e conosce sempre meglio con novità
dalle 8 e 9) e "compilare" Java in JS (GWT)?
Java e/o GWT hanno ancora le carte per giocarsela (prestazioni,
produttività, durabilità) su tutti e tre gli ambiti?
GWT è passato di moda - si - ma non lo vedo una soluzione
tecnologicamente morta se alternativa è passare a scrivere in TS/ES6/ES7
transpilando in ES5 ;D
Non ho mai non sento esigenze di scalabilità/volumi/numeri stile
Google/Amazon/Facebook & co. ma più di "manutenzione"/"evoluzione" di
funzionalità dei software negli anni.

Ecco condiviso alcuni miei "dubbi".
AMMISSIONI: ammetto che GWT mi ha sempre affascinato e non ho mai
usato (quindi non ne conosco pregi e difetti).
Io ho la sensazione che GWT non sia finito, anche se "snobbato" dalle
nuove mode ... ma "tutti" attorno mi dicono "che mi sbaglio".

Mirco

[Mirco Attocchi]

L'approccio di Vaadin stando a quanto mi pare di capire dal blog e
risposte ricevut è quello di portare avanti parallelamente:
1) componenti frontend (basati su polymer) - usabili qunidi anche
standalone in JS o altri FW
2) wrapper Java di questi componenti per GWT

Mi pare un approccio intelligente dal loro punto di vista che tiene
viva loro proposta sia per mercato fronted "puro" (anche se on conosco
polymer) che "storico" GWT

Mirco

[Mario Alexandro Santini]

2017-09-07 10:55 GMT+02:00 Mirco Attocchi <ami...@gmail.com>:

Ecco condiviso alcuni miei "dubbi".
AMMISSIONI: ammetto che GWT mi ha sempre affascinato e non ho mai
usato (quindi non ne conosco pregi e difetti).
Io ho la sensazione che GWT non sia finito, anche se "snobbato" dalle
nuove mode ... ma "tutti" attorno mi dicono "che mi sbaglio".

Ciao, non sono in grado di suggerirti una strategia da adottare e nemmeno la mia esperienza personale, dato che io ho sempre dovuto adattarmi a scelte altrui e conviverci.

Quello che ho imparato e' che devi sempre metterti in condizione di mollare ogni dipendenza che hai, tipo librerie, framework, linguaggi.

Leggendo e parlando con persone di varia esperienza (liberi professionisti) non italiani ti posso riportare che la scelta comunqe e' quella di farsi tutto in casa senza usare nulla di esterno:

VanillaJS (se usi javascript) o Vanilla Java

Per esempio niente Hibernate o JPA: si fanno le query via stringa...

Per rispondere alla tua domanda su GWT, al di la delle impressioni personali, c'e' una cosa che si puo' fare: usare google trends.

https://trends.google.com/trends/explore?date=all&q=GWT,Zk,Angular,Vue

Temo che il "coltellino svizzero" nel software assomigli piu' alla pietra filosofale e quindi ci si debba rassegnare ad avere in valigia piu' linguaggi.

Per le App su cellulari e tablet: Kotlin (Android) + Swift https://developer.apple.com/swift/ (non la cantante ;) per iOS)

Per le web app: Javascript

Per tutto il resto: Java

A meno di non riuscire a concentrarsi su un ambito particolare e quindi poter scegliere il linguaggio adatto.

Ma da quanto scrivi mi sa che non hai questa possibilita'.

 

Mirco

--

 Mario

[Nicola Pedot]

Ciao Mirco,

Partirei proprio da qui:

>Non ho mai non sento esigenze di scalabilità/volumi/numeri stile
>Google/Amazon/Facebook & co. ma più di "manutenzione"/"evoluzione" di
>funzionalità dei software negli anni.

è giusto tenersi allenati,

però se le esigenze non ti stringono per i piccoli come noi dobbiamo stare attenti agli investimenti,

è vero che JSF a leggere wikipedia pare sia in disuso:

https://it.wikipedia.org/wiki/Java_Server_Faces

eppure le specifiche JEE continuano ad avanzare, il che garantisce vita ancora per un bel po',

non dico 10 anni ancora ma almeno cinque meli giocherei,

un esempio di forza ne è la spinta che la comunità ed il mercato hanno dato ad Oracle per JEE8.

Se il tuo tipo cliente A è felice con JSF puoi andare con calma.

Discorso diverso se hai clienti B innovativi che vivono di frontend, qui c'e' ampia scelta in base alle richieste cliente.

Tutti i frontend framework si differenziano in qualche cosa a ben vedere.

Di buono nel frontend "estremo" lato dev c'e' che se il cliente vive di cose così allora deve mettere in conto una riscrittura a breve

quindi anche eventuale tuo dubbio di manutenzione va di pari passo.

Ti auguro di non dover servire ->da solo<- in produzione clienti AB, perchè garantire e mantenere quello che A offre in B è molto duro/costoso.

Tornando alla domanda di Davide, personalmente non ho esperenza per poter parlare di gwt/vaadin, e non posso risponderti,

però vedo che ambo i progetti sono ancora vivi, con una loro comunità, a vedere le attività in rete,

se calzano al problema non vedrei perchè abbandonarle, in assenza di altri vincoli o proiezioni.

NiPe

2017-09-07 10:55 GMT+02:00 Mirco Attocchi <ami...@gmail.com>:

> email to jugtaa+unsubscribe@googlegroups.com.

> To post to this group, send email to jug...@googlegroups.com.
> Visit this group at https://groups.google.com/group/jugtaa.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+unsubscribe@googlegroups.com.

[Marte Marte]

Ciao,

  anche io ho la percezione che GWT non sia più usato da un bel pò e sia più "alla moda" Angular e React

è vero che JSF a leggere wikipedia pare sia in disuso:

https://it.wikipedia.org/wiki/Java_Server_Faces

conosco aziende trentine che non seguono le mode e hanno tempi stretti ed esperienza su JSF ed investono su quello per i loro progetti.

Ciao!

Alberto

> email to jugtaa+un...@googlegroups.com.

> To post to this group, send email to jug...@googlegroups.com.
> Visit this group at https://groups.google.com/group/jugtaa.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+un...@googlegroups.com.

[Luca Guadagnini]

È vero che i JS literal può essere usato come una mappa (o dizionario à la C#), ma quello che crei è sempre e comunque un oggetto JS. :( 

@Davide

Il punto è che se uno ti scrive un oggetto come quello che hai riportato, effettivamente niente e nessuno ti impedisce di scrivere altro, nemmeno i vari strumenti come JSlint dove ti danno un semplice avviso, ma non ha nulla a che vedere con l'interpretazione del linguaggio, visto che la sintassi risulta essere corretta. E l'intoppo è che JS è un linguaggio interpretato e non compilato, quindi è assai complesso di principio compiere delle analisi statiche che ti concedano una certa di linearità e rigore di sviluppo (che vabbè stanno migliorando intendiamoci e WebStorm è favoloso).

Anche le novità introdotte nei nuovi standard EcmaScript non aiutano (a parte il «let», l'unica cosa veramente buona), il codice rimane sempre interpretato ed è solo qui il nocciolo della questione, il resto è solo rumore come diceva Raffaella Carrà.

Un esempio in vanilla JS di come bisognerebbe creare/estendere oggetti lo si può prendere da qui: https://github.com/trystick/feedback/blob/master/feedback-js/src/engine/xsprite.js guardando la function XSprite (spero sia comprensibile, al di là del numero di metodi presenti). Nei miei repo c'è anche un'app fatta in Vue.js se ti può interessare, molto più facile di qualsiasi altro framework disponibile.

Ovviare ai problemi del linguaggio parlando di test, mi sa come suggerire al pattinatore dilettante di andare sul ghiaccio fino del lago con il salvagente :)

 On Wednesday, 6 September 2017 14:27:43 UTC+2, Davide wrote:

Ciao Luca, mi sapresti quantificare a spanne a che grandezza dell'app 
avevi questi problemi? Tipo un ordine di grandezza di classi o linee di 
codice? 

Dunque l'applicazione era piccolina direi: una decina di sezioni dove fare semplicemente CRUD. Le classi erano contenute di per sé (tranne quella della GUI principale doveva venivano inizializzati i componenti principali della prima pagina), ma il muflone rimaneva il framework. Faccio presente però che usavo una versione forse un po' vecchia - 7.x - e so che con la 8 hanno fatto un sacco di migliorie anche per permettere una comunicazione più efficiente con il back-end, ma non l'ho provata (e non credo che ne avrò l'occasione in futuro). Magari sulle grandi applicazioni riesci a mitigare il problema dicendo al cliente che ci son tanti dati da elaborare :D scherzo! Non ne son diventato un esperto, ma la percezione che mi ha dato per fare front-end non è stata alla fine delle migliori, tuttavia credo che sia un buon compromesso nel caso il tuo team abbia solo sviluppatori Java che non vogliano cimentarsi nel magico mondo di JS (come avevo già detto prima).

Grande Nicola che cita JSF :D io l'ho sempre trovato un accrocchio e PrimeFaces è arrivato troppo tardi a salvarci tutti, tant'è che la versione 3.0 di JSF (chiamata poi MVC1.0) è stata completamente tolta dallo standard JEE e data alla comunità. Quello che sarà introdotto in JSF2.2 saranno solo patch e funzionalità introdotte dalla comunità, ma direi che lo sviluppo da parte dei big player è da considerarsi morto (RichFaces di Red Hat per esempio è stato dismesso), quindi da evitare oramai.

[Mario Alexandro Santini]

2017-09-07 17:50 GMT+02:00 Luca Guadagnini <elg...@gmail.com>:

Ovviare ai problemi del linguaggio parlando di test, mi sa come suggerire al pattinatore dilettante di andare sul ghiaccio fino del lago con il salvagente :)

I test non servono a ovviare ai "problemi" del linguaggio, ma a risolvere quelli del pattinatore che non sa nuotare.

:)

Mario

[Luca Guadagnini]

ma perché deve imparare a nuotare se vuole imparare a pattinare? :)

quello che volevo dire è che se qualcuno ha bisogno di programmare e vuole starsene al sicuro sin dal principio, usa un linguaggio statico e compilato (tipo Typescript~)

[Davide]

I test servono per testare le funzionalità. Se con javascript devo
scrivere ULTERIORI test per controllare i tipi (perché si scoprono solo
a runtime i problemi) allora vi siete mai chiesti se il costo di questi
ULTERIORI test è INFERIORE al costo di usare un linguaggio tipizzato?

Qualcuno mi spiegherebbe come mai è stato introdotto typescript, e per
esempio angular 2 lo usa, se i programmatori erano finalmente così
contenti con la dinamicità del linguaggio?

A volte non capisco se si parla di programmazione per hobby, e quindi
uso il linguaggio che più più piace/moda/credo ignorando la
produttività/qualità/costo o se in qualche modo vi auto
osservate/misurate/confrontate sui risultati usando diverse tecnologie?

Io per esempio una volta ho scritto un utility di 200 righe in
javascript e poi successivamente ho aggiunto i tipi con typescript. E'
uscito che in qualche caso avevo a mente sbagliato a pensare al tipo o
al parametro/numero di parametri. Possiamo *scommettere* che se ognugno
di voi ripetesse l'esperimento succederebbe la stessa cosa?

Typescript è un po' meglio di javascript, ma secondo me insufficiente.

Problemi Typescript che mi vengono in mente che mi sono accaduti realmente:

* duck typing: class Persona(nome), class Cane(nome);
let p:persona = new Cane(); // compila :-((((

* dichiarazione multipla delle variabili permessa:
for (let i = 0; ....)
...
for (let i = 0; ....
per il compilatore è tutto ok (si lamenterebbe solo se il tipo è
diverso) ma
su quei cicli non oserei pensare quanto tempo ci passa qualcuno a
trovare il problema

* tipi controllati in compilazione ma non in esecuzione/runtime.
Se io dichiaro una variabile string e faccio il cast da una variabile
any per esempio derivante da un'altra libreria di terzi,
questo NON mi assicura
che li dentro c'e' una stringa. Il cast in typescript NON FALLISCE MAI
(diversamente da java) Quindi, se il codice non è 100%
typescript ma un misto (come capita in pratica perché su usano
librerie di terzi non mappate su ts) il rischio che dentro alle
variabili ci siano tipi sbagliati è probabilissimo! E tra l'altro
questi tipi sbagliati passano nel codice fino a che ad un certo
punto non uscirà un misterioso "undefined"!!!

Io non ho voglia di perdere tempo quando programmo a fare il compilatore
a mente quanto ne esiste software che lo può fare per me e in maniera
decisamente più affidabile!

Unica eccezione alla regola e che io voglia effettivamente creare
dinamicamente nuovi attributi sugli oggetti a runtime per risolvere
elegantemente un problema. Per questi casi javascript sarebbe figo!

On 07/09/2017 18:18, Mario Alexandro Santini wrote:
>
>
> 2017-09-07 17:50 GMT+02:00 Luca Guadagnini <elg...@gmail.com

> <mailto:elg...@gmail.com>>:

>
>
> Ovviare ai problemi del linguaggio parlando di test, mi sa come
> suggerire al pattinatore dilettante di andare sul ghiaccio fino del
> lago con il salvagente :)
>
>
> I test non servono a ovviare ai "problemi" del linguaggio, ma a
> risolvere quelli del pattinatore che non sa nuotare.
> :)
>
>
> Mario
>

> --
> You received this message because you are subscribed to the Google
> Groups "JUG Trentino Alto Adige Suedtirol" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jugtaa+un...@googlegroups.com

> <mailto:jugtaa+un...@googlegroups.com>.

> To post to this group, send email to jug...@googlegroups.com

> <mailto:jug...@googlegroups.com>.

[Luca Guadagnini]

Hai centrato il discorso :)

Typescript è un linguaggio interessante, il perché abbiano iniziato a usarlo per Angular (e Aurelia) è proprio dovuto alle difficoltà di testare JS e per cercare di attrarre gli sviluppatori di back-end. Ma ci stiamo addentrando in altri meandri :D

[Mario Alexandro Santini]

2017-09-07 19:45 GMT+02:00 Davide <d...@vide.bz>:

I test servono per testare le funzionalità. Se con javascript devo scrivere ULTERIORI test per controllare i tipi (perché si scoprono solo a runtime i problemi) allora vi siete mai chiesti se il costo di questi ULTERIORI test è INFERIORE al costo di usare un linguaggio tipizzato?

Scusa Davide, non per essere brusco o scortese, ma questa tua frase mi lascia basito.

Se l'esempio che hai fatto originariamente non ha rotto un test, significa che quella funzionalità non l'hai testata!

E quindi ti mancano dei test, ne hai fatto meno di quelli che avresti dovuto e non di più. E questo vale anche se stai scrivendo codice Java.

Al resto non rispondo, perché ho l'impressione che non sia più una discussione argomentata.

Ho fatto le mie proposte e suggerimenti, come hanno fatto altri, se ci sono commenti su quelli sono disponibile.

Mario

[Chris Mair]

Ciao,

io sono fondamentalmente d'accordo con te, Davide.

Ma giusto per voglia di discussione osservo che

> * dichiarazione multipla delle variabili permessa:
>   for (let i = 0; ....)
>      ...
>      for (let i = 0; ....

e` amesso perche`
- for inizia un nuovo block e
- lo scope di una variabile let e` proprio il blocco e
- variabili in blochi annidati sono ammessi (quella interna copre quella esterna)

for (let i = 0; i < 5; i++) {
for (let i = 0; i < 5; i++) {
console.log(i);
}
}

ha come output 25 righe.

Anche

for (let i = 0; i < 5; i++) {
{
let i = 7;
console.log(i);
}
}

e` amesso e stampa cinque volte 7.

E` valido anche in C (non ricordo se 89 o 99 in poi).

Non e` un comportamento a random - il linguaggio e` definito cosi`.

Il mio sospetto e` che una buona percentuale di critiche a JavaScript
derivano dal fatto che *assomiglia* a prima vista a Java/C# ma
poi risulta totalmente diverso...

IMHO il JavaScript deve essere visto in concorrenza a Perl/Python/Ruby,
non in concorrenza a Java/C#/C++. Almeno io lo uso con quella logica.

(e se vedo {} penso al % di Perl, non al new X() di Java...)

Poi, si`, c'e` il dramma del web frontend. Ma in questo thread abbiamo
visto che ci sono alternative (e non e` che devi scrivere migliaia di
righe di JS nel frontend... almeno spero :).

Bye,
Chris.


PS: per farti disperare, Davide:

console.log([[][[]]+[]][+[]][++[+[]][+[]]]);

stampa 'n' ;)

[Davide]

On 07/09/2017 20:12, Mario Alexandro Santini wrote:
> Ho fatto le mie proposte e suggerimenti, come hanno fatto altri, se ci
> sono commenti su quelli sono disponibile.

Ciao Mario, le tue proposte e suggerimenti non li ho ignorati, anche se
esprimevo altri obettivi e ti stimo come professionista. Sono degli
ottimi suggerimenti e ne terrò conto per le volte che gioco/forza dovrò
usare javascript.

[Luca Guadagnini]

Io credo che Davide volesse semplicemente dire un'altra cosa. È un po' come testare in Java tipi nullable quando vuoi che questi siano obbligatori:

public void method(Integer number) { ... } // possibile null pointer exception se non si verifica la presenza valida del parametro, quindi test necessario

public void method(int number) { ... } // non c'è alcun bisogno di fare test sulla presenza valida del parametro, ci si concentra solo sul valore

Lo stesso dicasi con i tipi statici, se un linguaggio te li propone, non hai alcun bisogno di testare il tuo metodo per verificare che questo prenda solo in ingresso il tipo a te interessato. Tutto lì.
Sul formalismo dei test nessuno mi pare che abbia nulla da dire. E ci mancherebbe :)

[Davide]

In typescript volendo c'e' anche questa:

i = 5;
var nome:string = 'davide'
var i:number;

che è legale :-) (a parte usare let ;-)

On 07/09/2017 21:08, Luca Guadagnini wrote:
> Io credo che Davide volesse semplicemente dire un'altra cosa. È un po'
> come testare in Java tipi nullable quando vuoi che questi siano obbligatori:
>
> public void method(Integer number) { ... } // possibile null pointer
> exception se non si verifica la presenza valida del parametro, quindi
> test necessario
>
> public void method(int number) { ... } // non c'è alcun bisogno di fare
> test sulla presenza valida del parametro, ci si concentra solo sul valore
>
> Lo stesso dicasi con i tipi statici, se un linguaggio te li propone, non
> hai alcun bisogno di testare il tuo metodo per verificare che questo
> prenda solo in ingresso il tipo a te interessato. Tutto lì.
> Sul formalismo dei test nessuno mi pare che abbia nulla da dire. E ci
> mancherebbe :)
>
> On Thursday, 7 September 2017 20:12:53 UTC+2, Mario Alexandro Santini wrote:
>
>
>

> 2017-09-07 19:45 GMT+02:00 Davide <d...@vide.bz <javascript:>>:

>
>
> I test servono per testare le funzionalità. Se con javascript
> devo scrivere ULTERIORI test per controllare i tipi (perché si
> scoprono solo a runtime i problemi) allora vi siete mai chiesti
> se il costo di questi ULTERIORI test è INFERIORE al costo di
> usare un linguaggio tipizzato?
>
>
> Scusa Davide, non per essere brusco o scortese, ma questa tua frase
> mi lascia basito.
>
> Se l'esempio che hai fatto originariamente non ha rotto un test,
> significa che quella funzionalità non l'hai testata!
>
> E quindi ti mancano dei test, ne hai fatto meno di quelli che
> avresti dovuto e non di più. E questo vale anche se stai scrivendo
> codice Java.
>
> Al resto non rispondo, perché ho l'impressione che non sia più una
> discussione argomentata.
>
> Ho fatto le mie proposte e suggerimenti, come hanno fatto altri, se
> ci sono commenti su quelli sono disponibile.
>
>
> Mario
>

[Chris Mair]

> In typescript volendo c'e' anche questa:
>
>         i = 5;
>         var nome:string = 'davide'
>         var i:number;
>
> che è legale :-) (a parte usare let ;-)

Non conosco typescript ma sarebbe valido anche in JS.
Lo scope di var e` l'enclosing function o script, la posizione di var non conta (vedi "hoisting").
C'e` un motivo per cui in ES6 hanno introdotto let con un block scoping piu` sano...

Bye,
Chris.

[Mario Alexandro Santini]

On Thu, Sep 7, 2017 at 10:04 PM, Chris Mair <ch...@1006.org> wrote:

In typescript volendo c'e' anche questa:

         i = 5;
         var nome:string = 'davide'
         var i:number;

che è legale :-) (a parte usare let ;-)

Non conosco typescript ma sarebbe valido anche in JS.

Non proprio.

In realtà la prima istruzione genera un ReferenceError.

In condizioni normali l'interprete non esterna questo errore e crea una variabile globale cui assegna il valore 5.

Ma se si usa la modalità più restrittiva, non si arriva oltre quella riga:

PS > node -use-strict

>

>

> i = 5

ReferenceError: i is not defined

    at repl:1:3

    at sigintHandlersWrap (vm.js:22:35)

    at sigintHandlersWrap (vm.js:96:12)

    at ContextifyScript.Script.runInThisContext (vm.js:21:12)

    at REPLServer.defaultEval (repl.js:340:29)

    at bound (domain.js:280:14)

    at REPLServer.runBound [as eval] (domain.js:293:12)

    at REPLServer.<anonymous> (repl.js:538:10)

    at emitOne (events.js:101:20)

    at REPLServer.emit (events.js:188:7)

Per quale motivo si è scelto questo comportamento?

Perché molto tempo fa, javascript serviva per codice di controllo e poco più e le variabili globali non erano un gran problema, perché si trattava comunque di poco codice.

Vi ricordate quando ogni modifica ricaricava la pagina del browser?

Ogni volta si resettava anche lo script javascript.

E quindi era più utile essere meno fiscali.

Dopo le cose sono cambiate, ma oramai la diffusione del linguaggio era tale che non era più possibile cambiare certi comportamenti.

Ecco perché la modalità strict, perché le nuove keyword per le variabili e tante altre cose.

C'e` un motivo per cui in ES6 hanno introdotto let con un block scoping piu` sano...

Bye,
Chris.

 

Si il let è una novità molto interessante, che finalmente impedisce le porcate tipo:

if (a == x) {

   var c = 1;

} else if(a == 2x) {

   var c = 3;

}

if( c > 2 ) doSomething();

Questo codice è sbagliato, ma purtroppo finché a è uguale a x o a 2x funziona.

Utilizzando let non funziona più.

const e let sono già supportati dalla maggioranza dei browser.

--

 Mario

[Chris Mair]

> Non conosco typescript ma sarebbe valido anche in JS.
>
>
> Non proprio.
>
> In realtà la prima istruzione genera un ReferenceError.
>
> In condizioni normali l'interprete non esterna questo errore e crea una variabile globale cui assegna il valore 5.
>
> Ma se si usa la modalità più restrittiva, non si arriva oltre quella riga:
>
> PS > node -use-strict
> >
> >
> > i = 5
> ReferenceError: i is not defined

> [...]

Invece si` :)

Non puoi solo dire i = 5 e basta. Devi darli tutto il codice incluso il var sotto
e non avrai nessun errore.

earth:~ chris$ cat bla.js
"use strict";

i = 5;

var i;

earth:~ chris$ node bla.js
earth:~ chris$ node -use-strict bla.js

> Per quale motivo si è scelto questo comportamento?
>
> Perché molto tempo fa, javascript serviva per codice di controllo e poco più e le variabili globali non erano un gran problema, perché si trattava comunque di poco codice.
>
> Vi ricordate quando ogni modifica ricaricava la pagina del browser?
> Ogni volta si resettava anche lo script javascript.
>
> E quindi era più utile essere meno fiscali.
>
> Dopo le cose sono cambiate, ma oramai la diffusione del linguaggio era tale che non era più possibile cambiare certi comportamenti.
>
> Ecco perché la modalità strict, perché le nuove keyword per le variabili e tante altre cose.

Quello che dici vale per "use strict" che e` stato introdotto con ES5 (mentre let solo con ES6).

Ma "hoisting" (cioe` che il var puoi metterlo dopo e che e` il motivo per cui il codice
completo va anche con "use strict") deve esserci da molto tempo se non praticamente dall'inizio.

A quanto pare hanno iniziato a chiamarlo "hoisting" solo di recente:

https://developer.mozilla.org/en-US/docs/Glossary/Hoisting

(io il termine l'ho sentito la prima volta da un partecipante a un mio corso molto prima
del 2015 pero`...).

Probabilmente senza "use strict" era piu` difficile accorgersene ;)

Bye,
Chris.

[Mario Alexandro Santini]

2017-09-07 23:26 GMT+02:00 Chris Mair <ch...@1006.org>:

Invece si` :)

Non puoi solo dire i = 5 e basta. Devi darli tutto il codice incluso il var sotto
e non avrai nessun errore.

earth:~ chris$ cat bla.js
"use strict";

i = 5;

var i;

earth:~ chris$ node bla.js
earth:~ chris$ node -use-strict bla.js

hai ragione.

E' perché javascript non è più interpretato, e questo caso lo dimostra.

Siccome lo compila in memoria il codice diventa questo:

i = 5;

var i = 2;

Diventa:

var i;

i = 5;

i = 2;

Ho cambiato il tuo codice per renderlo più chiaro.

Quello che dici vale per "use strict" che e` stato introdotto con ES5 (mentre let solo con ES6).

Ma "hoisting" (cioe` che il var puoi metterlo dopo e che e` il motivo per cui il codice
completo va anche con "use strict") deve esserci da molto tempo se non praticamente dall'inizio.

L'hoisting è precedente di sicuro alla modalità ristretta.

Crockford suggerisce di dichiarare tutte le variabili in cima allo scope per evitare fraintendimenti.

A me non piace, perché rende difficile la lettura del codice.

Preferisco evitare le variabili quando posso. :)

Probabilmente senza "use strict" era piu` difficile accorgersene ;)

Bye,
Chris.

 

Direi che in questo caso ci avrebbe salvato solo jslint...

Ma in generale con l'utilizzo di entrambi: use strict + jslint si risolvono un bel po' di grane.

--

 Mario

[Luca Guadagnini]

On Thursday, 7 September 2017 23:53:16 UTC+2, Mario Alexandro Santini wrote:

hai ragione.

E' perché javascript non è più interpretato, e questo caso lo dimostra.

Siccome lo compila in memoria il codice diventa questo:

i = 5;

var i = 2;

Diventa:

var i;

i = 5;

i = 2;

Certo che per chi è abituato a leggere il codice sequenzialmente è comunque dura vedersi cose del genere :)

 

Quello che dici vale per "use strict" che e` stato introdotto con ES5 (mentre let solo con ES6).

Ma "hoisting" (cioe` che il var puoi metterlo dopo e che e` il motivo per cui il codice
completo va anche con "use strict") deve esserci da molto tempo se non praticamente dall'inizio.

L'hoisting è precedente di sicuro alla modalità ristretta.

Da quel che ricordo le hoisted variables esistevano già da Javascript 1.5, ma è un concetto di cui si potrebbe fare a meno, una funzionalità abbastanza inumana.

[Mario Alexandro Santini]

2017-09-07 20:25 GMT+02:00 Davide <d...@vide.bz>:

Ciao Mario, le tue proposte e suggerimenti non li ho ignorati, anche se esprimevo altri obettivi e ti stimo come professionista. Sono degli ottimi suggerimenti e ne terrò conto per le volte che gioco/forza dovrò usare javascript.

Forse sbaglio, ma ho avuto l'impressione che tu voglia utilizzare le varie implementazioni di ecma262 come se fossero Java.

ecma262 == Java

E tutto quello che diverge da Java lo consideri una anomalia.

Ripeto, avrò avuto l'impressione sbagliata ma questa è la mia impressione.

I problemi di ecma 262 sono tanti, tantissimi e le parti buone sono poche, come spesso ricordano tanti che ne capiscono più di me citando il libro di Crockford: Javascript, the good part

La battuta è sempre:  è un libro molto breve.

Non so se un giorno ecma 262 abbandonerà la dinamicità e imbriglierà definitivamente i tipi.

Tutto è possibile, anche se, nel caso introducessero le modifiche che speri, la transizione sarà moolto moolto lunga, visti i tempi di decisione di TC39, e per nulla scontata.

Non dimenticarti che esiste una montagna enorme di codice ecma 262 in giro e molti del TC39 sono responsabili del mantenimento di quel codice.

Potrebbe anche nascere una mini JVM nel browser compilata in javascript:

http://asmjs.org/spec/latest/

--

 Mario

[Mario Alexandro Santini]

2017-09-08 8:59 GMT+02:00 Luca Guadagnini <elg...@gmail.com>:

Da quel che ricordo le hoisted variables esistevano già da Javascript 1.5, ma è un concetto di cui si potrebbe fare a meno, una funzionalità abbastanza inumana.

E' meglio usare const e let, per i quali il problema dell'hoisting non c'è.

Per i dettagli vi consiglio: https://medium.freecodecamp.org/what-is-variable-hoisting-differentiating-between-var-let-and-const-in-es6-f1a70bb43d

Purtroppo rimuovere var è difficile, c'è tanto codice da riscrivere e ci vorrà tempo, ma ora abbiamo delle alternative.

--

 Mario

[Luca Guadagnini]

Il fatto buffo è che in futuro invece di parlare dei design flaw di Java, si parleranno di quelli di JavaScript. Il tutto reso ancora più buffo dal fatto che in entrambi linguaggi ci sia il nome Java.

[Davide]

On 08/09/2017 09:37, Mario Alexandro Santini wrote:
> E tutto quello che diverge da Java lo consideri una anomalia.

Io considero l'oop (oggetti/classi, attributi privati, extends, static
typing, ecc..) un uno strumento potente per affrontare le difficoltà del
software e aumentare qualità/efficienza e ridurre i costi.
Quando non ho questi strumenti mi sento come analogamente avere una
macchina senza abs, o scrivere un testo senza correttore ortografico.

Dalle mie autovalutazioni ritengo di poter *misurare* che il costo nel
programmare senza questi strumenti sia più alto (almeno per me). per
esempio perché perdo più tempo in problemi inspiegabili.

Ma potremmo anche fare una cosa più scientifica aumentando il campione:
una bella sfida di gruppo organizzata dal jugtaa come abbiamo fatto con
tomcat/node o typescipt/es6 ovviamente in stile goliardico e con pizza
finale tutti insieme e amici come prima!

Java mi aiuta in questa mia idea di sviluppo software

Ma "purtroppo" mi piacciono anche le app nel browser single page di una
certa complessità.

E qui nativamente si può ricadere solo su javascript. Non c'e' scelta.
Il browser è l'unico linguaggio di programmazione che capisce nativamente.
Javascript di per se non odio, ma per chi ragiona oop, ha dei pericoli
pratici che abbiamo in parte elencato, che per il *mio* modo di
affrontare lo sviluppo software mi sembra proprio di pattinare sul
ghiaccio, di affrontare manualmente problemi già risolti da strumenti
... e perdere ore preziose inultimente.

javascript non è un oop.

La cosa che trovo buffa è che, mentre io cerco di usare l'oop nel
browser spingendo veri strumenti oop come gwt, vaadin o altri, ci sia
mezzo mondo
che vuol usare javascript per poi accorgersi, con l'aumentare della
complessità, dei pericoli, e come invece l'oop aiuterebbe (non pensate
che angular2 sia stato scritto in typescript perché abbiano sentito la
necessità di maggiore affidabilità visto che magari volevano oltrettutto
espendere le funzionalità?).

trovo ancora più buffo che il gruppo javascript che dici si scaldi se
modifico internamente lo stato di un oggetto: ma è proprio la modifica
dinamica di un oggetto il punto di forza di javascript! Non è un
paradosso che un gruppo javascript "limiti" il linguaggio ad un concetto
dell'oop (quando javascript non lo è) che è il mascheramento dello stato
di un oggetto invece di lodare la sua dinamicità per risolvere i problemi?

E come se io sul jug lodassi la hashmap e dicessi di evitare le classi!!!

Una volta un programmatore javascript mi ha detto che lui odia
typescript: la sua scelta è coerente!

[Davide]

Questo era il mio ragionamento, qual'e' invece la vostra opinione su gwt
& co?

[Mirco Attocchi]

Un veloce aggiornamento cofronto sul tema GWT, vi elenco qui alcune
considerazioni recenti che mi viene da condividere e sottoporre al
gruppo per eventuali "correzioni":

1) Vaadin in qualche modo si sta "allontananto" da GWT, si stanno
muovendo verso un frontend di componenti HTML+CSS+JS basato su Polymer
2 + programmazione Java per "binding" client-server. (possibile che
meccanismo di binding è ancora basato su GWT ma non ne sono certo,
anzi possibile che non sia così) https://vaadin.com/flow
2) Su un principio simile si basa anche http://erraiframework.org/ che
mette insieme templating HTML + programmazione client-server Java
(sembre basato su GWT) + supporto a CDI / EE
3) GWT, guardando di recente alcuni video GWT CON 2016/2017 mi pare
che l'attenzione di un team di Google sia verso J2CL (un compilatore
Java to Closure) che promettono di rilasciare opensource a breve. Mi
pare di intuire che la direzione sia quella di fare in modo che anche
GWT 3 in futuro supporti questo meccanismo. Se non ho capito male la
"visione" è quella di un modo ibrido Java-JS quindi l'idea è quella di
avere un compilatore J2CL che produce file che possono a loro volta
essere ottimizzati da un unico processo insieme ad altri sorgenti JS
(cosa che attualmente non è possibile). Questo insieme alla feature
JsInterop di GWT permette di mixare librerie Java e JS in modo
"agevole" (magari organizzati in moduli ES6? - aggiungo)
Pare che internamente J2CL sia in uno stadio avanzato/stabile tanto
che è usato già su nuova versione di Inbox semplicemente però non si
sono concentrati a costruire attorno ciò che serve per renderlo
progetto open usabile da altri (plugin Eclipse, IntelliJ etc)

Non ci resta che aspettare per vedere che cosa ci riserva BigG ... nel
frattempo una decisione bisogna prenderla ;D

Mirco

> --
> You received this message because you are subscribed to the Google Groups
> "JUG Trentino Alto Adige Suedtirol" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to jugtaa+un...@googlegroups.com.
> To post to this group, send email to jug...@googlegroups.com.

[Davide]

Ciao Mirco,

confermo le tue informazioni e sensazioni. Mi è piaciuta anche la tua
riflessione: se si usa typescript o transpilatori forse a questo punto
anche transpilare java può ritornare in gioco se ci si abitua che
javascript è il "compilato" della situazione.

Anche se a mia opinione javascript piace così com'e' per la sua
semplicità e ogni iniziativa di "elevarlo" non sembra avere molto
successo di massa.

Credo infatti che da una parte abbiamo le caratteristiche tecniche dei
linguaggi, dall'altra abbiamo un mercato di programmatori influenzati da
gusti, esigenze, marketing, mode, necessità quotidiane.

Il problema si fa più delicato per le aziende che devono fare
investimenti di "lungo" periodo in un software web.

[Nicola Pedot]

Grazie Mirco dell'aggiornamento su GWT!

>Non ci resta che aspettare per vedere che cosa ci riserva BigG ... nel
>frattempo una decisione bisogna prenderla ;D

Sempre con premessa che non ho esperienza diretta con GWT nello specifico,

in generale dovendo scegliere una strategia io direi transpiller solo se mi danno un vantaggio immediato oppure ho capitale (es. Java) da mantenere,

altrimenti preferirei la strada dell'investimento in soluzioni più pure, standard come WebComponents in una delle sue forme.

ps. anche i WebComponents cmq vedono una spinta notevole sempre da BigG :)

Nicola

[Davide]

On 25/10/2017 09:48, Nicola Pedot wrote:
> Sempre con premessa che non ho esperienza diretta con GWT nello specifico,

Ciao, io invece l'ho provato più volte. In certi progettini ho provato
volutamente senza e con. Io personalmente vedo una differenza di almeno
5x a utilizzare gwt in quanto costruendo via via degli oggetti più di
alto livello (menu, lista, mappa, ecc.) l'assemblaggio dell'app diventa
un giochetto!

Probabilmente sono avvantaggiato da conoscenza java e web allo stesso tempo.

[Nicola Pedot]

Ecco, il tuo è un caso di capitalizzazione, se hai già le conoscenze ... avanti tutta.

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+unsubscribe@googlegroups.com.

[Davide]

On 25/10/2017 10:04, Nicola Pedot wrote:
> Ecco, il tuo è un caso di capitalizzazione, se hai già le conoscenze ...
> avanti tutta.

Per me personalmente si, diverso però è farlo capire ai clienti per i
loro progetti.

[Stephan Perktold]

Ciao,

volevo segnalarvi il seguente articolo che ho trovato interessante:
5 Pillars of a Successful Java Web Application (Part 1/3)

È il primo di una serie e parla delle problematiche e delle esigenze specifiche di applicazioni web di grandi dimensioni.
Sembra anche che il prossimo GWT 3 faccia un passo considerevole in avanti e che potrebbe essere una scelta promettente per il futuro (sempre per applicazioni di grandi dimensioni che devono essere mantenute per anni).

Stephan

[Mario Alexandro Santini]

2017-11-07 19:45 GMT+01:00 Stephan Perktold <stephan....@gmail.com>:

Ciao,

Ciao Stephan,

 

volevo segnalarvi il seguente articolo che ho trovato interessante:
5 Pillars of a Successful Java Web Application (Part 1/3)

È il primo di una serie e parla delle problematiche e delle esigenze specifiche di applicazioni web di grandi dimensioni.
Sembra anche che il prossimo GWT 3 faccia un passo considerevole in avanti e che potrebbe essere una scelta promettente per il futuro (sempre per applicazioni di grandi dimensioni che devono essere mantenute per anni).

Stephan

Grazie per il link.

Ho letto l'articolo e resto perplesso...

La grande novità di GWT 3 è il compilatore J2CL che non compila in Javascript, ma in Clojure.

Si tratta di un linguaggio compilato di tipo funzionale, ma dinamico come Javascript (anche sui tipi se ho capito bene).

Il vantaggio di Clojure è che ha un transpilatore in codice Javascript migliore di quello Java.

Infatti l'articolo accenna del vantaggio di poter compilare il singolo sorgente.

Non discuto i vantaggi prestazionali, solo perplesso sul come il traformare Java -> Clojure -> Javascript sarà gestito senza aumentare la complessità.

Ho anche perplessità nella lista di "linguaggi" suggeriti:

Typescript, Dart, Elm, ScalaJS, PureScript, or TeaVM

Manca Kotlin (https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html)

Manca Elixir (https://elixir-lang.org/), che è acerbo come Elm, ma sembra molto più promettente.

Manca Flow che è analogo a Typescript come sistema per aggiungere i tipi in Javascript.

Dart è OOR, ma non sembra aver riscosso molto successo nel mondo web.

Elm è praticamente immaturo, peraltro nel capitolo sui tipi:

"Types

One of Elm's major benefits is that users do not see runtime errors in practice. This is possible because the Elm compiler can analyze your source code very quickly to see how values flow through your program. If a value can ever be used in an invalid way, the compiler tells you about it with a friendly error message. This is called type inference. The compiler figures out what type of values flow in and out of all your functions."

Per capire meglio:

"Like in JavaScript or Python, we just write the code with no extra clutter."

Se posso permettermi la licenza "poetica" è pensato per non far usare i tipi al programmatore... troppo pericoloso! :)

Scusate la battuta.

ScalaJS sembra interessante è functional + classi, sembra portare Scala in javascript e anche la parte di tipi sembra apprezzabile.

Non conosco performance e maturità...

PureScript: un'altro linguaggio funzionale che compila in Javascript... è recente e sembra in contrapposizione con Elm (come Ruby vs Python).

Dulcis in fundo: TeaVM

Questo sembra veramente interessante: trasforma il bytecode java in WebAssembly

http://teavm.org/

E' una idea recente che propone di usare la virtual machine javascript presente sul browser per eseguire un "compilato" javascript costituito da un subset di istruzioni.

Questo approccio permette di scrivere una web application in rust, compilare il codice con cargo ed eseguire il binario su una pagina web.

Il motivo per cui lo fanno sono le prestazioni eccezionali e la possibilità di usare qualunque linguaggio di programmazione che possa essere compilato (quindi pure Python... ;) ).

Ma siamo all'alba del concept. Ci sono esempi funzionanti e demo, i browser più aggiornati possono far girare le demo, ma non è esattamente un sistema "production ready".

In sostanza l'articolo non mi ha convinto molto, mi ha dato l'impressione di essere un po' superficiale e soprattutto di mischiare cose molto diverse fra loro.

Un punto che ritengo non sia stato affrontato nel parlare di web application di grosse dimensioni è la necessità di utilizzare framework e librerie.

Mentre piccole applicazioni web possono essere scritte in Vanilla Javascript, le applicazioni di "caratura" aziendale che vivono per decenni necessitano che i programmatori siano maggiormente focalizzati sulla logica di business e mantengano soluzioni comuni per risolvere gli stessi problemi. Ecco la necessità di utilizzare framework e librerie che hanno già delle soluzioni standard.

I linguaggi proposti non sempre hanno un ecosistema ricco come quello in Javascript e spesso si includono librerie JS per sopperire alle mancanze.

Il che produce il problema per lo sviluppatore di lavorare su più linguaggi con logiche diverse e workflow diversi per debuggare i problemi.

Scusate sono andato un po' lungo, ma volevo motivare le mie osservazioni.

--

 Mario

[Davide]

Buongiorno,

io vedo la cosa nel seguente modo.

Gwt, vaadin e altri framework (tra cui una mia jvm implementata in
javascript con cui gioco ogni tanto) non hanno di per se problemi
tecnologici a far girare codice java con javascript. E' possibile da
java interagire in entrambe le direzioni con javascript nativo e css,
quindi non vedo limiti particolari.

Non è nemmeno un problema di soldi in se.

Il problema è il mercato. Le app web complesse e di lunga durata sono un
nicchia in confronto al mercato in espansione del web inteso come
siti/ecommerce/ecc...

Per cui ovviamente chi fa framework è più interessato ad un grande
potenziale mercato.

Altra questione è che un app web scritta in java + framework web
richiede skill sia notoriamente "backend" con skill "frontend" nella
stessa persona. Non facile da trovare.

In più pensavo anche se in futuro le "mega form" non verranno, per via
della digitalizzazione, spezzate in più parti di un workflow che
acquisce parte dei dati direttamente dall'utente, altri da banche dati o
web service, backoffice, ecc...

Gwt & co non stanno cercando soluzioni tecniche ma di trovare un modo
per inserirsi in questo mondo web per avere mercato.

On 07/11/2017 20:54, Mario Alexandro Santini wrote:
>
>
> 2017-11-07 19:45 GMT+01:00 Stephan Perktold <stephan....@gmail.com

> <mailto:stephan....@gmail.com>>:

>
> Ciao,
>
>
> Ciao Stephan,
>
> volevo segnalarvi il seguente articolo che ho trovato interessante:
> 5 Pillars of a Successful Java Web Application (Part 1/3)

> <https://developers.redhat.com/blog/2017/11/06/5-pillars-successful-java-web-application-part-13/>

> --
> You received this message because you are subscribed to the Google
> Groups "JUG Trentino Alto Adige Suedtirol" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to jugtaa+un...@googlegroups.com
> <mailto:jugtaa+un...@googlegroups.com>.

> To post to this group, send email to jug...@googlegroups.com

> <mailto:jug...@googlegroups.com>.

[Luca Guadagnini]

Come sempre si sta cercando di piegare un linguaggio per cercare di renderlo più trasversale possibile. Cercare di usare Java per il frontend web è per me una forzatura, un po' come cercare di usare SQL per fare tutta la parte di backend, il ché mi fa dilatare le narici.

[Davide]

Ciao Luca,

credo che in molti la pensano come te al lato pratico. Siamo "noi"
"javaboys" che quando entriamo nel mondo javascript rimpiangiamo le
sicurezze a cui siamo abituati e che ci aiutavano a gestire la
complessità con (più) serenità.

On 08/11/2017 14:16, Luca Guadagnini wrote:
> Come sempre si sta cercando di piegare un linguaggio per cercare di
> renderlo più trasversale possibile. Cercare di usare Java per il
> frontend web è per me una forzatura, un po' come cercare di usare SQL
> per fare tutta la parte di backend, il ché mi fa dilatare le narici.
>
> On Tuesday, 7 November 2017 19:45:02 UTC+1, Stephan Perktold wrote:
>
> Ciao,
>
> volevo segnalarvi il seguente articolo che ho trovato interessante:
> 5 Pillars of a Successful Java Web Application (Part 1/3)

> <https://developers.redhat.com/blog/2017/11/06/5-pillars-successful-java-web-application-part-13/>

>
> È il primo di una serie e parla delle problematiche e delle esigenze
> specifiche di applicazioni web di grandi dimensioni.
> Sembra anche che il prossimo GWT 3 faccia un passo considerevole in
> avanti e che potrebbe essere una scelta promettente per il futuro
> (sempre per applicazioni di grandi dimensioni che devono essere
> mantenute per anni).
>
> Stephan
>
> Am Mittwoch, 25. Oktober 2017 10:06:18 UTC+2 schrieb Davide:
>
>
>
> On 25/10/2017 10:04, Nicola Pedot wrote:
> > Ecco, il tuo è un caso di capitalizzazione, se hai già le
> conoscenze ...
> > avanti tutta.
>
> Per me personalmente si, diverso però è farlo capire ai clienti
> per i
> loro progetti.
>

> --
> You received this message because you are subscribed to the Google
> Groups "JUG Trentino Alto Adige Suedtirol" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to jugtaa+un...@googlegroups.com
> <mailto:jugtaa+un...@googlegroups.com>.

> To post to this group, send email to jug...@googlegroups.com

> <mailto:jug...@googlegroups.com>.

[Mario Alexandro Santini]

2017-11-08 14:16 GMT+01:00 Luca Guadagnini <elg...@gmail.com>:

Come sempre si sta cercando di piegare un linguaggio per cercare di renderlo più trasversale possibile. Cercare di usare Java per il frontend web è per me una forzatura, un po' come cercare di usare SQL per fare tutta la parte di backend, il ché mi fa dilatare le narici.

Concordo con te.

-- 

 Mario

[Davide]

Ciao,

parliamo invece di un altro punto di vista per l'azienda: i costi e la
competitività.

Valutiamo le due possibilità nello sviluppare un app complessa di lungo
periodo (es. gestionale)

a) usare tecnologie web "classiche"
b) usare gwt + trovare un programmatore a cui piace usare java lato client

Mi auto faccio la domanda da 1M di dollari: quali delle due strade mi
avrà dato maggiore competitività e minori costi dopo 5 anni?

C'e' effettivamente una non convenienza economica ad usare gwt o non
stiamo investendo in una nuova soluzione (che può piacere o meno ma a
livello di business è "bello" ciò che fa guadagnare ;-)?

On 08/11/2017 18:31, Mario Alexandro Santini wrote:
>
>
> 2017-11-08 14:16 GMT+01:00 Luca Guadagnini <elg...@gmail.com

> <mailto:elg...@gmail.com>>:

>
> Come sempre si sta cercando di piegare un linguaggio per cercare di
> renderlo più trasversale possibile. Cercare di usare Java per il
> frontend web è per me una forzatura, un po' come cercare di usare
> SQL per fare tutta la parte di backend, il ché mi fa dilatare le narici.
>
>
> Concordo con te.
>
>
> --
>
>
>  Mario
>

> --
> You received this message because you are subscribed to the Google
> Groups "JUG Trentino Alto Adige Suedtirol" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to jugtaa+un...@googlegroups.com
> <mailto:jugtaa+un...@googlegroups.com>.

> To post to this group, send email to jug...@googlegroups.com

> <mailto:jug...@googlegroups.com>.

[Tiziano Lattisi]

Ciao.

Direi che proprio questo è il punto.

Le scelte aziendali devono essere semplicemente scelte che ripagano la strategia aziendale, e rischiano quindi di essere ortogonali alle scelte che farebbe uno sviluppatore.

Da qui ne discendono le classiche affermazioni "i miei capi non capiscono nulla di informatica", che mi portano nella maggior parte dei casi a pensare "meno male". ;-)

T

Il giorno 8 novembre 2017 23:20, Davide <d...@vide.bz> ha scritto:

Ciao,

parliamo invece di un altro punto di vista per l'azienda: i costi e la competitività.

Valutiamo le due possibilità nello sviluppare un app complessa di lungo periodo (es. gestionale)

a) usare tecnologie web "classiche"
b) usare gwt + trovare un programmatore a cui piace usare java lato client

Mi auto faccio la domanda da 1M di dollari: quali delle due strade mi avrà dato maggiore competitività e minori costi dopo 5 anni?

C'e' effettivamente una non convenienza economica ad usare gwt o non stiamo investendo in una nuova soluzione (che può piacere o meno ma a livello di business è "bello" ciò che fa guadagnare ;-)?



On 08/11/2017 18:31, Mario Alexandro Santini wrote:

2017-11-08 14:16 GMT+01:00 Luca Guadagnini <elg...@gmail.com <mailto:elg...@gmail.com>>:

    Come sempre si sta cercando di piegare un linguaggio per cercare di
    renderlo più trasversale possibile. Cercare di usare Java per il
    frontend web è per me una forzatura, un po' come cercare di usare
    SQL per fare tutta la parte di backend, il ché mi fa dilatare le narici.


Concordo con te.


--


  Mario

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+unsubscribe@googlegroups.com <mailto:jugtaa+unsubscribe@googlegroups.com>.

To post to this group, send email to jug...@googlegroups.com <mailto:jug...@googlegroups.com>.
Visit this group at https://groups.google.com/group/jugtaa.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+unsubscribe@googlegroups.com.
To post to this group, send email to jug...@googlegroups.com.

[Stephan Perktold]

Grazie a tutti per le osservazioni molto gradite!

@Mario:
Una piccola correzione: J2CL non compila in Clojure ma in Closure-annotated ES6 che poi viene ottimizato dal Closure compiler.
Secondo me il messaggio principale è che per applicazioni web di grandi dimensioni e di lunga durata la scelta migliore è quella di utilizzare linguaggi con tipo statici. La scelta loro è Java con GWT, ma ovviamente si possono utilizzare anche altri linguaggi. Tutti quanti hanno in comune i tipi statici (che aiutano il refactoring a lunga durata) e la transpilazione in JavaScript.

Il fatto di poter utilizzare Java (tramite GWT o altri framework) anche per il frontend web significa che anche applicazione "vecchie" si possono "aggiornare" con un frontend abbastanza moderno riutilizzando gran parte del codice legacy. Esistono parecchie applicazioni con decine di anni/uomo di sviluppo con un'architettura e struttura dati del tutto aggiornata, dove il frontend "vecchio" non può essere buttato via e riscritto in tempo ragionevole coll'ultimo linguaggio e l'ultima libreria (JavaScript) supersexy.

Per nuovi progetti che partono da zero la scelta sarà ovviamente un'altra ...

Stephan

To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+un...@googlegroups.com <mailto:jugtaa+un...@googlegroups.com>.

To post to this group, send email to jug...@googlegroups.com <mailto:jug...@googlegroups.com>.
Visit this group at https://groups.google.com/group/jugtaa.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jugtaa+un...@googlegroups.com.

[Mario Alexandro Santini]

2017-11-09 10:58 GMT+01:00 Stephan Perktold <stephan....@gmail.com>:

Grazie a tutti per le osservazioni molto gradite!

@Mario:
Una piccola correzione: J2CL non compila in Clojure ma in Closure-annotated ES6 che poi viene ottimizato dal Closure compiler.

Ciao, 

hai ragione! :)

Ho preso un'abbaglio.

 

Secondo me il messaggio principale è che per applicazioni web di grandi dimensioni e di lunga durata la scelta migliore è quella di utilizzare linguaggi con tipo statici. La scelta loro è Java con GWT, ma ovviamente si possono utilizzare anche altri linguaggi. Tutti quanti hanno in comune i tipi statici (che aiutano il refactoring a lunga durata) e la transpilazione in JavaScript.

Anzitutto premetto che non volevo criticare le scelte fatte, notavo solo che l'articolo era un po' superficiale.

Non sono molto d'accordo sul fatto che la scelta vada verso linguaggi fortemente tipizzati per favorire il refactoring. Penso che invece, si stia lasciando stare la parte di tipizzazione nel linguaggio e caricando i compilatori o interpreti dell'onere di fare inferenza sul tipo usato e segnalare situazioni sospette al programmatore.

I "linguaggi" alternativi a Java/GWT proposti nell'articolo erano tutti dinamici.

Anche Javascrip ha i suoi tipi, solo che il tipo della variabile viene risolto a runtime invece che a compile time. Ma dato che oggigiorno anche Javascript è compilato in bytecode non stupirebbe scoprire che si possono fare analisi e inferenze per individuare bug sfuggiti al programmatore.

Non dimenticare che il WebAssembly si basa sulla natura attuale di javascript, hanno solo esposto delle API per accedere ad un subset di istruzioni. Ed il WebAssembly si basa proprio su una tipizzazione forte, che permette di eseguire codice compilato con altri linguaggi grazie all'utilizzo di un bytecode.

Il fatto di poter utilizzare Java (tramite GWT o altri framework) anche per il frontend web significa che anche applicazione "vecchie" si possono "aggiornare" con un frontend abbastanza moderno riutilizzando gran parte del codice legacy. Esistono parecchie applicazioni con decine di anni/uomo di sviluppo con un'architettura e struttura dati del tutto aggiornata, dove il frontend "vecchio" non può essere buttato via e riscritto in tempo ragionevole coll'ultimo linguaggio e l'ultima libreria (JavaScript) supersexy.

Io credo che la soluzione sia una conseguenza del problema che ci troviamo ad affrontare e diffido delle "pietre filosofali" spesso proposte dal marketing.

La mia opinione è che al di la delle considerazioni che si possono fare sulla bontà di un linguaggio e dell'infrastruttura che lo circonda, alla fine della giornata dobbiamo sempre partire dal punto in cui ci troviamo con i piedi ben piantati a terra.

Nella mia carriera mi sono spesso trovato a scegliere tecnologie e linguaggi che non mi convincevano molto, rispetto ad altri in senso assoluto, ma che nella situazione particolare dove mi trovavo ad operare, erano i più adatti, anche con i limiti che avevano.

Ma tieni presente che alle volte l'ultima libreria "supersexy" non è soltato facciata, e ti da veramente un valore in più rispetto a come fai le cose ora. Compito dell'architetto è anche quello di riuscire a vedere questo valore e a fare la scelta delicata e difficile di abbracciare le novità quando ne vale la pena.

Sembra una banalità, ma a volte è quasi un salto nel buio, perché sono molte le cose che possono andare storte e a volte tutto quel valore che ci sembrava di vedere svanisce improvvisamente.

Sono scelte difficili.

Per nuovi progetti che partono da zero la scelta sarà ovviamente un'altra ...

Stephan

--

 Mario

[Mirco Attocchi]

leggendo un tweet sui migliori plugin per eclipse ho scoperto questo
traspilatore Java-to-JS http://www.jsweet.org/
Non conosco progetti che ne fanno uso ma ho guardato il set di
librerie che supporta ... non me lo aspettavo, interessante ...

Mirco

[Davide]

molto scarso perché la conversione quasi uno a uno non tiene conto del differente comportamento in certi casi: null, equals, ecc .

Sent from mobile phone

.

[Davide]

conversione implicita dei tipi ....

Sent from mobile phone

.