Сегодня у меня был 3й подход в попытке понять что же такое Backbone.js 🙂

Я был в шоке когда узнал что с Backbone мы более не можем просто обратиться к атрибуту объекта. Нам надо использовать get для получения или set для изменения.

И по своей сути это аналог WordPress для php & MySQL. Мы не можем просто получить данные, мы должны использовать get_post_meta или update_post_meta.

В обоих случаях это делается с целью прослушки и контроля событий по получению или изменению данных.

Скажем если мы храним данные персоны в записи, то метод его обновления в BB и WP похожи:

WP: update_post_meta($person_id, ‘age’, 25);

BB: person.set(‘age’, 25);

Понятно что это классический CRUD.

Суть фреймворка

Получается что Backbone для JS  это тоже самое что WP для php. Другими словами это фреймворк.

Тут же углубляется понимание смысла фреймворков. Фреймворки придуманы и нужны в тот момент, когда возникает проблема нового слоя абстракций или архитектуры. Еще это можно назвать словом «культура». Или еще это можно назвать фразой «слой правил».

По сути любой фреймворк это по своей сути некий новый слой правил.

Любой новый слой правил подразумевает проблему — этот слой надо изучить.

Вот почему матерых и старых php-кодеров сложно загнать на WordPress. Они начинают сопротивляться и говорить мол «зачем это надо, мне быстрее на голом php это все запилить». И они правы до какого-то уровня сложности продукта.

Просто чем сложнее продукт и чем больше в нем частей, тем ближе подходишь к проблеме второй половины шахматной доски (с зернами).

В начале старта продукта кажется что нет никаких проблем. Что проще писать на голом языке. Но чем дальше в лес, тем больше число частей появляется в системе и тем сложнее поддерживать эти части в рамках единой архитектуры. В какой то момент система может умереть от переизбытка сложности. Именно для решения таких проблем и нужны фреймворки. Они задают новый слой правил, чтобы система смогла стать больше без особых потерь в сложности взаимодействия ее частей. Да этот новый слой правил потребует больше времени на изучение и ввод каждого нового члена команды разработки продукта. Потому по возможности стоит избегать такие слои. Не надо вводить новый слой правил (фреймворк) пока не пришло на то время.

 

WordPress — это не только фреймворк

WordPress уже давно перестал быть просто фреймворком. А возможно он им только сейчас становится. Тут все зависит от точки зрения 🙂

Он походит на фреймворк в части возможности создания нового слоя правил для php по аналогии с Backbone для JS.

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

По сути с одной стороны это конструктор сайтов как Wix, а с другой стороны это фреймворк как Laravel.

Не понятно как обозвать такого зверя, ну пусть будет CMS 🙂

Какие еще бывают фреймворки?

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

  1. WordPress это тот же php + некие готовые комбинации действий. Называется это API WP.
  2. В CSS это может быть Bootstrap. Да, он снова заставляет нас учить новый слой правил, но зато существенно экономит на ошибках и проблемах при оформлении страниц сайта. Да это тот же CSS + некий набор готовых комбинаций 🙂
  3. В движении ног и рук может быть фреймворком Кикбоксинг.  Кикбоксинг это те же махания руками и ногами, но опять же некий слой правил и готовых комбинаций этих маханий. И черт возьми этот слой правил надо изучать чтобы освоить. А кому это охота? 🙂

Потому каждый сам решает когда ему надо просто махать руками и ногами, а когда пора учить Кикбоксинг 🙂

Да, мозг разорвало на эту тему после просмотра серии видеоуроков по Backbone.js