Passare al vero ES6 / ES2015 [chiuso]

0

È eccitante il tempo di avere Babel e di poter usare tutte le belle funzionalità. Mi ha fatto pensare, cosa succede in futuro? Nessuno ne parla davvero. Voglio dire che alcuni browser potrebbero implementare caratteristiche diverse in base alle specifiche, alcune saranno carenti.

Babel ci consente di disattivare selettivamente qualsiasi funzionalità, facendo affidamento sull'implementazione nativa. Cosa significa in realtà? Stiamo per finire con diverse build delle nostre applicazioni per diverse versioni di browser? Ci sarà uno script di "bootstrap" che rileva le funzionalità e poi dice al server quale build vuole?

Suppongo che le applicazioni attualmente scritte probabilmente finiranno per essere eseguite solo su Babel. E i futuri? Non dovremmo pensare a come sovrapporre più facilmente questo divario in uno sviluppo?

    
posta FredyC 12.07.2015 - 10:41
fonte

1 risposta

2

Risposta diretta / TL; DR

...

Il futuro è la compilazione per sempre, la compilazione in più luoghi (ad es. nodo) e la compilazione di sempre più sviluppatori / progetti.

Are we going to end up with different builds of our applications for different versions of browsers?

Ho intenzione di andare con qualunque cosa le grandi aziende a determinare sia la migliore. Hanno un profilo di esperienza maggiore, il tempo di impegnarsi e la più grande partecipazione ad avere siti e app veloci.

È probabile che l'utilizzo di più bundle avviti con qualche strumento o ottimizzazione che non esiste ancora. Puoi farlo oggi con lo user agent sniffing o il metodo che hai suggerito.

Shouldn't we think about how to overlap this gap in a development most easily?

Non vedo la proposta di valore. Alla fine le funzionalità verranno eliminate dai compilatori (generalmente con < 1% di utilizzo). "più facilmente" è ciò che abbiamo ora.

Disattiva selettivamente qualsiasi funzionalità

Quali caratteristiche? Se semplifichiamo queste sono le variabili che dobbiamo considerare.

  • funzioni che usi
  • caratteristiche del motore X supporta
  • compatibilità del motore di destinazione

Questo è già piuttosto complicato.

Ecco un diagramma di come (penso) la maggior parte delle persone pensa che funzioni:

Tuttavia,eccounamigliorerappresentazionediesso.Modoinfondovedraiunasezionebianca,cheha33stranezzeeccezionali.Ridimensionatoda1.440per15.0001:

Immagina un'altra colonna per ciò che il tuo codice utilizza e un'altra per le opzioni di destinazione che utilizzerai. E poi devi dividerlo in polifibri e trasformazioni di sintassi e abilitare / disabilitare ciascuno per soddisfare i tuoi requisiti.

I miei presupposti eterni

  1. desideri utilizzare le funzioni non supportate nei browser di destinazione
  2. la dimensione dei polyfill è trascurabile nel grande schema delle cose

    • inizialmente la versione nativa ha una probabilità del 3% di essere più veloce di polyfill / transform
    • dopo un anno la versione nativa ha una probabilità del 70% di essere più veloce di polyfill / transform
    • la nuova versione del motore ha reso l'output di polyfill / compilatore più veloce rispetto alla versione precedente
  3. i tuoi strumenti possono produrre codice più veloce di quanto non fosse 6 mesi fa, e i plugin specifici per framework rendono ancora più veloce!

  4. questa versione della specifica consente analisi statiche migliori / più facili
  5. molti usano superset di ecmascript senza alcuna intenzione di cambiarlo

  6. le persone ottimizzeranno la micro-ottimizzazione

    • le tue micro-ottimizzazioni sono errate
    • Le micro-ottimizzazioni di
    • tuoi strumenti sono infine corrette e più probabilmente mantenute
    • siamo in grado di eseguire più codice che ignora il parallelismo in parallelo
    • scrivere codice ovvio leggibile è alla fine più veloce di
risposta data 12.07.2015 - 14:51
fonte

Leggi altre domande sui tag