Come dovrei valutare le nuove lingue del browser?

2

In questi giorni ci sono molti progetti il cui obiettivo è quello di portare nuove lingue nel browser compilandole in JavaScript. Tra gli altri si possono citare ClojureScript, CoffeScript, Dart, haXe, Emscripten, Amber Smalltalk.

Mi piacerebbe provare alcuni di questi, ma non sono sicuro di cosa dovrei cercare quando valuti questi linguaggi per vedere se sono adatti alla produzione.

Come dovrei valutare una nuova lingua del browser e quali sono le insidie che dovrei cercare?

    
posta Andrea 21.03.2012 - 10:29
fonte

4 risposte

5

Questo elenco potrebbe essere utilizzato per valutare una lingua, una tecnologia o un processo.

  • Questo linguaggio offre alcuni vantaggi rispetto a quello che attualmente utilizzo e di cui ti fido?
  • Chi altro sta utilizzando la tecnologia in produzione e come appare da un punto di vista degli utenti?
  • Che tipo di supporto comunitario ha questo progetto? Più persone usano e lavorano con qualcosa di nuovo, maggiori sono le possibilità di sistemare le cose e di aggiungere nuove funzionalità.
  • Che tipo di curva di apprendimento ha questa lingua per la tua squadra? Più difficile è raccogliere i maggiori ritorni di funzionalità, velocità, leggibilità o manutenibilità.
  • Questo ha senso per il progetto che stai tentando di completare? Una grande tecnologia con pochi piccoli vantaggi potrebbe non valerne la pena.
  • Infine, dai un'occhiata. Guarda come funziona su un piccolo campione per vedere come funziona davvero per te e quali problemi devi risolvere.

Cose specifiche da cercare con le lingue che compilano in JavaScript:

  • La velocità è un grosso problema con JavaScript, quindi testare la nuova lingua su un'attività vs il JavaScript che scrivi ti sarà molto utile. Potresti scoprire che la lingua scrive codice in esecuzione più veloce di te.
  • Quanto è facile eseguire il debug rispetto all'utilizzo di JavaScript strait? Può essere un problema se il codice JavaScript generato è difficile da comprendere quando le cose vanno male.
  • Verifica il sovraccarico dell'utilizzo delle librerie incluse, se tutto è locale può essere ingannevole sulla quantità di codice che viene trasferita al client ad ogni caricamento della pagina.
risposta data 21.03.2012 - 16:50
fonte
2

Lista di controllo:

Potenziali preoccupazioni negative:

  • Come gestisce una webapp moderatamente complessa in tutti i browser che in genere supportano.
  • Con quale frequenza vengono corretti i bug?
  • Come sono le opzioni di debug del compilatore?
  • Che cosa succede quando vuoi integrarti con il codice JS di altri sviluppatori?
  • Che cosa succede quando vuoi spiegare il tuo codice agli sviluppatori JS che devono lavorare con i tuoi?
  • Cosa succede se la comunità dietro di esso si allontana e JS alla fine si evolve oltre causando la rottura quando il down-compilatore JS continua a sputare codice che non è più legale.
  • Quale vantaggio è per la tua carriera di sviluppatore se non ottiene mai popolarità e hai seccato anni di esperienza professionale in un linguaggio di moda prodotto da persone a cui semplicemente non piace qualcosa che non funziona come le lingue che hanno conosci meglio?

Preoccupanti preoccupazioni per la vittoria:

  • Ti aiuta a produrre più velocemente?
  • È una gioia assoluta lavorare con?
  • Semplifica il lavoro con il DOM rispetto al JS nativo (una specie di API goffo)
  • È più facile per lo sporco a buon mercato, ma per lo meno inutili sviluppatori di sweatshop che riescono a malapena a capire il Java che fingono di sapere produrre codice di front-end valido? (suggerimento: no, non lo è)

Ovviamente ho un po 'di inclinazione qui, ma non ho alcun problema con altre lingue che diventano popolari sul front end. Ma non abbreviato in JS. Questo è solo in qualche modo offensivo per me come sviluppatore JS. Se JS fa ciò che ti serve, piega la piega e la mutila in qualcosa che funzioni meglio per il tuo processo di pensiero. È flessibile come quello. La sintassi principale non può essere modificata, ma puoi ridefinire il modo in cui risolvi i problemi con facilità molto facilmente una volta che la conosci abbastanza bene.

    
risposta data 23.03.2012 - 01:05
fonte
1

Devi ignorare queste nuove lingue a meno che non abbiano una VM / interprete nativa in almeno due browser. Al momento solo JavaScript è conforme a tali criteri.

  • Se una lingua non ha una VM / interprete nativa è inefficiente. Se stai scrivendo un'applicazione non giocattolo, ti preoccuperai di essere in grado di ottimizzare le prestazioni di parti pesanti della tua applicazione. Dover usare il linguaggio astratto e JS ottimizzato a mano è un incubo di manutenzione
  • Se una lingua non è supportata in modo nativo nei browser, non è una prova futura, è una fase che sparirà presto, (VBScript chiunque?)
  • Tutte queste astrazioni perdono. Dovresti scrivere o eseguire il debug di JavaScript alla fine e non vorrei fare entrambe le cose quando posso fare solo JavaScript.

Se sei disposto a mantenere sia JavaScript che la lingua astratta nella tua applicazione, potresti prendere in considerazione l'idea di usarli

    
risposta data 21.03.2012 - 16:19
fonte
0

Trovo che giocare con una nuova tecnologia sarà sempre il modo migliore per conoscerlo.

Una volta acquisite le nozioni di base, spesso inizi a provare le funzionalità o gli scenari più avanzati (ad esempio l'utilizzo dello strumento in alcune app Web complesse).

Questi sono quando puoi iniziare a trovare i limiti di uno strumento.

Quando ciò accade, inizio a cercare SO, forum ecc., per cercare di trovare modi per risolvere i problemi. In questi luoghi probabilmente inizierai a leggere le opinioni di altre persone e i problemi che hanno riscontrato e ti aiuta a ottenere un "feeling" migliore per lo strumento.

Un modo più formale potrebbe essere quello di provare a confrontare lo strumento con altre soluzioni. Esegue "bene". (dove "bene" deve essere definito dalle esigenze del tuo sistema).

    
risposta data 21.03.2012 - 15:30
fonte

Leggi altre domande sui tag