Node.js는 프레임 워크입니까? [닫은]


35

채용 담당자, 개발자 등이 Node.js를 프레임 워크라고합니다. 내 생각에 이것은 Node.js가 실제로 무엇인지에 대해 무지하지 않습니다.

종종 작업 설명에서 Node.js는 AngularJS , React 등 의 라이브러리로 그룹화됩니다 . 일반적으로 차이를 모르는 사람 (HR, 모집 자 등)이 입력 한 것으로 간주합니다.

제 생각에는 Node.js는 플랫폼 또는 런타임 환경입니다. 파일 시스템 (브라우저가 아닌 서버로 실행되기 때문에)과 같은 다양한 다른 API에 대한 DOM API (브라우저의 JavaScript)를 전환합니다.

사람들이 Node.js가 프레임 워크라고 생각하는 이유는 무엇입니까? 내가 잘못? 실제로 프레임 워크입니까?



5
특히, 그러나 나는 혼란을 볼 수 있었다.
ndugger

1
오래 전에 노드가 처음 나왔을 때 노드에 프레임 워크가 아니라고 대답했습니다. 그 대답은 당시 극도로 하향 조정되었습니다. 오늘날 노드를 사용하는 사람은 거의 프레임 워크라고 생각하지 않습니다. Swift가 프레임 워크이거나 Go가 프레임 워크이거나 Rust가 프레임 워크 인 것과 같은 의미에서 프레임 워크입니다. 현대의 프로그래밍 언어에는 단순히 프레임 워크로 구현되었던 매우 높은 수준의 API가 있습니다. "플랫폼"은 좋은 단어입니다. 나는 (그 단어의 의미 전통적인 유닉스를 사용)가 자신 통역 말하고 싶지만
slebetman

노드는 DOM API를 전환하지 않으며 노드를 사용하거나 사용하지 않고 Javascript로 실행할 수있는 모든 항목을 계속 사용할 수 있습니다.
Rob

@slebetman 통역사의 "다른"의미는 무엇입니까? 나는 거기에도 토론이 있다는 것을 몰랐다! : S
J. Abrahamson

답변:


44

이 단어들이 잘 정의되어 있지 않기 때문에 말하기가 약간 어렵습니다. 일반적으로 Node.js를 프레임 워크라고 부르는 것은 비정형 적이라고 생각하지만 정확히 왜 그렇지 않은지에 대해 논쟁하는 데 어려움을 겪을 것입니다.

이 모든 것은 어리석은 일이며, 나는 종종 언어의 사용이 열악하다는 것을 종종 알기 때문에 명시 적이며 바닥에서부터 시작할 것입니다


JavaScript는 컴퓨터 언어입니다. 즉, 좁은 의미에서, 우리는 실행 의미 를 갖는 것으로 많은 텍스트를 읽고 해석 할 수있게하는 규칙입니다 . 인터프리터 , 컴파일러 , 트랜스 필러 , 린터 , 형광펜 등 의 프로그램 클래스는 모두 텍스트를 가져 와서 코드를 실행하는 방법에 대한 일반적인 이해로 무언가를 시도합니다.

  • 통역사는 실제로 일부 컴퓨터 (일반적으로 컴퓨터)를 작동하여 실행 의미론을 수행 합니다. 당신은 그것들을 당신의 자바 스크립트 프로그램에 쓰여진 지시에 기초하여 "이 문자 인쇄"와 같은 스위치를 뒤집는 컴퓨터 내부의 작은 사람으로 생각할 수 있습니다.
  • 컴파일러 는 JavaScript 텍스트를 다른 언어 (아마 컴퓨터가 직접 실행할 수있는 특수 속성이있는 언어)에 대한 실행 의미가있는 새로운 텍스트 세트로 변환하려고합니다.
  • 트랜스 파일러는 JavaScript 텍스트를 가져 와서 다른 언어의 텍스트를 출력한다는 점에서 일반화 된 컴파일러 형식입니다. 따라서 차이는 약간 주관적이지만 일반적으로 컴파일러는 매우 낮은 수준의 코드 를 출력하는 것으로 컴파일러를 생각 하고 높은 수준의 코드 를 출력하는 변환기를 생각 합니다.
  • 린터 , 형광펜 , 타입 검사기 , 의 실행 의미에 영향을하지만 실제로 대표되지 않는 자바 스크립트의 텍스트 출력 분석 제품의 어떤 종류의 모든 테이크 강조 텍스트 예.

