SHARE
TWEET

Untitled

a guest Dec 1st, 2015 149 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. ## Первый тезис:
  2.  
  3. Полностью декларативный код не работает, всегда начинаются проблемы с расширением и выразительностью, и вместо простоты получается каша из костылей, где под каждый случай — кастомная хуета. С этим становится сложнее разбираться, поддерживать и работать.
  4.  
  5. Есть множество примеров где это не удалось:
  6. 1. Все исключительно декларативные валидаторы (в основном северные, типа встроенные в симфони2 валидаторы, или теже формы из симфони2, в каждой большой серверной хуете есть что то такое) показывают большие проблемы на хоть сколько нибудь сложных проектах.
  7. 2. Все исключительно декларативные шаблонизаторы становится использовать сложно, даже на проектах размером с twitterовскую веб морду (смотри mustache, да даже handlerbars, который "чуть менее декларативный" становится сложно использовать), из за тех же причин что описаны выше.
  8.  
  9. Есть альтернативная "реализация" декларативности — функциональное реактивное программирование, где по сути из композиции императивных (хотя подразумевается что они "чистые") функций собирается декларативное дерево изменения состояния.
  10.  
  11. Реакт – что то среднее. Он частично реализует ФРП, так как обладает вполне ограниченным flow (ну если без хаков) данных и соответственно детерменированностью обновления интерфейса, при этом позволяет декларативный подход к описанию интерфейса средствами JSX (аргумент про то, что JSX компилируется в императивный код — не аргумент. ВСЕ декларативные шаблонизаторы, валидаторы и прочее декларативное описание так или иначе компилируются в императивный код.)
  12.  
  13. Should component update это вещь, которая очень помогает с кэшированием, чего например лишены 3D движки. К чему 3D движки тут? Читай следующий тезис.
  14.  
  15. ## Второй тезис:
  16.  
  17. Держать прямую связанность объектов и отображения, или полностью реактивная связанность почти всегда (за исключением редких случаев когда это у тебя входит в сам язык, в его свойства, и он умеет это оптимизировать (по разному) см. elm, haskell), на больших объемах всегда ДОРОЖЕ чем пересчитать дерево объектов интерфейса (не будем говорить про конкретно DOM в браузерах) полностью! Из за этого любой UI требующий большой скоростью (будь то отображение состояния игрового мира в игре, или быстро изменяющиеся графики в браузере) почти всегда пересчитываются с нуля! И это будет большой удачей и удобством, что бы ЕЩЕ дополнительно ускорить это за счет какого то слоя кэширования, который появляется исключительно из свойств используемой технологии. В реакте это — быстрые дифы (они не полные и достаточно быстрые) и shouldComponentUpdate, которые позволяют сказать браузеру, что надо обновлять, а что нет.
  18.  
  19. При этом реакт тебя не учит никакому псевдосинтаксису для итерирования, для логических выражений, и не вынуждает писать хаки для случаев когда тебе нехватает выразительности, надо сделать сложное условие, разделить код, при этом пробрасывая нужные данные. Ты просто пользуешься функциями и передаешь в них аргументы. Да тут ожидается что ты будешь писать "чистые функции", и немножко переучивать людей приходится, но зато это дает более просто тестируемый код, так что это улучшение которое полезно _не только для реакта_.
  20.  
  21. Никаких сомнений нет, в том что реакт заменится как нибудь на что нибудь более лучшее.
  22.  
  23. Извиняюсь за некоторую сумбурность мыслей, но еще работать как то надо, пойду поработаю.
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
Top