Un sacco di persone hanno commentato come Fibers (che fornisce codice sincrono in Node.js) rompa la compatibilità con il 99% dei pacchetti npm. Sono più interessato alle implicazioni sulle prestazioni.Implicazioni sul rendimento del rendering lato client e Fibre in Meteor
Questo annulla "Node.js è molto veloce, guarda, è asincrono/basato su eventi!" discussione? Qual è l'implicazione pratica del team di Meteor che cuoce in Fibre?
Inoltre, dopo aver distribuito un'enorme riscrittura in cui le pagine sono state visualizzate sul lato client, Twitter reversed their decision in favore di servire HTML dal server per migliorare i tempi di caricamento della pagina. Cosa significa questo per i potenziali limiti di prestazioni di Meteor (specialmente sul carico della prima pagina)?
'Un sacco di' e '99%' sono parole di donnola ... –
Scusa, Tom. Per quanto riguarda un sacco di cose, è stata una lamentela che ho ignorato, ma c'è sicuramente un precedente per questo. Come punto di partenza, vedi [argomento di un concorrente] (http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-meteor/) contro Fibers. E secondo una rapida ricerca su http://search.npmjs.org/, 13 pacchetti 11320 supportano (menzionano) le Fibre. Quindi il 99,9885% dei pacchetti npm probabilmente (parola donnola ?!) sarebbe incompatibile. – redtree
Non sono molto interessato a Fibers oltre a aver seguito il supporto di Windows (per ottenere Meteor in esecuzione su Windows), ma le fibre non consentono semplicemente di effettuare una chiamata a tali moduli e creare il blocco di chiamata? Come in ... È possibile inserire 'Fiber.yield();' nel callback e quindi racchiudere la chiamata in un 'Fibra (...). Run()'. Perché penso che il punto sia che i pacchetti non devono essere resi compatibili in quanto non è possibile che siano incompatibili (a parte il fatto che * lo utilizzino *). –