OpenSilver и возвращение Silverlight

Как реализация Silverlight с открытым исходным кодом нацелена на использование веб-сборки для конкуренции с Blazor и современными платформами JavaScript

OpenSilver недавно заявил о своем присутствии и объявил, что Silverlight, как и дискотека, на самом деле не мертв и по-прежнему актуален, чем когда-либо - albiet в довольно измененной форме.

Как бывший разработчик Silverlight и специалист по XAML, позвольте мне рассказать вам, что такое Silverlight, чем отличается OpenSilver, и мой первоначальный взгляд на то, имеет ли это значение (и для кого это может иметь значение).

XAML и основа Silverlight

Если вы похожи на многих новых разработчиков, с которыми я общаюсь, возможно, вы не знакомы с Silverlight или даже с XAML, поэтому позвольте мне подготовить почву для вас.

Еще в 2006 году Microsoft выпустила .NET Framework 3.0, включая новую настольную технологию под названием Windows Presentation Foundation (WPF). WPF был (и остается) чрезвычайно мощным способом создания и настройки пользовательских интерфейсов рабочего стола. Он решал многие проблемы с Windows Forms и был нацелен на создание технологии пользовательского интерфейса, основанной на так называемом XAML.

XAML означает расширяемый язык разметки приложений и был способом создания пользовательского интерфейса в формате, не зависящем от инструментов, на основе расширенного набора XML, чтобы дизайнеры могли работать с XAML в одном инструменте, а разработчики - в другом.

WPF стал хитом, и его технологии позволили получить потрясающий опыт разработки, который продолжается и сегодня, когда WPF поддерживается в .NET Core. Многие другие технологии приняли XAML для своих пользовательских интерфейсов, включая Silverlight, Windows Phone, универсальную платформу Windows (UWP), Xamarin, Uno и, возможно, некоторые другие, о которых я сейчас забыл.

Взлет и падение Silverlight

Silverlight возник как способ использовать широкие возможности приложений WPF и применить их к приложениям, размещенным внутри браузера.

В то время, когда фреймворки JavaScript находились в зачаточном состоянии, ASP .NET переходил с WebForms на MVC / Razor, и не было отличного решения для веб-приложений, которые должны были бы выполнять большую часть клиентской логики.

Вместо этого браузеры полагались на плагины, такие как Flash и Silverlight, чтобы предоставить конечным пользователям эти широкие возможности. Это полагалось на отдельные браузеры для поддержки плагинов и продолжения их поддержки.

К сожалению, плагины представляют собой уязвимости безопасности и замедляют работу конечных пользователей, поэтому браузеры, начиная с Chrome, прекратили поддержку плагинов.

После объявления о том, что браузеры больше не будут поддерживать плагины, Silverlight стал очень дорогостоящим вложением для организаций, которые разрабатывали приложения в этой структуре, поскольку теперь у них был фиксированный момент времени, когда они больше не запускались для конечных пользователей.

Это фактически остановило будущую разработку Silverlight и заставило сообщества, зависящие от плагинов, такие как Flash и Silverlight, искать что-то новое.

Рост одностраничных приложений

Урок, извлеченный из кончины Silverlight, заключался в том, что нельзя полагаться на возможности, не присущие установленным веб-стандартам. Это означало, что если вам нужно было сделать что-то творческое на уровне клиента, вам нужно было сделать это в JavaScript.

Этот внезапный бум приложений, которые необходимо было переписать на JavaScript, подлил топливо на ранние JavaScript-фреймворки и, по сути, положил начало гонке вооружений между Angular, React, Vue и другими, поскольку веб-разработчики искали лучшие фреймворки для адаптации своего существующего кода и лучшие способы создания новых приложений.

Примечание автора. Я перешел с Silverlight на Angular, и мне он понравился. React хорошо работает от людей, пришедших из кодовой базы MVC, но Angular хорошо подходит для архитектур MVVM.

Веб-сборка и Blazor

