Future of JavaScript in 2017 and Beyond

JavaScript’s Journey Through 2016

  Every year, there seems to be more and more ways to use JavaScript and 2016 turned out to be no different. Depending on your level of optimism, this can be extremely exciting or extremely confusing. Last year, we made some predictions about JavaScript in 2016. Now, we’ll look back to see if our predictions held true or went the way of the political pundits. Then, we’ll use what we’ve learned this year to make an educated guess on what we’ll get out of 2017.

 매년 자바 스크립트를 사용하는 방법이 점점 더 많아지며 이것은 2016년의 기조와 크게 다르지 않습니다. 개발자의 새로운 기술을 습득하는 수준에 따라 매우 흥미롭거나 혼란스러울 수 있습니다. 작년에 우리는 2016 년에 자바 스크립트에 대한 몇 가지 예측을 했습니다. 이제 우리의 예측이 진실인지 또는 정치 전문가일 뿐인지 살펴볼 것입니다. 그런 다음 올해 우리가 배운 것을 활용하여 2017년에 나올 내용을 교육적으로 접근해봅니다.

ES2015 Browser Implementation

  As of June 2016, the development community moved from the 6th edition of ECMAScript—ES2015 (once referred to as ES6)—to the 7th edition—ES2016. The next edition developers will move to is ES2017 but that may not arrive until June 2017 (if not later). Sometimes, like in the chart below, the upcoming features of ES2016 and ES2017 are just lumped into the ES2016+ category. This whitepaper will refer back to this chart, so for clarity sake ES2016+ will be used to describe future features as well. ES2015 contained a lot of features that developers felt would make programming in JavaScript better, like arrow functions, promises, destructuring and more. Here we’ll look into how the features of ES2015 were handled in 2016 and if they held up to our expectations.

  2016 년 6 월 현재 개발 커뮤니티는 ECMAScript-ES2015의 제 6 판 (한 번은 ES6이라고 함)에서 제 7 판 -ES2016으로 옮겼습니다. 다음 버전의 개발자는 ES2017로 전환하지만 2017 년 6 월까지는 도착하지 않을 수 있습니다 (나중에는 그렇지 않은 경우). 아래 차트와 같이 ES2016 및 ES2017의 향후 기능이 ES2016 + 범주로 묶일 때도 있습니다. 이 백서는이 차트를 다시 참조 할 것이므로 명확한 설명을 위해 ES2016 +는 향후 기능을 설명하는 데 사용됩니다. ES2015에는 화살표 기능, 약속, 구조 조정 등과 같이 JavaScript로 프로그래밍하는 것이 더 좋을 것이라고 개발자가 느낀 많은 기능이 포함되어있었습니다. 여기에서는 ES2015의 기능이 2016 년에 어떻게 처리되었는지와 기대에 부합하는지 살펴 보겠습니다.

  In order to use features from ES2015 that weren’t supported by browsers, servers or runtimes source-to-source transpilers like Babel and Traceur are used so developers can write with the ES syntax and then have it compiled into compatible JavaScript. Thanks to the ever-handy ECMAScript compatibility table from kangax, we can see a lot of green, in the chart—this means that many of the features are supported in various browsers.

  브라우저에서 지원하지 않는 ES2015의 기능을 사용하려면 개발자가 ES 구문으로 작성한 다음 호환 가능한 JavaScript로 컴파일 할 수 있도록 Babel 및 Traceur와 같은 서버 또는 런타임 소스 간 변환기를 사용하십시오. ECMAScript의 kangax 호환성 테이블 덕분에 차트에서 많은 녹색을 볼 수 있습니다. 즉, 다양한 브라우저에서 많은 기능이 지원됩니다.

  Currently, Firefox 50 is supporting 92% of the ES2015 features, Chrome 55+ and Node 6.5+ are at 97%, while Safari 10 and iOS 10 are at 100%. The only feature holding back the 97%-ers is the optimization feature of ES2015, proper tail calls. This is great news for developers who want to use these features without transpilers

  현재 Firefox 50은 ES2015 기능의 92 %를 지원하고 Chrome 55+ 및 Node 6.5+는 97 %, Safari 10 및 iOS 10은 100 %입니다. 97 % -를 지탱하는 유일한 기능은 적절한 꼬리 호출 인 ES2015의 최적화 기능입니다. 이것은 transpilers없이 이러한 기능을 사용하고자하는 개발자에게 좋은 소식입니다.

  Although there are some features of ES2016+ already being supported (Firefox 52+ is already at 91%) there is still a lot of red.

  ES2016 +의 일부 기능이 이미 지원되고 있지만 (Firefox 52+는 이미 91 %) 이미 많은 빨간색이 있습니다.

  So far though, this feature list is shorter than ES2015 and the only “large feature” is async functions (which is already supported on Firefox 52+ and Chrome 55+). With the success of the browser support for ES2015, it looks very likely developers will once again get close to 100% compatibility with the main browsers for the ES2016+ features.

  지금까지이 기능 목록은 ES2015보다 짧으며 "큰 기능"은 비동기 기능 (Firefox 52 이상 및 Chrome 55 이상에서 이미 지원됨)입니다. ES2015에 대한 브라우저 지원의 성공으로 인해 개발자는 다시 ES2016 + 기능의 주요 브라우저와 거의 100 % 호환 될 가능성이 높습니다.

Modules, the Most Important Addition?

  Last year, we asserted that ES6 modules would be the most important addition. As predicted, a lot of developers have taken advantage of the ES6 module syntax in their code thanks to transpilers like Babel or Traceur. It’s hard to gather numbers to back this up but if you read all the articles on the “top” or “favorite” new features from ES2015, the modules feature is almost always listed.

  작년에 우리는 ES6 모듈이 가장 중요한 추가 기능이라고 주장했습니다. 이 주장에 따르면 많은 개발자들이 Babel이나 Traceur와 같은 변환기를 사용하여 코드에서 ES6 모듈 구문을 이용했습니다. ES2015의 "최고"또는 "좋아하는"새로운 기능에 대한 모든 기사를 읽으면 대부분 모듈 기능을 볼 수 있을 것입니다.

  We were hoping for a native module system in 2016 so that commonJS, AMD, UMD, and non-native loaders like browserify, webpack and systemJS were no longer necessary. However, tackling the loading process for modules seems to be quite a feat, so that feature may still be far off. That said, there does seem to be a good measure of interest and work going into this feature. There is a great recap from James Snell about a TC-39 meeting he attended to get info on the feature. “There is a proposal being put before TC-39 that would introduce a new import() function.” Snell wrote. The import() function...is processed at evaluation. It also imports an ESM (or CommonJS module) but, like the require() method in Node.js currently, operates completely during evaluation. Unlike require(), however, import() returns a Promise, allowing (but not requiring) the loading of the underlying module to be performed fully asynchronously.”

  우리는 commonJS, AMD, UMD 및 browserify, webpack 및 systemJS와 같은 기본이 아닌 로더가 더 이상 필요하지 않도록 2016 년에 기본 모듈 시스템을 원했습니다. 그러나 모듈의 로딩 프로세스에 대처하는 것은 상당한 일로 보입니다. 따라서 이 기능은 여전히 멀리 떨어져있을 수 있습니다. 즉, 이 기능에 관심과 노력이 있는 것으로 보입니다. 제임스 스넬 (James Snell)이 그가 TC-39 모임에 관해 대담하게 요약하여 기능에 대한 정보를 얻었습니다. "TC-39 이전에 새로운 import() 함수를 도입할 수 있도록 제안했다."라고 Snell은 썼습니다. import () 함수는 평가시 처리됩니다. 또한 ESM (또는 CommonJS 모듈)을 가져 오지만 현재 Node.js의 require () 메소드와 마찬가지로 평가 중에 완전히 작동합니다. 그러나 require ()와 달리 import ()는 Promise를 반환하므로 기본 모듈의로드가 완전히 비동기 적으로 수행 될 수 있습니다.

  This feature would also enable developers to make calls like await import(‘foo’). To be clear, this may still be a long way off but it is currently in stage 3. Here’s a breakdown of their process to explain what ‘stage 3’ actually means: TC-39 Process. Based on the amount of interest in this feature, it’s likely that it will get released in 2017.

  이 기능을 사용하면 개발자는 import('foo')와 같은 호출을 할 수 있습니다. 명확히 말하면, 이것은 아직 멀기는하지만 현재 3 단계에 있습니다. 다음은 '3 단계'가 실제로 의미하는 것을 설명하기위한 프로세스의 분석입니다. TC-39 프로세스. 이 기능에 대한 관심의 정도에 따라 2017 년에 출시 될 가능성이 큽니다.

Popular Features of 2016

  Following ES6 modules, we predicted that the other stand-out feature of the year would be promises. No one likes callback hell or the pyramid of doom, so the addition of native promises was a very welcomed move.

Promises have been covered in a lot in posts and tutorials across the web, likely because they seem complex when developers first start using them.

  ES6 모듈에 이어 우리는 올해의 다른 두드러진 특징이 promises 일 것이라고 예측했습니다. 아무도 콜백 지옥이나 운명의 피라미드를 좋아하지 않기 때문에 native promises을 추가하는 것은 매우 환영받는 조치였습니다.

Promises은 개발자가 처음 웹을 사용하기 시작할 때 복잡해 보일 수 있기 때문에 웹 전반의 게시물 및 자습서에서 많은 부분을 다루었습니다.

  A few other ES6 features that got a lot of attention were spread parameters, destructuring and default parameters. Many developers found these features to be helpful for making their existing JavaScript code more powerful, concise and/or readable.

  많은 관심을 끄는 다른 몇 가지 ES6 기능은 spread parameters, destructuring 및 default parameters입니다. 많은 개발자가 이 기능이 기존 JavaScript 코드를보다 강력하고 간결하며 읽기 쉽도록 만드는 데 유용하다는 것을 알았습니다.

  A few of the new features are also touted to fix the “bad parts” of JavaScript. To add block scope and prevent variable hoisting outside of the scope, you can now use let and const. With arrow functions, the variable “this” always points to the object that it is physically located within.

  새로운 기능 중 일부는 JavaScript의 "불량 부품"을 수정하기 위해 선전되었습니다. 블록 범위를 추가하고 범위 외부에서 변수 호이 스팅을 방지하려면 let 및 const를 사용할 수 있습니다. 화살표 함수(arrow function)를 사용하면 "this"변수는 항상 그 안에 물리적으로 위치한 객체를 가리 킵니다.

  The rest parameters feature lets us treat the parameters like an array so that we can use the array functions like slice, sort, etc.

  나머지 매개 변수(rest parameters) 기능을 사용하면 slice와 같은 배열 함수를 사용할 수 있도록 배열과 같은 매개 변수를 처리 할 수 있습니다.

  As developers get used to the new syntax changes and the benefits they yield, they may become more open to adding new features. Across the web, more and more tutorials are popping up that incorporate the ES2015 syntax without mention or explanation of ES2015. This suggests that it is becoming the new normal and that this trend will continue into 2017.

  개발자는 새로운 구문 변경과 이점을 통해 익숙해지기 때문에 새로운 기능을 추가하는 데 더 많은 지식이 필요할 수 있습니다. 웹 전반에 ES2015에 대한 언급이나 설명없이 ES2015 구문을 통합하는 자습서가 점점 더 많이 등장합니다. 이것은 새로운 정상이되고 있으며 이러한 추세가 2017 년까지 계속 될 것임을 시사합니다.

 Classes: Objects and Prototypes

  There were many discussions and strongly-held views about the inclusion of ES2015 Classes. Thankfully, people have made their points and the debate has seemingly to dying down.

  ES2015 Classes을 포함하는 것에 대한 많은 논쟁과 보수적 관점 있었습니다. 고맙게도, 사람들은 요점을 만들었고 논쟁은 잦아들고 있어 보입니다.

  As predicted, people stay steadfast in their preference to Object-Oriented Programming, Functional Programming, etc. The biggest point made about ES6 Classes was to specify that they were mostly syntactical sugar for prototypes and not to be confused with traditional classes like those from Java.

  예상대로 사람들은 객체 지향 프로그래밍, 기능 프로그래밍 등을 선호하는 경향이 있습니다. ES6 클래스에 대한 가장 큰 요점은 이들이 프로토 타입을 위한 syntactical sugar(문법적 편의성) 이었고 Java와 같은 전통적인 클래스와 혼동하지 않도록 지정하는 것이 었습니다 .

  Next year will not be the year that all developers decide they will all work together and only write functional JavaScript. IAs many developers have found first hand, simply getting five people to agree on semicolon usage is difficult enough. React had built a class system for its own framework but are very open to the inclusion of ES2015 classes, as is Angular 2. With frameworks making the use of classes easily accessible, it will be up to teams and developers to choose whether they want to be classy or classless in their code.

  내년은 모든 개발자가 모두 협력하고 기능적 JavaScript 만 작성한다고 결정한 해는 아닙니다. 많은 개발자들이 처음 손을 찾았으므로 단순히 세미콜론 사용에 동의하는 5 명을 얻는 것이 어렵습니다. React는 자체 프레임 워크를위한 클래스 시스템을 구축했지만 Angular 2와 마찬가지로 ES2015 클래스를 포함 할 수 있습니다. 클래스를 쉽게 액세스 할 수있게하는 프레임 워크에서는 팀 및 개발자가 원하는대로 선택할 수 있습니다. 코드에 고급 스럽거나 클래스가 없다.

