Share
Una stella luminosa nella community JavaScript, Addy Osmani è salito alle stelle non solo per i suoi favolosi articoli JavaScript e contributi open source, ma anche per essere uno degli sviluppatori più gentili e disponibili in giro.
Il suo blog è una fonte di conoscenza del front-end e merita la visita. In questo post, parleremo con Addy di come si è bagnato i piedi in JS e ha sollevato alcuni argomenti difficili relativi al suo lavoro nelle relazioni con gli sviluppatori di Google.
JavaScript avrebbe svolto un ruolo importante nel rendere ciò possibile.
Ho scritto alcuni dei miei primi JavaScript quando Netscape Navigator era il browser dominante. Lo sviluppo dinamico del front-end stava lentamente iniziando a diventare più popolare all'epoca, ma l'idea di poter scrivere qualcosa solo con HTML / CSS / JS e farlo funzionare ovunque era potente. Mi sono appassionato a questa idea e da allora sono stato sempre. Alcune delle mie prime creazioni erano piccole cose di cui rideresti oggi - calcolatrici, generatori di password, niente di troppo sorprendente.
Come appassionato di linguaggio, mi è piaciuto che JavaScript fosse basato su prototipi e debolmente tipizzato, così ho deciso di continuare ad apprenderlo insieme ad altri linguaggi come il C ++. Nei primi anni 2000, ho provato a collegare le lingue scrivendo un piccolo interprete su SpiderMonkey (il motore JavaScript di Mozilla), che mi permette di scrivere la logica per le mie app desktop in JS e definire i componenti dell'interfaccia utente usando C ++. È stata un'idea sciocca, ma ho imparato molto sui componenti interni del motore JavaScript nel processo.
Ho passato molto tempo a costruire piccoli siti di hobby, ma quando ero al mio ultimo anno al liceo, ho deciso di rimanere davvero intrappolato nel mondo degli interni dei browser. Ho scritto un motore di rendering leggero, parser HTML 4.01 / CSS 2.1 di base e ho avvolto tutte queste parti nel mio piccolo browser. Il progetto è stato un incubo per lavorare in modo affidabile, in parte a causa della scarsa conformità degli sviluppatori web con le norme nelle loro pagine: è divertente essere dall'altra parte del recinto ora! Le sfide maggiori erano la conformità con le specifiche, il rendering di tabelle di grandi dimensioni e il mantenimento delle prestazioni, mentre si caricavano i plug-in video (qualcuno ricorda il buon vecchio ActiveX?).
Ho continuato ad imparare e ad usare JavaScript come sviluppatore web freelance mentre ero al college, scrivendo lentamente siti più complessi e giocando con Dojo. Non è stato, tuttavia, fino a quando non ho ricevuto un invito a GMail nel 2006 che mi è venuto in mente che il browser sarebbe stato la prossima piattaforma per la creazione di applicazioni avanzate. JavaScript avrebbe svolto un ruolo importante nel rendere ciò possibile e ho deciso di abbandonare definitivamente lo sviluppo di app desktop.
Da allora, ho cercato di continuare ad imparare e dove posso, spingere la comunità front-end in avanti attraverso la mia scrittura e i contributi ad open-source. JavaScript è praticamente ovunque oggi ed è uno dei motivi per cui amo la lingua. Se voglio insegnare a uno dei miei figli a scrivere JavaScript, posso semplicemente aprire il mio browser DevTools e mostrarlo. Non sono necessari ulteriori passaggi di compilazione: c'è qualcosa di veramente speciale in questo.
Se passi a un argomento non banale con questa mentalità, è necessario scomporlo in passaggi semplici e facilmente digeribili
Il segreto è che mi considero un po 'stupido. Veramente. Se entri in un argomento non banale con questa mentalità, è necessario scomporlo in passaggi semplici e più facilmente digeribili per fare in modo che ogni parvenza di senso.
È questa la prospettiva che ritengo sia accessibile alla mia scrittura - cerco di dare un senso a quei concetti o strumenti che inizialmente possono sembrare scoraggianti per lo sviluppatore medio. È importante essere in grado di applicare questo agli articoli e in particolare alla documentazione. Quindi, tienilo semplice. Questo aiuta a rendere gli articoli più mirati. Come faccio a generare così tanto contenuto mentre capisco il materiale? Bene, rendo la comprensione un prerequisito.
Prima fallo, poi fallo bene, quindi fallo meglio.
Einstein ha questa grande citazione: "Se non riesci a spiegarlo semplicemente, non lo capisci abbastanza bene" ed è vero. Non puoi insegnare o pretendere un quadro, uno strumento o una buona pratica, a meno che tu non abbia effettivamente avuto il tempo di usarlo tu stesso. Trovare questa volta è più facile nel mio ruolo attuale, ma nei miei giorni come ingegnere di 9-5, passavo il tempo a colazione e a pranzo usando attivamente quello che avrei scritto più tardi durante il fine settimana.
Trovare il tempo per fare tutto è sempre una sfida. Negli ultimi anni ho questo mantra che cerco di applicare ad ogni compito - "
Puoi quindi condividere questa prima iterazione con i tuoi colleghi e capire se stai andando nella giusta direzione o se vale la pena perseguire l'idea. Per me, è molto più sensato che passare settimane su una bozza o un prototipo prima di chiedere un input.
C'è qualcosa di speciale nell'essere parte di un'azienda con standard così elevati.
Sia AOL che Google sono aziende con team di ingegneri terrificanti, e nessuna delle mie riflessioni sulla cultura non riguarda gruppi specifici, più un'osservazione generale.
La cultura ingegneristica di Google è tale che ci preoccupiamo molto di lucidare e spedire le cose quando riteniamo che siano giuste. C'è qualcosa di speciale nell'essere parte di un'azienda con standard così elevati.
In AOL, ero orgoglioso di tutti i prodotti o applicazioni che abbiamo completato, ma a causa della natura frenetica del business e della concorrenza, ritardare lanci o rilasci per la lucidatura non era sempre fattibile. Penso che sia una realtà per molte aziende, nonostante qualsiasi desiderio possa dover cambiare quella cultura.
Quando è possibile posticipare i rilasci a, come dice Google, ottenerlo "giusto", penso che possa fare un mondo di differenza per le prime impressioni dei tuoi utenti sui tuoi prodotti.
Sono soddisfatto della direzione che TC39 ha assunto negli ultimi anni.
Sono soddisfatto della direzione che TC39 ha assunto negli ultimi anni, che in parte è stato aiutato con il coinvolgimento di Rick Waldron e Yehuda Katz del progetto jQuery. Hanno prestato molta attenzione ai modelli e alle librerie su cui gli sviluppatori si sono fortemente basati e hanno studiato come questi potrebbero essere meglio risolti usando i primitivi della piattaforma. Non farò commenti specifici su ES6, ma non vedo l'ora di vedere moduli, classi, "lascia" e Object.observe () disponibile più ampiamente.
Nella community JavaScript: siamo in un buon posto ma l'unica cosa che vorrei fare collettivamente è dedicare meno tempo a creare nuovi framework e più tempo a investire negli sforzi per migliorare le soluzioni esistenti. Penso che sia fantastico che gli sviluppatori stiano spendendo del tempo per imparare come risolvere i problemi da soli - è uno dei modi migliori per imparare cose nuove - ma se si tratta di un esperimento, chiariscilo in modo che altri sviluppatori non si aspettino che tu mantenga il progetto. Questo tipo di cose non fa che aumentare il rumore, quindi tieni a mente il supporto quando rilascerai le cose!.
Uno dei grandi miti là fuori è che esiste per sostituire JavaScript.
Ero davvero curioso di sapere di più sugli obiettivi che Dart aveva quando sono entrato a far parte di Google. Uno dei grandi miti là fuori è che esiste per sostituire JavaScript, ma si scopre che questo non è del tutto vero. Dart è rivolto a quegli sviluppatori che hanno più familiarità con Java, C ++, C #, che stanno cercando di creare app web ad alte prestazioni; e così via, avere certe aspettative attorno al loro stampo e al linguaggio. Penso che sia una ragione legittima per qualcosa come Dart esistere.
Come azienda, sia JavaScript che Dart sono tecnologie in cui crediamo e investiamo. Partecipiamo a TC39, lavorando sul futuro di JavaScript e continuando a lavorare su V8, il motore JavaScript veloce. Gli ingegneri di Chrome continuano a lavorare per spingere il web in avanti con nuove specifiche come Web Components. Nel frattempo, il team che ha originariamente costruito V8 sta ora costruendo la Dart VM.
Tornando alla tua domanda iniziale, credo che la forking di WebKit abbia avuto molto più a che fare con la divergenza dell'architettura multiprocesso tra entrambi i progetti che con il tentativo di incorporare Dart in Chrome. Dart è un progetto open source separato con i suoi stessi obiettivi e puoi ancora ottenere Dartium oggi (la build di Chromium usando la Dart VM).
Quando ho sentito per la prima volta la notizia di Blink, temevo che ora avremmo un altro browser da supportare.
La realtà, tuttavia, è che ci sono già state così tante differenze tra le varie porte WebKit che questo non avrà un impatto negativo su come sviluppate e testate.
Infatti, Blink ci consente di offrire agli sviluppatori più strumenti, caratteristiche e compatibilità di cui hanno bisogno per ottenere il massimo dal Web come piattaforma. A lungo termine ci consentirà di dare la priorità alle funzionalità che faciliteranno la creazione della prossima generazione di app Web e nello stesso modo in cui V8 ci ha dato un modo per velocizzare JavaScript, penso che Blink ci consentirà di innovare in modi che possano avvantaggiare tutta la piattaforma.
Al giorno d'oggi siamo spesso coinvolti nel dibattito tra nativo e web, ma non parliamo tanto della necessità di mettere al primo posto i nostri utenti. Sono al centro. Ci sono molti casi in cui puoi offrire un'esperienza avvincente per il web su desktop e mobile e funzionerà in modo fantastico. Detto questo, ce ne sono altri, dove la piattaforma o i browser mobili hanno ancora bisogno di lavoro. Come azienda, è spesso necessario effettuare una chiamata su ciò che ha più senso per gli utenti. Penso che, al momento, sia molto sensato offrire agli sviluppatori le migliori piattaforme possibili per effettuare una chiamata su nativo vs web, ed è quello che facciamo, tramite Android e Chrome per dispositivi mobili.
Componenti riutilizzabili.
Componenti riutilizzabili Tradizionalmente, molti di noi hanno sviluppato applicazioni in modo abbastanza verticale, diffondendo un singolo concetto (che si tratti di logica o interfaccia utente) in diverse parti del progetto. Ciò non solo rende più difficile mantenere l'idea, ma rende anche difficile estrarre e riutilizzare l'idea nelle applicazioni future senza un grande sforzo. Riduce anche le nostre possibilità di essere in grado di condividere il componente con gli altri.
Senza fare riferimento a tecnologie specifiche, stiamo lavorando per semplificare la definizione e il pacchetto di componenti sul lato della piattaforma web, e ora è un ottimo momento per iniziare a pensare a come le tue app potrebbero essere scritte, se fossero suddivise in componenti specifici.
Il front-end sta assistendo a una rivoluzione degli strumenti in questo momento con un numero crescente di sviluppatori che iniziano a utilizzare Grunt ed esplorano gli strumenti del flusso di lavoro attorno a esso come Yeoman. Gli sviluppatori stanno prestando maggiore attenzione a ciò che possono automatizzare e penso che ciò contribuirà a facilitare più tempo a spendere per costruire app migliori e meno tempo per quei processi manuali tra.
Tornando all'idea dei componenti, penso che tra componenti web e gestione dei pacchetti front-end abbiamo un'enorme opportunità per cambiare radicalmente il modo in cui sviluppiamo per il web. AngularJS (e le direttive Angular) hanno fatto un ottimo lavoro di reintroduzione dell'idea di blocchi riutilizzabili di funzionalità e le cose stanno davvero cercando il lato della gestione dei pacchetti delle cose, attraverso Bower.
Scrivere un'app con gli elenchi che desideri rendere ordinabili? Grande. Alcune battute sulla riga di comando e tu hai capito. Vuoi rendere gli elementi in quell'elenco persistenti quando sei offline? Nessun problema. Qualche altra sequenza di tasti e stai usando un pacchetto che un altro sviluppatore ha dovuto scrivere per ottenere quella capacità. Vuoi trasformare la tua lista in un componente riutilizzabile che chiunque altro può usare? Questo è facile. Questo è il futuro a cui stiamo lavorando.
Siamo fortunati ad avere a disposizione una vasta gamma di strumenti utili sul front end in questi giorni, strumenti che ci fanno risparmiare tempo e che rendono le nostre vite un po 'più semplici. Astrazioni come Sass e CoffeeScript, framework come Twitter Bootstrap, caricatori di moduli come RequireJS, un elenco infinito di MVC e librerie di test di unità ... alcuni direbbero che abbiamo solo l'imbarazzo della scelta ed è interessante vedere quanto tempo ci vuole per ottenere un progetto avviato.
Stai ancora aggiornando manualmente il browser ogni volta che apporti una modifica alla tua app?
Per quanto questi strumenti funzionino eccezionalmente bene da soli, può essere un processo noioso che li aiuta a lavorare insieme, soprattutto se si deve mettere insieme un flusso di lavoro e un processo di compilazione in cui vengono compilati e ottimizzati in modo sintetico. Anche se riesci a ottenere un solido processo di costruzione, spesso ti rimane molto tempo per scrivere il codice di caldaia per la tua applicazione.
Anche allora, devi chiederti quanto bene si adatta al tuo flusso di lavoro quotidiano. Ci sono diversi piccoli passi che ripetiamo ripetutamente durante lo sviluppo, che possono essere trasferiti più facilmente agli utensili. Stai ancora aggiornando manualmente il browser ogni volta che apporti modifiche all'app per vedere in anteprima come appaiono? Stai ancora cercando di capire se stai usando le ultime versioni di tutte le tue dipendenze? Ti chiedi se ci fosse solo qualcosa che ti consenta di continuare a scrivere codice e dimenticare un sacco di lavoro?
Eravamo anche noi, motivo per cui abbiamo iniziato a valutare se potevamo offrire agli sviluppatori una soluzione a molti di questi problemi comuni. Abbiamo provato a risolverli in un progetto open source gratuito che abbiamo recentemente rilasciato chiamato Yeoman. Lo slogan ufficiale di Yeoman è che siamo uno "stack lato client" robusto e supponente, composto da strumenti e framework che possono aiutare gli sviluppatori a creare rapidamente applicazioni Web convincenti "..
In pratica, siamo una serie di strumenti e attività che ti aiutano a ottenere l'automatizzazione di alcuni dei compiti più noiosi nello sviluppo front-end. Siamo composti da yo (lo strumento per impalcature), grunt (lo strumento di costruzione) e bower (per la gestione dei pacchetti).
Se scopri che stai ancora scrivendo il codice boilerplate per la tua applicazione, gestendo manualmente le dipendenze per le tue app o assemblando il tuo sistema di compilazione per lavorare con gli strumenti che ami, potresti trovare Yeoman un bel modo per risparmiarti un po 'di mal di testa.
La community degli sviluppatori di Windows potrebbe davvero aiutarci qui.
Creare uno strumento da riga di comando che funzioni bene su più piattaforme può essere una danza delicata. Una delle sfide iniziali con il supporto di Windows era che gran parte del nostro team era abituato ad usare un sistema * nix e ad avere accesso a homebrew / apt-get. Tuttavia, non eravamo altrettanto esperti nell'usare PowerShell o Chocolatey (l'equivalente basato su PowerShell di Windows in apt-get) e avevamo bisogno di tempo per capire quanto bene queste soluzioni rispetto agli strumenti che avevamo a disposizione altrove.
Ci è voluto del tempo per trovare (o ottenere) tutti i pacchetti richiesti su Chocolately poiché avevamo bisogno di git, fantasmi, optando e molti altri. La situazione è notevolmente migliorata dalla nostra prima versione e Windows è ora ufficialmente supportato da Yeoman usando le istruzioni sulla nostra homepage.
La comunità degli sviluppatori di Windows potrebbe davvero aiutarci qui sostenendo una più ampia adozione di strumenti come Chocolately e aiutandoci a raggiungere la parità con strumenti come apt-get. Oltre a questo sono stati fantastici e abbiamo davvero apprezzato l'aiuto e il supporto che la comunità di sviluppatori di Windows ci ha offerto nel corso della nostra strada verso la compatibilità.
Devo dare una chiamata a Sindre Sorhus, Mickael Daniels e Paul Irish, tutti i quali hanno davvero aiutato a migliorare i nostri sforzi di Windows nei primi giorni.
Al momento, sono scritti molti (fantastici) strumenti di sviluppo che non sono solo * nix, ma specifici per Mac perché renderli multipiattaforma ha i propri costi di sviluppo e spese generali. Mi piacerebbe vedere più discussioni aperte e sviluppo di strumenti che possano funzionare ovunque, ma questo non può essere fatto senza l'aiuto degli utenti.
Se c'è uno strumento che vuoi per Windows che vedi su Mac, per favore sii voce su di esso - ancora meglio, invia una richiesta di pull!
Prova a scoprire cosa ci vorrebbe per portarlo su Windows (e altrove) e chi lo sa? Forse gli sforzi congiunti di più comunità sarebbero sufficienti per far accadere qualcosa.
Rilasciando il mio primo libro, Apprendimento di modelli di progettazione JavaScript (con O'Reilly) è stata probabilmente la realizzazione che mi ha dato la più grande soddisfazione. Era il mio più grande progetto di scrittura, e ho preso la decisione che fosse completamente open source fin dall'inizio - una telefonata di cui non mi pentirò mai. Rendere il materiale educativo disponibile a chiunque, ovunque se lo può permettere, ha il potenziale per una grande quantità di entrambi buoni.
Ha anche il potenziale per aumentare l'impatto del tuo libro, quindi se sei un autore, per favore considera di farlo. Non te ne pentirai!
Accentsconagua