Веб-стандарты росли и становились зрелыми, и у нас действительно был - ах - стабильный набор установленных функций JavaScript, с которыми было неудобно работать, когда появился ECMAScript 6.

С развитием веб-стандартов пришло время Web Assembly и новый дикий запад развития, который все еще находится в начальной стадии своего развития.

Веб-сборка - это, по сути, язык ассемблера для вашего браузера, который позволяет эффективно выполнять веб-разработку на стороне клиента с использованием технологий отличных от JavaScript.

Обещание Web Assembly аналогично обещанию Silverlight: если вы не хотите работать с JavaScript, вам и не нужно.

Одним из первых претендентов на арену веб-сборок была технология Microsoft Blazor, цель которой - запускать сборки .NET в браузере пользователя. Эта технология только что достигла ранних стадий зрелости и принятия, и это интересное место для разработчиков .NET.

В отличие от Silverlight, Blazor построен на установленных веб-стандартах и ​​также ориентирован на использование синтаксиса стиля MVC / Razor вместо XAML.

OpenSilver и возвращение Silverlight

Вчера команда OpenSilver анонсировала OpenSilver и способ запуска Silverlight в современных браузерах.

Чем он отличается от Silverlight?

Чтобы было ясно: это не Silverlight. Фактически, это повторная реализация Silverlight, которая для достижения своих целей использует веб-сборку вместо подключаемых модулей браузера.

Это означает, что OpenSilver соответствует установленным веб-стандартам и будет работать с поддерживающими их браузерами. По сути, OpenSilver, похоже, делает то же самое, что и Blazor, с Web Assembly и Mono.

Silverlight также значительно более зрелый, чем OpenSilver, по очевидным причинам, учитывая недавнее открытие OpenSilver. В OpenSilver заметно не хватает предварительной компиляции, значительной настройки и дополнительных исправлений, хотя они должны появиться со временем в течение оставшейся части 2020 года и в будущем.

Чем он отличается от Blazor?

Ну, во-первых, он использует XAML вместо синтаксиса Razor для своих представлений. Это означает, что если у вас есть большой опыт работы с XAML или вы инвестируете в код XAML из приложений Desktop, Xamarin или мертвых Silverlight, вы сможете гораздо проще запустить эти приложения в OpenSilver, чем если бы вы выполняли перезапись в Blazor или полный перенос на фреймворк JavaScript.

Менее позитивно то, что Blazor опирается на всю мощь и мощь Microsoft, а OpenSilver - нет. Это означает, что не гарантируется тот же уровень поддержки и обработки инструментов, который получают другие диалекты XAML и других технологий .NET. Это не означает злонамеренного намерения, просто это потенциально менее важно.

Имеет ли это значение?

Итак, OpenSilver - это не Silverlight, но позволяет делать с XAML те же действия, что и с Silverlight. У него нет такой же слабости надстройки, как у Silverlight, и он все еще улучшается. Но какое это имеет значение?

Ответ на этот вопрос такой же, как и на любую новую технологию: все зависит от обстоятельств.

Если у вас есть .NET-магазин со значительными навыками или вложением кода в XAML, это абсолютно важно.

Если вы - команда, которой удобнее работать с MVC / Blazor или существующими фреймворками одностраничных приложений, то OpenSilver имеет для вас значительно меньшее значение.

Поскольку OpenSilver все еще созревает, и с отсутствующими частями, такими как предварительная компиляция, вы не сможете писать производственный код с OpenSilver в ближайшее время. Однако этот ранний этап внедрения не означает, что вам не следует смотреть и рассматривать OpenSilver.

Полезные ссылки для начала:

Возможность писать код в одном месте, который работает на многих платформах, - это приз, которого мы все искали на протяжении десятилетий с момента изобретения Интернета. OpenSilver - последний соперник на этой арене, и он не последний, но его обязательно стоит посмотреть.

Первоначально опубликовано на https://killalldefects.com 11 марта 2020 г.