Не то чтобы он победил

Юзаешь бовер?)

Я в том плане что фреймворки есть и будут

Они на задворках индустрии

Но это не значит что нельзя допилить функциональность под себя пакетами

Вместе с нетфликсом, фейсбуком, твиттером и аирбнб ;)

Бандеролька, китайская ele уже используют вью

Ангуляр — обязательная альтернатива, чтобы у людей был выбор. Собственно, на этом из фреймворков всё

Вообще в азиатских странах вью довольно популярный

Потому что развивается на бабло алиэкспресс

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

Ага

Я в принципе про это, да) Фреймворки сменили экосистемы

Надо зафиксировать, что Канистра континуума утверждает, что вью не жилец

Наториалтно заверить

Я нигде не говорил, что он не жилец

Влачить можно очень долго

Но лучше ужасный конец, чем ужас без конца

Но лучше ужасный конец, чем ужас без конца

Двусмысленно, очень двусмысленно

Деньги увы всё-равно решают, как только что-то становится популярным - так туда заходят корпорации. Пиарят свой стек чтобы облегчить поддержку за счет опенсорса, иногда зарабатывают и на обучении и всем таком, но тем не менее если этот стек юзается лично у них - им выгодно рекламировать продукты. В то что известо - заходят много людей, в итоге популярность и тп. Вообще тот же реакт и ангуляр живут достаточно давно по меркам JS и ещё не превратились в полумертвый легаси, всё бодро и тп.

Деньги увы всё-равно решают, как только что-то становится популярным - так туда заходят корпорации. Пиарят свой стек чтобы облегчить поддержку за счет опенсорса, иногда зарабатывают и на обучении и всем таком, но тем не менее если этот стек юзается лично у них - им выгодно рекламировать продукты. В то что известо - заходят много людей, в итоге популярность и тп. Вообще тот же реакт и ангуляр живут достаточно давно по меркам JS и ещё не превратились в полумертвый легаси, всё бодро и тп.

Да ладно, первый ангуляр уже забросили поди

А Васю Пупкина, который сделал суперудобный фреймворк, уже забыли, причем дважды

Уже давно не в дел вакансия под него

Второй-Третий-Четвертый зато есть

Но переход на 2 версию был не простым, да

Второй-Третий-Четвертый зато есть

Третьего нет

Я условно

Гугл взял идею Майкрософта с нумерацией, да

Гугл взял идею Майкрософта с нумерацией, да

Кстати, покажи пример нормального дата биндинга на jQuery

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

Но никакого волшебства быть не может - ибо если шаблоны там какие или типа того - это либо нужно чтобы генерилось всё на основе компонетов в рантайм, либо парсинг страницы на момент вставок по каким-либо правилам шаблонизатора

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

Есть есть хренолион таких мест и всё очень прям динамично то прям вообще - тогда нужно брать конечно инструмент поинтереснее чтобы избавиться от кода, который из раза в раз нужно повторять

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

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

Но также нет никакого тайного волшебства - просто вводится ещё 1 код, который обрабатывает уже компоненты

Ох уж етот олдскульный императивный жс

Решил вспомнить самое начало, да

:D

В ExtJS вон вообще всякие там сторы, у которых есть прокси, есть ещё несколько там слоев обмена данными, также отдельная абстракция с эвентами, эвент-домены там, потоки эвентов направлять там, пропускать через себя их, 100500 методов для простой кнопки чтобы сделать с ней вообще всё что угодно что хоть когда-то может пригодится и одним методом, а также отдельный биндинг стилей, темы с наследованием и ещё 100500 всего. Просто в 1 момент решили биндинг, да, удобно, давайте компоненты, удобно, да, хм, давайте в сеть ходить через отдельный слой абстракции, а там ещё и ещё слои, а теперь объекты начнут общаться как в истинном ООП через асинхронные эвенты и пошло поехало.

Полюбому в какой-то момент веб расслоится на несколько слоев со своими там скопами и предназначенными для своих дел

Хотя это может остаться и на программном уровне в рамках фреймворков или библиотек, да

