Комментарии 40
Наверное лучше написать «по статистикЕ»
Почему подобные сообщения не отправлять в личку?
Когда опечатка — тогда в личку. А когда весь текст пестрит результатами современного школьного образования — тогда нужно коммент оставить. В данном случае можно было бы и в личку.
«А когда весь текст пестрит результатами современного школьного образования — тогда нужно коммент оставить» — с чего вы решили?
Подобные комментарии: ни как не помогают раскрытию тему обозначенной автором статьи; никак не помогут ее обсуждению и никак не помогут остальным участникам в понимании ее важности или никчемности… Они как по моему: лишь повод «высказаться» человеку которому нечего сказать…
Подобные комментарии: ни как не помогают раскрытию тему обозначенной автором статьи; никак не помогут ее обсуждению и никак не помогут остальным участникам в понимании ее важности или никчемности… Они как по моему: лишь повод «высказаться» человеку которому нечего сказать…
Ну почему же? В случае тотальной безграмотности автора, это «есть что сказать» означает: «автор дурень, грамматика родного языка ему неподвластна. Чего уж говорить о поднимаемой им теме, если он свои мысли грамотно изложить не может». Повторюсь, в данном случае, скорее всего, имела место быть опечатка, сообщить о ней можно было в личку.
Если вы хотите развить тему опечаток, то предлагаю опять же в Личку, если же вам нечего сказать по данной теме, то данную ветвь, в данном топике я считаю бессмысленной.
«автор дурень, грамматика родного языка ему неподвластна. Чего уж говорить о поднимаемой им теме, если он свои мысли грамотно изложить не может»
Ваш чудный слог конечно прекрасно Помогает данному обсуждению, а знания «родного» просто умиляют…
«автор дурень, грамматика родного языка ему неподвластна. Чего уж говорить о поднимаемой им теме, если он свои мысли грамотно изложить не может»
Ваш чудный слог конечно прекрасно Помогает данному обсуждению, а знания «родного» просто умиляют…
Оценки же ставили в дневник, а не сообщали лично. Культ грамотности очень хорош на самом деле. Когда некоторое время перепроверяешь себя на предмет ошибок — вырабатывается грамотность. Тут это заметно слабо, а вот раньше, когда одно закрытое сообщество ещё было тем и там за ошибки обкладывали хyями — я был очень рад каждому замечанию. Именно там меня научили писать тся\ться!
Интересно, чем объясняется резкий скачок в районе начала августа?..
Забавно: с одной стороны jQuery обходит prototype.js, с другой — script.aculo.us обошла jQuery UI (это если смотреть не 10K, а общую статистику).
Это означает что 89% тех, кто пользует prototype юзает script.aculo.us, и лишь 3.6% использующих jQuery юзают jQueryUI.
В моем конкретном случае мне приходилось подключать script.aculo.us лишь для того чтобы сделать простейшую анимацию с помощью prototype, а jQuery ее умеет из коробки. Это может говорить не столько о популярности script.aculo.us сколько о том что prototype не дает каких-то важных возможностей, раз такой большой процент людей пользуется его расширением.
В моем конкретном случае мне приходилось подключать script.aculo.us лишь для того чтобы сделать простейшую анимацию с помощью prototype, а jQuery ее умеет из коробки. Это может говорить не столько о популярности script.aculo.us сколько о том что prototype не дает каких-то важных возможностей, раз такой большой процент людей пользуется его расширением.
Может стоит включить его в браузер? Хотя можно же как юзер-скрипт залить, только вот трафик все равно будет грузить…
В браузер, конечно, её не стоит включать, потому что из первых миллиона сайтов библиотеку использует только 31% ).
А если серьёзно, то она постоянно меняется, в отличие от языка.
А если серьёзно, то она постоянно меняется, в отличие от языка.
Жопу с пальцем не путайте, эти фреймворки решают разные задачи: jQuery создан быстрой и удобной работы с DOM, MooTools для ОО программирования.
«Правда, но отчасти»? Нормальный ООП на jQuery не реализован, его нет. В MooTools это «из коробки». Да MooTools тоже может работать с DOM, а на jQuery с горем пополам можно написать, что-то похожее на класс, используя, например, систему плагинов. При чём тут «порог вхождения» и «более академичен» я вообще не понимаю: у автомата Калашникова тоже «ниже порог вхождения», а танк Т-90 «более академичен», только сделаны они для разных вещей, хоть оба и стреляют.
Категорически советую к прочтению, ибо холивар этот древний как говно мамонта, пора заканчивать спорить. Оба фреймворка очень хороши для своей области.
Категорически советую к прочтению, ибо холивар этот древний как говно мамонта, пора заканчивать спорить. Оба фреймворка очень хороши для своей области.
Вам «ООП» или ехать? Создавать проект на основе библиотеке которая поддерживается как сообществом так и создателями или придерживаться инструмента который в своем развитии Застыл. Вам важен процесс по «паттернам» или важен результат?
Это, простите, кто «застыл»? Mootools? По поводу «ООП или ехать»: я ещё раз повторяю — фреймворки решают разные задачи. Вы вообще писали на js что-нибудь >1000 строчек кода? Когда необходимо иметь по 10 функций на одну страницу, которые должны иметь один контекст исполнения, иметь общие переменные и т.д? Думаю вряд ли, иначе бы подобный вопрос не задавался бы. Или может быть server-side приложения, например под APE, будете на jQuery писать?
Да писал, и пишу более 14 тысяч строк, текущие проекты, разбор «замечательных» soap ответов, включая анализ и коллбэки серверу и постраение интерфейса на основе северных объектов тд… jquery прекрасно справляется со своими задачами. Именно на нем, особенно благодаря отличной модели работы с ajax, data-атрибутами DOM получается отлично построить как работу.
«Или может быть server-side приложения, например под APE, будете на jQuery писать?»
Как «базу» для приложения действительно на данный момент я выбираю именно jQ, я постоянно рассматриваю альтернативы, но данный момент это оптимальный инструмент в разработке приложения практически любого уровня.
Как «базу» для приложения действительно на данный момент я выбираю именно jQ, я постоянно рассматриваю альтернативы, но данный момент это оптимальный инструмент в разработке приложения практически любого уровня.
У jQuery UI разработчики не пользуюися фотошопом. Хотите знать почему?
При пересохранении ресурсов фотошоп не позволяет сохрать такие длинные имена, которые задают разработчики. Удивительно не удобно.
При пересохранении ресурсов фотошоп не позволяет сохрать такие длинные имена, которые задают разработчики. Удивительно не удобно.
>Prototype огорчил, за этот же период потерял 2%.
за полгода постепенно перевел проект с Prototype на jQuery
так что где-то в этих 2% и мои 0.0..5 копеек :)
есть кое-какие вещи, которые в Prototype было лаконичней делать, но в общем с jQuery(+свой FW) стало намного легче работать.
за полгода постепенно перевел проект с Prototype на jQuery
так что где-то в этих 2% и мои 0.0..5 копеек :)
есть кое-какие вещи, которые в Prototype было лаконичней делать, но в общем с jQuery(+свой FW) стало намного легче работать.
Даже не удивительно, уж больно хорош jQuery относительно конкурентов, во всяком случае для базовых задач.
Мне кажется, такие библиотеки не очень подходят для крупных проектов (2-страничный сайт, сверстанный за 2 дня — там конечно использование jQ здорово экономит время и позволяет прикрутить какую-нибудь анимацию за 5 минут). jQuery не очень годится для аякс-приложений и подобных вещей, так как содержит, во-первых, кучу костылей, которые только замедляют его работу, во-вторых он тяжелый и медленный, особенно в ИЕ6-7, в-третьих, содержит перегруженый лишних хламом sizzle (зачем нужен поиск по сложным селекторам типа .class[attr=value]:visible? надо правильно проектировать приложение а не грузить браузер).
Лаконичный синтаксис jQ выглядит мило для простых действий (вроде $(.element).addClass('active')), но он провоцирует на написание неэффективного кода.
Во-первых, вызовы вроде $('.someClass').click(), $(.someClass).css(), $(.someClass).hide() и так далее — крайне неэффективны: вместо того. чтобы ставить 50 листенеров, гораздо выгоднее стаивть 1 — на документ, вместо того, чтобы применять одинаковые css-стили к 50 элементам. выгоднее поменять класс на их родителе (в 1 месте).
Понятно, что грамотный разработчик знает об этом и не станет так писать, но мы-то знаем, сколько процентов разработчиков в наши дни хоть что-то знают дальше подсмотренного на Хабре примера. Таким образом, своими безграничными возможностями jQuery провоцирует написание некачественного и медленного кода (вместо того, чтобы открыть стандарт w3c DOM и quirksmode и подумать головой).
Теперь поговорим о сложных приложениях. В таких приложениях обычно много JS-кода и логики на нем, и там эта библиотека только утяжелит и замедлит работу. Для приложений нужно писать свой, максимально компактный и быстрый базовый фреймворк. Доказательства моим словам — исходный код vkontakte, facebook и google: там нет никаких jQuery. Более того, в приложениях нужны вещи вроде виджетов, контроллеров, моделей и прочего, чего в jQ отродясь не было. А писать такие вещи на jQ чревато злостным нарушением DRY и появлением кучи лиспоподобного (со скобкам и замыканиями) спагетти-кода вместо стройной системы View Controllers.
Ну еще добавлю пару слов про jQuery UI: это кривокод. Загляните в исходники любого класса в нем, например button, и вам расхочется его когда-либо исползовать. Код там крайне неэффективен и написан в упомянутом выше спагетти-стиле.
Езще добавлю пару слов про Prototype/Mootools: расширять прототипы DOM элементов (которые в ИЕ не расширяются) — большая глупость. Где-то была большая английская статья с подробным объяснением, почему. Но если кратко, то host objects — не нативные объекты яваскрипта, их API проприетарен и постоянно меняется и их расширение может вызывать конфликты, труднообнаружимые баги и прочее. Вот ссылка: perfectionkills.com/whats-wrong-with-extending-the-dom/
А, еще по моему не самая разумная вещь — использование костылей типа Class/Extend — в JS нет наследования, как в ООП-языках, и имитировать его неразумно.
Ну а самая неразумная вещь — использовать сразу 2 библиотеки, например jQuery и Prototype одновременно. И вообще, надо помнить, Open Source библиотеки писались авторами в первую очередь для себя, а не для вашего приложения — и не факт, что онив ам идеально подойдут.
Лаконичный синтаксис jQ выглядит мило для простых действий (вроде $(.element).addClass('active')), но он провоцирует на написание неэффективного кода.
Во-первых, вызовы вроде $('.someClass').click(), $(.someClass).css(), $(.someClass).hide() и так далее — крайне неэффективны: вместо того. чтобы ставить 50 листенеров, гораздо выгоднее стаивть 1 — на документ, вместо того, чтобы применять одинаковые css-стили к 50 элементам. выгоднее поменять класс на их родителе (в 1 месте).
Понятно, что грамотный разработчик знает об этом и не станет так писать, но мы-то знаем, сколько процентов разработчиков в наши дни хоть что-то знают дальше подсмотренного на Хабре примера. Таким образом, своими безграничными возможностями jQuery провоцирует написание некачественного и медленного кода (вместо того, чтобы открыть стандарт w3c DOM и quirksmode и подумать головой).
Теперь поговорим о сложных приложениях. В таких приложениях обычно много JS-кода и логики на нем, и там эта библиотека только утяжелит и замедлит работу. Для приложений нужно писать свой, максимально компактный и быстрый базовый фреймворк. Доказательства моим словам — исходный код vkontakte, facebook и google: там нет никаких jQuery. Более того, в приложениях нужны вещи вроде виджетов, контроллеров, моделей и прочего, чего в jQ отродясь не было. А писать такие вещи на jQ чревато злостным нарушением DRY и появлением кучи лиспоподобного (со скобкам и замыканиями) спагетти-кода вместо стройной системы View Controllers.
Ну еще добавлю пару слов про jQuery UI: это кривокод. Загляните в исходники любого класса в нем, например button, и вам расхочется его когда-либо исползовать. Код там крайне неэффективен и написан в упомянутом выше спагетти-стиле.
Езще добавлю пару слов про Prototype/Mootools: расширять прототипы DOM элементов (которые в ИЕ не расширяются) — большая глупость. Где-то была большая английская статья с подробным объяснением, почему. Но если кратко, то host objects — не нативные объекты яваскрипта, их API проприетарен и постоянно меняется и их расширение может вызывать конфликты, труднообнаружимые баги и прочее. Вот ссылка: perfectionkills.com/whats-wrong-with-extending-the-dom/
А, еще по моему не самая разумная вещь — использование костылей типа Class/Extend — в JS нет наследования, как в ООП-языках, и имитировать его неразумно.
Ну а самая неразумная вещь — использовать сразу 2 библиотеки, например jQuery и Prototype одновременно. И вообще, надо помнить, Open Source библиотеки писались авторами в первую очередь для себя, а не для вашего приложения — и не факт, что онив ам идеально подойдут.
Я считаю, что не мудро начинать стартап без использования каких-либо фреймворков, значительно сокращающих время разработки и удешевляющих оную. В противном случае стартап может завершиться, так и не начавшись, из-за того, что js-программер так и не осилил поддержку мультибраузерности, например.
Когда проект выйдет на 1к+ уников, тогда уже можно начинать задумываться об убыстрении и переписывании кода (конечно, если это действительно нужно).
Я не вижу особых проблем в том, что тяжёлый и неэффективный jQuery-код будет вертеться на клиентских машинах, ведь на производительность сервера это никак не влияет, а будет пользователь ждать открытия закладки 0,01 сек или 0,05 сек — помоему никакой разницы нет.
Когда проект выйдет на 1к+ уников, тогда уже можно начинать задумываться об убыстрении и переписывании кода (конечно, если это действительно нужно).
Я не вижу особых проблем в том, что тяжёлый и неэффективный jQuery-код будет вертеться на клиентских машинах, ведь на производительность сервера это никак не влияет, а будет пользователь ждать открытия закладки 0,01 сек или 0,05 сек — помоему никакой разницы нет.
Вы будете плакать/смеяться, сегодня только видел фразу «просто на форумах которые я читал все жаловались на 56Кб веса))) хотя не знаю насколько сильно это влияет на скорость загрузки»
ссылко
ссылко
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
По статистике, более 50% сайтов используют jQuery