Я вот щас придумал future web app platform. Без всякого гомняного CSS HTML и жабоскрипта, всяких gulp grunt uglify и 100 прочего унылого однодневного crap, а будет как старый добрый виток desktop apps, ну всякие там Swing, Windows Forms итп. Короче, DOM используется чисто как девайс для постскрипта. Есть шрифты, есть их метрики, известны размеры. Есть output device (document.body.clientWidth x height), расставляй себе буквы как пожелаешь. Линии там рисуй (через канвас получится). Поля ввода тоже расставляй, они без рамок и паддингов, рамки и паддинги рисуются как линии если чо. Всякие layout managers и вообще весь код - приходят в бровзер на webassembly и они работают быстрее чем встроенный в бровзер, т.к. специализация и никакой тебе backward compatibility 20 лет. Если сайт хочет, он вообще изобретает себе сам язык разметки, кладет в бровзеру в кеш webassembly килобайт 300 и с тех пор он сам себе HTML. А разработка ведется на каком-нибудь в натуре dart-подобном языке (который удобен тем, что весьма динамический, но аннотирован типами и нормально компилится в llvm и как следствие в вебасм) Кроме того, Дартиум (или прочий бровзер с поддержкой VM для норм языка разработки, отличного от javascript) становится не нужен (он уже и так помирает в случае дарта, но по своим причинам). Пишешь ты как прежде было в GWT - прямо в IDE на любимом язычке который нативно вертится в своей VM, а всякое отображение с евентами рисуется удаленно по TCP в бровзере, и никакого DOM описания не гоняется там по протоколу, боже упаси, исключительно "нарисуй строку там", "картинку сям (и вот так)", а тут жолтеньким подкрась. Так как HTML layout весь отсутствует, тяжелый DOM с вложенностью двадцать уровней - отсутствует, то анимации "вручную" должны норм летать, если что. Да, и здесь полностью становится не нужен GC на жабоскрипте, да. Хотя конечно DOM bridge будет что-то кушать, но немного. А потом вообще сделают бровзеры интерфейс между webassembly и экраном прямой (тк щас этого интерфейса нет почти ничего). Не канвас, потому что текст-ориентированные аппы все-таки (ну там копи-паст должен работать, например, а его в канвасе не задумано), а что-то минуя js/dom layer. Станет разработка под бровзер приятной как раньше. Запомните это псто!
2017-12-18 19:05:51

Участники:
@SannySanoff - 3, @nibb13 - 1, @zinid - 1, @rkit - 1

@rkit
>Станет разработка под бровзер приятной как раньше. >как раньше. :)
#2892400/1 2017-12-18 19:25:21
@SannySanoff
как раньше под десктоп, имеется в виду.
#2892400/2 → /1 2017-12-18 19:33:50
@zinid
Ага, тож поржал. Вспомнилась шутка с какой-то конференции: > Мы же хотим, чтобы писать распределённые приложения было также просто как мультитредовые
#2892400/3 → /1 2017-12-18 20:49:57
@SannySanoff
Почетное стремление. Если помнить что мультитредовые не особо просто писать БЕЗ определенной системы, которые придумывают там и сям, начиная с STM и заканчивая no shared mutable state. Я полагаю, что упомянутое тобой заявление следует рассматривать в таком же ключе. То есть они хотят систему, которая просто формально не позволит выразить задачу, которая задевает какие-то углы в распределенных вычислениях, которые не желательно задевать. Вон к в Rust например с memory management придумали. Я вот думаю, что в гугле и подобных конторках в решении своих внутренних задач подошли достаточно близко (проделали достаточно попыток) чтобы формализовать это таким образом для рядовой публики, чтобы небритый программист c бодуна мог наговнокодить так, чтобы оно даже работало в общем случае, значительно безглючнее и производительнее, чем в общем случае работает сейчас.
#2892400/4 → /3 2017-12-18 22:07:40
@nibb13
Чёт мне кажется, что ты флэш изобрёл.
#2892400/5 2017-12-19 02:43:46
@SannySanoff
Да, но без флэша.
#2892400/6 → /5 2017-12-19 09:56:58