Накопление знаний
Математическо-низкоуровневое

Web 3.0

Компоненты и их поддержка на уровне браузера - классно конечно, только компонентных фреймворков понасоздавали уже 20+ и это только в экосистеме node.js
То есть опять все видят проблематику - web приложения необходимо создавать быстро, под конкретную задачу и в web приложении фактически главным является клиентоориентированность. Исходя из этих двух тезисов

  1. важен пользователь - значит эргономично и креативно (кто не помнит креативность это не розовые ретузы, а методика)
  2. web приложения должны делать быстро - значит автоматизатор бизнеса должен думать о "поведении" приложения, а не о чистоте функций (чистота функции - это не про чистящее средство)

То есть хочется, чтобы можно было делать 2 вещи

  • спроектировать расположение компонентов
  • описать логику их поведения в комплексе

Как мы понимаем тогда нужны 2 вещи
  • дизайнер форм - в режиме LookAndFeel
  • модули поведения - в режиме точек входа от формы

И самое главное не забыть про финальный DSL

Ну и казалось бы - все же достаточно просто. И даже уже сделано

Но - конечному автоматизатору, который понимает логику пользователя и видит техническое задание, предлагается кодировать поведение компонентов... внимание... на javaScript. Хорошо что не на ClosureScript.

То есть объектная модель компонентов остается низкоуровневой, чтоб нивелирует вообще все плюсы. Потому что доступ к компоненту в коде осуществляется через this.$.something.ref. и т.д. А биндинг из компонента внутрь прикладного кода через явное объявление прототипов функций руками и никакой автоматизации. В итоге - все наплевали на дизайнер и кодят как обычно, с компонентами но... всё на javaScript.

web 3.0 - в итоге скорее всего вынужден будет когда-то изобрести DSL язык, где предметом будет только компоненты и их методы. БЕЗ javaScript (хотя компилироваться будет именно в него).