JavaScript - 축복인가 저주인가?

모든 사람은 인생에서 적어도 한 번은 JavaScript로 코딩합니다. 우리는 그것을 좋아한다고 말하는 사람도 있고 그렇지 않다고 말하는 사람도 있습니다. JS 생태계에 대해 좋든 나쁘든 감정이 동떨어진 사람들에게 보내는 작은 “편지”가 될 것입니다.

시작하기 전에 Javascript의 역사를 이해해야 합니다. 자바스크립트는 언어가 아니라 생태계입니다. Java 또는 C는 Javascript가 아닌 언어입니다. ECMAScript는 언어의 실제 이름입니다. 우리가 자바스크립트를 비난하는 것은 실제로 생태계를 비난하는 것입니다.

자바스크립트의 역사

프로그래밍은 많은 것입니다. 프로그래밍을 큰 영역으로 생각한다면 웹이 가장 큰 부분을 차지합니다.

프로그래밍에 관해 이야기하면 80%가 웹 관련 기술입니다. 이것이 바로 1995년 Javascript가 1997년 IE4에서 지원되는 웹 언어로 순수하게 시작된 이유입니다. 따라서 이해를 위해서는 Javascript가 서버에서 사용하도록 의도된 것이 아니라는 점을 알아야 합니다. 실제로 Javascript를 지원하는 최초의 브라우저인 Netscape는 Mocha를 Javascript 엔진으로 사용했지만 V8까지의 모든 것은 충분하지 않았습니다.

요구가 커지면서 Javascript를 더 강력하고 빠르게 만들기 위한 첫 번째 시도가 시작되었지만 Google 팀은 기적을 일으켰고 실제로 클라이언트뿐만 아니라 Ryan Dahl의 V8 및 Node.js 도입으로 Javascript를 충분히 빠르게 만들었습니다. 서버에서도 사용할 수 있습니다.

C나 Java와 같은 다른 언어는 기계 수준에서 사용되며 낮은 수준의 프로그램을 생성하도록 고안되었습니다. 서버의 기적적인 Javascript가 무엇인지 이해하려면 Java를 클라이언트에 배치한다고 상상해 보십시오. 언어의 의도는 DOM 및 웹 API와 상호작용하는 데 사용되는 것이 아니므로 많은 속임수가 필요합니다.

ECMAScript 1은 웹 브라우저용 언어였으며 웹 브라우저에서만 실행되도록 만들어졌습니다. 그렇다면 성능에 대해 언어를 비난한다면 언어가 아니라 언어 뒤에 있는 엔진이라는 것을 알아야 합니다

자바스크립트가 성장하기 시작했습니다

거의 10년이 지난 2009년에 ECMAScript의 필요성이 증가하면서 마침내 ES5가 등장했습니다. 여기서 빅 붐이 일어났습니다. 실제로 ECMAScript 언어는 단순한 프런트엔드 애플리케이션보다 더 많은 용도로 사용할 수 있었습니다. 불과 몇 년 후, express.js가 도입되면서 React와 기타 프레임워크가 프론트엔드뿐만 아니라 백엔드에서도 등장하기 시작했습니다

Javascript는 프론트엔드가 백엔드 개발처럼 엄격하고 빡빡하지 않고, React 클라이언트 측 붐의 예술적 요구와 이전에는 규칙과 제한이 많지 않은 상당히 느슨한 생태계를 만들었기 때문에 자유로워야 했습니다.

10년 넘게 서버에 다른 언어가 있었다면 Javascript가 진출하고 싶은데, 구문이 단순해서 언어를 사용하기 쉽고, 프론트엔드와 백엔드 개발에 동일한 프로그래밍 언어를 사용하는 것이 편리합니다. .

하나의 코드베이스

내가 이야기하고 싶은 것은 이것이다. Shopify가 공식적으로 플랫폼을 출시하기 전인 2009년 이전에는 백엔드 서비스와 상호 작용이 많지 않았습니다. Javascript의 나쁜 특성은 당시 웹에 충분했고 당시 존재했던 소수의 대형 웹 플랫폼에서는 PHP를 백엔드로 사용하고 Facebook과 같은 프런트엔드를 사용했으며 더 많은 요구 사항이 있으면 Java를 백엔드로 사용했습니다. API와의 상호작용이 좋지 않아 변경이 필요했습니다.

Node.js는 개발자가 원하는 작업을 수행하여 웹을 개발을 위한 원활한 환경으로 만들고 동일한 기능 세트에 대해 다른 언어를 사용할 필요가 없도록 도와주었습니다. 처음에는 Nodejs의 성능이 나빴고, 확장도 어려웠으며 뭔가 조치가 필요했습니다.

