Trudno powiedzieć, ponieważ słowa te nie są dobrze zdefiniowane. Mówiąc ogólnie, myślę, że nazywanie Node.js ramą jest trochę nietypowe, ale trudno byłoby mi się spierać, dlaczego tak nie jest.
Wszystko to staje się trudne i często widzę naprawdę słabe użycie języka, więc będę otwarcie i zaczął od dołu
JavaScript to język komputerowy, to znaczy, wąsko, zestaw konwencji, które pozwalają nam czytać i interpretować kilka tekstów jako semantykę wykonania - wymyślne słowo określające „sposób interpretacji języka jako zestawu instrukcji”. Klasy programów zwanych tłumaczy , kompilatory , transpilers , puch , mazaki itp doprowadzenie wszystko tekstem i próbować coś zrobić z tym konwencjonalnego rozumienia, jak wykonać kod.
- Tłumacze faktycznie wykonują semantykę wykonania, obsługując jakiś komputer - zwykle komputer. Możesz myśleć o nich jak o małym człowieku w twoim komputerze, zmieniającym przełączniki, np. „Drukuj ten znak” na podstawie instrukcji napisanych w twoim programie JavaScript.
- Kompilatory próbują przekonwertować tekst JavaScript na nowy zestaw tekstów, który ma semantykę wykonania dla innego języka - być może taki ze specjalną właściwością, że komputery mogą go bezpośrednio wykonać.
- Transpilery są uogólnioną formą kompilatora, ponieważ pobierają tekst JavaScript i tekst wyjściowy w innym języku. Różnica jest więc nieco subiektywna, ale zwykle myśli się o kompilatorze, który generuje kod o bardzo niskim poziomie, a transpiler jako o kodie wysokiego poziomu .
- Linters , mazaki , typu warcaby , itp wszystko wziąć w tekście JavaScript i wyjściu jakiś rodzaj produktu analitycznego, podświetlony tekst np, który jest pod wpływem semantyki wykonania, ale nie faktycznie przedstawiciel niego.
Teraz zagłębmy się nieco w semantykę wykonania. Ogólnie rzecz biorąc, semantyka wykonania obejmuje proces czytania tekstu języka i dochodzenia do opisu abstrakcyjnej maszyny lub opisu możliwych do zaobserwowania efektów ubocznych . Chciałbym zasugerować, że oba zakładają potrzebę istnienia pewnego rodzaju „niskopoziomowego API” albo do obsługi maszyny, albo do wykonania obserwowalnych efektów. Zazwyczaj są one uważane za część środowiska wykonawczego
- Środowisko wykonawcze lub środowisko wykonawcze to zestaw założonych prymitywów, które konwencja językowa musi istnieć, aby działać. Jeśli chodzi o język, mogą istnieć pewne założenia dotyczące ich zachowania, ale są one nie do zaobserwowania. Na zdjęciach powyższego tłumacza „człowiek w środku” po prostu porusza przełącznikami środowiska uruchomieniowego - nie może osobiście sprawdzić, co robią.
Słowo „ środowisko wykonawcze” jest zwykle nadużywane, aby oznaczać zarówno sam zestaw założonych prymitywów, jak i ich rzeczywistą instancję.
Więc teraz dochodzimy do czegoś włochatego. Język jest zbiorem konwencji, które zakładają istnienie środowiska wykonawczego w celu nadania znaczenia jego semantyce wykonania. Nigdy ich nie „sonduje”, ponieważ są poza zasięgiem.
Aby faktycznie używać języka, potrzebujesz implementacji kompilatora lub tłumacza obok implementacji środowiska wykonawczego. Kompilator / interpreter i środowisko wykonawcze idą w parze z faktycznym wykonaniem kodu.
- Chrome V8 , często nazywany silnikiem , jest pakietem zawierającym interpreter, kompilator, implementację środowiska wykonawczego zgodną z interfejsem środowiska wykonawczego wymaganym przez standardowe konwencje JavaScript ECMA.
Więc gdzie pasuje do tego Node.js?
Musimy to rozbić na części:
- Node.js rozszerza język JavaScript , zapewniając większy zestaw prymitywów środowiska wykonawczego - tych, które są poza zakresem standardów ECMA. Należą do nich takie rzeczy jak plik I / O . Oznacza to, że Node.js zmienia język i jest w pewnym sensie nowym językiem: „Node.js JavaScript”
- Node.js jako pakiet zawiera interpreter i kompilator. Po prostu kradnie je z V8.
- Node.js zapewnia implementację środowiska wykonawczego Node.js, które umożliwia wykonanie „Node.js JavaScript”.
- Node.js zapewnia zestaw standardowych bibliotek zbudowanych na nowych prymitywach, które czynią je bardziej dostępnymi dla użytkowników końcowych „Node.js JavaScript”.
Node.js to wiele rzeczy!
Ale czy to ramy?
W tym miejscu terminologia całkowicie się rozpada - nikt nie ma dobrej, spójnej i znaczącej definicji tego, czym właściwie jest struktura.
Toczą się debaty: „czym jest framework kontra biblioteka” i kończą się na niezadowalających rzeczach, takich jak „biblioteka to coś, co nazywasz, a framework to coś, co nazywa cię”. Nie chcę nawet tak smutnego wyjaśnienia ujrzeć światła dziennego - ale JavaScript, aw szczególności JavaScript Node.js, jest ogromnym ciosem dla tej definicji, ponieważ cała technika przekazywania zwrotnego oznacza, że ciągle przełączasz się między dzwonieniem i wezwanie.
Moim osobistym zdaniem jest tu coś istotnego. Nie chcę narysować jasnej linii, ale powiem tylko
- Zestaw kodu jest podobny do biblioteki, jeśli działa jak zestaw legos : podzielny i stworzony do złożenia. Chociaż może istnieć kilka przykładów korzystania z biblioteki, to na ogół to użytkownik sam zestawia ją zgodnie z własnymi potrzebami.
- Zestaw kodu jest podobny do frameworka, jeśli jest niepodzielny i implikuje konwencje *: dzielenie go na części może spowodować niepowodzenia wielu założeń, dlatego musisz zrozumieć konwencjonalne użycie , aby właściwie używać frameworka.
Jest to linia zręcznie falująca, ale chcę wyciągnąć naprawdę interesujący punkt na temat ram:
Ramy sugerują zestaw konwencji interpretacji kodu; są zatem językiem samym w sobie.
To może być coś, o co ludzie również chcą się kłócić, ale jeśli kupiłeś moją wcześniejszą definicję, że język jest tylko zbiorem konwencji, które dają życie blokowi tekstu, wtedy ilekroć ustanawiasz nową warstwę konwencji, „ zbudowałem nowy język. Być może w ramach szkieletowych surowce są semantycznymi interpretacjami języka macierzystego zamiast surowych plików tekstowych, ale idea jest taka sama!
Tak więc, po tym wszystkim, jestem szczęśliwy, że mogę nazwać Node.js ramą, nawet jeśli jest to trochę niezgodne z normą! Node.js dodaje funkcjonalność do surowego JavaScript poprzez rozszerzenie języka . Dzięki niemu pojawiają się nowe założenia i narzędzia do pracy w tym rozszerzonym języku. Funkcjonalnie te pomysły są takie same jak pomysły innych dobrze przyjętych platform, takich jak Ruby on Rails .
Twierdziłbym, że jeśli w tej chwili czujesz się trochę oszołomiony i chcesz argumentować, że istnieje duży podział między Ruby on Rails i Node.js w ten sposób , to oczywiście jestem z tobą . Rodzaje pojęciowych światów, w których żyją, są drastycznie różne - chcę tylko powiedzieć, że są to te same rzeczy: zestawy konwencji dotyczących rozszerzania mocy języka podstawowego w określonej dziedzinie.
Z przyjemnością sugeruję również, że domena Node.js jest niewielka i wąska, a zatem konwencje, które dodaje, są proste do uzasadnienia i stosunkowo łatwe do poprawienia. OTOH, Ruby on Rails żyje w złożonej, źle zdefiniowanej domenie „biznesowych aplikacji internetowych”, co oznacza, że konwencje, które ustanawia, są z pewnością rozmyte i złamane.
Ale to wszystko długa droga do powiedzenia: tak, rekruterzy prawdopodobnie nie mają pojęcia, co mają na myśli, mówiąc to. Domyślam się, że „framework” to po prostu lepsze, bardziej zrozumiałe słowo niż „środowisko uruchomieniowe” lub „silnik”.