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 задает интереснейшие вопросы однозначно выходящие за рамки тривиальных, т.к. они ближе к философским. Ваша странная язвительность не понятна, т.к. хорошо заданный вопрос ведет к новым ответам, а иногда и к новым открытиям.
Здравствуйте, Aquilaware, Вы писали:
A>Ваша странная язвительность не понятна
То, что вы приняли за "странную язвительность" является сильным (мягко говоря) удивлением от способности человека усваивать большое количество разнообразной информации.
A>т.к. хорошо заданный вопрос ведет к новым ответам, а иногда и к новым открытиям.
Могли бы вы привести примеры оного (желательно из топиков, инициированных Shmj)?
Здравствуйте, Shmj, Вы писали:
S>Какое мнение вам ближе и почему?
Я знаю только два хорошо сделанных фреймворка с "резиновой" версткой для UI — HTML/CSS и QT. Заменять не на что. Canvas — это, конечно, хорошо, но кто напишет библиотеку компонентов? Простейшее поле ввода совсем не простейшее, если задуматься, сколько для него нужно функционала.
Здравствуйте, so5team, Вы писали:
S>Могли бы вы привести примеры оного (желательно из топиков, инициированных Shmj)?
Например, обсуждение в вопросе про GraphQL. Люди пообщались и участники дискуссии познали несколько интересных моментов использования, которые до этого могли даже не всплывать на радаре.
ЭФ>> Очень жаль, что HTML не смог упаковаться в XML νsb> О чём речь?
О цитате из википедии:
Развитие XHTML остановлено; новые версии XHTML не выпускаются; рекомендуется[кем?] использовать HTML
Если что-то мёртвое, то учить его не надо.
Пользуясь случаем, я ещё хотел бы сказать, что Markdown крут тем, что подходит для любого естественного языка (там всё символами сделано) и только то, что он не поддерживается браузерами напрямую не нравится в нём мне.
И с таблицами в нём сложно, к HTML-ным уже привык, а в markdown — нет.
S>Неожиданно. Тот факт, что у вас находится время для собственных проектов вызывает удивление и искреннее уважение.
А что не так с наличием времени? Или есть мысль, что создание тем на рсдн его опустошает?
S>А вы свои проекты в OpenSource публикуете или исключительно для себя делаете?
Мне кажется, качество таких проектов будет такого же уровня, как и задаваемые вопросы.
МР>В пользу того, что в целом XAML это не только для UI можно привести примеры использования XAML в MsBuild (для описания правил разметки самого MsBuild), в WorkflowFoundation (насчет 4 версии не знаю, а в 3 и 3.5 для сериализации использовался XAML).
scf>Я знаю только два хорошо сделанных фреймворка с "резиновой" версткой для UI — HTML/CSS и QT. Заменять не на что. Canvas — это, конечно, хорошо, но кто напишет библиотеку компонентов? Простейшее поле ввода совсем не простейшее, если задуматься, сколько для него нужно функционала.
Вообще-то, в Qt реализованы оба подхода: и через системные компоненты, и через рисование. По сути, аналогично HTML vs Canvas, поэтому если в Qt это осилили, то осилят рендеринг компонентов и через канвас. Поэтому, оба подхода так и будут жить дальше, пока не придумают что-то ещё — тогда будет три подхода (xkcd standards).
Здравствуйте, flаt, Вы писали:
F>В msbuild точно XAML или просто XML?
Нет-нет, файлы проекта в MSBuild это обычный XML, тут всё верно.
Я про внутренний механизм MSBuild, так называемые XamlRules, которые описывают какие Items могут быть добавлены в тот или иной файл проекта и какие у них метаданные (а местами даже правила их вычисления/хранения).
Например, rules, которые идут в базовой поставке MSBuild можно посмотреть тут https://github.com/dotnet/msbuild/tree/main/src/Tasks/XamlRules.
Наверное, правильнее было бы говорить, что эти правила — все же часть Common Project System (CPS) — системы поддержки проектов в Visual Studio, а не часть MSBuild.
Честно говоря, я даже не до конца уверен, что эти правила как-то используются в MSBuild, но некий код их поддержки там-таки имеется.
Однако, единственное описание, как с этими Rules работать, я нашел только в привязке к CSP, вот тут.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Но я считаю, что обязательно нужен ещё один формат, ЭФ>с тегами из русских слов на кириллическом алфавите.
ЭФ>Без этого тексты HTML-документов сложно включать в документацию, ЭФ>ведь официальные документы должны быть написаны на государственном языке.
Можно же сделать русские тэги Web_Components
но кто будет поддерживать? и самое главное кто захочет использовать? заставлять?
Смотрел на ютубе Стрим по ЯОС, такое себе. Заменили PROCEDURE на проц.
Половина программистов начнет сразу упираться. У каждого свой вкус.
Здравствуйте, Эйнсток Файр, Вы писали:
νsb>>Какие-то конкретные претензии кроме цитат из википедии есть?
ЭФ>https://wiki.c2.com/?XhtmlIsDead
Да шо ты какими-то кривыми ссылками кидаешься. Ты по-существу скажи. Какие проблемы ты наблюдаешь с XHTML? Я вот писал XHTML-страницы, используя современные HTML5 теги. Проблем никаких нет. Хром парсит строго.
Единственный, кто может убить XHTML это хром. Если он объявит, что больше не будет его строго парсить. Я таких объявлений не видел.
При этом я, конечно, согласен, что штука мягко говоря нишевая. Про неё мало кто слышал, а из тех, кто слышал, ещё меньше знают, что оно до сих пор работает.
Здравствуйте, flаt, Вы писали:
S>>Неожиданно. Тот факт, что у вас находится время для собственных проектов вызывает удивление и искреннее уважение.
F>А что не так с наличием времени? Или есть мысль, что создание тем на рсдн его опустошает?
Если вдумчиво читать то, что в темах пишут, и так же вдумчиво писать ответы, то время улетает только в путь. Проверено.
S>>А вы свои проекты в OpenSource публикуете или исключительно для себя делаете?
F>Мне кажется, качество таких проектов будет такого же уровня, как и задаваемые вопросы.
Вот и хотелось бы один раз увидеть, чем 100 раз предполагать.