Автору следовало бы понять ещё на этапе выбора компонента, что для поиска совпадений по 26К городам надо писать свой поиск, а не пользоваться компонентом, предназначенным для общих случаев, поиска по небольшим массивам (тэги и т.п.).
И поиск этот можно сделать как очень быстрым (поиск по 30К+ городам ~1—3 мс), так и не блокирующим UI (async или webworkers).
Все дальнейшие выводы автора о языке и других компонентах основываются на не соответствии его ожиданий (очевидно, полагаясь на опыт в других ЯП), документации (которую довольно часто не читают) и особенностях (WAT?) JS.
Вы молодцы. Лишь очень немногие проекты, которые делаются на энтузиазме, доходят хотя бы до альфы (а это только начало).
Присоединюсь к мнениям выше, что потрачено на проект 80 т.р. + 62.5 человекомесяца (10000/160) * некая усреднённая з/п. Конечно, это весьма условно и есть ещё много факторов, но это хотя бы даёт (в первую очередь вам) представление о затратах.
Отличный материал для понимания «магии» ангуляра (в первую очередь, принцип работы digest-цикла и вотчеров). В идеале, читать после начала работы с ангуляром, чтобы понимать о чём речь.
Версия мало имеет значения, главное — экосистема, стабильность, преемственность API и далее по списку в моём предыдущем комменте (уже 3-й раз повторил :)
естественно, но вот код, который написан на нем, как правило, «хорошими знатоками» js… мягка говоря, качественным не назовешь.
&
Доводилось видеть… допускает ошибки в js
Да всем, на всех языках программирования, доводилось видеть всякое. Это же не повод экстраполировать.
В общем, вывод очевиден: дело-то совсем не в инструменте (jQuery), а в не очень опытных падаванах. Чем выше популярность языка, тем чаще встречается «всякое». Суть претензии к jQuery в том, что это «всякое» может вполне себе работать, но тут ведь только от падавана зависит желание учиться как делать правильно (и, в идеале, под присмотром коллег-мастеров).
Да, и в контексте вашей версии истории, главный косяк-то в руководстве «аутсорс»-конторы, которое не сумело определить, что товарищ-то пока ещё не совсем опытный для позиции «ведущий фронтендер». Когда в проекте грамотный тимлид и ведущие по своей части, степень бардака резко снижается.
k12th всё правильно написал в комментарии выше. Это уже уровень стратегии развития проекта. Стабильность, популярность, экосистема, поддержка и кол-во спецов на рынке гораздо важнее сэкономленных килобайтов (тем более это всё относительно и со временем сойдёт на нет). Единственное, с чем соглашусь, что подключение увесистого jQuery UI ради одного компонента — моветон, если есть возможность найти аналогичный jQ/standalone-компонент.
Далее вы начали уже мешать архитектуру, фреймворки и UI. А jQuery — это база для кросс-браузерного UI (не путать с jQ UI).
Так что же теперь думает Ваня о своих чудесных предшественниках? и считает ли он их программистами?
Если плагины хорошие, грамотно написаны и поддерживаются, то всё неплохо, как минимум. Гораздо хуже было бы, если
представляли из себя велосипеды не самого лучшего качества, которые никто кроме самих авторов поддерживать не может (и уже не будет). Есть, конечно, вариант, что эти самописные компоненты будут грамотно написаны, оттестированы и заопенсорсены (+ появятся контрибьюторы, соответственно и поддержка). 1) Вопрос: сколько на это потребуется времени? (а время — деньги) 2) Вероятность такого поворота, в контексте вашей версии истории, близится к 0 (пока не придёт Ваня :).
на профессиональном уровне освоил javascript на предыдущей работе, разбирается во многих его особенностях, отлично знает концепции многих фреймворков, из-за чего начал искоса поглядывать на jquery
Никто из коллег фронтендеров не смотрит искоса на jQuery (бывают, конечно, споры / ворчание, но всё же...). Наоборот, все прекрасно понимают его вклад в развитие и аргументы, изложенные выше. Главное понимать, где его использование будет уместно, а где нет.
Если веб-приложение тормозит, jQuery стоит в конце списка, где может быть проблема.
P.S. Есть хорошее английское выражение — «It depends ...». Всё зависит от требований, проекта, браузеров, команды, сроков (!) и т.п. Если проект делается под нормальные браузеры и сроки вменяемые, сами с удовольствием и по возможности делаем standalone-компоненты, там где это уместно.
Мне лично нравится концепт модульности небольших компонентов/либ проекта Component (что это такое, список плагинов, github) — своего рода unix-way для фронтенда (по большей части), но он пока только набирает обороты.
1. var $ = document.querySelectorAll.bind(document) — сильно ограничен в возможностях, т.к. выборка будет всегда с корня; есть ещё такой вариант:
var $ = Function.prototype.call.bind(HTMLElement.prototype.querySelectorAll);
// use:
var somediv = $(document.body, 'div')[10];
var spans = $(somediv, 'span');
2. jQuery силён своей экосистемой, поддержкой и стандартами. Время, когда большая часть браузеров будет нормальными, совсем скоро, соотвественно и ядро jQ будет весить совсем немного (как Zepto ±).
А вы не пробовали сделать на HTML5 стеке + какой-нибудь PhoneGap / Appcelerator? В этом случае убиваете 2-х зайцев: и мобильная версия сайта, и приложения могут выглядеть и работать почти одинаково. И стратегически выгодно, что разработкой и поддержкой занимается свой же отдел фронтенда.
Хотя, конечно, ФБ недавно добавил ложки дёгтя со своим «HTML5 wasn't ready», но парни из Sencha приняли челлендж и сделали довольно шустрый HTML5-клиент.
Сколько книг написано и будет написано… основной сутью всё-равно остаётся, что во главе угла стоит человеческий фактор (peopleware), а инструменты/методологии вторичны.
Специфика Angular UI позволяет юзать .value, потому что у него нет единого предопределённого дефолтного конфига, т.е. подразумевается, что разработчик определит ui.config в конфигурационной части приложения (где-нибудь рядом с app.config).
В вашем случае, нельзя никак поменять часть дефолтного конфига (ну кроме как в исходнике :). Достаточно поменять .value на .constant, чтобы была возможность редактировать конфиг oiFileConfig на этапе конфигурирования в app.config (в котором доступны только провайдеры и константы).
Ещё было бы неплохо вынести тексты ошибок в сам конфиг, чтобы можно было менять их.
В остальном, спасибо за модуль — определённо в закладки ;-)
Не вижу связи с модой. 95-й, это не 82-й. Конечно фактор «быть в то время и в том месте» играет немаловажную роль. Но и немаловажную роль играет кто и как делает проект: не только техническую часть, но и маркетинг, продукт, стратегия, дальновидность инвесторов. Яху был основан в 95-м, Гугл в 98-м, ФБ в 2004.
До Фейсбука ничего подобного не было в англоязычном сегменте сети
Classmates.com — 1995 год. Хотя это и аналог одноклассников, никто им не мешал ещё занять и нишу универов (за 9 лет-то).
Поэтому таки реализация — всё.
Почему для тестов не использовали проверенный годами benchmark.js (в основе jsperf.com)?
Во-вторых, использовать методы getElements{ByTagName, ByClassName /*, etc */} можно просто ради интереса (зная что они возвращают «live» NodeList/HTMLCollection, которые малопригодны для чего-то сложнее простых операций выборки/перебора и своих велосипедов). Но тогда где querySelector{All}?
На данный момент, большинство либ и селекторных движков по типу jQuery работают по одинаковому принципу ± свои оптимизации. Если мы видим значительную разницу в скорости (порядки), значит используются свои обёртки, другие подходы (например просто ф-я, которая парсит селектор, выбирает и возвращает тот же live NodeList/HTMLCollection) или недопустимые хаки (модификация оригинального DOM), но тогда мы теряем в удобстве и скорости разработки, которую даёт jQuery, что гораздо важнее.
Мне кажется в переводе и источнике некорректные данные, в том числе и видео (автор видео какой-то NMANewsDirect, не ясна связь с проектом Hyperloop).
Вот статья в NY Times (15.07.2013), в которой цитируется слова Элона Маска (сентябрь 2012) о поездке из Сан-Франциско в Лос-Анджелес за 30 минут, что говорит о скорости ~1200 км/ч (между СФ и ЛА ~600 км).
Потом, опять же, из статьи можно предположить, что стоимость линии от ЛА до НЙ (4700км) будет начинаться с 47+ млрд. $ (ЛА -> СФ (600км) — 6 млрд. $). Относительно окупаемости: штат Калифорния прорабатывает план по ЖД-линии между ЛА и СФ на 60 млрд. $ (и это скорее всего из бюджета только штата), а уж соединение восточного и западного побережья вполне реально будет поддержано и на федеральном уровне.
И поиск этот можно сделать как очень быстрым (поиск по 30К+ городам ~1—3 мс), так и не блокирующим UI (async или webworkers).
Все дальнейшие выводы автора о языке и других компонентах основываются на не соответствии его ожиданий (очевидно, полагаясь на опыт в других ЯП), документации (которую довольно часто не читают) и особенностях (WAT?) JS.
Присоединюсь к мнениям выше, что потрачено на проект 80 т.р. + 62.5 человекомесяца (10000/160) * некая усреднённая з/п. Конечно, это весьма условно и есть ещё много факторов, но это хотя бы даёт (в первую очередь вам) представление о затратах.
Удачи в развитии проекта. Через тернии к звёздам.
ES7 WIP: Value Objects Operators Overloading
Вы несколько преувеличиваете :)
Ждём продолжения.
&
Да всем, на всех языках программирования, доводилось видеть всякое. Это же не повод экстраполировать.
В общем, вывод очевиден: дело-то совсем не в инструменте (jQuery), а в не очень опытных падаванах. Чем выше популярность языка, тем чаще встречается «всякое». Суть претензии к jQuery в том, что это «всякое» может вполне себе работать, но тут ведь только от падавана зависит желание учиться как делать правильно (и, в идеале, под присмотром коллег-мастеров).
k12th всё правильно написал в комментарии выше. Это уже уровень стратегии развития проекта. Стабильность, популярность, экосистема, поддержка и кол-во спецов на рынке гораздо важнее сэкономленных килобайтов (тем более это всё относительно и со временем сойдёт на нет). Единственное, с чем соглашусь, что подключение увесистого jQuery UI ради одного компонента — моветон, если есть возможность найти аналогичный jQ/standalone-компонент.
Далее вы начали уже мешать архитектуру, фреймворки и UI. А jQuery — это база для кросс-браузерного UI (не путать с jQ UI).
Если плагины хорошие, грамотно написаны и поддерживаются, то всё неплохо, как минимум. Гораздо хуже было бы, если
представляли из себя велосипеды не самого лучшего качества, которые никто кроме самих авторов поддерживать не может (и уже не будет). Есть, конечно, вариант, что эти самописные компоненты будут грамотно написаны, оттестированы и заопенсорсены (+ появятся контрибьюторы, соответственно и поддержка). 1) Вопрос: сколько на это потребуется времени? (а время — деньги) 2) Вероятность такого поворота, в контексте вашей версии истории, близится к 0 (пока не придёт Ваня :).
Никто из коллег фронтендеров не смотрит искоса на jQuery (бывают, конечно, споры / ворчание, но всё же...). Наоборот, все прекрасно понимают его вклад в развитие и аргументы, изложенные выше. Главное понимать, где его использование будет уместно, а где нет.
Если веб-приложение тормозит, jQuery стоит в конце списка, где может быть проблема.
P.S. Есть хорошее английское выражение — «It depends ...». Всё зависит от требований, проекта, браузеров, команды, сроков (!) и т.п. Если проект делается под нормальные браузеры и сроки вменяемые, сами с удовольствием и по возможности делаем standalone-компоненты, там где это уместно.
Мне лично нравится концепт модульности небольших компонентов/либ проекта Component (что это такое, список плагинов, github) — своего рода unix-way для фронтенда (по большей части), но он пока только набирает обороты.
var $ = document.querySelectorAll.bind(document)— сильно ограничен в возможностях, т.к. выборка будет всегда с корня; есть ещё такой вариант:2. jQuery силён своей экосистемой, поддержкой и стандартами. Время, когда большая часть браузеров будет нормальными, совсем скоро, соотвественно и ядро jQ будет весить совсем немного (как Zepto ±).
Хотя, конечно, ФБ недавно добавил ложки дёгтя со своим «HTML5 wasn't ready», но парни из Sencha приняли челлендж и сделали довольно шустрый HTML5-клиент.
--harmony— уже).Хотя опыт написания своего препроцессора со своей версией блекджека в любом случае останется полезным :)
.value, потому что у него нет единого предопределённого дефолтного конфига, т.е. подразумевается, что разработчик определитui.configв конфигурационной части приложения (где-нибудь рядом сapp.config).В вашем случае, нельзя никак поменять часть дефолтного конфига (ну кроме как в исходнике :). Достаточно поменять
.valueна.constant, чтобы была возможность редактировать конфиг oiFileConfig на этапе конфигурирования вapp.config(в котором доступны только провайдеры и константы).Ещё было бы неплохо вынести тексты ошибок в сам конфиг, чтобы можно было менять их.
В остальном, спасибо за модуль — определённо в закладки ;-)
Classmates.com — 1995 год. Хотя это и аналог одноклассников, никто им не мешал ещё занять и нишу универов (за 9 лет-то).
Поэтому таки реализация — всё.
Во-вторых, использовать методы
getElements{ByTagName, ByClassName /*, etc */}можно просто ради интереса (зная что они возвращают «live» NodeList/HTMLCollection, которые малопригодны для чего-то сложнее простых операций выборки/перебора и своих велосипедов). Но тогда где querySelector{All}?На данный момент, большинство либ и селекторных движков по типу jQuery работают по одинаковому принципу ± свои оптимизации. Если мы видим значительную разницу в скорости (порядки), значит используются свои обёртки, другие подходы (например просто ф-я, которая парсит селектор, выбирает и возвращает тот же live NodeList/HTMLCollection) или недопустимые хаки (модификация оригинального DOM), но тогда мы теряем в удобстве и скорости разработки, которую даёт jQuery, что гораздо важнее.
Вот статья в NY Times (15.07.2013), в которой цитируется слова Элона Маска (сентябрь 2012) о поездке из Сан-Франциско в Лос-Анджелес за 30 минут, что говорит о скорости ~1200 км/ч (между СФ и ЛА ~600 км).
Потом, опять же, из статьи можно предположить, что стоимость линии от ЛА до НЙ (4700км) будет начинаться с 47+ млрд. $ (ЛА -> СФ (600км) — 6 млрд. $). Относительно окупаемости: штат Калифорния прорабатывает план по ЖД-линии между ЛА и СФ на 60 млрд. $ (и это скорее всего из бюджета только штата), а уж соединение восточного и западного побережья вполне реально будет поддержано и на федеральном уровне.