Additional Features 

  Last year, we suggested the proposals likely to be added to the language were Exponential Operator, Array.protoype.inlcludes, SIMD.JS - SIMD APIs + polyfill and Async Functions. Let’s see how far along these additional features are.

  작년에 우리는이 언어에 추가 될 가능성이 높은 제안을 지수 연산자(Exponential Operator), Array.protoype.inlcludes, SIMD.JS - SIMD API + polyfill 및 Async 함수라고 제안했습니다. 이러한 추가 기능에 대한 상황을 알아보겠습니다.

  Array.prototype.includes: This feature is still considered an ES2016 feature and is actually supported on Edge 14, Firefox 45+, Chrome 55+, Safari 10, Node 6.5+ and iOS 10.

  Array.prototype.includes: 이 기능은 여전히 ES2016 기능으로 간주되며 실제로 Edge 14, Firefox 45+, Chrome 55+, Safari 10, Node 6.5+ 및 iOS 10에서 지원됩니다.

  SIMD: This feature is listed as a “Candidate” at stage 3 but will be a large feature.

  SIMD: 이 기능은 3 단계에서 "후보자(Candidate)"로 표시되지만 큰 기능입니다.

  Async Functions: This feature is the only “large” feature on the list for ES2017 features and are already supported by Firefox 52+ and chrome 55+.

  비동기 기능: 이 기능은 ES2017 기능의 목록에있는 유일한 "대형"기능이며 Firefox 52+ 및 Chrome 55+에서 이미 지원됩니다.

  

Package Managers

  Going into 2016 we suggested using systemJS and jspm.io and it is still a solid option. In 2016 alone systemJS has been downloaded over 4.4 million times, ~520,000 times in the past month.

  2016 년에 우리는 systemJS와 jspm.io를 사용하도록 제안했고 지금도 여전히 훌륭한 선택입니다. 2016년 한 해에만 systemJS가 지난 달에 440만번 ~ 520만번 다운로드되었습니다.

  It seemed that people were leaning toward making npm the go-to package manager for the both front and backend. This still seems to be the case, especially with npm being paired with webpack and browserify.

  패키지 관리를 위해서 프론트엔드와 백엔드 모두 npm을 사용하는 방향으로 선택한듯 싶습니다. NPM이 webpack 혹은 browserify가 함께 사용되는 경우에 이러한 경향은 더욱 뚜렷합니다.

  The npm registry is still at the top, after all it provides access to over 300,000 packages and there are more than 4 million people using the registry. There is an advantage to using the same package manager if you are using Node.js as your backend.

  npm 레지스트리는 여전히 최상위에 있으며, 300,000개 이상의 패키지에 대한 액세스를 제공하고 레지스트리 사용자는 4백만 명이 넘습니다. Node.js를 백엔드로 사용하는 경우 동일한 패키지 관리자를 사용하면 이점이 있습니다.

  Looking back on last year’s predictions, we did not take into account the option of a new package manager coming onto the scene. Yet, that’s exactly what happened when Facebook introduced Yarn in October.

  지난 해의 예측을 되돌아 볼 때 우리는 새로운 package manager에 대한 옵션을 고려하지 않았습니다. 그러나 페이스 북이 10 월에 Yarn을 소개했을 때 그런 일이 일어났습니다.

  Facebook had been using npm but once their codebase and engineering team grew, the company started running into problems and decided to create its own package manager. Yarn piqued the interest of developers at launch thanks to the big names involved: Google and Facebook. Based on the npm download stats, Yarn took a dip while the U.S. was on Thanksgiving break and hasn’t surpassed its ~160,000 weekly download record from November.

  페이스 북은 npm을 사용했지만 코드베이스 및 엔지니어링 팀이 성장하자 문제가 발생하기 시작하여 자체 패키지 관리자를 만들기로 결정했습니다. Yarn은 구글과 페이스 북과 같은 큰 이름의 개발자 덕분에 개발자의 관심을 끌었다. npm 다운로드 통계에 따르면, 미국은 추수 감사절 11월부터 주당 160,000회 다운로드 되었지만 Yarn은 하향세에 있다.

  We’ll have to keep an eye on Yarn but so far its November downloads (~538,000) aren’t even coming close to npm’s (~3.6 million)

  우리는 Yarn을 주시해야하지만, 지금까지 11월의 다운로드 수 (~ 538,000)는 npm (~ 360 만)에 근접하지 않습니다.

  To be clear, Yarn is not a replacement for npm. It is a CLI client that fetches the modules from the npm registry. It’s unlikely that we would not see another package manager surfaces in 2017 but Facebook may have opened the field up to new contenders. Even with snafus like the left-pad situation, npm feels very reliable.

  명확히 말하면, 얀은 npm을 대체하지 않습니다. npm 레지스트리에서 모듈을 가져 오는 CLI 클라이언트입니다. 2017 년에 다른 패키지 관리자가 등장하는 것을 보지 못할 것 같지만 페이스 북은 새로운 경쟁자에게 필드를 열어 놓았을 것입니다. 왼쪽 패드 상황과 같은 불안정한 경우에도 npm은 매우 안정적이라고 느낍니다.

Issues Resolved in 2016

  We touched on a few key issues that we believed needed to be resolved in 2016, here’s the update on each of those.

  우리는 2016 년에 해결해야 할 것으로 생각되는 몇 가지 주요 쟁점을 다루었습니다. 여기에 각각의 업데이트가 있습니다.

  “How native modules are loaded in a browser will need to be ironed out and an initial implementation will need to commence.”

  "네이티브 모듈을 브라우저에로드하는 방법은 다림질(개선?)되어야하며 초기 구현을 시작해야합니다."

  As we touched on a bit before, this is still a work in progress. The good news is that this is something the technical committee is working on. The implementation has not happened but it seems to be on track for 2017.

  이전에 약간 만져 보았지만 여전히 진행중인 작업입니다. 좋은 소식은 이것이 기술위원회가 수행하고있는 작업이라는 것입니다. 그 시행은 일어나지 않았지만 2017년에 궤도에 진입 한 것으로 보인다.

  “We haven’t fully scratched the async itch. While, await functions will help, the journey is far from complete. Promises and eventually streams will need to be used throughout (e.g. HTTP promises). And O’yeah, canceling a promise. That might be a good idea.”

  "우리는 비동기 가려움증을 완전히 긁어 내지 못했습니다. 기능이 도움이 될 때까지 기다리는 동안 여행은 완전히 끝나지 않습니다. Promises 및 최종 스트림을 전체적으로 사용해야합니다 (예 : HTTP promises). 그리고 O'yeah, promise을 취소까지. 좋은 아이디어라 생각한다."

  Promises are supported on all major browsers and async functions are set to be a 2017 feature.

  Promises은 모든 주요 브라우저에서 지원되며 async functions은 2017 기능으로 설정됩니다.

  The TC39 are considering multithreading but it is hard to say when that will start making its way through the pipeline. There is a proposal for parallelism with web workers, running scripts in background threads. It is a very complicated issue to work through but it would increase performance using multicore processors.

  TC39는 멀티 스레딩을 고려하고 있지만 언제 파이프 라인을 통해 진행될지를 말하기는 어렵습니다. 백그라운드 스레드에서 스크립트를 실행하는 web workers와의 병렬 처리에 대한 제안이 있습니다. 이를 해결하는 것은 매우 복잡한 문제이지만 멀티 코어 프로세서를 사용하면 성능이 향상됩니다.

  “The ‘should we or shouldn’t we’ debate about immutable native objects will hopefully conclude.”

  "immutable native objects에 관해 우리가 논쟁해야하는지, 아니면하지 말아야 하는지를 희망적으로 결론 지을 것이다."

  The conversation around this hasn’t been as active lately, presently but it seems to boil down to what programming paradigm you subscribe to. If you are truly using functional programming, you never attempt to mutate state. Therefore, it should not matter if the state is technically mutable. If you are using objectoriented programming, immutability is an odd fit because immutability is technically about data-structures. That being said, there are ways to make it work, if you’re up for it. Here is a thorough article discussing just that.

  최근에이 대화는 현재 활발히 진행되지 않았지만 현재 귀하가 구독하는 프로그래밍 패러다임에 이르는 것으로 보입니다. 진정으로 함수형 프로그래밍을 사용한다면 절대로 상태를 변경하려고 시도하지 마십시오. 따라서 국가가 기술적으로 변경 가능한지 여부는 중요하지 않습니다. 객체 지향 프로그래밍을 사용하는 경우 불변성은 기술적으로 데이터 구조에 관한 것이므로 불변 성은 이상한 요소입니다. 그것이 말하게되면, 그것을 작동시키는 방법이 있습니다. 여기에 대해 자세히 설명하는 철저한 기사가 있습니다.

  “Lastly, payoff whomever it takes for all browser manufacturers to treat the JavaScript runtimes in a mobile browser with the same status as a regular browser.”

  "마지막으로, 모든 브라우저 제조업체가 일반 브라우저와 동일한 상태의 모바일 브라우저에서 JavaScript 런타임을 처리하는 데는 성과가 있습니다."

  Unfortunately, looking back at the ECMA Compatibility Table, it seems no one has been paid off. iOS has 100% compatibility but Android seems to be falling behind at a mere 25% for Android 5.1. With Google’s recent push for Progressive Web Apps and focus on cell phone and tablet usage, all mobile browsers will have to catch up fast. Maybe then, the only ones getting a payoff will be us, the users!

  유감스럽게도 ECMA Compatibility Table을 되돌아 보면 아무도 지불하지 않은 것으로 보입니다. iOS의 호환성은 100 %이지만 안드로이드 5.1의 안드로이드는 25 %에 머물러있는 것으로 보입니다. 구글이 최근 프로 그레시브 웹 애플리케이션을 추진하고 휴대폰과 태블릿 사용에 초점을 맞추면 모든 모바일 브라우저가 빠르게 따라 잡아야 할 것이다. 어쩌면 결과를 얻는 유일한 사람들은 우리 (사용자)가 될 것입니다!

