goffreder/Note su JS

## Note su JS
Immutable collections (oggetti immutabili)
Si tratta di creare oggetti che non possono essere mutati. Esiste un'implementazione standard (Object.freeze()) ma ha alcuni problemi e non fornisce helpers. Esistono varie librerie.
Permettono di fare comodamente undo/redo salvando i vari stati (soprattutto se si sa che alcune parti non cambiano, è semplice mantenere gli stati facendo diff) [https://scott.mn/2014/04/27/why_immutable_collections/]
Separazione tra identità e valori (vedere Clojure [https://scott.mn/2014/01/20/reference_types_separate_identities_and_values/])
Molto efficiente unione React + immutable (se opportunamente configurato si possono evitare alcuni re-render dell'applicazione, sapendo che a identità diverse corrispondono valori diversi) [http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/] (vedere benchmarks, Backbone [http://swannodette.github.io/todomvc/architecture-examples/backbone/index.html] vs Om (Clojure) [http://swannodette.github.io/todomvc/labs/architecture-examples/om/index.html])

VirtualDOM
Sembra una figata ([http://calendar.perfplanet.com/2013/diff/]), lo usa React ma sembra essere implementabile in modo "agile" [https://gist.github.com/Raynos/8414846]. Però React implementa un sacco di "boilerplate" che probabilmente finiremmo per riscrivere noi (eventi, VirtualDOMNodes, etc...).
Dai benchmark ([http://www.filamentgroup.com/lab/mv-initial-load-times.html]) pare molto più veloce di dirty-checking (Angular), pub/sub (Ember).

Data binding
C'è chi dice che non sia fondamentale, a me pare una figata. Indagare. [http://bitworking.org/news/2014/05/zero_framework_manifesto] [https://andywalpole.me/#!/blog/142134/2015-the-end-the-monolithic-javascript-framework]


Valutazione MVC vs "resto"
Il pattern MVC si presta male a un mondo event-driven come una web application. [http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/]
Flux continua a sembrarmi che richieda troppo codice “boilerplate” e ha una struttura semplice da capire ma complessa da tirare su [https://medium.com/@garychambers108/understanding-flux-f93e9f650af7][https://medium.com/@garychambers108/flux-in-practice-ec08daa9041a]. Probabilmente in un progetto che si prevede veda avvicendarsi un po’ di sviluppatori e un tempo lungo di sviluppo e mantenimento è una scelta vincente, per il software di tagging (teoricamente da sviluppare in una volta sola e con manutenzione minima) il tempo necessario per comprenderlo e applicarlo al software potrebbe essere troppo rispetto a un MVC più classico, forse più complesso da mantenere ma più rapido da realizzare(?).


Angular
Molto male nella decisione di cambiare le API da versione 1.x a versione 2.0, molte lamentele. Google non è secondo me affidabilissima dal punto di vista dello sviluppatore. [http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/]
Comporta di scrivere molto codice nel DOM (brutto), sembra scritto con un approccio alla Java, framework abbastanza vecchio (più giovane solo di Backbone), non lo usano nemmeno loro.
[http://www.quirksmode.org/blog/archives/2015/01/the_problem_wit.html]

React
Ci hanno fatto l’applicazione web di Whatsapp.

Ember
Mi piace molto la filosofia che hanno adottato: rilasci frequenti (ciclo di 6 settimane) in cui ciò che è deprecato ha il tempo di essere corretto (ottimi sia i messaggi di console del framework base, sia l’utilizzo dell’estensione Ember Inspector), se trovano una tecnica migliore (anche copiandola) cercano di adottarla (vedi caso VirtualDOM di React), documentazione buona (migliore di Angular), comunità buona (inferiore ma secondo me più “qualitativa” rispetto ad Angular), approccio comunque conservativo (non intendono “spaccare tutto” ad ogni release), “convention-over-configuration” (concetto un po’ magico ma valido, se i componenti sono chiamati in modo coerente si includono implicitamente, (Es. TestView che chiama TestController che usa TestModel)), molto molto figo ember-cli (usa node), valida anche piattaforma di testing (usa Qunit). Performance non eccezionali (ma ci stanno lavorando).
L’ho approfondito molto più di Angular comunque.
Esempio famoso di utilizzo: Discourse [http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.html]


Uso di framework vs librerie vs "nulla"
Scegliere un framework comporta scegliere una comunità e ti "lega" a quel tipo di soluzioni. Una valida alternativa è quella di comporre uno stack di librerie e micro-framework che possano essere sostituiti a seconda della necessità. [http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/] D'altra parte, l'utilizzo di un framework “full stack” nel momento in cui arriva una nuova tecnologia o metodologia, rende virtualmente possibile che questo ci sia totalmente trasparente (es. Ember scopre che VirtualDOM > pub/sub => lo implementa senza cambiare API). Da un punto di vista aziendale, se si usano JS+HTML+CSS "standard" come collante tra le librerie, un nuovo assunto deve solo conoscere gli standard e non il framework. Potenzialmente però meno efficiente rispetto a usare un framework conosciuto e assumere qualcuno che abbia esperienza (comporta però saperlo usare noi in primis). [https://andywalpole.me/#!/blog/142134/2015-the-end-the-monolithic-javascript-framework]
Decidere di non usare un framework inevitabilmente comporta di scrivere il proprio. Però se non si ha bene in testa questa conseguenza, si finisce per scrivere una serie di funzioni non modulari (nè modulabili) senza documentazione o API coerenti e che necessita di manutenzione. [http://blog.ryanflorence.com/you-cant-not-have-a-framework.html]


Performance
Il VirtualDOM (React) sembra essere molto performante (vedi benchmark con Om/Clojure). I framework monolitici sembrano essere più lenti soprattutto su dispositivi mobile, sia Ember che Angular hanno performance inferiori a Backbone (che però per altri motivi non mi sembra una via percorribile) [http://www.filamentgroup.com/lab/mv-initial-load-times.html] (vedere anche spreadsheet linkato per performance Ampersand e React).

Offline
Per far funzionare l’applicazione offline ci sono varie possibilità.
ServiceWorker: sembra la soluzione migliore, verificare ancora supporto. Necessita di HTTPS. [https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker_API/Using_Service_Workers - non sono riuscito a far funzionare l’esempio]
AppCache: “is a douchebag” [http://alistapart.com/article/application-cache-is-a-douchebag], utilizza un file di manifest in cui specificare quali file vengono cachati e a quali condizioni [http://diveintohtml5.info/offline.html]
Gestione di conflitti quando si torna online, vari aspetti “concettuali” da valutare [http://alistapart.com/article/offline-first].


Link vari
Un confronto tra vari framework (tira in ballo anche Polymer e Ampersand) [http://blog.andyet.com/2014/08/13/opinionated-rundown-of-js-frameworks]
Overview interessante sull'architettura di un app JS nel 2015. Web components (estrema modularità e incapsulamento, functional programming, React in pratica), implementabili come Shadow DOM (per migliore encapsulamento e closure di eventi e stili [http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/], interessante eventualità React + ShadowDOM). MVC superato (comunicazione tra componenti caotica, meglio modello Flux - CSP (da approfondire [http://phuu.net/2014/08/31/csp-and-transducers.html][http://jlongster.com/Taming-the-Asynchronous-Beast-with-CSP-in-JavaScript]). Grosso uso di npm per sviluppo, strumenti come Browserify [http://benclinkinbeard.com/posts/how-browserify-works/] e transpilers per ES6 (anche 7). Ragionare offline e mobile first (in questo caso per software tagging meno importante). [https://medium.com/@addyosmani/javascript-application-architecture-on-the-road-to-2015-d8125811101b]
	Immutable collections (oggetti immutabili)
	Si tratta di creare oggetti che non possono essere mutati. Esiste un'implementazione standard (Object.freeze()) ma ha alcuni problemi e non fornisce helpers. Esistono varie librerie.
	Permettono di fare comodamente undo/redo salvando i vari stati (soprattutto se si sa che alcune parti non cambiano, è semplice mantenere gli stati facendo diff) [https://scott.mn/2014/04/27/why_immutable_collections/]
	Separazione tra identità e valori (vedere Clojure [https://scott.mn/2014/01/20/reference_types_separate_identities_and_values/])
	Molto efficiente unione React + immutable (se opportunamente configurato si possono evitare alcuni re-render dell'applicazione, sapendo che a identità diverse corrispondono valori diversi) [http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/] (vedere benchmarks, Backbone [http://swannodette.github.io/todomvc/architecture-examples/backbone/index.html] vs Om (Clojure) [http://swannodette.github.io/todomvc/labs/architecture-examples/om/index.html])

	VirtualDOM
	Sembra una figata ([http://calendar.perfplanet.com/2013/diff/]), lo usa React ma sembra essere implementabile in modo "agile" [https://gist.github.com/Raynos/8414846]. Però React implementa un sacco di "boilerplate" che probabilmente finiremmo per riscrivere noi (eventi, VirtualDOMNodes, etc...).
	Dai benchmark ([http://www.filamentgroup.com/lab/mv-initial-load-times.html]) pare molto più veloce di dirty-checking (Angular), pub/sub (Ember).

	Data binding
	C'è chi dice che non sia fondamentale, a me pare una figata. Indagare. [http://bitworking.org/news/2014/05/zero_framework_manifesto] [https://andywalpole.me/#!/blog/142134/2015-the-end-the-monolithic-javascript-framework]


	Valutazione MVC vs "resto"
	Il pattern MVC si presta male a un mondo event-driven come una web application. [http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/]
	Flux continua a sembrarmi che richieda troppo codice “boilerplate” e ha una struttura semplice da capire ma complessa da tirare su [https://medium.com/@garychambers108/understanding-flux-f93e9f650af7][https://medium.com/@garychambers108/flux-in-practice-ec08daa9041a]. Probabilmente in un progetto che si prevede veda avvicendarsi un po’ di sviluppatori e un tempo lungo di sviluppo e mantenimento è una scelta vincente, per il software di tagging (teoricamente da sviluppare in una volta sola e con manutenzione minima) il tempo necessario per comprenderlo e applicarlo al software potrebbe essere troppo rispetto a un MVC più classico, forse più complesso da mantenere ma più rapido da realizzare(?).


	Angular
	Molto male nella decisione di cambiare le API da versione 1.x a versione 2.0, molte lamentele. Google non è secondo me affidabilissima dal punto di vista dello sviluppatore. [http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/]
	Comporta di scrivere molto codice nel DOM (brutto), sembra scritto con un approccio alla Java, framework abbastanza vecchio (più giovane solo di Backbone), non lo usano nemmeno loro.
	[http://www.quirksmode.org/blog/archives/2015/01/the_problem_wit.html]

	React
	Ci hanno fatto l’applicazione web di Whatsapp.

	Ember
	Mi piace molto la filosofia che hanno adottato: rilasci frequenti (ciclo di 6 settimane) in cui ciò che è deprecato ha il tempo di essere corretto (ottimi sia i messaggi di console del framework base, sia l’utilizzo dell’estensione Ember Inspector), se trovano una tecnica migliore (anche copiandola) cercano di adottarla (vedi caso VirtualDOM di React), documentazione buona (migliore di Angular), comunità buona (inferiore ma secondo me più “qualitativa” rispetto ad Angular), approccio comunque conservativo (non intendono “spaccare tutto” ad ogni release), “convention-over-configuration” (concetto un po’ magico ma valido, se i componenti sono chiamati in modo coerente si includono implicitamente, (Es. TestView che chiama TestController che usa TestModel)), molto molto figo ember-cli (usa node), valida anche piattaforma di testing (usa Qunit). Performance non eccezionali (ma ci stanno lavorando).
	L’ho approfondito molto più di Angular comunque.
	Esempio famoso di utilizzo: Discourse [http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.html]


	Uso di framework vs librerie vs "nulla"
	Scegliere un framework comporta scegliere una comunità e ti "lega" a quel tipo di soluzioni. Una valida alternativa è quella di comporre uno stack di librerie e micro-framework che possano essere sostituiti a seconda della necessità. [http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/] D'altra parte, l'utilizzo di un framework “full stack” nel momento in cui arriva una nuova tecnologia o metodologia, rende virtualmente possibile che questo ci sia totalmente trasparente (es. Ember scopre che VirtualDOM > pub/sub => lo implementa senza cambiare API). Da un punto di vista aziendale, se si usano JS+HTML+CSS "standard" come collante tra le librerie, un nuovo assunto deve solo conoscere gli standard e non il framework. Potenzialmente però meno efficiente rispetto a usare un framework conosciuto e assumere qualcuno che abbia esperienza (comporta però saperlo usare noi in primis). [https://andywalpole.me/#!/blog/142134/2015-the-end-the-monolithic-javascript-framework]
	Decidere di non usare un framework inevitabilmente comporta di scrivere il proprio. Però se non si ha bene in testa questa conseguenza, si finisce per scrivere una serie di funzioni non modulari (nè modulabili) senza documentazione o API coerenti e che necessita di manutenzione. [http://blog.ryanflorence.com/you-cant-not-have-a-framework.html]


	Performance
	Il VirtualDOM (React) sembra essere molto performante (vedi benchmark con Om/Clojure). I framework monolitici sembrano essere più lenti soprattutto su dispositivi mobile, sia Ember che Angular hanno performance inferiori a Backbone (che però per altri motivi non mi sembra una via percorribile) [http://www.filamentgroup.com/lab/mv-initial-load-times.html] (vedere anche spreadsheet linkato per performance Ampersand e React).

	Offline
	Per far funzionare l’applicazione offline ci sono varie possibilità.
	ServiceWorker: sembra la soluzione migliore, verificare ancora supporto. Necessita di HTTPS. [https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker_API/Using_Service_Workers - non sono riuscito a far funzionare l’esempio]
	AppCache: “is a douchebag” [http://alistapart.com/article/application-cache-is-a-douchebag], utilizza un file di manifest in cui specificare quali file vengono cachati e a quali condizioni [http://diveintohtml5.info/offline.html]
	Gestione di conflitti quando si torna online, vari aspetti “concettuali” da valutare [http://alistapart.com/article/offline-first].


	Link vari
	Un confronto tra vari framework (tira in ballo anche Polymer e Ampersand) [http://blog.andyet.com/2014/08/13/opinionated-rundown-of-js-frameworks]
	Overview interessante sull'architettura di un app JS nel 2015. Web components (estrema modularità e incapsulamento, functional programming, React in pratica), implementabili come Shadow DOM (per migliore encapsulamento e closure di eventi e stili [http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/], interessante eventualità React + ShadowDOM). MVC superato (comunicazione tra componenti caotica, meglio modello Flux - CSP (da approfondire [http://phuu.net/2014/08/31/csp-and-transducers.html][http://jlongster.com/Taming-the-Asynchronous-Beast-with-CSP-in-JavaScript]). Grosso uso di npm per sviluppo, strumenti come Browserify [http://benclinkinbeard.com/posts/how-browserify-works/] e transpilers per ES6 (anche 7). Ragionare offline e mobile first (in questo caso per software tagging meno importante). [https://medium.com/@addyosmani/javascript-application-architecture-on-the-road-to-2015-d8125811101b]