Silverlight로가는 길 : Silverlight를 선택하지 않겠습니까?

2010 년 말부터 Silverlight의 임박한 죽음에 대한 많은 목소리가있었습니다. 그런 다음 점점 더 많은 사실에 따르면 Microsoft는 실제로 Silverlight를 점차 포기하고 있음을 보여주었습니다. 근본적인 이유는 대략 HTML5의 압력을 느끼기 때문입니다. 직접적인 이유는 플래시 경쟁에서 많은 승리를 거두지 않았기 때문입니다.

iPhone의 인기로 인해 Jobs는 모든 브라우저 플러그인이 "악"이라고 자신있게 발표 했으므로 iOS 브라우저는 Flash 및 Silverlight를 포함한 모든 플러그인을 거부했습니다. 그런 다음 Win8의 Metro-I가 실제로 설계된 작업과 같고 플러그인을 지원하지 않으면 안경이 부러 졌다고 여전히 믿을 수 없었습니다. Microsoft가 자신감이 많고 독립적 인 이유는 무엇입니까?

모든 제품은 도구입니다. 나는 Silverlight의 디자이너가 아니며 특별한 감정이 없습니다. 더 나은 기술을 대체 할 수있는 기술이 있다면 훌륭합니다. 나는 신제품을 지원하기 위해 최초의 사람이 될 것입니다. 그러나 문제는 HTML5가 실제로 Silverlight를 대체 할 수 있습니까?

Silverlight는 C# (또는 vb.net) 언어로 개발 된 뚱뚱한 클라이언트입니다. 이 계보는 선천적으로 개발 프로세스를 결정합니다. 프로그램 구조는 Windows 응용 프로그램의 구조와 정확히 동일해야합니다. 사실, 그것은 한 걸음 더 나아갑니다. WPF의 Silverlight에 의해 상속 된 계보는 MVVM이 매우 이상적입니다. 이 완전한 제품 세트는 .NET 프레임 워크, MVVM을 기반으로 한 강력한 생태 체인, 조직 모델로서, 개발 언어로서 높은 수준의 언어를 구성합니다. Silverlight는 클라이언트와 서버의 개발 기술을 통합하고 다른 브라우저 간의 간격을 채 웁니다.

그 이상. Silverlight는 SOA 작업 모델에서 특히 유용합니다. WCF와의 깊은 통합은 강력하고 서비스 지향적 인 웹 프로그램을 개발하는 것이 간단하고 우아합니다.

HTML5는 어떻습니까? 그래픽 처리 기능을 향상시키고 스트리밍 기능을 추가하며 다른 실제 기능을 추가합니다. 그러나 이것은 여전히 ​​RIA와는 거리가 멀다. 소프트웨어 엔지니어링, 성능 및 개발 효율성에는 쓸모가 없습니다.

우선, 언어와 구조의 관점에서, 높은 수준의 언어, 강력한 타이핑 및 객체 지향의 장점은 불필요한 설명이 필요하지 않습니다. 지난 수십 년 동안 소프트웨어의 역사는 철의 증거였으며, 탁월한 설계 패턴은 소프트웨어의 가독성, 유지 관리, 보안 및 유연성에 더욱 중요합니다. 이와 관련하여 기본적으로 추가 "증거"가 필요하지 않습니다. 프로그래밍을 배운 모든 사람은 디자인 패턴의 중요성과 역할을 알아야합니다.

HTML5는 "HTML 자체"가 아닙니다. 실제로, 사람들이 거의 무시하는 JavaScript라는 주인공이 있습니다. HTML5의 멋진 전망과 크로스 플랫폼 기능에 대해 이야기하는 모든 곳에서는 거의 JavaScript의 이름을 언급하지 않았습니다. 그러나 실제로 HTML의 다양한 동적 기능과 동작은 전적으로 JS에 의해 구현되어야합니다. 웹 애플리케이션 솔루션으로서 HTML5는 실제로 "HTML5 및 JavaScript"솔루션이라고해야합니다.

실제로, 당신이 그것에 대해 더 신중하게 생각한다면, 당신은 사람들이 의도적으로 무대 뒤에 숨겨져있는 JavaScript가 실수 1 위의 주인공이며, HTML5는 실제로 지원하는 역할 일뿐입니다.

얼마 전, Microsoft는 HTML5와 함께 구현되었다고 주장하는 "Cutting Rope"라는 게임을 보여주었습니다. 게임은 실제로 놀랍습니다. 그러나 웹 개발에서 일하는 사람은이 게임의 구현에서 HTML5가 JavaScript가 얼마를 계정하는지에 대해 즉시 알아야합니까? 기능 코드는 어떤 언어입니까? 대답은 매우 간단하고 명확합니다. 이 게임이 HTML5를 표시하는 데 사용된다고 말하는 대신 JavaScript를 표시하는 것이 낫다고 생각합니다.

