5
Wiele osób skomentowało, w jaki sposób Fibers (które daje kod synchroniczny w Node.js) łamie kompatybilność z 99% pakietów npm. Jestem bardziej zainteresowany konsekwencjami wydajności.Implikacje wydajności renderowania po stronie klienta i włókien w Meteoru
Czy to cofa "Node.js jest naprawdę szybkie, spójrz, to jest asynchroniczne/oparte na zdarzeniach!" argument? Jaka jest praktyczna implikacja pieczenia zespołu Meteor w włóknach?
Ponadto, po wdrożeniu ogromnego przepisu, w którym strony były renderowane po stronie klienta, Twitter reversed their decision na rzecz obsługi HTML z serwera, aby poprawić czas ładowania strony. Co to oznacza dla potencjalnych ograniczeń wydajności Meteor (szczególnie przy ładowaniu pierwszej strony)?
"Wiele" i "99%" to słowa łasicy ... –
Przepraszam, Tom. Jeśli chodzi o "wiele", to była to skarga, którą zlekceważyłem, ale na pewno istnieje precedens. Jako punkt wyjścia patrz [argument zawodnika] (http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-meteor/) przeciwko Fibers. I według szybkiego wyszukiwania na http://search.npmjs.org/, 13 z 11320 pakietów obsługuje (wspominając) Fibers. Tak więc 99,99885% pakietów npm prawdopodobnie (słowo łasce ?!) byłoby niezgodne. – redtree
Naprawdę nie jestem w Fibre poza tym, że śledziłem jego obsługę Windowsa (aby Meteor działał w systemie Windows), ale czy Fibres nie pozwala ci tylko zawinąć połączenia do takich modułów i wykonać blok połączenia? Podobnie jak w ... Można umieścić 'Fibre.yield();' w wywołaniu zwrotnym, a następnie owijać wywołanie w 'Fibre (...). Run()'. Ponieważ myślę, że chodzi o to, że pakiety nie muszą być kompatybilne, ponieważ nie ma możliwości, aby były niezgodne (inne niż czy * używają * go). –