Hacker News Digest

Как MVC стало таким бардаком

Классическое Smalltalk-MVC:

• Model — данные, ничего не знает об UI.
• View — рисует Model, подписывается на её изменения.
• Controller — переводит клики/клавиши в команды Model.

Связь Model→View только через наблюдение (observer), поэтому Model переиспользуема.

Apple (и большинство фреймворков) всё перепутали:

• View и Controller слили в «View-Controller» — толстый монстр, который одновременно держит UI-элементы и кучу логики.
• Controller превратился в мусорный бак кода, «непереиспользуемый — но это нормально».
• Model зачастую делают пассивной структурой, а состояние хранят в самом виджете (чекбокс знает своё значение).

Итог: вместо «Model как источник истины» получаем размазанное состояние по View-Controller’ам, гонки данных и невозможность тестировать.

Почему случилось: в C/Pascal сделать observable-Model было больно, поэтому в Xerox Lisa пожертвовали чистотой ради скорости. За ними потянулись все.

Как надо:
Model — любой observable-объект (даже bool в обёртке). View подписывается и рисует текущее значение; никогда не спрашивает «каков чекбокс?» — он знает только Model. Controller лишь говорит Model «переключись». Можно цеплять сколько угодно View к одной Model без изменения кода.

• MVC — «религия без евангелия»: все уверены, что знают, что такое Model и View, но Controller — у каждого свой.
• Исходные определения настолько абстрактны, что под MVC подгоняют любую структуру из трёх классов; реальные кодовые базы показывают 1:1 связь V-C, что уничтожает пользу разделения.
• Контроллер быстро превращается в «всё, что не влезло в M или V», из-за чего страдает тестируемость и масштабируемость; 15 лет рефакторинга iOS-проектов подтверждают: 100 % проблем — в недостаточной проработке Model.
• RAD-фреймворки и визуальные редакторы ускорили искажение: код-behind стал контроллером, а «настоящий» MVC остался только в Smalltalk-историях.
• Практический выход: оставить MV, убрать лишний C или превратить его в тонкий «GluePuppy», который просто связывает наблюдаемую Model с реактивной View; всё остальное — следствие Expression Problem и отсутствия языковой поддержки композиции.

TextKit 2 (NSTextLayoutManager) появился на WWDC21, но уже 4 года не оправдывает надежд. Архитектура продумана: NSTextContentManager, NSTextElement, NSTextLayoutManager. На практике работает только NSTextContentStorage → NSTextStorage, а элементы должны наследовать NSTextParagraph. UITextView/NSTextView не принимает альтернатив.

Баги многочисленны: «extra line fragment», регрессии между версиями, часть отчётов без ответа.

Viewport — главная боль. Он лениво раскладывает только видимую область, поэтому высота документа постоянно пересчитывается и «прыгает» при прокрутке. Постоянные инвалидации и кэширование усложняют код.

• TextKit 2 выглядит «сырым»: демо работает, но стоит отойти от happy path — всплывают баги, плохая документация и отсутствие публичного списка проблем.
• Основной способ использования — кастомизация UITextView/NSTextView; попытки полностью заменить их приводят к боли.
• На macOS TextKit 2 сломал даже TextEdit: появились глюки прокрутки и повреждение текста.
• «Дрожание» скроллбара из-за lazy layout и оценок высоты считается «как задумано», но выглядит неприемлемо; решения есть (Flutter, эвристики), но не встроены.
• Apple, судя по всему, не додогфудила API: внутренние приложения не отловили острые углы, поэтому теперь каждый разработчик получает синяки.