게임과 관련하여 최근 몇 년 동안 중국에서 인기있는 웹 버전의 온라인 게임에 익숙해야합니다. 강력한 기능은 JS에 의해 완전히 실현됩니다. 내가 생각하면 마비를 느끼게합니다. 가능한지 여부에 관계없이, 그것이 할 수 있더라도, 이것이 프로그래밍 역사의 주요 회귀라고 생각하지 않습니까? ---- 수년간의 개발 후, 고급 언어는 스크립팅 언어로 대체 되었습니까?

사실, 게임은 그 예일뿐입니다. 웹 애플리케이션이 점점 더 대중화됨에 따라 사람들은 더 강력하고 섬세하며 고급 성능 및 더 복잡한 클라이언트 응용 프로그램이 필요하며, 이는 모두 더 큰 프로그래밍 척도를 의미합니다. "HTML5 솔루션"의 경우 실제로 모든 사용자 기대는 JavaScript를 통해 구현되어야하며 대규모 응용 프로그램의 경우 수백만 행의 코드 라인을 의미 할 수 있습니다. ----이 척도의 프로그래밍에서 JS는 강력한 C#과 비슷합니까?

그것은 단지 아닙니다.

예를 들어, 회사의 프로젝트 인 웹 응용 프로그램은 로컬 영역 네트워크에 중점을두고 인터넷의 한계를 고려하지 않습니다. ---- 이것은 실제로 많은 웹 애플리케이션에 대한 사용 시나리오입니다. LAN에서 Silverlight와 같은 클라이언트 플러그인은 매우 고성능 통신 (이진 데이터 스트림) 및 데이터 처리를 달성 할 수 있습니다. 이것은 일반 텍스트 해석을 기반으로 한 HTML5 계보에 대한 장벽입니다. 그 성능은 플러그인보다 결코 높을 수 없습니다.

커뮤니케이션 성능 외에도 동적 효과 성능도 있습니다. Silverlight는 하드웨어 가속도를 직접 사용할 수 있지만 HTML5는 브라우저에 의존하므로 통신 성능과 마찬가지로 Silverlight보다 낮고 가능성이 높지 않습니다.

개발 효율성 (시간 비용)이 있습니까? .NET를 기반으로 한 Silverlight는 Visual Studio의 강력한 기능을 완전히 사용할 수 있습니다. 개발자는 종종 이것과 Windows 프로그램 개발의 차이를 느끼지 않습니다. .NET 프레임 워크는 많은 기성품 기능, 풍부한 컨트롤, 친숙한 프로그래밍 경험 및 강력한 디버깅 지원을 캡슐화합니다.

우리는 또한 JS의 개발에 익숙합니다. VS는 거대한 .NET 프레임 워크 및 성숙 .NET 런타임 및 디버거와 비교하여 수년에 걸쳐 JS에 대한 지원을 지속적으로 강화해 왔지만 스크립팅 언어 일뿐입니다. 마우스가 아무리 지방이 있더라도 코끼리보다 무겁지 않습니다. 이것은 기본적인 상식입니다.

위의 실질적인 문제를 제쳐두고 HTML5는 어디에 있습니까?

우선, HTML에는 브라우저 지원이 필요합니다. HTML5 자체는 표준 일 뿐이며 구현은 브라우저에 따라 다릅니다. 여러 가지 이유로 각 브라우저에는 항상 고유 한 "성격"이 있습니다. HTML4는 표준이 없지만, 앞에있는 사실은 브라우저 제조업체 가이 표준을 어떻게 처리 할 것인지 완전히 입증되었습니다. HTML5의 시대 가이 문제를 완전히 해결할 수 있음을 증명할 이유가 없습니다.

둘째, 여전히 HTML5 브라우저를 지원하는 소수만이 있습니다. 모든 오래된 브라우저를 제거하는 것은 여전히 ​​먼 길입니다. 또한 5 년 또는 10 년 안에 시장은 다양한 버전의 브라우저로 채워질 것이며 각 브라우저는 다소 다를 것으로 예측할 수 있습니다. 또한 Microsoft의 IE9가 얼마나 오래 출시 되었습니까? IE10이 출시되었습니다. IE10과 IE9는 모두 HTML5를 지원하는 브라우저이지만 많은 가시적 인 차이가 있습니다. 여전히 생생한 브라우저 중에서 Microsoft만으로도 IE6에서 IE10까지 5 가지 제품이 있습니다.