Вообще императивность хороша когда что-то такое делается под конкретную задачу и никуда больше.

Главное понять что эта задача - эта самая

И это не значит что нужно писать плохой код, но значит что можно писать код решающий исключительно конкретный набор задач

В ExtJS вон вообще всякие там сторы, у которых есть прокси, есть ещё несколько там слоев обмена данными, также отдельная абстракция с эвентами, эвент-домены там, потоки эвентов направлять там, пропускать через себя их, 100500 методов для простой кнопки чтобы сделать с ней вообще всё что угодно что хоть когда-то может пригодится и одним методом, а также отдельный биндинг стилей, темы с наследованием и ещё 100500 всего. Просто в 1 момент решили биндинг, да, удобно, давайте компоненты, удобно, да, хм, давайте в сеть ходить через отдельный слой абстракции, а там ещё и ещё слои, а теперь объекты начнут общаться как в истинном ООП через асинхронные эвенты и пошло поехало.

Асинхронные эвенты это хорошо

reactive programming тоже под капотом на них основан

С них главное вовремя соскочить))

Там с этой темой конкретно развили всё. Каждый компонет может файрить эвенты, может слушать их, может проксировать их от других, что актуально для больших компонентов, состоящих из множества малых. Например есть условно таблица, снизу 2 кнопки управляющие. Можно на них подписаться, но всё-таки кнопки жестко привязаны к логики таблицы - лучше всё это в 1 компонент оформить и проксировать эвенты нажатия на кнопки через единый интерфейс и дать какие-нибудь более интерсные имена им, add-line и remove-line например.

ну вот с момента "проксировать" они и покатились

Это ложная абстракция

Далааадна

Да

Я же описал как и почему

Это же абстракция, как модульность, только для потока эвентов

Паттерн "фасад" же

Вот, да, я про то же

по прежнему ложная абстракция.

Это не прокси, это просто stream.map(transformFn)

Который возвращает новый стрим

Нет, абстракция обусловленная необходимостью

я описал решение без абстракции

Ибо иначе это будет ад

Один метод, одна функция, один новый объект

А у них что?

Не понял про что ты со стримом

Я описал, как выглядит это решение если не упарываться ооп)

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

stream — поток эвентов, "прокси" твой — это просто функция, каким либо образом преобразующая этот поток. Возвращает новый экземпляр стрима

нет никакого "наружу", у компонента есть просто объект stream

Что-то мы похоже про сильно разное

Лол, вот самое смешное, что нет

Но то, что в ооп решают чудовищным набором слоев абстракций — делается парой функций

Концепция reactive — это декларативный путь объявления твоих императивных абстракций. Честно, это все правда делается парой функций

В этом трагедия ооп)) Строили-строили, а в результате — пшик, десятилетие заблуждений

Короче, есть компонент "таблица с кнопками", внутри есть компоненты "таблица", "тулбар", в нем кнопки "добавить строку", удалить строку". Компонент "таблица с кнопками" инкапсулирует всё внутри. Он подписан на события нажатия на соответствующие кнопки. По соответствующему эвенту происходят какие-то действия и в зависимости от результата - эвенты с новым именем файрятся от имени компонента "таблица с кнопками". Итого мы имеем единый программный интерфейс к этому компоненту и не лезем в механику внутри. Однако может быть причина просто пробросить эвент изнутри, вообще ничего не меняя, за исключением того что он будет от имени компонента. Допустим есть тулбар, в нем кнопка и поле ввода, мы можем тулбаром читать эвенты кнопки и поля ввода и пробрасывать их от имени толбара. Но не GUI единым - хранилища данных могут файрить эвенты например по факту добавления новых данных или синхронизации с сервером.

Ты описываешь требовния, не реализацию

Реши мне проблему с "таблица с кнопками" по своему

Реализация вроде же не звучит сложной, хранилище подписчиков и всё такое

Тебе сейчас почему то кажется что я тебе рассказываю про клингонский

Я просто сообщаю как факт, что в данном подходе есть некоторые шаблоны, которые люди уже обобщили, и все эти велосипеды из прокси — уже давно solved problem