Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
а тот дельфист хитер… это же новый революционный способ отладки для тех, кто не умеет польтзоваться дебаггером!
во время отладки visible=true, а потом в релизе false
во время отладки visible=true, а потом в релизе false
Ага, и вселенский заговор против вас лично :)
Честно, они без моих соплей обойдутся, так как очень хорошо себя чувствуют. Я просто выражаю компании свое уважение, потому что это был мой университет, и я добился того чего добился, потому что получил ключевые навыки там.
Честно, они без моих соплей обойдутся, так как очень хорошо себя чувствуют. Я просто выражаю компании свое уважение, потому что это был мой университет, и я добился того чего добился, потому что получил ключевые навыки там.
Нифига, это пиар Битрикса ;)
JS ещё пока редко встречается, как основное требование в вакансиях. Пока он не станет «основным», большинство программистов будут воспринимать его как вспомогательный и не будут чувствовать разницы между чистым JS & DOM Scripting, не говоря уже о фреймворках. Людей которые пишут о знании JS в резюме, но которые не читали спеку — каждый 2, если не больше.
JS переживает сейчас очень интересные времена — тут и откат спеки ECMAScript 4, компонентный ExtJS, лёгкий jQuery, полноценный JavaScriptMVC, серверные Jaxer/Helma & JS-генераторы GWT & ZKoss.
JS с развитием RIA находится «в поиске», и очень интересно, чем это закончится.
JS переживает сейчас очень интересные времена — тут и откат спеки ECMAScript 4, компонентный ExtJS, лёгкий jQuery, полноценный JavaScriptMVC, серверные Jaxer/Helma & JS-генераторы GWT & ZKoss.
JS с развитием RIA находится «в поиске», и очень интересно, чем это закончится.
Хе-хе К тому же скоро еще и JavaScript-to-JavaScript compiler Google выпустит.
В этом и проблема, что в вакансиях не ищут JS программистов. А дают в руки PHP программеру Prototype, Scriptaculous и Lightbox.
Реально сам видел когда берут Prototype только для того чтобы проверить пополнены ли поля в форме и показать 1 поп-уп. Ужес!
Реально сам видел когда берут Prototype только для того чтобы проверить пополнены ли поля в форме и показать 1 поп-уп. Ужес!
старая как мир мудрость:
скальпелем можно как убить, так и прооперировать
все зависит от того кто его держит в руках.
но если посмотреть с другой стороны, ведь есть и такие кто через фреймворки выходит к низкоуровневому программированию, да редко, да спустя время и через пару трупов-франкенштейнов, но бывает и так.
скальпелем можно как убить, так и прооперировать
все зависит от того кто его держит в руках.
но если посмотреть с другой стороны, ведь есть и такие кто через фреймворки выходит к низкоуровневому программированию, да редко, да спустя время и через пару трупов-франкенштейнов, но бывает и так.
Я что-то не понял. Вы серьезно считаете, что C — это framework над языком assembler? И вы так же уверены, что Delphi — это framework.
Delphi — среда быстрой разработки, основанная на библиотеке визуальных компонент, которые в сумме представляют собой framework. Но сама среда Delphi — это только лишь среда. Она упрощает и ускоряет процесс разработки, но ни коим образом не запрещает горе программисту неправильно использовать ее возможности.
C — это язык программирования, который, кстати, не упрощает работу с TCP/IP. Это делает не язык, а библиотеки, которые кстати не могут считаться фреймворками.
БИБЛИОТЕКА != FRAMEWORK
ORM — это вообще концепция. Парадигма, если хотите. Те инструменты ORM, которыми приходилось пользоваться мне (Hibernate, TopLink и собственные велосипеды), фреймворками не называют. И правильно делают.
И я категорически не согласен с утверждением, что причина перечисленных вами бед — фреймворки или библиотеки. Может это проблема образования или еще чего-нибудь, но никак не фреймворков. Фреймворк — не серебрянная пуля, и не решает всех проблем, возникающих при разработке ПО и ничего не делает за разработчика.
Как минимум необходимо хотя бы поверхностно изучить возможности любого фреймворка и те механизмы, которые лежат в основе его работы. А если этого не делать, то получится разработка в стиле вашего знакомого дельфиста. Хотя какой он к черту дельфист, если умеет только контролы на форме располагать.
Любой язык развивается. Тысячи людей ежедневно пытаются решать круг одних и тех же задач. Так почему бы не использовать готовое решение. Что кстати соответствует принципу повторного использования кода. Так было испокон веков ИТ-индустрии (вспомните библиотеки процедур на фортране) и так будет вероятно всегда.
PS: Кстати, несколько некорректно называть TLabel компонентом. Это всего-лишь класс, который скрывается за компонентом Label IDE Delphi.
Delphi — среда быстрой разработки, основанная на библиотеке визуальных компонент, которые в сумме представляют собой framework. Но сама среда Delphi — это только лишь среда. Она упрощает и ускоряет процесс разработки, но ни коим образом не запрещает горе программисту неправильно использовать ее возможности.
C — это язык программирования, который, кстати, не упрощает работу с TCP/IP. Это делает не язык, а библиотеки, которые кстати не могут считаться фреймворками.
БИБЛИОТЕКА != FRAMEWORK
ORM — это вообще концепция. Парадигма, если хотите. Те инструменты ORM, которыми приходилось пользоваться мне (Hibernate, TopLink и собственные велосипеды), фреймворками не называют. И правильно делают.
И я категорически не согласен с утверждением, что причина перечисленных вами бед — фреймворки или библиотеки. Может это проблема образования или еще чего-нибудь, но никак не фреймворков. Фреймворк — не серебрянная пуля, и не решает всех проблем, возникающих при разработке ПО и ничего не делает за разработчика.
Как минимум необходимо хотя бы поверхностно изучить возможности любого фреймворка и те механизмы, которые лежат в основе его работы. А если этого не делать, то получится разработка в стиле вашего знакомого дельфиста. Хотя какой он к черту дельфист, если умеет только контролы на форме располагать.
Любой язык развивается. Тысячи людей ежедневно пытаются решать круг одних и тех же задач. Так почему бы не использовать готовое решение. Что кстати соответствует принципу повторного использования кода. Так было испокон веков ИТ-индустрии (вспомните библиотеки процедур на фортране) и так будет вероятно всегда.
PS: Кстати, несколько некорректно называть TLabel компонентом. Это всего-лишь класс, который скрывается за компонентом Label IDE Delphi.
Спасибо за развернутое мнение.
Суть слова фреймворк в том, что это система, построенная над какой-то технологией, позволяющая программисту сконцентрироваться на логике его программы, при этом не решая смежные задачи.
А если бы я написал, что:
— В Delphi/Kylix/C++ Builder есть VCL/CLX (которая, кстати не смотря на название не является библиотекой визуальных компонентов), а именно фреймворком (она ведь начинается с класса TObject) над Object (Delphi) Pascal, которая как раз вместе с самой IDE (Delphi/Kylix/C++ Builder) и создает максимально эффективную среду для создания приложений. На самом деле IDE и VCL/CLX неразрывны. Поэтому для меня Delphi всегда является синонимами. Также известна попытка создать фреймворк для Delphi for PHP, но не совсем удачная. :( Кстати именно по поводу поддержки PHP я с DX идеологически разошелся.
— Моя статья лучше бы не стала.
P.S. Мне кажется, что в погоне за терминологией, вы упускаете суть вещей.
Суть слова фреймворк в том, что это система, построенная над какой-то технологией, позволяющая программисту сконцентрироваться на логике его программы, при этом не решая смежные задачи.
А если бы я написал, что:
— В Delphi/Kylix/C++ Builder есть VCL/CLX (которая, кстати не смотря на название не является библиотекой визуальных компонентов), а именно фреймворком (она ведь начинается с класса TObject) над Object (Delphi) Pascal, которая как раз вместе с самой IDE (Delphi/Kylix/C++ Builder) и создает максимально эффективную среду для создания приложений. На самом деле IDE и VCL/CLX неразрывны. Поэтому для меня Delphi всегда является синонимами. Также известна попытка создать фреймворк для Delphi for PHP, но не совсем удачная. :( Кстати именно по поводу поддержки PHP я с DX идеологически разошелся.
— Моя статья лучше бы не стала.
P.S. Мне кажется, что в погоне за терминологией, вы упускаете суть вещей.
Приведенная каша из сокращений конечно делает статью хуже. Но невладение терминологией не делает ее лучше. Более того, неправильное употребление терминов заставляет сомневаться в компетентности и объективности автора. Мы же не в курилке с вами общаемся, где всегда можно сказать что оговорился и поправить ситуацию. Более менее публичные заявления должны быть продуманы и взвешены. Это имхо конечно.
Статья не о терминологии.
А определения у фреймворка нет. То что я назвал TLabel компонентом, а не классом, вряд-ли исказило суть статьи.
А определения у фреймворка нет. То что я назвал TLabel компонентом, а не классом, вряд-ли исказило суть статьи.
http://ru.wikipedia.org/wiki/Framework
Wikipedia конечно не бог весть какой авторитетный источник, но думаю, что многие согласятся с основными свойствами, присущими фреймворку.
Статья не о терминологии, но использует ее. Если я говорю «грянул гром», то большинство людей представят себе погодное явление. Вы пишите сатью для масс, а не для себя.
На этом предлагаю дискуссию закрыть, т.к. мы уже совсем отклоняемся от темы.
Wikipedia конечно не бог весть какой авторитетный источник, но думаю, что многие согласятся с основными свойствами, присущими фреймворку.
Статья не о терминологии, но использует ее. Если я говорю «грянул гром», то большинство людей представят себе погодное явление. Вы пишите сатью для масс, а не для себя.
На этом предлагаю дискуссию закрыть, т.к. мы уже совсем отклоняемся от темы.
Есть такая идея, что:
Если у программиста возникают проблемы с написанием чистого JS вне фреймворка, то проблема не в фреймворке, а в программисте.
Если у программиста возникают проблемы с написанием чистого JS вне фреймворка, то проблема не в фреймворке, а в программисте.
Придерживаясь логики статьи, можно предположить что когда нибудь появиться и фреймворк над jQuery.
Нет. Тут есть забавный феномен: фреймворк можно модифицировать, языки программирования, как правило, нельзя. Второе обуславливает пофвление фреймворков (кому был бы нужен фреймворк если бы можно было выложить на сайт JSQuery, который можно было бы использовать вместо JavaScript'а?), первое — обуславливает их размножение но в результате фреймворки над фреймворками не по появляются. За исключением случаев когда какой-то фреймворк настолько окостеневает, что его изменение становится невозможным (пример: STL в C++). jQuery до этого ещё далеко — и не факт что про него не забудут раньше…
Думаю, всё же флэш стал катализатором развития интерактива — до него JS использовался скорее для приколов и эксперементов.
А вообще, действительно, хорошему программисту фреймворк позволяет писать быстрее, а плохому — плохому уже ничего не поможет.
А вообще, действительно, хорошему программисту фреймворк позволяет писать быстрее, а плохому — плохому уже ничего не поможет.
Фреймворки это шаг к уменьшению стоимости разработки. И там где импользование фреймворка (пускай даже в самых простых задачах, в которых можно было обойтись без него) не влечет за собой избыточной нагрузки на браузер (т.е. когда всё не начинает тормозить), в таких ситуациях фреймворк — это однозначно хорошо.
Вобщем я веду к тому, что обростание любого языка программирования фреймворками — неизбежно. Это прогресс. Но конечно же люди которые будут знать «чистый» JavaScript будут на коне, так как всегда (пускай не всегда, но ещё довольно долго) будет нужна низкоуровневая отладка JavaScript приложений — для увеличения производительности, либо для других целей. В конце концов даже ассемблер-разработчики щас нужны (и я думаю эти люди зарабатываю побольше людей программирующих на более тривиальных языках программирования).
Вобщем я веду к тому, что обростание любого языка программирования фреймворками — неизбежно. Это прогресс. Но конечно же люди которые будут знать «чистый» JavaScript будут на коне, так как всегда (пускай не всегда, но ещё довольно долго) будет нужна низкоуровневая отладка JavaScript приложений — для увеличения производительности, либо для других целей. В конце концов даже ассемблер-разработчики щас нужны (и я думаю эти люди зарабатываю побольше людей программирующих на более тривиальных языках программирования).
Но все таки если в компании пишут хороший код, то круг JS специалистов шире, которые смогут его поддерживать, чем круг jQuery специалистов.
Звучит как-то странно, может лучше:
круг JS специалистов, которые смогут его поддерживать, шире?
А по сути: я полностью согласен с автором фреймворки — это хорошо, но JS тоже нужно знать.
Звучит как-то странно, может лучше:
круг JS специалистов, которые смогут его поддерживать, шире?
А по сути: я полностью согласен с автором фреймворки — это хорошо, но JS тоже нужно знать.
Если у человека есть голова на плечах — он всегда найдет выход, ибо понимает суть.
А если человек занимается не тем, чем должен, то тут никакие призывы не помогут :)
А если человек занимается не тем, чем должен, то тут никакие призывы не помогут :)
> там где-то в их недрах сидит чистый Javascript, на котором можно делать
> удивительные вещи, которые надстройкам и не снились
Можете какой-нибудь пример привести?
> удивительные вещи, которые надстройкам и не снились
Можете какой-нибудь пример привести?
Писать фреймворки ;)
да, мне тоже стало интересно :) все-таки, фреймворк ничуть не ограничивает исходный язык, для которого он написан. хотя урезать кругозор программистов он, безусловно, может.
Toggle или tooltip-скрипт весом 2-3 кб (без комментов, пробелов и переносов строки). А теперь посчитайте, какой объем занимают решения на фреймворках :)
Ну если правильно настроить кеширование, это как-бы не совсем хороший аргумент.
Во-первых просили просто пример, а во-вторых, по статистике, важна именно самая первая загрузка страницы, пока перед юзером просто белый экран, а прогресс-бар загрузки показывает «500 кб / 50%». У меня мегабитный канал, и мне как-то все равно, но я еще живо помню сидение перед экраном когда инет обеспечивает смарт и GPRS. Так что юзер может и не дождаться самой первой загрузки сайта, когда в кэше еще пусто.
Вместе с фреймворками? Смотря что за фреймворк. В mootools (который целиком весит 60 кб) есть core builder, в котором можно сгенерировать файл библиотеки, состоящий только из нужных модулей. В jquery, вроде бы, нет такого генератора, но она и без него целиком весит всего 30 кб.
Так же размер зависит от требуемой функциональности и самой реализации. А еще, с библиотеками писать гораздо удобнее.
Так же размер зависит от требуемой функциональности и самой реализации. А еще, с библиотеками писать гораздо удобнее.
На сайте mootools при выборе того, что нужно включить в пакет перед упаковкой пакером показываются зависимости библиотеки. Так вот, конкретно эффект toggle тянет за собой 13 библиотек на сколько я помню (включая естественно core). В итоге вес такой либы ради одного эффекта приближается к 40 кб.
Я с этим целиком согласен, просто фреймворки обеспечивают избыточную функциональность, которая полностью никогда не будет использоваться ценой избыточного веса скрипта. Скорость разработки безусловно намного выше, для большинства задач уже написаны готовые плагины, достаточно только собрать все в кучу и подключить к фреймворку. Правда и весить это все будет тоже прилично.
Предвижу аргумент «фреймворк можно почистить и выкинуть из него лишнее»- а не проще написать 5 кило кода, чем ворошить 50, не зная на все 100% особенностей архитектуры фреймворка?
Так же размер зависит от требуемой функциональности и самой реализации. А еще, с библиотеками писать гораздо удобнее.
Я с этим целиком согласен, просто фреймворки обеспечивают избыточную функциональность, которая полностью никогда не будет использоваться ценой избыточного веса скрипта. Скорость разработки безусловно намного выше, для большинства задач уже написаны готовые плагины, достаточно только собрать все в кучу и подключить к фреймворку. Правда и весить это все будет тоже прилично.
Предвижу аргумент «фреймворк можно почистить и выкинуть из него лишнее»- а не проще написать 5 кило кода, чем ворошить 50, не зная на все 100% особенностей архитектуры фреймворка?
Сдается мне, что для Javascript просто настало то самое удачное время. Просто сошлись в одном месте условия:
— можно нормально обеспечить кроссбраузерность
— все браузеры вполне нормально начали работать с JS без активных тормозов
— мощность машин сильно увеличилась, что способствует переносу обработки на сторону клиента
— распространение Ajax
— появление фреймворков
Все это способствует распространению использования самого JS.
Прошли времена когда Опера например пыталась объявлять себя как IE, подделывая, но не полностью его функциональность.
Золотое время для JS наступило :-)
А про фрэймворки бояться не стоит. Всегда будут люди которым надо «просто», а есть специалисты. И ничего плохого в этом нет ни для кого. Тем кому надо «просто» рано или поздно лежит путь в спецы или заказчика спецов. :-)
— можно нормально обеспечить кроссбраузерность
— все браузеры вполне нормально начали работать с JS без активных тормозов
— мощность машин сильно увеличилась, что способствует переносу обработки на сторону клиента
— распространение Ajax
— появление фреймворков
Все это способствует распространению использования самого JS.
Прошли времена когда Опера например пыталась объявлять себя как IE, подделывая, но не полностью его функциональность.
Золотое время для JS наступило :-)
А про фрэймворки бояться не стоит. Всегда будут люди которым надо «просто», а есть специалисты. И ничего плохого в этом нет ни для кого. Тем кому надо «просто» рано или поздно лежит путь в спецы или заказчика спецов. :-)
Кстати, имхо в JS фреймворки нужны как ни в одном другом языке. В первую очередь потому, что существует много реализаций этого JavaScript для каждого браузера и они не полностью совместимы между собой. Обычному программисту однозначно было бы неинтересно возиться и сглаживать разницы между браузерами.
Вперед, напиши скрипт для проверки на валидность данных в форме отправки письма на мыло (регэкспы- самое простое что будет в этом коде), сброс данных по умолчанию при фокусе на input, выделение если в input введены иные данные, ответ о неверных данных onBlur, счетчик символов в textarea, отправку данных на аяксе, и при этом всем чтобы работало во ВСЕХ браузерах и весь js-код был вынесен в скрипт, а не перемешан с html. Благодаря одному ИЕ код увеличивается в два раза из-за его специфической (чтобы не сказать «кривой») реализации DOM. В итоге я часть js-кода все-таки оставил в html, ради упрощения скрипта.
Вся статья помещается в известную цитату «Учиться, учиться и еще раз учиться». Если не считать пары названий и ссылки, конечно же.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
The Javascript Way