셋째, 강력한 웹 애플리케이션을 구축하려면 기본 기술의 성숙도가 필요할뿐만 아니라 많은 클래스 라이브러리가 필요합니다. HTML5 자체는 충분히 성숙하지 않으며 HTML5 (JS)를 기반으로 한 복잡한 웹 응용 프로그램을 구축하면 충분한 설득 및 클래스 라이브러리 지원이 부족합니다. 미래의 브라우저가 실제로 Silverlight 또는 Flash와 같은 JS를 설명 할 수 있다면 개인적으로 불가능하다고 생각하는 것은 물론 매우 긴 프로세스가 될 것입니다.

HTML5의 미숙 성과 비교하여 Silverlight는 당신 앞에 완제품입니다. 10 년에서 20 년 후에 무슨 일이 일어날 지 걱정됩니다. 그것은 내가 가득 차서 할 일이 없기 때문입니다.

글쎄, 나는 10 년에서 20 년 후에 일어날 일에 대해 걱정한다고해서 반드시 당신이 가득 차서 할 일이 없다는 것을 의미하지는 않습니다. 그런 다음 미래를 살펴 보겠습니다.

Win8은 실제로 Win7+Metro와 같습니다. 즉, Win7과 뒤로 호환되는 데스크탑 모드를 제쳐두고 메트로 모드는 실제 Win8입니다.

그러나 메트로는 무엇입니까? 메트로 모드는 창, WPF 및 심지어 .NET을 포기합니다. 그렇게 큰 가격으로 실제로 모바일 운영 체제를 복제합니다. 외관이 완전히 innovinative 일뿐 만 아니라 Windows 애플리케이션 스토어는 Apple에 대한 사랑을 직접 표현합니다. 메트로 아이의 비정상적인 디자인을 고려하면 ... 나는 일자리의지도하에 Win8이 개발되었는지 의심의 여지가 있습니다.

지하철 모드가 약간 상쾌 해 보이지만 개인용 컴퓨터는 게임 콘솔이 아닙니다. 더 많은 사람들이 컴퓨터를 사용하여 일하거나 사무실과 비슷한 일을해야합니다. 그들이 더 많이 사용할수록 창문이없는 메트로 모드를 갖는 것이 얼마나 고통 스러운지 더 많이 알게됩니다. 사람들이 동시에 둘 이상의 응용 프로그램을 사용하는 것이 일반적입니다. 또한 모니터의 크기가 계속 증가하기 때문에 모니터는 실제로 매년 더 많은 정보를 표시 할 수 있지만 Metro는 사용자에게 다음과 같이 말합니다. 아니요, 모든 화면을 사용하여 하나의 응용 프로그램 만 표시 할 수 있습니다. 영화를 보면서 QQ와 채팅하고 싶습니까? 친애하는, 그것은 허용되지 않습니다 ...

컴퓨터는 휴대 전화가 아닙니다. Win8의 디자이너는 그런 단순한 진실을 이해하지 못했습니다. Win8의 지하철은 아무 소용이 없다고 말할 수는 없지만 실제로 사용이 매우 제한적입니다.

따라서 Windows의 미래 개발 방향은 분명히 둔한 지하철이 아니라 고전적인 창 모드가 될 것입니다.

이것을 이해하면 미래는 플러그인을 비활성화하지 않을 것이라고 믿을 수 있습니다. Metro가 여전히 Win9의 변형 괴물처럼 운영 체제에서 기생충이라도 폭풍을 일으키지 않습니다. 데스크탑 기반 Win7 모드는 킹이며 브라우저가 플러그인을 비활성화하지 않는 한 Silverlight 또는 Flash의 가용성에 대해서는 의심의 여지가 없습니다. 아마도 Microsoft는 Silverlight 6을 다시 출시하지 않을 것입니다. Silverlight는 10 년 후에 일어날 일에 대해 최소 10 년 안에 여전히 잘 작동 할 것입니다 ... 실제로 대부분의 코드는 그렇게 오래 지속되지 않을 것입니다.

"수비학의 조상을 잊어 버리십시오"라는 오래된 중국인이 있습니다. 웹 응용 프로그램의 경우 기술의 천재가 수비학의 조상을 잊고 있다고 생각합니다. 그들은 크로스 플랫폼에 대해 맹목적으로 환상적이지만 어떤 컴퓨터 기술이 사용되는지 잊어 버리나요?