이제 실행 의미론을 조금 파헤쳐 봅시다. 일반적으로 실행 의미론은 언어 텍스트를 읽고 추상 기계관찰 가능한 부작용에 대한 설명에 도달하는 프로세스를 포함합니다 . 내가 제안하고 싶은 것은 두 가지 모두 기계를 작동하거나 관찰 가능한 효과를 수행하기 위해 일종의 "낮은 수준의 API"가 필요하다고 가정한다는 것입니다. 이들은 일반적으로 런타임 환경의 일부로 간주됩니다

  • 런타임 환경 또는 런타임은 언어 규칙이 작동하기 위해 존재하는 데 필요한 가정 프리미티브의 집합입니다. 언어가 진행되는 한, 그들의 행동에 대한 몇 가지 가정이있을 수 있지만 관찰 할 수는 없습니다. 위의 인터프리터 이미지에서 "man inside"는 런타임 스위치를 가볍게칩니다. 자신이하는 일을 개인적으로 조사 할 수는 없습니다.

런타임 이라는 단어 는 일반적으로 가정 된 프리미티브 세트 자체 실제 인스턴스화 를 의미하기 위해 남용됩니다 .


자, 이제 털이 나옵니다. 언어는 실행 시맨틱에 의미를 제공하기 위해 런타임이 존재한다고 가정하는 규칙 세트입니다. 그들이 범위를 벗어 났기 때문에 결코 그들에게 조사되지는 않는다.

실제로 언어를 사용하려면 런타임 구현과 함께 컴파일러 또는 인터프리터와 같은 것을 원합니다. 컴파일러 / 통역사와이 런타임은 실제로 코드를 실행하는 데 도움 이됩니다 .

  • 엔진 이라고도하는 Chrome의 V8 은 ECMA 표준 자바 스크립트 규칙에서 요구하는 런타임 인터페이스와 호환되는 인터프리터, 컴파일러, 런타임 구현을 포함하는 패키지 거래입니다.

그렇다면 Node.js는 어디에 적합합니까?

우리는 그것을 부분으로 나누어야합니다.

  1. Node.js 는 ECMA 표준 범위를 벗어난 더 큰 런타임 환경 기본 세트를 제공 하여 JavaScript 언어확장합니다 . 여기에는 파일 I / O 와 같은 것들이 포함됩니다 . 이는 Node.js 가 언어를 변경하고 어떤 의미에서 "Node.js JavaScript"라는 새로운 언어임을 의미합니다.
  2. 패키지로서 Node.js는 인터프리터와 컴파일러를 포함합니다. V8에서 이것들을 훔칩니다.
  3. Node.js는 "Node.js JavaScript"를 실행할 수 있는 Node.js 런타임 환경구현을 제공합니다 .
  4. Node.js는 새로운 기본 요소 위에 구축 된 표준 라이브러리 세트를 제공하여 "Node.js JavaScript"의 최종 사용자가 더 쉽게 액세스 할 수 있도록합니다.

따라서 Node.js는 많은 것들입니다!

그러나 프레임 워크입니까?


이것은 용어가 완전히 분리되는 곳입니다. 프레임 워크가 실제로 무엇인지에 대한 우수하고 일관된 의미있는 정의는 없습니다.

"프레임 워크와 라이브러리 란 무엇인가"라는 분노가 있으며, "라이브러리는 호출하는 것, 프레임 워크는 호출하는 것"과 같은 불만족스러운 것에서 끝납니다. 콜백 전달 기술 전체 가 호출 간을 끊임없이 전환 한다는 의미이므로 JavaScript와 특히 Node.js JavaScript는 이러한 슬픈 설명을 밝히고 싶지 않습니다. 그리고 부름 받고 있습니다.

제 개인적으로는 여기에 상당한 것이 있습니다. 나는 밝은 선을 그리고 싶지 않지만 그냥 말할 것입니다.

  • 코드 세트가 레고 세트처럼 작동하면 라이브러리와 비슷합니다 . 라이브러리를 사용하는 방법에 대한 몇 가지 예가있을 수 있지만 일반적으로 사용자는 자신의 요구에 맞게 라이브러리를 조립해야합니다.
  • 코드 세트는 나눌 수없고 규칙을 암시하는 경우 프레임 워크와 유사합니다. 코드 조각을 분리하면 많은 가정이 실패 할 수 있으므로 프레임 워크를 올바르게 사용하려면 일반적인 사용법 을 이해해야 합니다.

이것은 확실히 손에 얽매이지 않는 선이지만 프레임 워크에 대한 흥미로운 점을 그려보고 싶습니다.

프레임 워크는 코드를 해석하는 방법에 대한 일련의 규칙을 암시합니다. 그러므로 그들은 그들 자신의 언어입니다.

이것은 사람들이 논쟁하고 싶은 것이 될 수도 있지만, 이전의 정의를 구입했다면 언어가 텍스트 블록에 생명을 부여하는 일련의 규칙 일뿐이라면 새로운 규칙을 적용 할 때마다 새로운 언어를 만들었습니다. 아마도 프레임 워크에서 원재료는 원문 파일 대신 호스트 언어 의 의미 론적 해석 이지만 아이디어는 동일합니다!


