1. Помереть не может, т.к. простой язык разметки диктуется жизненной необходимостью и заменять его чем-то типа XAML бессмысленно, ибо разница в удобстве не существенная, зато к HTML все уже привыкли и он учитывает потребности десятилетий практики.
2. Наличие Canvas и WebAssembly — это потенциальный крест на HTML-легаси, в котором нет никакого смысла в скором времени он отправится на свалку. Будущее верстки в отображении через Canvas на более вменяемом языке типа XAML.
Из 20 топиков, которые сейчас находятся вверху раздела "Компьютерные священные войны" 9 созданы вами. Кроме этой здесь есть еще:
Что заставит вас перейти на другой ЯП/платформу?
IT-батл — доцент МГУ vs студент Rust-офил
Кроссплатформа — состояние на конец 2022
Пределы LowCode — максимально возможный LowCode
Авто-генерация документации — смысла нет.
[Ref] Почему не смогли применить готовое решение для простой задачи?
Top 10 ЯП- чей холоп
Статья про 1С и вообще про LowCode
Можно ли полюбопытствовать, вынесли ли вы для себя хоть что-нибудь практически значимое из этих тем?
S> Можно ли полюбопытствовать, вынесли ли вы для себя хоть что-нибудь практически значимое из этих тем?
Конечно же да. Услышал мнения разных людей по заданным вопросам, да и просто пообщался.
Вы как бы намекаете, что топикстартер дурачок. Но на самом деле это Вы мразь с такими намёками (это не оскорбление, а констатация).
Выражаясь культурно, товарищей надо подтягивать на свой уровень, а не кичиться своей неповторимостью.
Помереть не может, ибо легаси не даст как минимум. Да и пока никаких признаков того, что собирается помирать, я не вижу.
S>2. Наличие Canvas и WebAssembly — это потенциальный крест на HTML-легаси, в котором нет никакого смысла в скором времени он отправится на свалку. Будущее верстки в отображении через Canvas на более вменяемом языке типа XAML.
Canvas уже много лет существует. WebAssembly ничего нового в браузер не добавил в этом плане. Поэтому сомнительно.
S>Какое мнение вам ближе и почему?
Мне ближе второй вариант (только место canvas — webgpu), но в том, что оно так будет, я совсем не уверен.
Здравствуйте, so5team, Вы писали:
S>Из 20 топиков, которые сейчас находятся вверху раздела "Компьютерные священные войны" 9 созданы вами. S>Можно ли полюбопытствовать, вынесли ли вы для себя хоть что-нибудь практически значимое из этих тем?
Есть предположение, что это студент за пачку дошиков "набрасывает" околоИТшные темы для раскрутки ресурса. Другого объяснения такой широте тем и глупости самих вопросов не вижу.
Здравствуйте, Shmj, Вы писали:
S>1. Помереть не может, т.к. простой язык разметки диктуется жизненной необходимостью и заменять его чем-то типа XAML бессмысленно, ибо разница в удобстве не существенная
Вот уже по этому катастрофически тупому заявлению видно, что чел либо не видел XAML, либо не понимает всей кошмарности HTML.
HTML, если так, по-хорошему, ДАВНО пора закапывать. Но ИТ-отрасль настолько закостенелая и инертная (при этом ещё и молодая!), что закапывание стюардессы запросто может продлиться ещё лет 10!
Мириады хомячков, едва выучившых десяток тегов, так просто из индустрии не схлынут — они будут говноклёпить свои сайтеги пока их не смоет хлоркой! Тут поможет только гигант, который выдвинет новый, адекватный стандарт. Но..... СТАНДАРТ ЧЕГО ИМЕННО?? Вот в чём вопрос!
HTML по своей сути был "чахотошным паблишингом" — болд, италик, картинка... Потом стал косить под "взрослый паблишинг" — шутка ли, у них появилась мера "пункт"! (pt) Появились многоколончатые страницы, слои... Но всё это настолько безобразно втискивалось в старый стандарт, что проще взять старый-добрый Quark и склепать всё в нём, чем мудохаться с браузером, периодически вопрошая "ну а сейчас-то что не так?!". (привет, межбраузерная совместимость!)
А с другой стороны, в сеть полезли HTML-приложения! Появилась надобность в rich формах, контролах, валидации... ко всему этому HTML не был приспособлен вообще. Не говоря о тошнотворном UX/UI этих, мать их, "приложений". Так что "главному стандартизатору будущего" придётся признать, что веб — убогий франкенштэйн и таки отделить жабры от копыт. Приложения — отдельно, паблишинг — отдельно. Пока эту задачу не решат, о светлом будущем паутины можно даже не заикаться.
Здравствуйте, Shmj, Вы писали:
S>>Можно ли полюбопытствовать, вынесли ли вы для себя хоть что-нибудь практически значимое из этих тем?
S>Да. Хотел писать один проект на энтузиазме, но после прочтенного мой энтузиазм иссяк. Т.е. сэкономил несколько месяцев времени.
Неожиданно. Тот факт, что у вас находится время для собственных проектов вызывает удивление и искреннее уважение.
А вы свои проекты в OpenSource публикуете или исключительно для себя делаете?
S>Да. Хотел писать один проект на энтузиазме, но после прочтенного мой энтузиазм иссяк. Т.е. сэкономил несколько месяцев времени.
Мне иногда кажется, что ты — бот для поддержания жизни на форуме.
Это просто нереально стольким всем интересоваться, чтобы иметь что спрашивать.
Однако, спасибо.
Здравствуйте, Буравчик, Вы писали:
Б>Что-то я даже XAML-стандарта не нашел
Стандарта вроде и не оформляли.
Но есть более-менее формальная спецификация https://www.microsoft.com/en-us/download/details.aspx?id=19600.
Б>Чем XAML лучше HTML?
Сложно сказать.
Наверное, будет правильнее сказать, что XAML, это не язык разметки UI, это XML-based язык для сериализации дерева объектов, с некоторыми своими особенностями.
Например (навскидку, что помню):
— синтаксис для свойств допускает указание свойств как атрибутов тэгов и в специальной нотации элементов:
— описан синтаксис для markup extensions в атрибутах
<Button Background="{Binding Path=ColorName}" Width="150" Height="30">
I am bound to be RED!
</Button>
В той же спецификации задаются базовые типы, которые поддерживаются "из коробки", а также правила инстанцирования, того, что записано в виде XAML-документа.
В пользу того, что в целом XAML это не только для UI можно привести примеры использования XAML в MsBuild (для описания правил разметки самого MsBuild), в WorkflowFoundation (насчет 4 версии не знаю, а в 3 и 3.5 для сериализации использовался XAML).
То, что XAML в WPF используется как язык разметки UI, это скорее следствие того, что в WPF так строится представление — в виде дерева контролов (хотя у кого это не так, я вот с ходу и не скажу...). Поэтому он там смотрится вполне органично.
Ну а если вернутся к исходному вопросу — чем лучше?
Если брать изначальный HTML, то вы манипулируете куда более низкоуровневыми понятиями и привязанными к тексту (параграф, список, ... ), тогда как XAML и ему подобные языки оперируют компонентами (Slider, tab, button).
Но, сейчас на HTML так пишут разве что для самых нетребовательных сайтов. Остальные же, там где нужен сложный интерфейс, даже если не используют React/Vue, применяют что-то типа Web Components (не те, которые в стандарте, а что-то из серии — например, у MS это FAST для Fluent UI на "чистом" HTML (да, там идет препроцессинг HTML, поэтому "чистый" я и взял в кавычки, чем это отличает от того же XAML?)
Приведу еще один пример, почему HTML и XAML сложно сравнивать.
Многие указывают на, то что механизм стилизации в XAML просто ужасен по сравнению с CSS. И спорить сложно если смотреть вот на такое:
<Window.Resources>
<!-- .... other resources .... -->
<!--A Style that affects all TextBlocks-->
<Style TargetType="TextBlock">
<Setter Property="HorizontalAlignment" Value="Center" />
<Setter Property="FontFamily" Value="Comic Sans MS"/>
<Setter Property="FontSize" Value="14"/>
</Style>
<!--A Style that extends the previous TextBlock Style with an x:Key of TitleText-->
<Style BasedOn="{StaticResource {x:Type TextBlock}}"
TargetType="TextBlock"
x:Key="TitleText">
<Setter Property="FontSize" Value="26"/>
<Setter Property="Foreground">
<Setter.Value>
<LinearGradientBrush StartPoint="0.5,0" EndPoint="0.5,1">
<LinearGradientBrush.GradientStops>
<GradientStop Offset="0.0" Color="#90DDDD" />
<GradientStop Offset="1.0" Color="#5BFFFF" />
</LinearGradientBrush.GradientStops>
</LinearGradientBrush>
</Setter.Value>
</Setter>
</Style>
</Window.Resources>
В сравнении с чем-то таким (примеры не совсем эквивалентны, но просто мне было лень да и некогда вспоминать WPF и разбираться с CSS):
p {
font-size: 14px;
font-family: Comic Sans MS;
text-align: center;
}
.text_title {
font-size: 26px;
background: linear-gradient(#90DDDD, #5BFFFF);
}
Возражать действительно сложно, но...
Во-первых, если взглянуть на первые части обоих примеров, то получается примерно баш на баш (с точностью до избыточности разметки XML)
Во-вторых, во второй части для Foreground идет очень громоздкое описание градиентной кисти, но, честно говоря, я не вижу почему бы для представления конкретно градиентов нельзя было бы сделать специальный markup extensions. Возможно, сами MS посчитали, что это редкий сценарий и не стали заморачиваться, а из сторонних разработчиков... ну может просто я не нашел.
В-третьих, строго говоря CSS — это не HTML, поэтому теоретически CSS можно было бы попытаться использовать и для WPF благо в той же Avalonia сделали поддержку селекторов в стиле CSS, а всё остальное — это маппинг конкретных свойств в CSS на аналоги в WPF (1-в-1 всё равно не получится, правда). Т.е. скорее всего бы получилось, но опять же никто, похоже, не видит смысла, ведь придется поддерживать еще один язык (а со стилями в том же WPF большая часть разработчиков предпочитает не связываться вообще и использовать стандартные, т.е. нужно будет — единицам).
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Shmj
S>Из 20 топиков, которые сейчас находятся вверху раздела "Компьютерные священные войны" 9 созданы вами. Кроме этой здесь есть еще:
Здравствуйте, so5team, Вы писали:
S>>Да. Хотел писать один проект на энтузиазме, но после прочтенного мой энтузиазм иссяк. Т.е. сэкономил несколько месяцев времени. S>Неожиданно. Тот факт, что у вас находится время для собственных проектов вызывает удивление и искреннее уважение. S>А вы свои проекты в OpenSource публикуете или исключительно для себя делаете?
Какие проекты?! Он хотел написать один проект. Но не написал.
Здравствуйте, Shmj, Вы писали:
S>Какое мнение вам ближе и почему?
Canvas — это нишевый вариант, потому что нужно сильно-сильно париться чтобы сделать layout engine, который бы мог работать на разных DPI, для разных культур, поддерживал бы стили, и т.д. А если кто-то сильно заморочится и таки сделает такой движок — это будет изобретение очень жирного велосипеда на десяток-другой мегабайт кода.
Поэтому тут всё очень просто — готовый язык разметки будет оставаться абсолютным мейнстримом.
Здравствуйте, so5team, Вы писали:
S>Можно ли полюбопытствовать, вынесли ли вы для себя хоть что-нибудь практически значимое из этих тем?
Ув. Shmj задает интереснейшие вопросы однозначно выходящие за рамки тривиальных, т.к. они ближе к философским. Ваша странная язвительность не понятна, т.к. хорошо заданный вопрос ведет к новым ответам, а иногда и к новым открытиям.
Появились многоколончатые страницы, слои... Но всё это настолько безобразно втискивалось в старый стандарт, что проще взять старый-добрый Quark и склепать всё в нём, чем мудохаться с браузером, периодически вопрошая "ну а сейчас-то что не так?!". (привет, межбраузерная совместимость!) 