컴퓨터는 도구이며 전체 개발 기록은 사용자에게만 서비스를 제공하는 것입니다. 사용자에게 더 나은 경험을 제공하는 기술은 귀중하고 오래된 기술을 물리 칠 수 있습니다. 웹의 미래를 낮은 수준, 유형이없고 제어하기 어렵고 저 성능 자바 스크립트 (HTML은 기본적으로 정적 컨텐츠를 제시하는 데 사용되며, 정적보다는 동적에 초점을 맞추기 위해서는 웹 애플리케이션이 어리석은 아이디어입니다. Jobs가 모든 플러그인이 "악"이라고 자랑스럽게 주장했을 때, 나는 그의 철학 ( "사전")이 의미가 있다는 데 동의했지만,이 사전을 세면서 그의 "조상"을 잊어 버렸습니다. (응용 프로그램은 사용자에게 서비스를 제공해야합니다)

기술은 인력을 절약 할 수 있기 때문에 사용자의 요구를 억제 할 수 없으며, 더 많은 사용자 컴퓨터 리소스를 불필요하게 소비해야합니다. 반대로, 성능을 향상시키고, 리소스를 저장하고, 더 나은 결과를 얻을 수 있다면, 얼마나 많은 노력을 기울이든,이를 수행해야합니다.

실제로 JS+HTML이 달성 할 수없는 많은 기능이 있으며 JS+HTML은 보안이 매우 열악합니다. (온라인 쇼핑의 보안을 누가 보장 할 수 있습니까?) 플러그인을 비활성화하는 것은 불가능합니다. 사용자에게 더 강력하고 안전한 웹 환경의 필요성에 대해 생각해보십시오. 플러그인은 제한 될 수 있지만 금지 될 수는 없습니다. (일부 지저분한 플러그인은 정말로 성가 시지만 가시가 있기 때문에 물고기를 먹는 것이 금지되어 있습니까? 질식으로 인해 식사를 포기하는 것은 항상 바보입니다)

Flash는 매우 훌륭하고 강력한 웹 플러그인이지만 Microsoft의 생태계에는 이상적이지 않으므로 실제로 Silverlight 대신 Flash를 사용하는 것은 비현실적입니다. Microsoft의 기술을 완전히 포기하거나 Silverlight는 전용입니다.

사실, 저는 개인적으로 웹의 미래가 여러 클라이언트의 SOA 모드를 기반으로해야한다고 생각합니다. 기능은 서비스에 의해 구현되며 UI는 가장 적절한 기술을 사용하여 다른 플랫폼에서 구현됩니다. 크로스 플랫폼을 맹목적으로 추구하는 것은 불합리합니다. 휴대 전화의 화면은 디스플레이 및 작동 모드 화면이 컴퓨터의 화면과는 달라야합니다.

이 주제는 약간 나빴지 만 여전히 언급해야합니다. 실제로 Silverlight6이라고 할 수있는 Win8 Metro App의 새로운 개발 방법은 여전히 ​​XAML을 사용하며 Silverlight와 같은 "제한된 .NET 프레임 워크"와 프로그래밍 프레임 워크와 유사하게 사용합니다. 일부 실버 라이트 프로그램은 라인을 변경하지 않고도 Win8 앱으로 직접 컴파일 할 수도 있습니다.

나는 Win8과 Metrol 앱에 대해 낙관적이지는 않지만 XAML과 MVVM은 영원히 지속될 것이라고 생각합니다. WPF는 죽지 않을 것이며 Silverlight에서 사용하는 기술은 죽지 않을 것입니다.

어떤 의미에서, Silverlight5가 실제로 마지막 버전이더라도 Silverlight가 이름을 바꾸었고 새로운 기술로 다시 태어났다는 것을 고려할 수 있습니다.

Microsoft는 Silverlight의 개발을 중단했지만 Microsoft는 Silverlight 프로젝트가 포기 될 것이라고 명시 적으로 발표하지 않았습니다. 이것은 매우 흥미로운 현상입니다. Microsoft의 현재 규정은 "언급 할 수 없습니다". Microsoft가 실제로 포기하기로 결심했다면 왜 타조 인 척하기 위해 "언급 할 수 없다"고해야합니까?

Microsoft도보고 있다고 생각합니다. 그들은 브라우저 플러그인에 실제로 전망이 없을 지 지켜보고 있습니다. Flash를 포함한 다른 플러그인이 앞으로 천천히 죽어 가면 Microsoft가 자연스럽게 Silverlight를 포기합니다. 반대로, 브라우저 플러그인이 매우 편안한 것으로 판명되고 죽음의 징후가 없다면 언제든지 Silverlight 프로젝트를 다시 시작하고 Silverlight6을 시작할 수 있습니다.

따라서 Silverlight의 환생과 재생이 고려되지 않더라도 Silverlight 제품 자체 (그리고이 이름)조차도 앞으로 부활 될 것입니다.

따라서 Microsoft의 하늘 아래에 사는 웹 개발자에게는 Silverlight를 선택하면 더 강력하고 우아하게 더 강력한 기능을 달성 할 수 있습니다. Silverlight를 선택하지 않는 이유는 무엇입니까?