Проблема фреймворков

В этом посте хотелось бы выразить своё мнение по поводу фреймворков, которые стали стандартом современного программирования. В чём отличие фреймворка от библиотеки? Если не вдаваться в детали и говорить простым человеческим языком, можно выразиться так: программист встраивает библиотеку в свой код, меняя лишь вызовы отдельных функций на библиотечные, тогда как фреймворк предполагает изменения самой концепции разработки. Один из ярких и показательных примеров - библиотека jQuery и фреймворк React. Оба этих инструмента предназначены для написания фронтенда на JS/TS, поэтому их вполне можно сравнивать. Для примера возьмём маленькую и лёгкую задачу - создать простейший кликер с одной кнопкой и счётчиком нажатий. На нативном JS+HTML эта задача решается так (HTML и JS-код намеренно объединены в один листинг для удобства): 0 Click me const counter = document.querySelector('#clickCount'); const button = document.querySelector('#click'); let clicks = 0; button.addEventListener('click', ()=>{ clicks++; counter.textContent = clicks; }); Предположим, что наш программист-кликатель захотел упростить себе жизнь и применить jQuery. Теперь его код выглядит так: 0 Click me const counter = $('#clickCount'); let clicks = 0; $('#click').on('click', ()=>{ clicks++; counter.text(clicks); }); Добавилась строка с подключением библиотеки, изменились названия функций и методов для работы с DOM-деревом, но концепция сохранилась - сначала производится поиск элемента на странице, а потом с ним производятся какие-то действия - подписка на событие, изменение текста и т.д. Если же нашему кликеролюбу захочется использовать React - его код будет выглядеть примерно так: function App() { const [clickCount, setClickCount] = React.useState(0); const handleClick = () => { setClickCount(clickCount + 1); }; return ( {clickCount} Click me ); } ReactDOM.render(, document.getElementById('root')); Как видно, концепция разработки полностью изменилась, код стал выглядеть совсем иначе - теперь применяются компоненты, состояния и т.п. Из этого примера можно сделать вывод - библиотеку легко встроить в существующий код, тогда как для программирования на фреймворке придётся переучиваться и менять методы разработки. Но плохо ли это? Для тренировки мозга новыми знаниями - нет. Для разработки - да, особенно, когда существует несколько разных фреймворков с разными подходами, миграция между которыми существующей кодовой базы превращается в боль и огромное количество рутинной работы. К тому же, из-за огромного распространения фреймворков начинающие программисты зачастую не умеют решать задачи без них и лепят их даже там, где можно обойтись легковесной библиотекой - особенно это заметно во фронтенде. Что с этим делать? Применять фреймворки только в тех случаях, когда их преимущества перевешивают недостатки - при разработке особо крупных проектов, а в остальных случаях обходиться набором библиотек.

Mar 17, 2025 - 01:47

В этом посте хотелось бы выразить своё мнение по поводу фреймворков, которые стали стандартом современного программирования.

В чём отличие фреймворка от библиотеки?

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

Один из ярких и показательных примеров - библиотека jQuery и фреймворк React. Оба этих инструмента предназначены для написания фронтенда на JS/TS, поэтому их вполне можно сравнивать.
Для примера возьмём маленькую и лёгкую задачу - создать простейший кликер с одной кнопкой и счётчиком нажатий.
На нативном JS+HTML эта задача решается так (HTML и JS-код намеренно объединены в один листинг для удобства):



    
         charset="UTF-8">
    
    
         id="clickCount">0
         id="click">Click me

Предположим, что наш программист-кликатель захотел упростить себе жизнь и применить jQuery. Теперь его код выглядит так:



    
         charset="UTF-8">
        
    
    
         id="clickCount">0
         id="click">Click me

Добавилась строка с подключением библиотеки, изменились названия функций и методов для работы с DOM-деревом, но концепция сохранилась - сначала производится поиск элемента на странице, а потом с ним производятся какие-то действия - подписка на событие, изменение текста и т.д.

Если же нашему кликеролюбу захочется использовать React - его код будет выглядеть примерно так:



    
         charset="UTF-8">
        
        
        
    
    
         id="root">

Как видно, концепция разработки полностью изменилась, код стал выглядеть совсем иначе - теперь применяются компоненты, состояния и т.п.

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

Но плохо ли это?

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

Что с этим делать?

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