Options Overload

   At the beginning of 2016, developers were already aware that the many different styles for constructing JavaScript applications were overwhelming. We had hoped that the developer community would be able to update the way we think about and teach JavaScript development to accommodate the variations. As the authors of this whitepaper, we do believe that the focus on best practices is present. Unfortunately, there are still so many ways to build JavaScript applications that it is hard to find multiple tutorials or examples that have the same application setup.

  개발자는 2016 년 초에 JavaScript 응용 프로그램을 구성하는 다양한 스타일이 압도적 이었음을 이미 알고있었습니다. 개발자 커뮤니티가 우리가 생각하는 방식을 업데이트하고 유사 콘텐츠를 수용하도록 JavaScript 개발을 가르치기를 기대했습니다. 이 백서의 저자 인 우리는 베스트 프랙티스에 중점을두고 있다고 생각합니다. 불행하게도 자바 스크립트 애플리케이션을 개발하는 방법은 여전히 많습니다. 동일한 애플리케이션 설정을 가진 여러 튜토리얼이나 예제를 찾기가 어렵습니다.

  Although many developers seem to be suffering from JavaScript fatigue, the bigger issue may actually be from the paradox of choice. In local JavaScript communities across the web there are always conversations about the pros and cons of using different JavaScript technologies and the best ways to implement new features. How do you commit when things are changing so fast?

  많은 개발자들이 자바 스크립트 피로로 고통 받고있는 것처럼 보이지만, 더 큰 문제는 실제로 선택한 패러독스의 문제 일 수 있습니다. 웹의 지역 JavaScript 커뮤니티에는 항상 서로 다른 JavaScript 기술을 사용하고 새로운 기능을 구현하는 최상의 방법에 대한 장단점에 대한 대화가 있습니다. 일이 빠르게 변할 때 당신은 어떻게 저촉합니까?

  New tools are popping up just as fast as old ones are dying. You can spend hours researching how to create your new JavaScript application. Then, after the onslaught of options, you end up paralyzed with indecision and instead decide you would be happier searching for Chevrotains in the rainforests of West Africa—which feels much more stable because they haven’t changed for over 5 million years.

  새로운 도구가 오래된 것들이 죽어가는 것처럼 빠르게 나타납니다. 새 JavaScript 응용 프로그램을 만드는 방법을 연구하는 데 시간을 할애 할 수 있습니다. 그런 다음 옵션의 맹공격 후에, 당신은 우유 부단으로 마비되게되고 그 대신 서 아프리카의 열대 우림에있는 Chevrotains를 찾는 것이 더 행복 할 것이라고 결정합니다. 그들은 5 백만년 이상 변하지 않았기 때문에 훨씬 안정적이라고 느낍니다.

  The good news is that developers, as a community, are becoming more aware of this problem. While we may not all decide to use the same style for how we build our JavaScript applications but, we may hopefully slow the creation of new options. This is a very optimistic prediction but in 2017 developers may just begin to streamline approach to building applications.

  좋은 소식은 개발자로서 커뮤니티로서이 문제를 더 잘 인식하고 있다는 것입니다. 우리 모두가 JavaScript 애플리케이션을 구축하는 방법에 대해 동일한 스타일을 사용하기로 결정하지는 않았지만, 새로운 옵션 생성을 느리게 진행할 수 있습니다. 이는 매우 낙관적 인 예측이지만 2017 년 개발자들은 응용 프로그램 구축에 대한 접근 방식을 간소화하기 시작할 수 있습니다.