자바스크립트에는 해결해야 할 문제가 많았습니다. 가장 먼저 해결해야 할 문제는 성능이었고 nodejs도 성능을 향상시켰습니다.

모든 것에 대한 단일 코드베이스는 가능했지만 업계 표준을 충족할 만큼의 확장성은 없었습니다. 유형 안전성은 필수였으며 Facebook이 Hack을 만들었고 Microsoft는 Typescript를 도입했습니다.

현대의 문제

Javascript는 성능 문제를 해결했습니다. Go나 Rust만큼 빠르지는 않을 수도 있지만 반드시 그럴 필요는 없습니다. 웹 표준을 위한 엄청난 성능은 필요하지 않으며, 그렇다면 Go 또는 Rust에서 서비스 하나만 생성하면 됩니다. 우리가 알고 있는 인터넷의 핵심은 PHP와 Ruby를 사용한다는 것입니다. Javascript보다 속도가 훨씬 느리고 리소스 집약적입니다.

Javascript는 유형 안전성 문제를 해결하여 대규모 프로젝트에서 사용할 수 있지만 마지막 문제는 며칠 전까지만 해도 Javascript를 찾아 큰 돌파구를 마련했습니다.

Javascript는 언어가 아니라 생태계이기 때문에 새로운 기능과 도구는 언어가 아닌 언어를 중심으로 구축됩니다. 백엔드에 3개의 엔드포인트가 있는 작은 SPA 애플리케이션을 실행하려면 20개의 구성 파일이 필요합니다. 우리에게 필요한 변화는 모든 것을 하나로 묶는 것입니다.

ECMAScript, Types, Linting, 보안 및 서식을 단일 번들에 담으세요. 왜냐하면 지금은 의존성 지옥에 빠져 있을 뿐만 아니라 작업 방법에 대한 단일 표준이 없기 때문에 코딩도 어렵기 때문입니다. Java, Ruby, Go, Rust 또는 Perl과 같은 다른 언어에는 언어 장벽 안에 모든 것이 있습니다.

자바스크립트의 미래

Ryan Dahl은 Deno를 소개했습니다. Deno는 모든 것을 하나로 묶는 작업을 시작했습니다. 매우 유망합니다.

지금의 Typescript는 그 성능, 라이브러리의 양, 언어를 중심으로 존재하는 SDK, 그리고 Deno의 약속을 포함해 전체 웹 산업을 장악할 것입니다.

명령과 함께 이러한 모든 파일이 단일 Javascript 엔진 내에 번들로 포함되어 있는 세상을 상상해 보세요.

• eslintrc.json

• tsconfig.json

• vite.config.js

• package.json

• postcss.config.js

• .prettierrc

• ecosystem.config.js

• .허스키

제 이해가 부족하기 때문에 Javascript는 불과 3~4년만 지나면 웹에서 당연한 선택이 될 것입니다. 마이크로서비스, 마이크로프론트엔드, 모놀리식을 구축하고 초당 5,000개 요청으로 확장하거나 간단한 SPA Javascript를 생성하려는 경우 이것이 유일한 솔루션이 될 것입니다.

Javascript에 시간을 주면 PHP, Ruby 또는 Go와 같은 웹용 대안이 뒤로 물러날 것입니다. 지금은 모두가 Javascript에 대해 타당한 주장을 하고 있지만 미래는 매우 밝습니다.

결론

결론적으로 JavaScript는 웹 브라우저를 위한 간단한 스크립트 언어로 시작하여 클라이언트 측 및 서버 측 애플리케이션을 모두 처리할 수 있는 강력한 생태계로 크게 발전했습니다. 그 여정은 성능, 확장성 및 유형 안전성의 지속적인 개선으로 표시되어 현대 웹 개발을 위한 다양한 선택이 되었습니다.

Node.js와 같은 도구와 React와 같은 프레임워크의 도입으로 기능이 확장되었으며 Deno와 같은 혁신은 다양한 도구와 구성을 응집력 있는 환경에 통합하여 개발 프로세스를 더욱 간소화할 것을 약속합니다.

지속적인 발전과 강력한 커뮤니티를 통해 개발자에게 내일의 웹 애플리케이션 구축을 위한 통합되고 효율적인 플랫폼을 제공하는 JavaScript의 미래는 유망해 보입니다.

위 내용은 JavaScript - 축복인가 저주인가?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!