- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
которая сопровождает наиболее ходовые фреймворки типа jquery/prototype
конечно. По невменяемости тягаться тяжело. Пусть будет ИМХО.
Так ведь и php-программисты медленно но верно,......
Я всегда считал, что интерфейс всегда первичен.
Вот именно. Если так, то для Вас, скорее всего, фреймворки и полезны. На мой взгляд, достойный функционал и без сложного GU интерфейса(не путать с юзабельностью) будет и нужным и полезным
конечно. По невменяемости тягаться тяжело. Пусть будет ИМХО
Ну да. А код сгенерированный .NET или запросы построенные через ORM вменяемые? Их тоже в топку? Или все-же цена разработки и сопровождения на первом месте?
Если так, то для Вас, скорее всего, фреймворки
Да не для меня. фреймворки - основной вектор развития. В ASP или Ruby он был с самого начала, В PHP и JS он просочился 3-4 года назад.
достойный функционал и без сложного GU интерфейса
Я плохо представляю надобность сложного js-функционала без наличия взаимодействия пользователя с интерфейсом. Придумать симулякр конечно можно, но если использовать готовые решения он будет дешевле и в разработке и в сопровождении.
но если использовать готовые решения он будет дешевле и в разработке и в сопровождении.
А кто же с этим спорит. Конечно, использовать собственные готовые наработки. Куда же без них. А на возможные собственные баги натягивать еще и баги чужие - зачем?
А на возможные собственные баги натягивать еще и баги чужие - зачем?
При прочих равных, количество багов - это производная от интенсивности тестирования. Я нисколько не сомневаюсь в вашей квалификации, или квалификации большинства остальных критиков jQuery/Prototype, но самописные фреймворки как правило тестируются на много порядков менее интенсивно чем продукты массовые - типа jQuery. Поэтому вероятность нарваться на баг с использованием массового продукта намного ниже. К тому же известный баг - это не баг. Это фича.
К тому же известный баг - это не баг. Это фича.
Ну философия, это замечательно, как и чуство юмора. Но исправить свой баг - это дело нескольких часов, самое большее. Исправить гквери - =))) почти смешно.
На счет тестирования - это все от лукавого. Если какой-либо модуль работает на 1-2 проектах с посещаемостью в 2-3 к в сутки в течении нескольких месяцев , это дает 99% уверенности что все ок.
T.R.O.N, есть один несомненный плюс в использовании фреймворков - это простота написания кода, другой вопрос что использование того же jQuery только ради одной/двух функции не разумно,
а вот если фреймворк используется по максимуму то писать свою библиотеку (практически с теми же функциями) уже не кажется таким разумным ;)
Если какой-либо модуль работает на 1-2 проектах с посещаемостью в 2-3 к в сутки в течении нескольких месяцев , это дает 99% уверенности что все ок.
У вас баг на форме сообщения об ошибках :)
T.R.O.N использование того же jQuery только ради одной/двух функции не разумно
соотношение числа функций/разумности - вопрос времени. ТРОН до сих пор уверен что нет такого функционала ради которого нужно использовать стандартные средства разработки, А у вас планка дошла до 4+ функций.
У вас баг на форме сообщения об ошибка
да когда же Вы человеческими понятиями начнете мыслить... Откуда же такое жаление при виде мухи хвататься за артиллерию....
а вот если фреймворк используется по максимуму то писать свою библиотеку (практически с теми же функциями) уже не кажется таким разумным
скажите, а разве за время Ваше работе с JS, до появления гквери, у Вас не появилось все необходимо и так?
burunduk, Когда человек знает основы, именно знает и понимает их, и когда задача оправдывает средства, уже не важно, что и как будет использоваться. Если же народ кидается изучать и использовать гквери не понимая что и как на самом деле происходит внутри (хотя-бы на уровне приблизительной модели)- это страшно. Потом появляются вопросы "если нужен AJAX нужно-ли знать JS".
PS Просто от себя, мне не нравится не модели выбранные в прототипе и гквери, ни то как они написаны. Это как машина, в одну садишся - "мое", а к другой и подходить не хочется, независимо от значка на радиаторе...
скажите, а разве за время Ваше работе с JS, до появления гквери, у Вас не появилось все необходимо и так?
не совсем, т.к. я не прогер и поэтому решаю вопросы по мере их поступления,
т.е. мне понадобилось работать с dom я изучил что это и с чем это едят, соответственно попробовал реализовать необходимое мне наиболее простым способом :)
Предлагаю вашему вниманию свой видеокурс по JavaScript, так сказать с пылу с жару. Сейчас опубликовано 4-е видеоурока, которые (по моим задумкам) должны дать общее представление о синтаксисе JavaScript, основных конструкциях и операторах. 4-й видеоурок начинает знакомить слушателей с ООП в JavaScript и далее полезу закапываться в DOM.
Надеюсь видеоуроки окажут пользу в освоении JavaScript и упростят процесс знакомства с AJAX. В любом случае, JavaScript, не смотря на все его минусы, очень полезен.
Вот ссылка на видеоуроки.