Очевидно, что за последние годы JavaScript превратился из «прикольного дополнения к HTML» в мощное средство для разработки веб-приложений. И превратился он в него не технологически, а идеологически. То есть он всегда был, как-бы на протяжении своего существования сильно не менялся, но почему-то стал использоваться на всю катушку сравнительно недавно. Как будто все неожиданно осознали, что веб тоже может быть интерактивным, и веб-сайты, как-бы не веб-сайты вовсе, а такие программы, со своей логикой. Эта тенденция оказала сильно и на требования к сайтам в общем.
До конца не ясно, то-ли возможности Javascript так повлияли на веб, то-ли веб сам стал требовать интерактива, и на помощь пришел JS. Я лично склоняюсь к первому варианту.
В результате этого, произошло то, что происходило уже не раз. Начали появляться полуфабрикаты для разработки интерактивных веб-сайтов, нам они известны как фреймворки.
Как мы все понимаем, понятию фреймворкам уже сто лет в обед. Например C можно считать фреймвоком над ассемблером. И изначально фреймворк нес собой добро. Он позволял программисту сосредоточиться на прикладных задачах, не отвлекаясь на смежные. Например при реализации передачи данных пользователю через интернет не надо думать о формате пакетов TCP/IP, так как система займется этим сама. Ну или более близкий нам пример — ORM: можно работать с данными даже не имея представления о СУБД.
(Касательно JS, то тут тоже со временем формализовался круг типовых задач, которые решаются с помощью него и они плавно локализовались в JS-фреймворки.)
Но при всем хорошем, что принесли фреймворки, с ними пришла одна большая беда. Появилась каста прикладных программистов, которые кроме своего любимого фреймворка ничего о программировании не знали. Моментально на память приходят гонения VBшников и дельфистов на различных профильных форумах. И в этом есть большая доля правды, так как я лично знаю человека, который хранил значения переменных в экземплярах класса TLabel (Delphi), фактически он для каждой переменной клал контрол на форму, называл его как переменную и ставил Visible в False. Это конечно клиника, но в большинстве своем апологеты фреймворков слабо себе представляют процессы, связанные с использованием оперативной памяти оптимизации загрузки и выполнения программы и многое другое. Потому, что за них это делает фреймворк. И для них становится открытием, что если запихнуть в приложение пятьдесят форм, причем все Autocreate, то оно в лучшем случае будет грузиться 5 минут, а в худшем упадет с ошибкой «Все, бля, не могу».
Вторая проблема с фреймворками, обусловлена, тем, что они исповедуют определенный стиль написания кода. (Кстати, это очень хорошо видно, на JS), фактически поэтому и появляются такие странные специализации как «1С программист», «Битрикс программист», а в будущем и jQuery-программист или mootools-программист. Используя какую-то технологию (фреймворк), компания становится ее заложницей. Так как во многом зависит от возможностей этой технологии. Это вынуждает, либо осваивать ее внутренности, чтобы подгонять под свои нужды либо делать только то, что позволено. Очень часто попадаются темы «Я пользуюсь… фреймвороком, но в нем не хватает … поэтому пришлось писать свою реализацию ...».
Вдумчивый читатель спросит, «Ведь любая технология имеет ограничения, почему вы пишете это в минус только фреймворкам». Согласен, проблема с нехваткой специалистов по фортрану хорошо это показывает. Но все таки если в компании пишут хороший код, то круг JS специалистов шире, которые смогут его поддерживать, чем круг jQuery специалистов.
К чему я все это написал. С популяризацией JS, он как и все технологии переживет такую-же классическую историю, но находится сейчас в середине. И хотелось бы чтобы во всем изобилии надстроек над ним (фреймворков), мы не забыли, что там где-то в их недрах сидит чистый Javascript, на котором можно делать удивительные вещи, которые надстройкам и не снились.
P.S. Я очень хорошо знаю все за и против использования фреймворков, так как три года работал в Developer Express. И я не в коем случае не выступаю против их использования, я выступаю против подмены ими вдумчивого подхода к разработке. Типа: «Я тут нафигачу, а фреймворк пусть сам это разгребает».
До конца не ясно, то-ли возможности Javascript так повлияли на веб, то-ли веб сам стал требовать интерактива, и на помощь пришел JS. Я лично склоняюсь к первому варианту.
В результате этого, произошло то, что происходило уже не раз. Начали появляться полуфабрикаты для разработки интерактивных веб-сайтов, нам они известны как фреймворки.
Как мы все понимаем, понятию фреймворкам уже сто лет в обед. Например C можно считать фреймвоком над ассемблером. И изначально фреймворк нес собой добро. Он позволял программисту сосредоточиться на прикладных задачах, не отвлекаясь на смежные. Например при реализации передачи данных пользователю через интернет не надо думать о формате пакетов TCP/IP, так как система займется этим сама. Ну или более близкий нам пример — ORM: можно работать с данными даже не имея представления о СУБД.
(Касательно JS, то тут тоже со временем формализовался круг типовых задач, которые решаются с помощью него и они плавно локализовались в JS-фреймворки.)
Но при всем хорошем, что принесли фреймворки, с ними пришла одна большая беда. Появилась каста прикладных программистов, которые кроме своего любимого фреймворка ничего о программировании не знали. Моментально на память приходят гонения VBшников и дельфистов на различных профильных форумах. И в этом есть большая доля правды, так как я лично знаю человека, который хранил значения переменных в экземплярах класса TLabel (Delphi), фактически он для каждой переменной клал контрол на форму, называл его как переменную и ставил Visible в False. Это конечно клиника, но в большинстве своем апологеты фреймворков слабо себе представляют процессы, связанные с использованием оперативной памяти оптимизации загрузки и выполнения программы и многое другое. Потому, что за них это делает фреймворк. И для них становится открытием, что если запихнуть в приложение пятьдесят форм, причем все Autocreate, то оно в лучшем случае будет грузиться 5 минут, а в худшем упадет с ошибкой «Все, бля, не могу».
Вторая проблема с фреймворками, обусловлена, тем, что они исповедуют определенный стиль написания кода. (Кстати, это очень хорошо видно, на JS), фактически поэтому и появляются такие странные специализации как «1С программист», «Битрикс программист», а в будущем и jQuery-программист или mootools-программист. Используя какую-то технологию (фреймворк), компания становится ее заложницей. Так как во многом зависит от возможностей этой технологии. Это вынуждает, либо осваивать ее внутренности, чтобы подгонять под свои нужды либо делать только то, что позволено. Очень часто попадаются темы «Я пользуюсь… фреймвороком, но в нем не хватает … поэтому пришлось писать свою реализацию ...».
Вдумчивый читатель спросит, «Ведь любая технология имеет ограничения, почему вы пишете это в минус только фреймворкам». Согласен, проблема с нехваткой специалистов по фортрану хорошо это показывает. Но все таки если в компании пишут хороший код, то круг JS специалистов шире, которые смогут его поддерживать, чем круг jQuery специалистов.
К чему я все это написал. С популяризацией JS, он как и все технологии переживет такую-же классическую историю, но находится сейчас в середине. И хотелось бы чтобы во всем изобилии надстроек над ним (фреймворков), мы не забыли, что там где-то в их недрах сидит чистый Javascript, на котором можно делать удивительные вещи, которые надстройкам и не снились.
P.S. Я очень хорошо знаю все за и против использования фреймворков, так как три года работал в Developer Express. И я не в коем случае не выступаю против их использования, я выступаю против подмены ими вдумчивого подхода к разработке. Типа: «Я тут нафигачу, а фреймворк пусть сам это разгребает».
