Newsgroup: it.comp.lang.javascript
Titolo: Approfondire Javascript

Ciao a tutti,
Uso Javascript da anni come sviluppatore web fullstack, ma per motivi
sia personali che lavorativi avrei intenzione di approfondirlo in modo
più "formale".
 
In ufficio abbiamo un vecchio libro: "Javascript - La guida" della
O'reilly. Si tratta di una edizione del 2000 relativo a Javascript 1.3.
Ha ancora senso leggersi un libro del genere, oppure è completamente
sorpassato?
 
-- 
g4b0, linux user n. 369000
http://brosulo.net
 

 sorpassato?
 
Beh i concetti fondamentali, costrutti del linguaggio, usi tipici
comuni, ecc. ci dovrebbero essere, il problema è che JavaScript
è il linguaggio più martoriato e più rimaneggiato degli ultimi
anni, quindi ne hanno introdotto di modifiche, aggiunte,
eliminazione di API obsolete, ecc...
Converrebbe quindi procurarsi qualcosa di più aggiornato,
dato anche che la versione utilizzata adesso è la 1.8.6
 
 
 
 

 ha scritto:

Anzi seguendo l'ECMA standard la versione corrente è la 6!
 
 
 

 dato anche che la versione utilizzata adesso è la 1.8.6
 
Immaginavo, anche se speravo che fosse un qualcosa di simile al C, per
il quale il K&R è ancora più che attuale.
 
Grazie per la delucidazione


 il quale il K&R è ancora più che attuale.
 
No purtroppo non è la stessa cosa, vero è che anche per il
linguaggio C esiste uno standard che però evolve mooolto più
lentamente di JavaScript. Per quest'ultimo invece si prende
come base lo standard ECMA che però evolve molto più velocemente
e sensibilmente, con variazioni anche significative tipo
come accennato l'eliminazione di API deprecate.
 
 
 

 come accennato l'eliminazione di API deprecate.
 
Capito.



 
Purtroppo è fermo a ES5, visto che mi non sembra siano state pubblicate 
edizioni aggiornate.
 
Nulla di nuovo e anche quando lo ebbi in mano trovai principalmente cose 
che uno sviluppatore js dovrebbe conoscere a memoria, ma è stato lo 
stesso un piacere leggerlo.
 
Forse per uno che js deve approfondirlo può funzionare ancora?

On Friday, 15 January 2016 13:10:59 UTC, g4b0  wrote:
 
[...]
Lascia stare il libro che hai in ufficio. 
 