따라서 모든 말로 Node.js가 표준에 약간의 영향을 주더라도 프레임 워크라고 부르는 것은 매우 기쁩니다! Node.js는 언어확장하는 방식으로 원시 JavaScript에 기능을 추가합니다 . 확장 된 언어로 작업하기위한 새로운 가정과 도구를 제공합니다. 기능적으로 이러한 아이디어는 Ruby on Rails 와 같이 널리 채택 된 다른 프레임 워크의 아이디어와 동일합니다 .

나는이 순간에 약간의 불편 함을 느끼고 이런 방식으로 Ruby on Rails와 Node.js 사이에 큰 격차가 있다고 주장하고 싶다면 당연히 당신과 함께 하고 있다고 주장합니다 . 두 사람이 살고있는 개념적 세계의 종류는 극적으로 다릅니다. 나는 단지 그들이 같은 종류라고 말하고 싶습니다. 특정 영역 내에서 기본 언어의 힘을 확장하기위한 규칙 세트입니다.

또한 Node.js의 도메인이 작고 타이트하므로 추가하는 규칙은 추론하기 쉽고 상대적으로 수정하기 쉽다는 것을 제안합니다. OTOH, Ruby on Rails는 잘 정의되지 않은 복잡하고 정의 된 "비즈니스 웹 애플리케이션"도메인에 살고 있습니다. 즉, 규칙이 명확하지 않고 부러져 있습니다.


그러나이 모든 것이 먼 길을 말하는 것입니다. 예, 신병 모집 자들은 그렇게 말할 때 그들이 무엇을 의미하는지 전혀 모릅니다. "프레임 워크"는 "런타임"또는 "엔진"보다 더 좋고 더 멍청한 단어처럼 들린다 고 생각합니다.


이봐, 놀랍게도 균형! 따라서 probably have no idea: '프레임 워크'는 실제로 차이를 만들 때 절약 할 수있는 유용한 기능인 프로그래머 없이도 이해할 수있는 단어입니다.
n611x007

"Node.js는 언어를 확장하는 방식으로 원시 JavaScript에 기능을 추가합니다." 사실이 아니라 언어가 아닌 기능을 확장하고 있으며 많은 프레임 워크에서 요구하는 코드 작성 방법을 변경하지 않습니다. 포함 된 라이브러리가 추가 할 수있는 것처럼 추가 된 다른 기능이나 객체가 있습니다. 호출하거나 새로운 함수 나 객체처럼 사용할 수 있습니다. 프로그래밍 스타일은 변하지 않으며 언어 기본은 동일하며 일부 기능 만 추가됩니다. 따라서 기본 플랫폼 라이브러리가 추가되어 기능이 추가 된 자바 스크립트 인 프레임 워크 나 언어가 아닙니다.
코드 비트

물론, 나는 당신의 측면을 완전히 따라갈 수 있습니다. 나는 여기의 선이 흐릿하다고 생각한다. 어느 쪽의 사고 방식이든 의미가 있습니다. 엄밀히 말하면 노드는 FFI를 제공하여 JS를 확장합니다. 이는 FFI를 제공하여 노드가 나중에 더 많은 시스템 라이브러리를 제공 할 수있게하는 핵심 요소입니다. 반면 "핵심"노드는 단지 런타임 (그리고이 FFI)이지만 사람들이 노드를 논의 할 때 대부분 "실시간 런타임, FFI 확장 및 그 위에 구축 된 기본 라이브러리 기능"을 의미합니다. 노드가 패키지되는 방식입니다.
J. Abrahamson

20

Node.js®는 Chrome의 V8 JavaScript 엔진을 기반으로 구축 된 JavaScript 런타임 입니다.

출처

노드는 런타임 또는 환경입니다. 프레임 워크가 아닙니다. Express와 같은 프레임 워크가 노드와 함께 어디에나 있기 때문에 사람들 (제 생각에)은 종종 잘못 생각합니다.

관심이 있다면 런타임 대 프레임 워크에 대한 더 많은 독서 .


inb4 "하지만 약 페이지에 '비동기 이벤트 중심 프레임 워크"라고 나와 있습니다.
rlemon

3
임베디드 v8이 런타임이 아닙니까? ;-)
johannes

@johannes 나는 이것에 당신과 동의하는 경향이 있습니다. V8은 런타임이며 노드는 단순히 개발자가 사용할 수있는 도구 (http 서버, util 등)를 확장하므로 프레임 워크 레이블이 여전히 작동한다고 생각합니다. 여전히 수정 된 v8 환경입니다. 노드는 프로젝트에 "포함"하는 것이 아닙니다. 그것은 내가 생각하는 모든 관점의 문제입니다.
Nick

@rlemon, 부품 프레임 워크 가 제거되었습니다.
ebram khalil
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.