.NET und C# ohne Web?
Потому что за ним прямо или косвенно стояли Гугл и Эппл... Поэтому Сильверлайт с удобным сишарпом и Флеш с достаточно удобным экшен скрипт умерли
ну чушь же, умерли потому что были громоздкие, медленные, не масштабируемые от слова "СОВСЕМ", еще и постоянно нужно плагин обновлять, и дыры в безопасности. "экшен скрипт" это вообще обновленная версия жаваскрипта которую забанил МС. Flash, сильвер для веба даже с трудом подходят, это просто костыли, максимум веселую ферму для одноклассников написать. Закладку не поставить, СЕО нулевое, поисковые машины там ничего не индексировали, грузить целиком весь swf. Java алеты бы еще вспомнили, то же ж клевая штука была ) даже с поддержкой 3D, правда заработает все, пока пользователю все мозги не вынести с установкой доп софта. Эти штуки были очень хороши для узкого ряда решений, но в целом для веба не годились.
а корявый джаваскрипт, на котором без тайпскрипт нормально не поразрабатывать, будет жить.
он корявый исключительно в корявых руках, чет за все время, что приходилось писать во фронте, ни разу тайпскрипт не понадобился, и все норм разрабатывается. Живет он потому что родился одновременно с браузером, и для браузера исключительно, и развивается параллельно с ним
инструменты для быстрого создания всяких красивых и интерактивных штук и игр - на джаваскрипт до сих пор ничего подобного нет
здрасти приехали, на жаваскрипте все интерактивности были еще со времен лохматых DHTML, работает на прямую с DOM, делай с ним что хочешь ) красивых интерактивных штук хоть отбавляй, да и большая часть из них вообще на css делается, жаваскрипт уже давно уехал в сторону бизнес логики больше. А если внедрять очередные навороченные инструменты, получатся те же грабли как и Flash - разработчикам различных браузеров, нужно будет все эти инструменты поддерживать. Они то и с css с трудом справляются, чтобы одинокого выглядело во всех браузерах
Поэтому Мозилла с Фаерфоксом подыхает (хотя долго брыкается)
с учетом что мозила есть нетскэйп, в котором и создали жаваскрипт, вряд ли по этому
Теперь попробуйте к этим молекулам через какой-нибудь Ангуляр или Реакт навесить через байндинги кучку свойств, событий, чтобы по кликам всплывали разные окошки
зачем? зачем использовать инструмент который совершенно не подходит к решению задачи, зачем забивать гвозди микроскопом )
Мозилла с Фаерфоксом подыхает
Сомниваюсь, хотя я не фанат файрфокса, из-за того что он медленно работает в Windows-е. У меня кнопочный телефон, там вроде файрфокс 
Эдоуби с экшен скрипт и флеш отправляется на помойку.
Бывшие флешевики до сих пор вспоминают удобные инструменты для быстрого создания всяких красивых и интерактивных штук и игр
О да! Была крутая вещь, жаль что прекращают поддержку, хотя вроде бы Adobe Air и FlashDevelop можно до сих пор скачать и установить. У меня лично до сих пор стоит SwishMax 3 с флэшплеером от версии 4 то 10 помойму.
Дневник тяжелобольного инвалида
Согласитесь, что просто куча мусора вокруг этого всего. Важные вещи я выделил жирным, остальное - в помойку:
Согласитесь, что вы написали кучу мусорного текста вокруг этого всего. Важные вещи я выделил жирным, остальное - в помойку:
Согласитесь, что просто куча мусора вокруг этого всего. Важные вещи я выделил жирным, остальное - в помойку:
Сам по себе формат XML (и, кстати, JSON) в принципе избыточен. Я понимаю, что вы предпочитаете работать с INI, но даже там необходимо отделять разделы и необходим символ '='.
Потому что за ним прямо или косвенно стояли Гугл и Эппл... Поэтому Сильверлайт с удобным сишарпом и Флеш с достаточно удобным экшен скрипт умерлину чушь же, умерли потому что были громоздкие, медленные, не масштабируемые от слова "СОВСЕМ", еще и постоянно нужно плагин обновлять, и дыры в безопасности. "экшен скрипт" это вообще обновленная версия жаваскрипта которую забанил МС. Flash, сильвер для веба даже с трудом подходят, это просто костыли, максимум веселую ферму для одноклассников написать. Закладку не поставить, СЕО нулевое, поисковые машины там ничего не индексировали, грузить целиком весь swf. Java алеты бы еще вспомнили, то же ж клевая штука была ) даже с поддержкой 3D, правда заработает все, пока пользователю все мозги не вынести с установкой доп софта. Эти штуки были очень хороши для узкого ряда решений, но в целом для веба не годились.
Скоро придёт Антихрист! Покайтесь, неверные!
Будущее веба: станет ли рендеринг в <canvas> заменой DOM? / RUVDS.com corporate blog / Habr
Сам по себе формат XML (и, кстати, JSON) в принципе избыточен. Я понимаю, что вы предпочитаете работать с INI, но даже там необходимо отделять разделы и необходим символ '='.
Мозилла с Фаерфоксом подыхаетСомниваюсь
Года полтора-два ему осталось. От силы. Потом либо закроется. либо на Хромиум перейдёт. Опера гораздо круче была, но давно уже сдулась. А Фаерфокс просто сообщество "не таких как все" себе сообразил, но и оно уже рассасывается. Причём не то, чтобы они реально были в передовиках удобства и функциональности, как та же Опера была, а именно чтобы просто "не такие как все".
YAML
Ну во-первых, YAML тоже избыточен :)
Во-вторых, никаких особенных преимуществ по сравнению с XML я тут не вижу:
bindings: - {ircEvent: PRIVMSG, method: newUri, regexp: '^http://.*'} - {ircEvent: PRIVMSG, method: deleteUri, regexp: '^delete.*'} - {ircEvent: PRIVMSG, method: randomUri, regexp: '^random.*'}
и в XML:
<bindings> <binding ircEvent="PRIVMSG" method="newUri" regexp="^http://.*" /> <binding ircEvent="PRIVMSG" method="deleteUri" regexp="^delete.*" /> <binding ircEvent="PRIVMSG" method="randomUri" regexp="^random.*" /> </bindings>
Так себе выигрыш :)
А если сделать шаг дальше? Например такой XML:
<bindings> <httpBinding ircEvent="PRIVMSG" method="newUri" regexp="^http://.*" /> <whatEverBinding ircEvent="PRIVMSG" method="deleteUri" regexp="^delete.*" /> <randomBinding ircEvent="PRIVMSG" method="randomUri" regexp="^random.*" /> </bindings>
Как такая структура будет выглядеть в YAML?
YAML - какая-то высосаная из пальца хренотень, которая дает... ничего :)
НП. А я раньше так программировал , использовал HTML тэги и атрибуты в Java, наоборот меньше возьни с методами, и отрисовывает всё как надо:
import java.awt.*;
import javax.swing.*;
class Main extends JFrame {
public Main() {
setTitle("Test");
setSize(640, 480);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setLayout(new GridLayout(1, 0));
add(new JButton("<html><div style=\"border:1px solid red; background:blue; color:yellow; font-size:20pt; padding:20px 20px;\"><b>Test</b></div>"));
setVisible(true);
}
public static void main(String[] args) {
new Main();
}
}
Дневник тяжелобольного инвалида
YAML - какая-то высосаная из пальца хренотень, которая дает... ничего :)
YAML в разы быстрее парсится чем XML и не требует овердофига памяти для DOM. Те же преимущества и недостатки, что и у JSON.
А если бы у разработчиков JS был бы мозг и они умели бы читать, то мы бы жили без JSON. JS использовал бы YAML.
В экосистеме Явы YAML используется как замена .properties. У него два неоспоримых преимущества - в нём данные по дефолту в UTF-8 (а в пропертях iso-8859-1) и запись компактнее, удобнее читать.
YAML в разы быстрее парсится чем XML и не требует овердофига памяти для DOM.
-----
Об чем ты?
Даны два файла/потока с данными - один ЯМЛ, другой ХМЛ.
Почему-то один ты собираешься читать и парсить последовательно, а другой - грузить разом и создавать дополнительный набор данных...
И на этом основании заявляешь что одно хуже другого?!!
преимущества - в нём данные по дефолту в UTF-8
-----
Не вижу никакого преимущества.
Вижу - недостаток. Например, при экспорте из систем, где дальше EBCDIC
не продвинулись.
запись компактнее, удобнее читать
-----
Хи-хи...
Ну да - человеку чутка более удобнее...
Вот только проблема - чел на анализе 5-6 килобайта все одно сдохнет...
А для железа - почти пофиг - оверхед по ХТТП будет перекрывать разницу...
XML мастдай, За YAML и JSON будущее.
-----
Будущее за тем, где вместе с данными можно будет передать не только формат и разбивку на проперти, но еще и контроль доступа к данным, и некоторую функциональность для данных, исполняемую на клиенте без доп.телодвижений.
Что-то из упомянутого делалось в Жабе на рубеже веков, но или не получилось, или не пошло в массы...
YAML в разы быстрее парсится чем XML и не требует овердофига памяти для DOM.
Во-первых, это не преимущество YAML, а скорее недостаток конкретного парсера XML. В свое время, те, кто не хотел использовать DOM брали tinyxml и в ус не дули.
Во-вторых, кого в современном мире волнует память для DOM?
В-третьих, я не очень хорошо представляю себе проект, в котором скорость десериализации будет иметь какое-то более или менее серьезное значение. Возможно, что такие проекты есть, но даже в задаче "принять данные -> десериализировать -> сохданить данные в БД" об оптимизиции процесса десериализации я бы задумался в последнюю очередь.
А вот отсутствие стандартной возможности описать данные и валидировать их - серьезная проблема (в том числе и для JSON)
До тех пор, пока в YAML и JSON нет схемы и валидирования, эти форматы будут иметь довольно узкую область применения.
А эачем это нужно? Ну общается бек с фронтом, послал данные, в чем проблема-то? По типу названия фронт или бек распознали, что получили то, что надо. Что тут еще нужно? Я не спец в фронтах, я реально не понимаю, объясните, пожалуйста, на пальцах с реальным примером, чтоб я понял зачем такое надобно! Спасибо!
Что тут еще нужно?
-----
Нужно подтвердить, что не только название, но и содержимое соответствует.
На пальцах... пришел документ... в нем обязательны 20 позиций в записи...
По факту - где 20, где 15, где 30...
Валидация, до обработки, говорит - негоден.
Это тебе не базу править когда туда вбили 30 или 15 вместо 20...
пока в YAML и JSON нет схемы и валидирования, эти форматы будут иметь довольно узкую область применения
что значит узкую? json во всю торчит в вебе, веб это узкая область?
просто каждый формат имеет свою роль и предназначение.
Тем не менее для JSON есть и схема и валидирование. Хотя за частую JSON это просто средство доставки уже свалидированных и подготовленных данных с бэкэнда, бери и кушай
Я не спец в фронтах, я реально не понимаю, объясните, пожалуйста, на пальцах с реальным примером, чтоб я понял зачем такое надобно! Спасибо!
нужно если скармливать json сторонней API, для предвалидации например, по схеме чекнуть все и потом уже скормить. Потом сама API будет по той же схеме все еще раз проверять. Например https://aws.amazon.com/de/premiumsupport/knowledge-center/...