Questa e` una lista dei libri che io ti consiglio:
 
http://www.goodreads.com/list/show/10757.Best_JavaScript_Books
 
 
Leggi qualunque cosa Douglas Crockford o John Resig scrivono ;)

 sorpassato?
 
Ce l'ho anche io. Puoi usarlo per alzare il monitor. :)
 
Il miglior libro su Javascript "moderno" che abbia mai letto è 
"Professional Javascript" di N. Zakas (della Wrox).
 
Si basa su Javascript 1.5/Ecmascript5 (ES5), che però è tuttora quello 
supportato da tutti i browser.
 
Ecmascript6/Ecmascript2015 (adesso hanno deciso di chiamarli con gli anni 
perchè sperano di rilasciarne uno all'anno) è stato più o meno formalizzato 
a dicembre 2015, e introduce un sacco di syntactic sugar. In parte fatto 
bene (let, const), in parte raffazzonato (class), in parte sbilenco 
(destructuring), IMHO
 
Prima di prenderlo in mano, imparati bene ES5, che rimane comunque valido 
(per esempio, come si gestisce il this o gli attributi degli oggetti).
 
Finito quello, prendi in mano un framework e inizia a studiartelo. Io ti 
sconsiglio Angular e React. Non perché non siano buoni, ma perché sono 
troppo chiusi in sè stessi e non ti insegnano niente tranne il loro 
sistema.
 
Parti da Backbone (con Underscore e jQuery), a cui poi aggiungi Marionette 
(quasi subito) e RequireJs. Anche se poi non lo userai, ti darà una buona 
base di MV*, rimanendo molto vicino al Javascript classico.
 
Fatto quello, a meno che non sia uscito qualcosa di completamente nuovo 
nel frattempo, puoi prendere in mano React, con tutta la sua pletora di 
tool aggiuntivi necessari per usarlo decentemente (jsx, babel, flux/redux/
sarcazzux, node/npm, grunt/gulp/sarcazzunp, ecc.).
 
Salterei a piè pari Angular, che farà presto la fine di GWT e YUI, IMHO.
 
Bye.

 Salterei a piè pari Angular, che farà presto la fine di GWT e YUI, IMHO.
 
Dici?


Secondo me sarà vittima della sua stessa "strategia". Ha rivoluzionato il 
modo di fare framework in JS, e meno di 2 anni dopo React lo ha 
rivoluzionato di nuovo, ma nel senso opposto.
 
Non morirà di certo in 1-2 anni. Ci sono troppi che l'hanno adottato, ma 
visto che la 2 sarà incompatibile, molti stanno già saltando il fosso, 
cercando di integrare i componenti di react o flux/redux nelle app 
angular. Cosa gli impedirà di passare direttamente a react quando la 1 sarà 
end-of-life?
 
Adesso non è più abbastanza cool da essere usato dalle startup, ed è già 
diventato legacy.
 
Nel giro di 2 anni potrebbe capitare lo stesso a react, eh. :)
 
Il panorama js adesso è completamente impazzito. Le tecnologie cambiano 
ogni settimana. Non fai in tempo a imparare un tool o una metodologia che 
te lo cambiano. O si stabilizza un po' o esplode del tutto, IMHO.
 
Esperienza personale: ho passato una giornata a configurare npm, babel, 
react, jsx per vedere come usare ES6 con React e Redux, per trovarmi alla 
fine con 300 MB di moduli node, e un banale hello world che scarica 1 MB 
di JS sul client. Tutto per "l'eldorado" delle app isomorfiche. In epoca 
di API e microservizi.
 
La stessa cosa in jQuery, Backbone, Marionette con require.js stava in 
meno di 200kb ed erano già tanti. E niente build-time o moduli node.
 
Mi sono chiesto se ne valga la pena, o se per caso non sarebbe meglio 
sviluppare un po' l'idea modulare di Marionette semplificando Backbone per 
fargli fare solo da model.
 
OK, mi sono sfogato un po', sorry. :)
 
Bye.

 ha scritto:

No ma è così purtroppo, ormai ci sono troppi framework, troppe
librerie, troppa roba "di contorno". Ormai è tutta un'accozzaglia
di file da importare e impastare, non c'è più una sana e giusta
progettazione dal basso, stando attenti al consumo di risorse
varie (banda, spazio, velocità, ecc.). E' per questo che
se c'è da fare una cosa in JavaScript io la faccio in
JavaScript puro, senza essere costretto a dipendere da
una libreria che oggi c'è e domani può benissimo essere
abbandonata.
 
 

 JavaScript puro, ... .
 
Evviva!
Qualcuno è rimasto ancora.
Ciao
 
-- 
Alex
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

 Detto questo, parecchio tempo fa Zer0
 
A proposito, che fine ha fatto? Si sente la sua mancanza. Mi ricordo 
quando mi ha spiegato le closure tre volte, perché ogni volta gli dicevo 
di avere capito e invece non avevo capito nulla, e poi le promise...
 


L'ho sentito, un po' di corsa, giusto stamattina: è vivo e vegeto e sta 
bene; non ho fatto in tempo a redarguirlo per la latitanza.
 
Quando lo sento con più calma gli dico che ti manca!
 


Grazie, mi farebbe piacere! E nel frattempo grazie a chi in sua assenza 
ha tenuto vivo il gruppo, io anche se non partecipo leggo tutto. In 
questo thread senza capire quasi nullax/nientux, ma non fa niente! :)

Grazie a tutti per i suggerimenti, vorrà dire che metterò mano al
portafogli e prenderò qualcosa di più recente.


 portafogli e prenderò qualcosa di più recente.
 
Alla fine ho preso questi, arriveranno a giorni:
 
http://www.amazon.it/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=&sr=
 
 
http://www.amazon.it/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=&sr=
 
 
Con quale inizio?


 
https://it.wikibooks.org/wiki/JavaScript/Costruttori_e_prototipi
 
 
Leggendo i due link ho notato che i metodi degli oggetti vengono
dichiarati in modo diverso. Quale dei seguenti è più corretto?
 
this.pippo = function() {}
function pippo() {}


 Con quale inizio?
 
Zakas e` piu` indicato per iniziare. Di Crockford ti consiglio di seguire anche la sua pagina personale: 
http://www.crockford.com/
 

 function pippo() {}
 
Il metodo migliore per costruire oggetti e` usare il constructor/prototype pattern:
 
function Dog(name, breed) {
 
this.name
 = name;
    this.breed = breed;
}
 
Dog.prototype.bark = function() {
    alert(
this.name
 + ': arf! arf!');
};
 
Dog.prototype.howl = function() {
    alert(
this.name
 + ': ouuuuuuu!')
}
 
var dog1 = new Dog('Fido', 'German Shepherd');
var dog2 = new Dog('Pluto', 'Bloodhound');
 
dog1.bark();
dog2.howl();

 dog2.howl();
 
Avevo letto da qualche parte che dal punto di vista delle performance
passare attraverso il prototype è meno performante che dichiarare i
metodi direttamente, ma forse era un articolo datato...
 
Però firefox che nella console mi segnala questo warning:
 
mutating the [[Prototype]] of an object will cause your code to run very
slowly; instead create the object with the correct initial [[Prototype]]
value using Object.create
 
In realtà non indica il codice a cui si riferisce, per cui forse sono io
che faccio confusione. Oppure no?


 dog2.howl();
 
Avevo letto da qualche parte che dal punto di vista delle performance
passare attraverso il prototype è meno performante che dichiarare i
metodi direttamente, ma forse era un articolo datato...
 
Però firefox che nella console mi segnala questo warning:
 
mutating the [[Prototype]] of an object will cause your code to run very
slowly; instead create the object with the correct initial [[Prototype]]
value using Object.create
 
In realtà non indica il codice a cui si riferisce, per cui forse sono io
che faccio confusione. Oppure no?
 


 value using Object.create
 
Perche` cambiare il prototype di un oggetto inesistente impedisce l'ottimizzazione (e quindi presumibilmente ammazza le performance), pero` puoi postare l'intero codice che hai utilizzato? 
 
 

 Perche` cambiare il prototype di un oggetto inesistente
 
*esistente
 
 
-- 
4ndr4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)
"Ora, questo "Delta11" non è nulla di più di uno scemo del 
villaggio[...]" - 
http://goo.gl/1nrkkX