Usage

  Last year we mentioned WebAssembly stealing some of the spotlight from JavaScript once it hit all the browsers. It hasn’t taken over the internet yet but the advancement of WebAssembly this year has been significant. V8 has a WebAssembly Browser Preview and the WebAssembly Community Group has their MVP and JavaScript API implemented on several browsers. They are planning for the Browser Preview to finish in Q1 2017, so we’ll see what comes next very soon! If you want to get a taste, you can check out the demo using Chrome Canary and Firefox Nightly (you will have to switch some flags).

  작년에 우리는 일단 WebAssembly가 모든 브라우저를 공격하면 JavaScript의 주목을 훔쳤다고 언급했습니다. 아직 인터넷을 인수하지는 않았지만 올해 WebAssembly의 발전이 중요했습니다. V8에는 WebAssembly 브라우저 미리보기가 있고 WebAssembly 커뮤니티 그룹에는 MVP 및 JavaScript API가 여러 브라우저에 구현되어 있습니다. 그들은 2017 년 1 분기에 브라우저 미리보기를 마칠 예정이므로 다음에 곧 출시 될 내용을 곧 보게 될 것입니다! 맛을보고 싶다면 Chrome Canary 및 Firefox Nightly (일부 플래그를 전환해야 함)를 사용하여 데모를 확인할 수 있습니다.

  We did predict that JavaScript would become the language of native applications (NativeScript, Electron, React Native) because developers would want to write in JavaScript alone. The State of JS survey results from Sacha Greif confirm that developers may be easing their way into JavaScript mobile frameworks. As for desktop applications, Electron has reached over 1.6 million downloads and React Native follows close behind with 1.5 million since their releases in 2014 (over 200,000 and 180,000 in the last month, respectively). With this increase in downloads and the NativeScript plans to include desktop support, JavaScript is definitely infiltrating the native application scene and will continue to do so into 2017.

  개발자는 자바 스크립트 만 쓰고 싶기 때문에 JavaScript가 네이티브 응용 프로그램 (NativeScript, Electron, React Native)의 언어가 될 것으로 예측했습니다. Sacha Greif의 JS 조사 결과에 따르면 개발자는 JavaScript 모바일 프레임 워크로 쉽게 이동할 수 있습니다. 데스크톱 애플리케이션의 경우 Electron는 160 만 건의 다운로드에 도달했으며 React Native는 2014 년 출시 이후 150 만 건으로 마감했습니다 (각각 지난달 200,000 건과 180,000 건 이상). 다운로드가 증가하고 NativeScript가 데스크톱 지원을 포함 할 계획이므로 Javascript는 네이티브 응용 프로그램 장면에 확실히 침투 해 있으며 2017 년까지도 계속 진행될 것입니다.

  Nothing seems to be hindering the continued growth of JavaScript usage and with it being a language you can use for practically everything—(mobile, IoT (internet of things), native, back-end, front-end—more developers may be switching over. The only perceivable downfall I see is that the onboarding process for new users may be quite overwhelming. With new features coming out from ES2015 and ES2016+, just writing JavaScript has many options. Once users decide on that, they then need to make a decision on frameworks, transpilers, package managers, modules and more. Nonetheless, all the powerful ways you can use JavaScript outweigh this issue.

  JavaScript 사용의 지속적인 성장을 방해하는 것은 없으며 사실상 모든 것을 위해 사용할 수있는 언어입니다. (모바일 인터넷, 네이티브, 백엔드, 프론트 엔드) 더 많은 개발자가 전환 할 수 있습니다. ES2015와 ES2016 +에서 나온 새로운 기능을 사용하면 자바 스크립트를 작성하는 데 많은 옵션이 있습니다. 사용자가이를 결정하면 결정을 내려야합니다. 패키지 관리자, 모듈 등을 포함하지만 자바 스크립트를 사용할 수있는 모든 강력한 방법이이 문제를 능가합니다.

JavaScript Wrap-Up

 There are still a lot of exciting features that are going to be worked on and added in 2017. Our predictions from last year turned out to be pretty close but the hopes for better mobile browser and native module support will have to wait a little while longer. We’ll check back next year to see if there are new package management tools, if we’re over JavaScript fatigue and if everyone is referring to ECMAScript editions correctly. Until then, I think that we’ll all be able to make great projects with JavaScript and continue to learn a lot while doing so.

  작년부터 우리의 예측은 꽤 가까웠지만 모바일 브라우저 및 기본 모듈 지원 향상에 대한 희망은 조금 더 기다려야 할 것입니다. . 새로운 패키지 관리 도구가 있는지, JavaScript 피로를 극복하고 모든 사람들이 ECMAScript 버전을 올바르게 언급 하는지를 확인하기 위해 내년에 다시 점검 할 것입니다. 그때까지는 JavaScript를 사용하여 훌륭한 프로젝트를 만들고 그렇게하면서 많은 것을 배우는 것을 계속할 수있을 것이라고 생각합니다.

  2016 was a pivotal year for JavaScript developers. That seems rather ironic considering that every year is somewhat of a pivotal year since JavaScript and the web platform seem to be in a state of constant evolution. The best practices of yesterday are today’s anti-patterns; yesterday’s libraries, today’s technical debt.

  2016 년은 JavaScript 개발자들에게 중요한 해였습니다. 자바 스크립트와 웹 플랫폼이 끊임없이 진화 한 이후 매년 해마다 중추적 인 해가되는 것을 감안하면 다소 모순적인 것 같습니다. 어제의 모범 사례는 오늘의 안티 패턴입니다. 어제의 도서관, 오늘날의 기술적 빚.

  This makes it all together frustrating to feel like one has ever really “mastered” JavaScript and has even garnered a catch word of its own in the industry known as “JavaScript Fatigue”.

  이로 인해 JavaScript가 실제로 "마스터 된"것처럼 느껴지기도하고, "JavaScript 피로 (JavaScript Fatigue)"라고 알려진 업계에서 독창적 단어를 얻기도 하였습니다.

  While change is inevitable and moving forward is always the best path, it is worth revisiting the past so that we can learn from it. It’s in that spirit that we look back on how JavaScript evolved in 2016, and what it’s trajectory is for 2017; so that we can ready ourselves for the next big changes for JavaScript.

  변화는 피할 수 없으며 앞으로 나아가는 것이 항상 최선의 길이지만, 과거로부터 다시 배울 가치가 있습니다. 2016 년에 자바 스크립트가 진화 한 방식을 되돌아보고, 그 궤도는 2017 년입니다. 자바 스크립트의 다음 큰 변화를 준비 할 수 있습니다.

Libraries And Frameworks

  It’s no longer debatable that JavaScript has amassed a popularity that is unmatched in the software development world. This manifests itself largely by the sheer number of open-source frameworks that are released each year for JavaScript developers. The site javascripting.com attempts to catalog each of these different frameworks and their popularity—there are 73 pages of libraries available in total.

  자바 스크립트가 소프트웨어 개발 분야에서 타의 추종을 불허하는 인기를 누리고 있다는 사실은 더 이상 논쟁의 여지가 없습니다. 이것은 JavaScript 개발자를 위해 매년 공개되는 수많은 오픈 소스 프레임 워크에 의해 크게 나타납니다. javascripting.com 사이트는 이러한 다양한 프레임 워크와 인기도를 각각 카탈로그 화하려고 시도합니다. 총 73 페이지의 라이브러리가 사용 가능합니다.

  While there are innumerable JavaScript libraries for various pieces of functionality (User Interface, Date Parsing, Data Storage, etc.), developers will be primarily familiar with the so-called JavaScript Frameworks; those libraries with the purpose of helping you compose the different pieces of your application.

  다양한 기능 (사용자 인터페이스, 날짜 구문 분석, 데이터 저장소 등)을위한 수많은 JavaScript 라이브러리가 있지만 개발자는 주로 JavaScript 프레임 워크에 익숙합니다. 응용 프로그램의 다른 부분을 작성할 수 있도록 도와주는 라이브러리.

  In the State of JavaScript Survey from Sasha Greif, the libraries that made the cut for awareness were React, Angular 2, Ember, Vue and Backbone. In addition, Aurelia gets a nod on the strength of its repeated occurrence as a write-in candidate. For those reasons, we’re going to look at each of these frameworks, substituting Aurelia for Backbone given the age of Backbone and its likely appearance as a legacy. Looking back can help us determine how each of these frameworks impacted web development in 2016, as well as where they are likely headed.

  사샤 그레이프 (Sasha Greif)의 자바 스크립트 설문 조사 (State of JavaScript Survey)에서 인지도를 높이기 위해 만든 라이브러리는 React, Angular 2, Ember, Vue and Backbone이었습니다. 또한, Aurelia는 기명 후보자로서 반복되는 출현의 힘을 끄덕임을 얻습니다. 이러한 이유로 우리는 Backbone의 시대와 유산으로서의 가능성을 고려할 때 Aurelia를 Backbone으로 대체하여 이러한 프레임 워크를 살펴볼 것입니다. 되돌아 보면 2016 년에 이러한 프레임 워크가 웹 개발에 어떤 영향을 주 었는지, 그리고 어디로 향할지를 결정하는 데 도움이 될 수 있습니다.

  First, it’s important to recognize the fundamental way in which the model of open-source has changed.

  첫째, 오픈 소스 모델이 바뀌는 근본적인 방식을 인식하는 것이 중요합니다.

An Open-Source Shift

  JavaScript has long enjoyed an almost entirely open-source pedigree. Up until now that was primarily on the strength of some remarkable individuals, such as John Resig (jQuery), Jeremy Ashkenas (Backbone,Underscore), Thomas Fuchs (Zepto, script.aculo.us), Mihai Baizon (Uglify), Eric Schoffstall (Gulp), Ben Alman (Grunt), and a host of others. The community would rally around these projects and remarkable things were accomplished. The entire web was run primarily on the work of hundreds of individuals who had never even met.

  JavaScript는 오랫동안 거의 모든 오픈 소스 혈통을 즐겼습니다. 지금까지 John Resig (jQuery), Jeremy Ashkenas (Backbone, Underscore), Thomas Fuchs (Zepto, script.aculo.us), Mihai Baizon (Uglify), Eric Schoffstall (Gulp), Ben Alman (Grunt) 및 기타 다수가 있습니다. 공동체는이 프로젝트를 중심으로 랠리를 벌이면서 주목할만한 것들이 성취되었습니다. 전체 웹은 한 번도 만난 적이없는 수백 명의 개인의 작업을 중심으로 실행되었습니다.

  Angular was the first open-source library to change this landscape. The Angular project is primarily built and controlled by Google. There is a team of developers, marketers and the like that are paid by Google to work on this project full time.

  Angular는이 풍경을 변경 한 최초의 오픈 소스 라이브러리였습니다. Angular 프로젝트는 주로 Google에서 제작하고 관리합니다. 개발자, 마케팅 담당자 등으로 구성된 팀이 Google에서이 프로젝트를 종일 종사하기 위해 돈을 지불합니다.

  React became the second entry in this category of open-source. Initially created at Facebook, it is heavily promoted and marketed by Facebook, which also pays a team of developers to work on React and React based tools and frameworks, such as React Native.

  React는이 카테고리의 오픈 소스에서 두 번째 항목이되었습니다. 처음에 페이스 북에서 창출 된 페이스 북은 페이스 북에 의해 크게 판촉되고 판매되며, React Native와 같은 React and React 기반 툴과 프레임 워크에서 일하는 개발자 팀에게 지불한다.

  Despite this, both frameworks are truly open-source in the classical sense that they have enormous communities that surround and contribute to their success. The defining difference is that at the end of the day, large corporations own and make the ultimate calls on these projects.

  그럼에도 불구하고, 두 프레임 워크는 진정으로 고전적인 의미에서 오픈 소스이며, 그들의 성공을 둘러싸고 기여하는 거대한 공동체를 가지고 있습니다. 가장 큰 차이점은 하루가 끝날 때 대기업이 소유하고 이러한 프로젝트에 대한 궁극적 인 목표를 세우는 것입니다.

Open-Source Predictions for 2017

  Given the now-large corporate involvement in open source, it’s likely this trend continue to grow more prominent in 2017. Look for players such as Microsoft or even Apple to join the fray with their own large opensource offerings for JavaScript developers.

  오픈 소스에 대한 대규모 기업의 참여를 고려할 때 2017 년에는 이러한 추세가 계속 더 두드러 질 것입니다. Microsoft 또는 심지어 Apple과 같은 플레이어가 JavaScript 개발자를위한 대규모 오픈 소스 오퍼링에 참여할 것입니다.

Angular 2

  We opened last year’s discussion of frameworks with React, but 2017 likely belongs to Angular 2, so we’ll start there.

  작년에 React와 함께 프레임 워크에 대한 토론을 시작했지만 2017은 Angular 2에 속할 가능성이 높으므로 여기에서 시작하겠습니다.

  Last year, we predicted that Angular 2 would be released in the first quarter of 2016.

  작년에 Angular 2는 2016 년 1 분기에 출시 될 것으로 예상했습니다.

  A release candidate was announced in May at ng-conf, but there ended up being five release candidates and each was a large breaking change from the previous, which did continue the instability of Angular through to the middle of September, when Angular 2 Final was released.

  릴리스 후보는 5 월에 ng-conf에서 발표되었지만 5 명의 릴리스 후보자로 끝나고 각각 이전 버전과 크게 달라졌습니다. Angular 2 Final이 있던 9 월 중순까지 Angular의 불안정성이 계속되었습니다.

  In addition to the core framework, the Angular team also released a command line interface tool to help control the complexity of an Angular 2 applications and scaffolding out commonly used boilerplate.

  핵심 프레임 워크 외에도 Angular 팀은 Angular 2 애플리케이션의 복잡성을 제어하고 일반적으로 사용되는 상용구를 스캐 폴딩하는 데 도움이되는 명령 줄 인터페이스 도구를 출시했습니다.

Angular Predictions for 2017

  Given the amount of interest in Angular—despite it’s rough road to final release and dozens of breaking changes—it’s clear that Angular enjoys a level of trust and adoption that virtually guarantee that Angular 2 will be the dominant framework of 2017.

  앵귤러에 대한 관심의 정도 - 최종 릴리즈와 수십 가지 변경 사항에 대한 거친 길에도 불구하고 Angular는 Angular 2가 2017 년의 지배적 인 틀이 될 것이라는 사실을 보장하는 수준의 신뢰와 채택을 누리고 있습니다.

  “What does ‘final’ mean? Stability that’s been validated across a wide range of use cases, and a framework that’s been optimized for developer productivity, small payload size, and performance. With ahead-of-time compilation and built-in lazy-loading, we’ve made sure that you can deploy the fastest, smallest applications across the browser, desktop, and mobile environments. This release also represents huge improvements to developer productivity with the Angular CLI and styleguide.“ Jules Kremer – Angular Team

  " '최종'은 무엇을 의미합니까? 다양한 유스 케이스에 걸쳐 검증 된 안정성과 개발자 생산성, 작은 페이로드 크기 및 성능에 최적화 된 프레임 워크 사전 컴파일 및 내장 된 지연로드 (lazy-loading) 기능을 통해 브라우저, 데스크탑 및 모바일 환경에서 가장 빠르고 가장 작은 응용 프로그램을 배포 할 수 있습니다. 이 릴리스는 Angular CLI 및 스타일 가이드를 사용하여 개발자 생산성을 크게 향상 시켰습니다. "Jules Kremer - Angular Team

  Angular 2 has some concepts that make it remarkably unique, including module theory and it’s complete decoupling from the DOM. This makes frameworks such as NativeScript possible so that developers can build native mobile apps with the same knowledge that they use to build web applications.

  Angular 2는 모듈 이론을 포함하여 매우 독창적 인 몇 가지 개념을 가지고 있으며 DOM과의 완벽한 디커플링입니다. 따라서 NativeScript와 같은 프레임 워크가 가능해 개발자가 웹 응용 프로그램을 작성하는 데 사용하는 지식과 동일한 기본 모바일 응용 프로그램을 만들 수 있습니다.

  The end of 2017 will likely see the release of Angular 3.0. While the team describes this as simply semantic versioning, version 3.0 will present an opportunity for the team to introduce necessary breaking changes. That said, we will not see the API change drastically from what it is in 2.0.

  2017 년 말에는 Angular 3.0이 출시 될 것입니다. 팀은이를 단순히 의미있는 버전 관리로 설명하지만 버전 3.0은 팀이 필요한 변경 사항을 도입 할 수있는 기회를 제공합니다. 그렇다고해서 API 2.0이 2.0에서 크게 변경되지는 않을 것입니다.

React

  React was an anomaly in 2015, and that trend continued with force in 2016. React is only a portion of the full front-end framework solution that most developers are looking for, which is the major difference between it and the other frameworks discussed here. That makes it very hard to draw a direct comparison.

  React는 2015 년의 예외였으며 2016 년에도 그 추세가 계속되었습니다. React는 대부분의 개발자가 찾고있는 프론트 엔드 프레임 워크 솔루션의 일부일 뿐이며 여기에서 논의 된 다른 프레임 워크와의 주요 차이점입니다. 따라서 직접적인 비교를하는 것은 매우 어렵습니다.

  In 2016, we predicted that React’s popularity would continue to grow, especially with consumer-facing applications. This turned out to be extremely accurate. While companies are slower to adopt React for enterprise-facing applications, React is seeing a lot of use for consumer applications, with big names such as Airbnb, Dropbox, eBay, Expedia and even internet behemoths such as Netflix using React.

  2016 년에 우리는 React의 인기가 특히 소비자 대면 응용 프로그램을 통해 계속 증가 할 것으로 예측했습니다. 이것은 매우 정확합니다. 기업이 기업용 애플리케이션에 대한 React를 채택하는 속도가 느려지는 동안 React는 Airbnb, Dropbox, eBay, Expedia 및 React를 사용하는 Netflix와 같은 인터넷 대기업과 같은 유명 인사와 함께 소비자 애플리케이션에 대한 많은 사용을보고 있습니다.

  We predicted that there would be continued controversy around JSX, which is the way React mixes HTML in JavaScript in an XML-like fashion. However, this melted into a complete nonissue in 2016, with nobody even batting an eye at this concept anymore.

  우리는 JSX를 둘러싼 논란이 계속 될 것이라고 예측했다. React가 HTML에서 JavaScript를 XML 형식으로 혼합하는 방식이다. 그러나 이것은 2016 년에 완전한 논쟁으로 녹아 들었으며 아무도이 개념을 더 이상 보지 못했습니다.

  We predicted that 2016 would be the year of the commercial React ecosystem. This turned out to be incorrect. While the open-source community is quite large, it is still very difficult to find complex, commercial-grade React components from wellknown vendors.

  우리는 2016 년이 상업적 반응 생태계의 해가 될 것이라고 예측했습니다. 이것은 틀린 것으로 판명되었습니다. 오픈 소스 커뮤니티는 규모가 크지 만 잘 알려진 벤더의 복잡한 상업용 React 구성 요소를 찾는 것은 여전히 어렵습니다.

  We predicted that enterprises would continue to watch React from a distance. This turned out to be largely true with the RC and Final releases of Angular 2 completely overshadowing React in the enterprise. This list of companies that use React confirms this assumption.

  우리는 기업들이 원거리에서 React를 계속 감시 할 것이라고 예측했습니다. 이것은 RC와 최종 버전의 앵귤러 2가 기업에서 React를 완전히 가리고있는 것으로 판명되었습니다. React를 사용하는이 회사 목록은 이 가정을 확인합니다.

React Predictions for 2017

  Considering that React does the few things that it does so well, it’s not likely that we will see a new or different version of React in 2017.

  React가 그렇게 잘하는 몇 가지 일을한다고 생각하면, 2017 년에 React의 새로운 버전이나 다른 버전을 볼 가능성은 없습니다.

  Given that Facebook weighed in on the React Starter Kit landscape by releasing the “Create React App” package, it’s likely that we may see the social media giant release other official React components. It’s easy to speculate that the React Router project may be merged into the official React repo at some point.

  페이스 북이 "Create React App"패키지를 공개함으로써 React Starter Kit 조경에 무게를 둔다면, 우리가 소셜 미디어 거물이 다른 공식 React 구성 요소를 공개 할 가능성이있다. React Router 프로젝트가 어떤 시점에서 공식 React Repo에 병합 될 수 있다고 추측하는 것은 쉽습니다.

  It’s also somewhat likely that React will release its own UI component framework in 2017. This is because Facebook itself has a lot of standard UI and CSS components. Given the recent trend to package and open-source virtually everything the company does, we would not be at all surprised to see a Facebook Bootstrap of sorts.

  또한 React가 2017 년에 자체 UI 구성 요소 프레임 워크를 공개 할 가능성이 다소 높습니다. Facebook 자체에는 많은 표준 UI와 CSS 구성 요소가 있기 때문입니다. 회사가하는 모든 것을 패키지화하고 오픈 소스 화하는 최근의 추세를 감안할 때 Facebook Bootstrap을 보는 것은 그리 놀랄만 한 일이 아닙니다.

Vue

  Vue didn’t even make our cut last year when we made framework predictions, and that’s because it simply wasn’t on the radar at that time. Since then, Vue has garnered a decent amount of attention from the JavaScript community.

  Vue는 작년에 우리가 프레임 워크 예측을했을 때 우리의 몫을 감당하지 못했습니다. 그 이유는 그 당시 레이더에 없었기 때문입니다. 그 이후로 Vue는 JavaScript 커뮤니티로부터 상당한 관심을 얻었습니다.

  As of the time of this writing, Vue is trending on GitHub with 122 stars just today and over 35K all time. Compare that with Ember which has 17K stars and Angular with 53K. There is no denying that Vue is a contender.

  이 글을 쓰는 시점에서 Vue는 현재 GitHub에서 122 개의 별과 함께 35,000 개 이상의 최신 트렌드로 진행되고 있습니다. 17K 개의 별을 가진 Ember와 53K의 Angular를 비교해보십시오. Vue가 경쟁자라는 것을 부인할 수 없습니다.

  Vue is different from all the other players in this whitepaper primarily due to its simplicity. Vue is likely the easiest of the modern JavaScript frameworks to work with. Its API is similar in some ways to Backbone (such as specifying elements and data for chunks of HTML) and there is also some influence from Angular in terms of using special custom HTML attributes to easily bind the DOM to Vue models. It also doesn’t eschew classic web development the way React does with JSX. Its single script include is a breath of fresh air in an era of JavaScript build systems that tend to cripple developers with their complexity.

  Vue는이 백서의 다른 모든 플레이어와 크게 다르지 않습니다. Vue는 현재 사용할 수있는 가장 쉬운 JavaScript 프레임 워크 중 하나입니다. 그것의 API는 백본 (HTML 덩어리를위한 요소와 데이터를 지정하는 것과 같은)과 몇 가지면에서 유사하며 특별한 사용자 정의 HTML 속성을 사용하여 DOM을 Vue 모델에 쉽게 바인딩한다는 측면에서 Angular의 영향이 있습니다. React가 JSX와 같은 방식으로 고전적인 웹 개발을 피하지 않는다. 그 하나의 스크립트를 포함시키는 것은 자바 스크립트 빌드 시스템의 시대에 신선한 공기의 숨결입니다. 개발자들은 복잡성을 무력화시키는 경향이 있습니다.

Vue Predictions for 2017

  Due to the intentional simplicity of Vue, its grassroots success and the constant draw of web developers back to the core concepts of the browser, we predict that Vue will unseat React in 2017 as the light-weight front-end framework of choice for consumer facing applications.

  의도적 인 Vue 단순성, 풀뿌리 성공 및 웹 개발자가 브라우저의 핵심 개념으로 끊임없이 이끌어 가면서 Vue는 2017 년 React를 소비자가 선호하는 경량 프론트 엔드 프레임 워크로 탈바꿈 할 것으로 예측합니다 응용 프로그램.

  That may seem like quite the statement, and is probably the wildest prediction of this whitepaper, but Vue contains all the elements of projects past that have taken the web by storm (see Bootstrap, jQuery), and unlike React and Angular, it is not built by a for-profit corporation, which is more true to the basic tenants of the open web.

  이는 꽤 성명처럼 보일지도 모릅니다.이 백서의 예측은 아마도 가장 야생이지만, Vue는 폭풍으로 웹을 찍은 프로젝트의 모든 요소를 포함하고 있습니다 (부트 스트랩, jQuery 참조). 그리고 React 및 Angular와 달리 영리 법인 (open-web)의 기본 임차인들에게 더욱 사실 인 영리 법인이 건설했습니다.

  Enterprises will continue to favor Angular due to its strong corporate backing element.

  기업은 강력한 기업 지원 요소로 인해 계속해서 Angular를 선호합니다.

Ember

  In 2016, we didn’t say much about Ember, other than that it was a “sleeper” framework and would continue to be just that. This is largely the case. Ember has a loyal cult following, but it tends to be like a musical act that everyone has heard of, but few people listen to. However, those that do will swear that it’s the best show of all time.

  2016 년에 우리는 Ember에 관해 많은 것을 말하지 않았으며, 그것은 "침목"프레임 워크였으며 계속해서 그렇게 될 것입니다. 이것은 대부분의 경우입니다. 엠버는 충성스러운 숭배를 따르지만, 모든 사람들이 들어 봤지만 듣는 사람은 거의없는 음악적 행동을 하는 경향이 있습니다. 그러나, 그것들은 모든 시간의 최고의 쇼라고 맹세합니다.

  We predicted that Ember would be the popular alternative to React for those consumer-facing applications, but it appears that honor has gone to Vue.

  우리는 Ember가 소비자 대응 응용 프로그램 제작에서 React에 대한 대중적인 대안이 될 것으로 예측했지만 Vue가 이 대안을 대신하는 것 같습니다.

  It should be noted that it is technically possible to use React alongside something like Ember. This is because React only solves part of the full stack JavaScript problem—specifically the view part. That means that it can also be used with Angular, although we typically do not see developers mixing React with another large-ish framework—Flux and Redux notwithstanding.

  React와 Ember를 함께 사용하는 것이 기술적으로 가능하다는 점에 주목해야 합니다. 이것은 React가 전체 스택 JavaScript 문제의 일부, 특히 뷰 부분 만 해결하기 때문입니다. 즉 Angular와 함께 사용할 수도 있지만 일반적으로 React를 다른 Large-ish 프레임 워크 인 Flux 및 Redux와 혼합하는 것을 볼 수는 없습니다.

Ember Predictions for 2017

  We don’t have any predictions for Ember in 2017. Much like jQuery and Backbone, this is a framework that is mature and unapologetic in its implementation. The only prediction one could safely make is that none of this will change.

  2017 년에 Ember에 대한 예측이 없습니다. jQuery 및 Backbone과 매우 유사하게 구현 된이 프레임 워크는 성숙하고 알 수없는 프레임 워크입니다. 안전하게 예측할 수있는 유일한 예측은이 중 어느 것도 변하지 않는다는 것입니다.

Aurelia

  Aurelia made our list last year and we had several predictions for the somewhat niche front-end framework. Aurelia frequently shows up in requests from customers that we talk to, and it shows up more often than any other framework in this whitepaper besides Angular.

  Aurelia는 작년에 우리의 목록을 만들었으며 우리는 다소 틈새 프런트 엔드 프레임 워크에 대한 몇 가지 예측을했습니다. Aurelia는 우리가 이야기하는 고객의 요청에 자주 등장하며 Angular 외에도 이 백서의 다른 프레임 워크보다 더 자주 나타납니다.

  What is it about Aurelia that developers seem to love so much? It could be the fact that it comes from the creator of Caliburn.Micro, which enjoyed massive success inside of the .NET community. It could also be because it relies almost entirely on just plain JavaScript constructs and doesn’t involve a lot of boilerplate. Whatever the reason, Aurelia has won the hearts and minds of some section of developers and deserves a look from anyone looking for their next JavaScript framework.

  개발자들이 그렇게 많이 사랑하는 것 같은 Aurelia에 대해서는 무엇입니까? .NET 커뮤니티 내부에서 큰 성공을 거둔 Caliburn.Micro의 제작자가 나온 것일 수도 있습니다. 거의 모든 JavaScript 구문에 거의 의존하고 많은 상용구가 포함되어 있지 않기 때문일 수도 있습니다. 그 이유가 무엇이든, Aurelia는 개발자 중 일부의 마음과 마음을 얻었으며 다음 자바 스크립트 프레임 워크를 찾는 사람들의 모습을 볼 자격이 있습니다.

  In 2016, we predicted that developers would adopt Aurelia in droves over the course of the year. While Aurelia seemed to hang on to its dedicated core, we did not see strong increase in the interest of Aurelia over 2015. The Google search trends show roughly the same sentiment over 2016.

  2016 년에 개발자는 Aurelia를 올해도 계속 추진할 것으로 예측했습니다. Aurelia가 전용 코어에 매달려있는 것처럼 보였지만 2015 년에는 Aurelia에 대한 관심이 크게 증가하지 않았습니다. Google 검색 트렌드는 대략 2016 년과 거의 같은 관심을 보여줍니다.

  We also predicted that Aurelia might see a native counterpart, such as NativeScript or ReactNative. This also did not turn out to be true, despite Aurelia’s explicit goal to be more than just a web framework.

  우리는 또한 Aurelia가 NativeScript 또는 ReactNative와 같은 네이티브 대응 물을 볼 수 있다고 예측했습니다. Aurelia가 웹 프레임 워크 그 이상을 목표로하고 있음에도 불구하고 이것은 사실이 아닙니다.

  We predicted that large enterprises would begin to adopt Aurelia since it was an officially supported product. This also turned out to be largely incorrect as Angular continues to dominate the enterprise JavaScript spectrum.

  우리는 대기업이 Aurelia를 공식적으로 지원 된 제품으로 채택하기 시작할 것이라고 예측했습니다. 또한 Angular가 계속해서 엔터프라이즈 JavaScript 스펙트럼을 지배함에 따라 크게 잘못된 것으로 판명되었습니다.

  “We’ve always seen Aurelia as a platform and ecosystem for building rich interactive applications on every device. In 2016, you’ll see the next phase of that vision realized as we move beyond Aurelia’s v1 release and on to other things we’re planning,” Rob Eisenberg, Creator of Aurelia

  "우리는 Aurelia를 모든 장치에서 풍부한 대화식 응용 프로그램을 구축하기위한 플랫폼 및 생태계로 항상 보았습니다. 2016 년에, 우리는 Aurelia의 v1 릴리즈를 넘어서 우리가 계획하고있는 다른 것들로 이동할 때 그 비전의 다음 단계를 깨닫게 될 것입니다. "Aurelia의 창조자 Rob Eisenberg

Aurelia Predictions for 2017

  Aurelia is a fascinating alternative to Angular and React, and we’re continually inspired by the work that Rob and his team do on the project. However, the sheer dominance of Angular 2 and React (or Vue) leave little room for anyone else besides niche players. While not much of a prediction, our guess is that this will remain the case for Aurelia in 2016. We also think that it will likely lose developers to Angular 2, which shares some concepts with Aurelia, such as using plain JavaScript classes as the binding context.

  Aurelia는 Angular and React의 매혹적인 대안이며 Rob과 그의 팀이 프로젝트에서 수행하는 작업에 지속적으로 영감을 받았습니다. 그러나 Angular 2와 React (또는 Vue)의 깎아 지른 지배력은 틈새 시장을 제외한 다른 모든 사람들에게 거의 여지가 없습니다. 2016년 예측은 정확하지 않았지만 몇몇 예측은 유효합니다. 또한 개발자는 Aurelia와 개념을 공유하는 Angular 2를 잃을 것으로 생각합니다. 예를 들어 일반 JavaScript 클래스를 바인딩으로 사용하는 것 문맥.

  While not a front-end framework like the rest of the items in this list, Progress® Kendo UI® is a bit of an anomaly. It is first and foremost a UI library of widgets and components. However, the version of Kendo UI based on jQuery does contain portions of full stack framework features, such as two-way binding, routing and view management. This qualifies it for inclusion in the whitepaper. Aside from that, Progress makes it so we know a little about its future.

  이 목록의 나머지 항목과 같은 프론트 엔드 프레임 워크는 아니지만 Progress® Kendo UI®는 약간의 예외입니다. 무엇보다도 위젯과 컴포넌트의 UI 라이브러리입니다. 그러나 jQuery 기반의 Kendo UI 버전에는 양방향 바인딩, 라우팅 및보기 관리와 같은 전체 스택 프레임 워크 기능이 포함되어 있습니다. 이는 백서에 포함시킬 수있는 자격이 있습니다. 그 외에도 진행 상황을 통해 우리는 미래에 대해 조금 알 수 있습니다.

Kendo UI

  In 2016, Progress launched Kendo UI for Angular 2 Beta, which was a complete rewrite of Kendo UI to use Angular 2 as the underlying framework for DOM manipulation, binding, routing and the like. This enables Kendo UI to leverage all the advantages of Angular 2, such as:

 • Binding speed • Ahead-of-time compilation • Dependency management

  2016 년 Progress는 Angular 2 Beta 용 Kendo UI를 출시했습니다.이 SDK는 Angular 2를 DOM 조작, 바인딩, 라우팅 등의 기본 프레임 워크로 사용하기 위해 Kendo UI를 완전히 다시 작성한 것입니다. 이를 통해 Kendo UI는 Angular 2의 모든 장점을 활용할 수 있습니다

Kendo UI Predictions for 2017

  To be fair, Progress makes Kendo UI so we know a bit about where it’s going. To that end, expect a full release of Kendo UI for Angular 2—which includes all the widgets in the Kendo UI portfolio—by May of 2017.

  공정성을 기하기 위해 Progress는 Kendo UI를 만들어 어디로 갈 것인지에 대해 조금 알 수 있습니다. 이를 위해 2017 년 5 월까지 Kendo UI 포트폴리오의 모든 위젯을 포함하는 Angular 2 용 Kendo UI의 정식 버전을 기대하십시오.

  Progress will also continue to work on Kendo UI for jQuery in 2017, as the company doesn’t see jQuery going anywhere and it’s still the most popular way for customers to build their applications.

  2017 년 jQuery의 Kendo UI도 계속 진행될 예정입니다. jQuery는 어디에서나 사용할 수 있으며 고객이 응용 프로그램을 개발할 수있는 가장 보편적 인 방법이기 때문입니다.

  In addition to the UI framework itself, Progress will release Kendo UI Builder, which is a visual tool for designing user interfaces composed of Kendo UI components. While currently limited to OpenEdge data sources, a mature Kendo UI Builder would connect to any data source to enable easy drag-and-drop composition and configuration of user interfaces with real-time visual feedback.

  Progress는 UI 프레임 워크 외에도 Kendo UI 구성 요소로 구성된 사용자 인터페이스를 디자인하기위한 시각적 도구 인 Kendo UI Builder를 출시 할 예정입니다. 현재 OpenEdge 데이터 소스로 제한되어 있지만 성숙한 Kendo UI Builder는 실시간 시각적 피드백을 통해 사용자 인터페이스의 손쉬운 드래그 앤 드롭 구성 및 구성을 가능하게하기 위해 모든 데이터 소스에 연결합니다.

Web Components / Polymer

  We’d like to close out our section on frameworks by discussing what may be the most important technology that the web community has yet to adopt: Web Components. We’ve lumped Polymer in here as well because it is Google’s polyfill library for Web Components which are largely unusable cross-browser without it.

  우리는 웹 커뮤니티가 아직 채택하지 않은 가장 중요한 기술이 무엇인지 논의함으로써 프레임 워크에 대한 섹션을 닫고 싶습니다. Web Components. Polymer는 웹 컴포넌트를위한 Google의 polyfill 라이브러리이기 때문에 여기에 Polymer를 포함 시켰습니다.이 라이브러리는 브라우저 없이는 사용할 수없는 크로스 브라우저입니다.

  Web Components are a standard for the way that developers build and deploy components for web applications. These are typically thought of as visual components, or rather custom HTML elements, but they can also include processes that occur in the background, such as AJAX. Web Components are so critical because they are the only thing that will be able to curtail the Cambrian explosion of JavaScript libraries, all of which may implement components in a different way and are usually only usable with a specific JavaScript framework.

  웹 구성 요소는 개발자가 웹 응용 프로그램 용 구성 요소를 만들고 배포하는 방식의 표준입니다. 이들은 일반적으로 시각적 구성 요소 또는 사용자 정의 HTML 요소로 간주되지만 AJAX와 같이 백그라운드에서 발생하는 프로세스도 포함 할 수 있습니다. 자바 스크립트 라이브러리를 축소 할 수있는 유일한 방법이기 때문에 웹 구성 요소는 매우 중요합니다. 이러한 구성 요소는 다른 방식으로 구성 요소를 구현할 수 있으며 일반적으로 특정 JavaScript 프레임 워크에서만 사용할 수 있습니다.

  Unfortunately, React inadvertently put the brakes on Web Components by creating a simple and elegant component model that worked across all browsers without polyfills or hacks. The rapid adoption of React meant that developers’ interest in Web Components was negated by their frenzy for React, which offered a similar yet much slimmer solution. It also highlighted that web components in their current state are still not meeting developers where their needs are.

  불행히도 React는 실수로 모든 브라우저에서 작동하는 간단하고 우아한 구성 요소 모델을 만들어 폴리곤이나 해킹없이 브레이크를 웹 구성 요소에 적용합니다. React가 신속하게 채택됨에 따라 Web Components에 대한 개발자의 관심은 React에 대한 열정으로 무위가되었습니다. React는 비슷하지만 훨씬 더 슬림 한 솔루션을 제공했습니다. 또한 현재 상태의 웹 구성 요소가 여전히 필요로하는 개발자를 만나지 않는다는 점을 강조했습니다.

  In 2016, we predicted that all major web browsers would support Web Components by the year’s end. This is simply not the case. The following chart shows the state of browser support for Web Components as of the time of this writing.

  2016 년에 우리는 모든 주요 웹 브라우저가 연말까지 웹 구성 요소를 지원할 것으로 예측했습니다. 이것은 단순히 사실이 아닙니다. 다음 차트는이 글을 쓰는 시점에서 Web Components에 대한 브라우저 지원 상태를 보여줍니다.

  Basically, Chrome is still the only browser that fully supports Web Components. Firefox has put HTML imports on hold and Custom Elements and Shadow DOM are still behind flags. Safari has remained annoyingly silent on HTML Imports, but in a surprising pivot decided to ship an implementation of Shadow DOM. While Edge appears to be the holdout, they have announced intent to ship support for HTML Template elements. They have not, however, fully committed to Web Components, citing that they will instead ship support for features as they become stable pieces of the Web Components Standard.

  기본적으로 Chrome은 여전히 웹 구성 요소를 완벽하게 지원하는 유일한 브라우저입니다. Firefox는 HTML 가져 오기를 보류하고 Custom Elements와 Shadow DOM은 여전히 플래그 뒤에 있습니다. 사파리는 HTML Imports에 대해 침묵을 지키고 있지만, 놀랍게도 Shadow DOM을 구현하기로 결정했습니다. Edge는 홀드 아웃 인 것처럼 보이지만 HTML 템플릿 요소에 대한 지원을 제공하겠다는 의사를 발표했습니다. 그러나 웹 구성 요소 표준의 안정적인 부분이 될 때 기능에 대한 지원을 대신 제공 할 것이라는 점에서 그들은 웹 구성 요소에 완전히 전념하지 않았습니다.

  “Following template support, and after completing the DOM rewrite, the next goal is to implement Shadow DOM, the second-hardest feature to polyfill, followed by Custom Elements. We plan to evaluate the rest of the first generation of Web Component specs after that. Naturally, as the specs continue to evolve and additional web component-related technologies rise in importance we may shuffle priorities along the way.” Travis Leithead and Arron Eicholz – Microsoft Edge and Web Components

  "템플릿 지원과 DOM 재 작성을 마친 다음 목표는 Polyfill에서 두 번째로 강력한 기능인 Shadow DOM을 구현 한 다음 Custom Elements를 구현하는 것입니다. 우리는 그 후 나머지 Web Component 사양을 평가할 계획입니다. 당연히 사양이 계속 발전하고 웹 구성 요소 관련 기술이 중요 해지면 우선 순위가 뒤섞 일 수 있습니다. "Travis Leithead와 Arron Eicholz - Microsoft Edge 및 Web Components

  We also predicted that JavaScript frameworks would begin to swap out their own component implementations in favor of Web Components. Given that Web Components aren’t fully baked, this has not happened.

  우리는 또한 JavaScript 프레임 워크가 웹 구성 요소를 위해 자신의 구성 요소 구현을 교체하기 시작할 것이라고 예측했습니다. 웹 구성 요소가 완전히 구워지지 않았기 때문에 이것이 발생하지 않았습니다.

  However, Angular 2 was designed from the beginning to support Web Components. They even ship their own Shadow DOM emulation. In other words, when Web Components are ready, only Angular 2 is specifically designed to use them. This is another reason that we are building many of our own components on Angular 2s infrastructure, so that when Web Components are ready, our own leap won’t be nearly as far.

  그러나 Angular 2는 처음부터 웹 구성 요소를 지원하도록 설계되었습니다. 심지어는 자신의 Shadow DOM 에뮬레이션을 제공합니다. 즉, 웹 구성 요소가 준비되면 Angular 2 만 사용하도록 특별히 설계되었습니다. 이것이 앵귤러 2s 인프라에서 많은 구성 요소를 구축하는 또 다른 이유이므로 웹 구성 요소가 준비되면 우리의 도약은 거의 멀지 않습니다.

JavaScript in 2017—Beyond the Browser

  As the technology world has evolved, JavaScript has evolved with it. In previous years, that meant JavaScript’s inclusion in software worlds it was never originally intended for, like server-side apps, mobile apps and robots. And today, JavaScript’s growth has brought the language to chatbots, virtual reality, IoT and a whole lot more.

  기술 세계가 진화함에 따라 JavaScript가 발전했습니다. 예전에는 자바 스크립트가 서버 측 앱, 모바일 앱, 로봇과 같이 처음에는 의도하지 않았던 소프트웨어 세계에 포함되었습니다. 그리고 오늘날 자바 스크립트의 성장으로 채팅 로봇, 가상 현실, IoT 등의 언어로 그 언어가 옮겨졌습니다.

  In addition to reaching new frontiers, JavaScript’s role has become more established and stable in ecosystems in which it has long been a part of, such as server-side Node.js apps, as well as mobile and desktop application frameworks. In this whitepaper, we’ll look back at some predictions we made a year ago for JavaScript in each of these software worlds, and then make some predictions about where JavaScript is heading outside of a browser in 2017. Let’s start by looking how JavaScript is doing in server-side app development.

  새로운 국경에 도달하는 것 외에도, 자바 스크립트의 역할은 모바일 및 데스크톱 애플리케이션 프레임 워크뿐 아니라 서버 측 Node.js 애플리케이션과 같이 오랫동안 지속 되어온 생태계에서보다 확고하고 안정적으로되었습니다. 이 백서에서는 각각의 소프트웨어 세계에서 자바 스크립트에 대한 몇 가지 예언을 살펴본 다음 2017 년에 자바 스크립트가 브라우저 외부로 향하는 것을 예측합니다. 서버 측 응용 프로그램 개발에서.

Node.js

  Node.js is an open-source runtime library for building both server-side apps, as well as small bits of JavaScript code you need to run outside of a browser environment. In the past few, years Node went from a niche technology popular in startups, to a mainstream development approach used by companies of all sizes.

  Node.js는 브라우저 환경 외부에서 실행해야하는 작은 JavaScript 코드뿐만 아니라 서버 측 응용 프로그램을 작성하기위한 오픈 소스 런타임 라이브러리입니다. 지난 몇 년 동안 노드는 신생 기업에서 인기있는 틈새 시장 기술에서 모든 규모의 기업에서 사용하는 주류 개발 접근 방식으로 발전했습니다.

  Node’s package manager, npm, has transformed from hosting utility modules for server-side apps to the canonical place to store distributable JavaScript code. Perhaps the best indication of Node’s rise is the sheer number of packages stored on npm. In last year’s predictions, we included the following chart to show npm’s dominance over package managers in alternative languages.

  노드의 패키지 관리자 인 npm은 배포 가능한 JavaScript 코드를 저장하기 위해 서버 측 응용 프로그램 용 유틸리티 모듈을 표준 위치로 변환했습니다. 아마도 노드의 상승을 나타내는 가장 좋은 지표는 npm에 저장된 패키지의 수입니다. 작년의 예측에서, npm이 다른 언어로 된 패키지 관리자보다 우위를 보이기 위해 다음 차트를 포함했습니다.

  Fast forward one year and npm’s growth shows no signs of slowing down. In fact, npm’s move from ~200,000 to ~350,000 packages has forced the Module Counts site to reconfigure its chart’s Y axis.

  빠른 1 년 및 npm의 성장은 둔화 조짐을 보이지 않습니다. 실제로 npm이 ~ 200,000 개에서 ~ 350,000 개 패키지로 이동하면 Module Counts 사이트가 차트의 Y 축을 다시 구성하게됩니다.

  There are a number of factors that have led to this increase, and one of them is a growing number of enterprise companies using Node in their infrastructure. In last year’s discussion, we made the following prediction.

  이 증가로 이어지는 요인에는 여러 가지가 있으며, 그 중 하나는 인프라에서 노드를 사용하는 엔터프라이즈 기업의 수가 증가하고 있습니다. 작년의 토론에서 우리는 다음과 같은 예측을했습니다.

  “In 2016 expect to see further adoption of Node and its package manager npm. The continued adoption of Node from large companies—Microsoft, IBM, Intel, Progress, etc.—as well as enterprise-friendly features such as long-term support plans, may signal a growth in Node adoption in the enterprise, replacing typical enterprise solutions like .NET and Java.”

  "2016 년에는 Node와 패키지 관리자 인 npm의 추가 채택을 기대합니다. Microsoft, IBM, Intel, Progress 등 대기업의 Node를 장기간 지원 계획과 같은 기업 친화적 기능과 함께 계속 채택하면 일반적인 엔터프라이즈 솔루션 대신 엔터프라이즈에서 노드 채택이 늘어날 수 있습니다. 닷넷과 자바와 같이. "

  This wasn’t exactly a risky or unique prediction given Node’s growth, but it seems to have been accurate. Node’s own case study page has a small list of not-very-small companies that have now adopted Node, including the likes of Netflix, GoDaddy and Capital One.

  이것은 노드의 성장을 감안할 때 위험하거나 독특한 예측은 아니지만 정확한 것으로 보입니다. 노드의 자체 사례 연구 페이지에는 현재 Netflix, GoDaddy 및 Capital One을 비롯하여 Node를 채택한 아주 작은 회사 목록이 있습니다.

  But perhaps the most telling sign of Node’s use in critical infrastructure comes from the first company listed on that page—NASA. You can read Node’s case study on NASA for yourself, but I’ll drop in an excerpt here just to give you an idea.

  그러나 중요한 인프라에서 Node가 사용하는 가장 중요한 징후는 NASA라는 해당 페이지에 처음으로 나와있는 회사에서 온 것입니다. NASA에서 NASA의 사례 연구를 직접 읽을 수는 있지만 아이디어를 얻기 위해 여기에서 발췌 할 것입니다.

  

  “When you’ve got the safety of astronauts on the line, little hiccups and service interruptions turn into lifeand-death situations. From EVA [extra vehicular activity] data to astronauts up in space, Node.js helps ensure there’s a safe home for everything and everyone.”

  "우주 비행사의 안전을 확보하면 작은 딸꾹질과 서비스 중단으로 인해 생명과 죽음의 상황이 생깁니다. 우주에서 EVA [추가 차량 활동] 데이터부터 우주 비행사까지 Node.js는 모든 사람과 모든 사람에게 안전한 집이 있음을 보장합니다. "

  But it’s not just the NASAs of the world driving Node’s growth. Node’s package manager, npm, has become the de facto choice to store JavaScript code across all environments—and that consolidation on a single package manager helps drive adoption of Node itself.

  그러나 Node의 성장을 주도하는 것은 NASA만이 아닙니다. 노드의 패키지 관리자 인 npm은 모든 환경에 JavaScript 코드를 저장하는 사실상의 선택이되었으며, 단일 패키지 관리자에서의 통합은 노드 자체의 채택을 촉진합니다.

  Literally every framework and technology we discuss in this article use npm to store and distribute their source code. A quick npm search for “jquery”, “polymer”,”react”, “cordova”, or “nativescript” can give you an idea of the sheer scale that npm operates at now. As JavaScript grows in popularity, npm grows in popularity. And as npm grows in popularity, so does Node.js. And there’s no reason to believe that this trend will end anytime soon.

  말 그대로이 기사에서 다루는 모든 프레임 워크와 기술은 소스 코드를 저장하고 배포하기 위해 npm을 사용합니다. "jquery", "polymer", "react", "cordova"또는 "nativescript"를 npm으로 빠르게 검색하면 npm이 현재 작동하는 완전한 규모를 알 수 있습니다. 자바 스크립트의 인기가 증가함에 따라 npm이 인기를 얻고 있습니다. 그리고 npm이 인기를 얻으면서 Node.js도 증가합니다. 그리고 이러한 추세가 조만간 끝날 것이라고 믿을만한 이유가 없습니다.

  Searching for “angular” on npmjs.com returns nearly 10,000 results. Angular is one of many libraries that is distributed via npm.

  npmjs.com에서 "각"을 검색하면 거의 10,000 개의 결과가 반환됩니다. Angular는 npm을 통해 배포되는 많은 라이브러리 중 하나입니다.

  In 2017, we believe more companies will make the switch to Node from more traditional development approaches like Java and C#. We believe TypeScript, a Microsoft-written superset of JavaScript will help drive Node’s growth, as its features make JavaScript a more approachable language for Java and C# developers. Node’s commitment to long-term support releases will also contribute to this growth, as it gives these companies a guarantee that the version they use will be supported in years to come.

  2017 년에는 더 많은 회사가 Java 및 C #과 같은 전통적인 개발 방식에서 Node로 전환 할 것으로 예상됩니다. Microsoft의 서체 인 JavaScript는 TypeScript를 사용하여 Java 및 C # 개발자가 JavaScript를보다 익숙한 언어로 사용할 수있게 해주므로 JavaScript가 Node의 성장을 촉진하는 데 도움이됩니다. 장기 지원 릴리스에 대한 노드의 약속은 이러한 회사가 사용하는 버전이 앞으로 지원 될 것이라는 보증을 제공하기 때문에 이러한 성장에 기여할 것입니다.

  Overall, large enterprises do not like maintaining multiple development systems and language, and Node enables these companies to consolidate on a single language for all of their development. And that consolidation applies to more than just server-side code. Let’s take an updated look at how JavaScript is affecting the mobile world as well.

  전반적으로 대기업은 여러 개발 시스템 및 언어를 유지 관리하는 것을 좋아하지 않으며 노드는이 회사가 모든 개발 과정에서 단일 언어로 통합 할 수있게합니다. 그리고 이러한 통합은 서버 측 코드 그 이상에 적용됩니다. 자바 스크립트가 어떻게 모바일 세계에 영향을 주는지에 대해 자세히 살펴 보겠습니다.

PhoneGap and Cordova

  PhoneGap and Cordova, the open-source framework on which PhoneGap is built, were JavaScript’s first foray into the world of native mobile development. Cordova’s basic approach is to wrap web code in a WebView, and then use that WebView to drive a native mobile application. This approach enables web developers to build mobile apps with skills that they already have—namely JavaScript—and because of that, Cordova has remained a compelling option for building mobile apps for many years.

  PhoneGap과 Cordova는 PhoneGap이 구현 된 오픈 소스 프레임 워크로, 자바 스크립트가 처음으로 모바일 개발 세계에 진입했습니다. Cordova의 기본 접근 방식은 WebView에서 웹 코드를 래핑 한 다음 해당 WebView를 사용하여 기본 모바일 응용 프로그램을 구동하는 것입니다. 이 방법을 사용하면 웹 개발자는 이미 보유하고있는 기술 즉 자바 스크립트를 사용하여 모바일 앱을 제작할 수 있으며, 그로 인해 Cordova는 수년 동안 모바일 앱을 구축 할 수있는 강력한 옵션으로 남아있었습니다.

  But that’s starting to change. Today, Cordova is being challenged by alternative development approaches, most of which leverage the same JavaScript-based skill set that Cordova development is known for.

  그러나 그것은 변화하기 시작하고 있습니다. 오늘날 코르도바는 대안 개발 접근법에 도전을 받고 있으며, 대부분은 코르도바 개발로 알려진 동일한 자바 스크립트 기반 기술을 활용합니다.

  Perhaps Cordova’s biggest challenger is the Google-led concept of Progressive Web Apps, or PWAs.

  아마도 코르도바의 가장 큰 도전자는 Google이 주도하는 Progressive Web Apps 또는 PWAs 개념입니다.

  PWAs bring many native-like features to the web world, such as push notifications, offline access, and home screen icons. Last year, we predicted that Google would start pushing the PWA approach a little. That prediction has turned out to be, well, wrong—as Google has made it clear that the company is heavily committed to the PWA approach through a number of events. The recent Chrome Developer Summit featured a staggering number of talks on PWAs, as did this year’s Google I/O conference.

  PWA는 푸시 알림, 오프라인 액세스 및 홈 스크린 아이콘과 같은 많은 기본 기능을 웹 환경에 제공합니다. 작년에 Google은 PWA 방식을 약간 추진하기 시작할 것이라고 예측했습니다. 그 예측은 잘 못된 것으로 밝혀졌습니다. 구글이 수많은 사건을 통해 PWA 접근법에 크게 전념하고 있음을 분명히했기 때문입니다. 최근 Chrome 개발자 정상 회의에서는 올해의 Google I / O 컨퍼런스와 마찬가지로 PWA에 대한 엄청난 회담이있었습니다.

  PWAs are relevant for our discussion because they eat into the primary use case of Cordova apps—web apps that need a bit of native functionality. If you have a web app that needs offline access or push notifications, building a PWA is a compelling alternative to building a Cordova-based native app. Although it’s hard to gauge how many people are choosing PWAs over hybrid apps, most data shows that Cordova usage has flatlined or is declining. For instance, here are Cordova’s weekly download numbers for the last two years. As you can see, although Cordova’s numbers are still very healthy, the trend line is no longer heading upwards as it was this time last year.

  PWA는 푸시 알림, 오프라인 액세스 및 홈 스크린 아이콘과 같은 많은 기본 기능을 웹 환경에 제공합니다. 작년에 Google은 PWA 방식을 약간 추진하기 시작할 것이라고 예측했습니다. 그 예측은 잘 못된 것으로 밝혀졌습니다. 구글이 수많은 사건을 통해 PWA 접근법에 크게 전념하고 있음을 분명히했기 때문입니다. 최근 Chrome 개발자 정상 회의에서는 올해의 Google I / O 컨퍼런스와 마찬가지로 PWA에 대한 엄청난 회담이있었습니다.

  But there’s another factor playing into this decline. Although we believe PWA usage is eating into Cordova’s usage, we also believe a relatively new entry in the mobile world is taking market share from Cordova as well.

  그러나 이러한 감소에 또 다른 요인이 있습니다. PWA의 사용이 Cordova의 사용을 먹고 있다고 생각하지만, 모바일 세계에서 비교적 새로운 진입이 Cordova의 시장 점유율을 차지하고 있다고 믿습니다.

Native Mobile Apps

  Pioneered by Appcelerator, the concept of a JavaScript-driven native app was popularized by a few new entries in the space—namely, Facebook’s React Native and Progress’s NativeScript. JavaScript-driven native apps do not use a WebView, therefore, they don’t suffer the same web-based performance problems that can plague Cordova-based applications.

  Appcelerator가 개척 한 JavaScript 기반 네이티브 앱의 개념은 공간의 몇 가지 새로운 항목, 즉 Facebook의 React Native 및 Progress의 NativeScript에 의해 대중화되었습니다. 자바 스크립트 기반 네이티브 응용 프로그램은 WebView를 사용하지 않으므로 Cordova 기반 응용 프로그램과 동일한 웹 기반 성능 문제가 발생하지 않습니다.

  In last year’s discussion we predicted that 2016 would be a year where these frameworks matured and started to see widespread usage, and that prediction appears to have been accurate. For example, you can see a continuous increase in React Native’s weekly download numbers over the last two years.

  작년의 토론에서 우리는 2016 년이 프레임 워크가 성숙 해지고 널리 보급되기 시작한 해일 것이라고 예측했습니다. 그 예측은 정확했던 것 같습니다. 예를 들어, 지난 2 년간 React Native의 주간 다운로드 수가 지속적으로 증가한 것을 볼 수 있습니다.

  And it’s not just download numbers that are up for these JavaScript-driven native frameworks. The recent State of JavaScript 2016 survey shows that JavaScript developers have a lot of interest in React Native, as well as burgeoning interest in NativeScript.

  그리고 이러한 자바 스크립트 기반 네이티브 프레임 워크의 숫자를 다운로드하는 것만이 아닙니다. 최근 JavaScript 2016 설문 조사에 따르면 자바 스크립트 개발자는 NativeScript에 대한 관심뿐만 아니라 React Native에 많은 관심을 가지고 있습니다.

  The analysis of the State of JavaScript survey sums up these results quite well.

  JavaScript 조사 상태를 분석하면 이러한 결과가 매우 잘 정리됩니다.

  “Cordova and PhoneGap (which are basically the same thing) have much lower interest ratings, and it makes you wonder if people are turned off by the performance issues you sometimes hear about. With Cordova and PhoneGap, you rely on the underlying phone browser and its JavaScript engine to do the heavy lifting, which is often slower than running native code like React Native.”

  "Cordova와 PhoneGap (기본적으로 똑같은)은  관심을 훨씬 덜 가지고 있습니다. 성능문제로 해당 기술을 사용하지 않는지 궁금할 것입니다. Cordova와 PhoneGap을 사용하면 기본 폰 브라우저와 JavaScript 엔진을 사용하여 무거운 짐을 덜어 낼 수 있습니다. 이 작업은 종종 React Native와 같은 기본 코드를 실행하는 것보다 느립니다. "

  

  In 2017, we expect the growth of these JavaScriptdriven native frameworks to accelerate, as more and more JavaScript developers look to build mobile apps. React Native stands to gain from the continued enormous usage of the React framework, and NativeScript—which announced complete Angular 2 support in May—stands to gain from the growing number of developers upgrading from Angular 1 to Angular 2. We also expect JavaScript-driven native frameworks to attract native iOS and Android developers, as JavaScript-driven native frameworks allow you to build truly native apps from a single codebase—not two.

  2017 년에는 더 많은 자바 스크립트 개발자가 모바일 앱을 개발하려고함에 따라 이러한 자바 스크립트 기반 네이티브 프레임 워크의 성장이 가속화 될 것으로 예상됩니다. React 네이티브는 React 프레임 워크의 지속적인 사용으로 얻을 수 있으며 NativeScript는 5 월에 완전한 Angular 2를 지원한다고 발표했습니다. Angular 1에서 Angular 2로 업그레이드하는 개발자가 증가하고 있습니다. JavaScript 기반 네이티브 iOS 및 안드로이드 개발자를 유치 할 수있는 네이티브 프레임 워크를 제공합니다. 자바 스크립트 기반 네이티브 프레임 워크를 사용하면 하나의 코드베이스에서 진정으로 기본 응용 프로그램을 만들 수 있습니다.

  On mobile JavaScript is increasingly encroaching on territory that was once dominated by languages like Objective-C and Java. But that’s not the only new territory where JavaScript is gaining usage; let’s move our discussion to the topic of desktop applications.

  모바일에서는 JavaScript가 기존에 Objective-C 및 Java와 같은 언어에 의해 지배 된 영역에서 점점 더 영향력을 키우고 있습니다. 재밌게도 모바일만이 자바스크립트가 사용되는 유일한 새로운 영역은 아닙니다. 토론을 데스크톱 응용 프로그램 주제로 이동해 봅시다.

Desktop Apps

  Traditionally, if you wanted to build a Windows or Mac app, you’d use platform-specific tools (like WPF and Windows Forms) or cross-platform interfaces (like Java or Adobe Air). But, like every other software ecosystem discussed in this whitepaper, JavaScript-based solutions are slowly working their way into this picture.

  전통적으로 Windows 또는 Mac 응용 프로그램을 만들려면 WPF 및 Windows Forms와 같은 플랫폼 관련 도구 또는 Java 또는 Adobe Air 같은 교차 플랫폼 인터페이스를 사용합니다. 그러나이 백서에서 논의 된 다른 모든 소프트웨어 생태계와 마찬가지로 JavaScript 기반 솔루션도 천천히이 그림으로 나아갑니다.

  In last year’s discussion, we talked about NW.js and GitHub’s Electron, the two most popular JavaScript frameworks for building desktop apps, and theorized that each of their usage would increase dramatically in 2016. In reality, that growth has occurred—but only for Electron, which has established itself as the de facto choice for JavaScript-based desktop application development.

  작년의 토론에서 우리는 데스크탑 애플리케이션을 개발하는 데 가장 널리 사용되는 JavaScript 프레임 워크 인 NW.js와 GitHub의 Electron에 대해 이야기하고 2016 년에는 사용량이 크게 증가 할 것이라고 이론화했습니다. Electron는 JavaScript 기반 데스크톱 응용 프로그램 개발을위한 사실상의 선택으로 자리 매김했습니다.

  For example, if you compare npm downloads for the “electon” and “nw” JavaScript packages, you’ll see that Electron (the red line) is now operating at a scale that competes with the likes of React Native, while NW.js downloads are relatively flat.

  예를 들어 "electon"및 "nw"JavaScript 패키지에 대한 npm 다운로드를 비교하면 Electron (빨간색 선)가 React Native와 경쟁하는 척도로 작동하고 NW.js 다운로드는 비교적 평평합니다.

  In December of 2015, Electron had 20,000 GitHub stars and NW.js had 25,000; today, Elecron has nearly 40,000 stars while NW.js has just over 30,000.

  2015 년 12 월, 일렉트론에는 20,000 개의 별이 있었고 NW.js는 2 만 5,000 개였습니다. 지금은 Elecron은 거의 40,000 개의 별을 가지고있는 반면 NW.js는 30,000 개가 넘습니다.

  Electron has also started to gain traction for mainstream desktop apps. The framework now powers the Visual Studio Code, the popular editor from Microsoft that boasted over half a million users back in April. Electron has also managed to perform the rare act of gaining popularity in both the React and Angular communities, and it’s easy to find tutorials for Electron usage with both frameworks on the web.

  일렉트론은 주류 데스크톱 응용 프로그램에 대한 관심도 끌기 시작했습니다. 이 프레임 워크는 이제 4 월에 50 만 명이 넘는 사용자를 자랑하는 Microsoft의 유명한 편집자 인 Visual Studio Code에 도움이됩니다. Electron는 또한 React와 Angular 커뮤니티 모두에서 인기를 얻는 드문 행동을 수행했으며, 웹에서 두 프레임 워크를 사용하여 전자 사용을위한 자습서를 쉽게 찾을 수 있습니다.

  In 2017 we expect Electron’s dominance to continue. We expect to see further Electron tooling integration with the web’s most popular frameworks—mostly React and Angular—as well as increased attention from software vendors. And as JavaScript continues to break into worlds traditionally dominated by Java- and Microsoft-based technologies, we expect Electon to continue to be used as an alternative to approaches such as WPF, Java, Adobe Air.

  2017 년에 우리는 Electron의 우위가 계속 될 것으로 기대합니다. React와 Angular를 비롯한 웹의 가장 널리 사용되는 프레임 워크와 전자 툴링의 통합은 물론 소프트웨어 공급 업체의 관심이 높아질 것으로 기대합니다. 그리고 JavaScript가 Java 및 Microsoft 기반 기술이 전통적으로 우세한 세계로 계속 침투하면서 Electon이 WPF, Java, Adobe Air와 같은 접근 방식의 대안으로 계속 사용될 것으로 기대합니다.

  The appeal of using a single language for all your development needs is strong, and it’s even taking JavaScript to some of the hippest and newest development approaches out there. Let’s end our discussion with a look at JavaScript in a handful of brave new software worlds.

  모든 개발 요구 사항에 단일 언어를 사용하는 것에 대한 호소력이 강하며, 가장 인기있는 최신 개발 접근법에 JavaScript를 사용하고 있습니다. 몇 가지 훌륭한 새로운 소프트웨어 세계에서 JavaScript를 살펴보고 토론을 끝내자.

JavaScript’s New Frontiers

  If you ask analysts about what’s coming in the development world, you’ll likely hear a lot buzzwords like virtual reality, chatbots and IoT.

  애널리스트들에게 개발 세계에 대한 정보를 묻는다면, 가상 현실, 채팅 봇, IoT와 같은 많은 유행어를 듣게 될 것입니다.

  Of all of these new technologies JavaScript is biggest in the chatbot ecosystem, where people are using JavaScript to build everything from simple Slack bots to far more complex bots used for tasks like commerce transactions. Most frameworks in the chatbot world include Node libraries in their SDKs, such as Botkit, Microsoft’s Bot Framework, and Facebook’s wit.ai. Microsoft’s Bot Framework’s documentation includes the following quote on why you should build bots with Node.

  이러한 새로운 기술들 중 JavaScript는 사람들이 자바 스크립트를 사용하여 간단한 슬랙 봇에서 상거래와 같은 작업에 사용되는 훨씬 복잡한 봇까지 모든 것을 구축하는 봇봇 생태계에서 가장 큰 것입니다. chatbot 세계의 대부분의 프레임 워크에는 SDK의 Node 라이브러리 (예 : Botkit, Microsoft의 Bot Framework 및 Facebook의 wit.ai)가 포함됩니다. Microsoft의 Bot Framework 문서에는 Node로 봇을 빌드해야하는 이유에 대한 다음의 인용문이 포함되어 있습니다.

  “Bot Builder for Node.js is a powerful framework for constructing bots that can handle both freeform interactions and more guided ones where the possibilities are explicitly shown to the user. It is easy to use and models frameworks like Express & Restify to provide developers with a familiar way to write Bots.”

  "Node.js의 Bot Builder는 자유형 상호 작용과 가능성이 사용자에게 명시 적으로 표시되는 유도 된 것들 모두를 처리 할 수있는 봇을 구성하기위한 강력한 프레임 워크입니다. 사용하기 쉽고 Express & Restify와 같은 프레임 워크를 사용하여 개발자에게 친숙한 봇 작성 방법을 제공합니다. "

  The same desire to reuse JavaScript skills has led many popular IoT libraries such as Losant and zetta to offer Node APIs, as well devices such as the Leap Motion. There’s also nascent interest in using JavaScript in virtual reality environments, led by the Google Chrome team as well as the A-Frame framework.

  자바 스크립트 기술을 재사용하고자하는 욕구와 마찬가지로 Losant 및 zetta와 같은 인기있는 IoT 라이브러리는 Leap Motion과 같은 노드 API를 제공합니다. 또한 가상 현실 환경에서 자바 스크립트를 사용하는 데 관심이 집중되고 있으며 Google 크롬 팀과 A 프레임 프레임 워크가 주도하고 있습니다.

  That being said, JavaScript is still a niche player in many of these fields, with more performant players such as C++, Python, and C# retaining a dominant role. For example, the popular Oculus Rift device largely uses C++, and Microsoft’s HoloLens requires you to write in C#.

  즉, 자바 스크립트는 여전히 C ++, Python, C #과 같은보다 능동적 인 플레이어가 지배적 인 역할을 유지하면서 이러한 분야의 틈새 시장 플레이어입니다. 예를 들어 인기있는 Oculus Rift 장치는 주로 C ++을 사용하고 Microsoft의 HoloLens는 C #으로 작성해야합니다.

  We expect this trend to begin to change in 2017. As JavaScript gains in popularity, and as JavaScript’s speed continues to increase, the language will continue to find inroads into environments like VR and the IoT. And as new software development ecosystems pop up we expect JavaScript to increasingly be included as a first-class citizen.

  우리는이 경향이 2017 년에 변하기 시작할 것으로 기대합니다. JavaScript가 인기를 얻고 JavaScript의 속도가 계속 증가함에 따라 언어는 VR 및 IoT와 같은 환경으로 계속 침투 할 것입니다. 새로운 소프트웨어 개발 생태계가 등장하면서 자바 스크립트가 점점 더 일류 시민으로 포함될 것으로 기대합니다.

JavaScript For All The Things

  Ten years ago, using JavaScript on the server was unthinkable. Today Node has 3.5 million users and an annual growth rate of 100%. Five years ago, using JavaScript to drive a native iOS or Android app was a niche; today NativeScript and React Native are growing at staggering rates. Three years ago using JavaScript to build desktop apps was rare; today Electon is downloaded over 100,00 times each month.

  10 년 전, 서버에서 JavaScript를 사용하는 것은 상상할 수 없었습니다. 현재 Node는 350 만 명의 사용자를 보유하고 있으며 연간 성장률은 100 %입니다. 5 년 전, 자바 스크립트를 사용하여 기본 iOS 또는 Android 앱을 구동하는 것이 틈새였습니다. 오늘날 NativeScript와 React Native는 엄청난 속도로 증가하고 있습니다. 3 년 전 자바 스크립트를 사용하여 데스크톱 앱을 제작하는 사례는 거의 없었습니다. 오늘 Electon은 매월 100,00 번 이상 다운로드됩니다.

  JavaScript will never be used for all programming, as many other languages are better suited to solve certain problems and use cases. However, JavaScript’s widespread usage ensures that it will always be a factor, regardless of the development platform. Perhaps Jeff Atwood’s famous quote on the topic is the best way to wrap up this discussion, as his statement has never seemed more prophetic.

  자바 스크립트는 모든 프로그래밍에 사용되지 않으며, 다른 많은 언어가 특정 문제 및 사용 사례를 해결하는 데 더 적합합니다. 그러나 JavaScript가 널리 사용되면 개발 플랫폼에 관계없이 항상 중요한 요소가됩니다. 아마도 제프 앳 우드 (Jeff Atwood)의 주제에 대한 유명한 인용문은 그의 성명서가 예언 적이 된 적이 결코 없기 때문에이 토론을 끝내는 가장 좋은 방법 일 것입니다.

  “[A]ny application that can be written in JavaScript, will eventually be written in JavaScript.” Jeff Atwood

  "JavaScript로 작성할 수있는 모든 응용 프로그램은 결국 JavaScript로 작성됩니다."Jeff Atwood