Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
зачем AngularJS если есть Ember JS?
У гугла меньше приложений на ангулар, на ембер их больше!!!
Зачем тогда ангулар?
Если свой фреймворк курит
А также «Зачем iOS, если есть Android», «Зачем Linux, если есть Windows», «Зачем молоток, если есть отвёртка», «Зачем левая рука, если есть правая»...
Вообще всё это дерьмо ни одна уважающая себя компания не использует. Vanilla.js — идеально подходит на все случаи жизни
Вообще всё это дерьмо ни одна уважающая себя компания не использует. Vanilla.js — идеально подходит на все случаи жизниВаапшэта, вы просто ретроград, Vanilla.js — уже давно не в моде, надо как минимум babeljs и очень рекомендуетсо еще и React :)
P.S. Не уверен что этот стек еще будет актуален к моменту когда я нажму «Додати коментар»
Пока вы нажимали кнопку «Додати коментар», появился 5 новых супер джс фреймворков, и 3 кануло в лету.
Да да, я в курсе! Вы правильно подметили: «не в моде». Пока гиганты промывания мозгов(google, facebook и тд ) делают из молодёжи скотов, подсаживая на зависимость от релизов их продуктов, софтварные конторы ищут просто js-разработчиков и пилят свои приложения на «просто javascript». По этой причине их продукты всегда работают стабильно и рационально используют ресурсы на любых платформах.
Что за чушь я прочитал только что?
Пока гиганты промывания мозгов(google, facebook и тд ) делают из молодёжи скотов, подсаживая на зависимость от релизов их продуктов, софтварные конторы ищут просто js-разработчиков и пилят свои приложения на «просто javascript». По этой причине их продукты всегда работают стабильно и рационально используют ресурсы на любых платформах.У вас получилась шутка позабавнее моей :)
Кстати, интересуюсь мнением, если нет необходимости делать single page app, а необходима сложные формы, много ajax и тд. Стоить ли пользовать комбайны типа angular, ember или чего-то еще? Насколько это будет оправдано?
Ну к то работал с React, как в таком случае ведет себя он, избыточен или не хватает?
то есть, процесс — это последовательность форм, такой себе wizard?
Нет. Ну предположим сложная форма добавления товара, с подгрузкой специфичных характеристик в зависимости от выбранного департамента, проверка «на лету» каких-то условий — например в категории «Картины» обязательно должна быть фотография или что при добавлении одежды, сумма состава ткани должна быть 100% и тд.
Второй случай — что-то вроде трекера на гитхабе, с комментированием, назначением лейблов — все через ajax.
у меня не большой опыт, если смотреть за пределы backbone.
осторожно выскажусь, что как минимум для первого кейса MVC(с любым вариантом расшифровки — Controller или Collection) — «занадто».
модель + two ways binding + условная валидация. фиг знает, flux поверх react’a выглядит достаточным(мнение дилетанта :))
второй кейс выглядит посложнее. если там пересекающиеся action flow, еще и с привлечением сервера — че-нить «полноценно-форматное», скорее всего, не будет лишним.
та й не кажи. розумнішим був, енергійним
pajax никуда не делся.
Утрировано, разница между настоящим SPA и pajax в том что первое само конструирует UI, на основе полученных данных, а второе — получает с сервера заготовки UI, которые встраивает в UI
Оба подхода, SPA и pajax имеют право на жизнь.
Общее правило (а потому имеющее тьму исключений)
SPA излишен там, где в целом
UI статичен.
UI не предполагает интерактивной работы с пользователем.
И про MVC. Если отойти от привычной трактовки, то разница между SPA и pajax будет
SPA: Сервер <---> MVC в браузере
pajax: Сервер MC <---> V в браузере
Мы пишем что-то вроде трекера на Гитхабе (кроме прочего) — на AngularJS, работает.
Зачем то, зачем это.... Зачем вообще ВСЕ? Скоро 30 лет в IT, и никак понять не могу — если есть язык С, на фига все остальное?
зачем С если есть ассемблер?
А зачем эти обе две штуки, уже спрашивали?
Внезапно. cloud.google.com
зачем AngularJS если есть Ember JS?Смысл в том, что гугл весь софт для своих нужд разрабатывает сам. Cкорее всего так с ангуляром и вышло. Насколько бы EmberJS ни был хорош, в гугл написали свой фреймворк.
EMBER ПОЯВИЛСЯ ПОСЛЕ ANGULAR!!!
Это не имеет значения, были другие библиотеки/фреймворки, но гугл все равно написал свой.
Я лишь имею ввиду, что вопрос: «Зачем нам (гуглу) Ангулар, если он курит?» — для гугла не стоит. Мы же гугл! Мы знаем лучше, как все нужно писать, и напишем все сами. Логика где-то такая (У меня инсайд, от знакомого из Гугла, есичо).
Мы же гугл! Мы знаем лучше, как все нужно писать, и напишем все сами.а кто усомнится в этом — тому под ие6 разрабатывать всю жизнь!
Є ще KnockoutJS, на самому сайті значно краща документація ніж по AngularJS, хоча на тому ж хабрі — навпаки.
Хіба knockout має речі, які має angular? Директиви, фільтри, сервіси? Я починав с нокаута — може я його неповністю використовував, але це, здається, лише бібліотека для two-way binding.
Не копав. Фільтри сам роблю. Використовую його для ajax-таблиць з фільтрами і редагуванням у модальному вікні.
Для цього вистачає.
Нокаут и есть библиотека для байндинга и тут она имеет все тоже что и Angular — директивы, фильтры. На основании нокаута сделана другая Durandal — вот она и является конкурентом Angular имея систему модульности. Отдельные компоненты сделаны удачней чем в Angular. Если почитать аннонсы, то в Angular 2 перейдут отдельные компоненты и подходы из Durandal.
Только вот дурандал решил отказаться от нокаута в новой версии — пилят свое. Не знаю к сожалению или к счастью :). Сам так и не определился для себя ангулар или нокаут.
В Knockout observable на scope, а в Angular оно само за состояниями следит.
зачем фреймворки когда есть чистый js?
Який буде все одне оформлений у фреймворк через деякий час.
А не заепётесь на чистом js изобретать велосипеды? Затем и нужны фреймворки, чтобы упростить жизнь и сохранить драгоценное время.
простите, забыл добавить табличку <sarcasm>
Ванилла — для хардкора и угара. Не каждый на работе может позволить себе такое — только тот, у кого проект идет неспеша, и заказчики не против такого.
Есть такие проекты, где даже ванилла тормозит, там где css тормозит, там не до фреймворков извините.
там не до фреймворков извинитето, что используется не backbone, а безымянный внутренний — не делает фреймворк не-фреймворком.
Есть такие проекты, где даже ванилла тормозит, там где css тормозит, там не до фреймворков извините.Минификация не помогает?
Мініфікація не прискорить роботу CPU або підсистеми пам’яті.
blog.stevensanderson.com/...one-of-js-2012
можливо щось корисне вичитаєте
Вся история популярности ангулара в одной фразе:
s a front-end framework by non-front-enders for non-front-enderswww.quirksmode.org/...roblem_wit.html
А еще есть Backbone, на котором приложений наверняка не намного меньше, чем на ангуляре и эмбере) А еще jQuery, который юзается чуть ли не на каждом сайте))
Отсюда вопрос: Зачем Angular и Ember, если есть jQuery и Backbone)))
Затем что
Angularи
jQueryнельзя сравнивать
Согласен) просто это у меня был #сарказм насчет впихивания сюда jQuery. Ибо: 1. для каждой задачи лучше подходит свой инструмент, 2. на вкус и цвет все фломастеры разные©: кому-то нравится Angular, кому-то Ember, а кому-то вполне хватает и jQuery) Вот мне нравится Vue.js (разбирал примеры из офф. гайда vuejs.org/guide — ИМХО вполне годно), агуляр в принципе тоже нра, с эмбером дела не имел.
Ну и плюс есть TodoMVC todomvc.com , где показано несколько разных фреймворков, где кстати, тоже есть упомянутый мной jQuery)
Это я все к тому, что Angular vs. Ember — это больше из разряда холиваров. Каждый из них имеет свои плюсы и минусы)
..."I can tell you that there are over 1600 apps inside of Google being built with Angular 1.2 or 1.3.“..
eisenbergeffect.bluespire.com/...ut-angular-2-0
А сколько на ембер тогда, если “на ембер их больше!!!”?
I can tell you that there are over 1600 apps inside of GoogleВ том-то и вся фишка — __внутри__ гугла. А вы назовите
— frameworkName1 лучше
— чем?
— чем frameworkName2
еще не встречал человека который бы внятно, без высосаных из пальца примеров, описал бы практический смысл применения подобных фреймворков.
Single page app, MVC. Если Вы биндите данные через innerHtml, то либо у Вас уже есть свой доморощенный «фреймворк», либо Вы на пректе всегда один, либо с Вами работает близнец, понимающий Вас с полуслова
ну как я и говорил — внятного обьяснения нет.
Меняше кода и SRP блее внятно?
меньше кода по сравнению с чем? Дело не в количестве кода а в том какие великие задачи решают данные фреймворки. Ведь данные так или иначе хранятся на сервере. Можно как угодно манипулировать данными на странице но так или иначе придется повторять бизнес логику на сервере. Разве что выгребать все данные на клиента, иначе даже сортировку на странице с пагинацией сделать нельзя. И вам не кажется идиотизмом делать MVC на клиенте в то время как все равно существует MVC на серверной стороне?
Просто приведите пример чего при нынешних скоростях интернета нельзя сделать (при той же трудоемкости) без применения фреймворков и шаблонизаторов с собственным «птичьим» языком и последующим парсингом страницы.
Вот еще история о переходе (и плюсах этого перехода) на Ember:
blog.intercom.io/...ts-at-intercom
Let’s the backend-frontend holy war begin.
Зачем браузер, если все хранится на сервере? telnet наше все.
браузер именно для того чтобы показывать что хранится на сервере.
Чем не подходит telnet?
картинки с голыми бабами в нем некрасиво. Зачем задаете глупые вопросы?
curl тогда.
Нєкананічна. wget наше все
И вам не кажется идиотизмом делать MVC на клиенте в то время как все равно существует MVC на серверной стороне?А вы вообще понимаете что такое MVC? Зачем оно надо? И чем оно отличается от отрисовки темплейтов?
Да, зачем оно надо, если есть SVC (structure, view, controller)
прекрасно понимаю, хотя есть сомнения в целесообразности применения MVC в вебе (имеется ввиду имплементация в стиле Zend а не идея разделения логики и предтавления вообще) в отличие от десктопа для которого MVC и было придумано.
Использование MVC еще и на клиенте — дикий изврат. В нем был бы какой то смысл если бы браузер непосредственно работал с персистентным хранилищем данных, но браузеры с серварами БД работать не умеют.
прекрасно понимаюСудя по комментарию, таки не понимаете :)
судя по ответу другого аргумента кроме «не понимаете» у вас нет.
МВК (Модель,Відображення, Контролер) — це не класи і не шаблони. Це парадигма. І навіть там, де навіть немає класів, шаблонів, баз даних або методів, може використатися МВК.
Использование MVC еще и на клиенте — дикий изврат.
Изврат — это код а-ля старые сайты на пхп. когда код пхп писался в том же файле, что и html , после чего черт-ногу сломит, где идет html, а где пхп.
Если не нравится отделение запросов к БД (model), html-кода (view) и логики (controller), то никто не запрещает все это (javascript/php/python/ruby/etc-код, html и запросы к базе данных) писать в одном файле. :)
MVC для веба — придуман для того, чтобы отделять мух от котлет (html, css, js и php код — в разных файлах тобишь), чтобы не мешать все это в один трудноудобоворимый венегрет. MVC для десктопа думаю аналогичную функцию исполняет.
З.Ы. И да, MVC разный бывает — один разраб в своем фреймворке его реализует криво, а другой — вполне достойно. Так что дело тут не в самом MVC, а в конкретных реализациях его.
Определить модель и байндинги и фокусироваться на коде много проще и читабельнее чем выковыривать данные из дом в перемешку с логикой. Это по поводу моего комментария выше.
А на сервере не обязательно MVC использовать и дублировать логику уж точно не стоит. Тут дискуссия может разростись. Один из вариантов на сервере выставить API и использовать его из браузера/мобильного клиента и т.д.
И стоит задуматься какую логику лучше выполнять на сервере, а какую на клиете.
чего [...] нельзя сделать (при той же трудоемкости)При той же трудаемкости, наверное, ничего нельзя сделать, если делать так, чтобы его потом можно было номально поддерживать. А придется свой самокат строить.
а не надо заковыривать данные в DOM тогда и выковыривать не придется.
насчет API — все равно за API Должна быть бизнес логика. если надо проверить логин никакие ухищрения на клиенте это сделать не могут. и потом где гарантия что другой разработчик или разработчик другого продукта использующего API сделает все всю необходимую логику на клиенте? API должно по любому закрывать весь функционал
И при чем тут чей то самокат? Я имею ввиду что вообще фреймворки а клиенте бессмысленны, хоть самокаты хоть харлеи.
а не надо заковыривать данные в DOM тогда и выковыривать не придется.Ок, а отображаете вы их как? Все равно с DOM нужно работать из JS, и скорее всего в вашем случае, вперемешку с логикой.
если надо проверить логинЗначит за проверку логина ответственен сервер, в чем проблема?
где гарантияCode contracts?
API должно по любому закрывать весь функционалЕсли пришли к этому — тогда вариант тонкий клиент. Не нужно дублировать логику.
вообще фреймворки а клиенте бессмысленныТолько храдкор, я вас понял.
/
Все равно с DOM нужно работать из JS,в подавляющем числе случаев это нужно не обьективно а потому что разраб решил заюзать очередное модное решение.
Значит за проверку логина ответственен сервер, в чем проблема?Что в таком случае делают фреймворки с целым MVC на клиенте?
Если пришли к этому — тогда вариант тонкий клиент. Не нужно дублировать логику.В подавляющем числе случаев — такой вариант и должен быть особенно с учетом мобильных браузеров — посему возвращаемся к вопросу нафига городить на клиенте целые фреймворки.
нафига городить на клиенте целые фреймворкиЭм.. для удобства?
потому что разраб решил заюзать очередное модное решениеА вы, простите, кто?
Не хочу ООП и SOLID, хочу пыщ-пыщ и в продакшн?
Эм.. для удобства?удобнее в кресле сидеть когда на ангуляре пишете?
Не хочу ООП и SOLID, хочу пыщ-пыщ и в продакшн?Не юлите. ООП и SOLID — не фреймворки.
Что в таком случае делают фреймворки с целым MVC на клиенте?
Такие фреймворки нужны для так называемых single page applications, когда работа с приложением идет без перезагрузки страницы (AJAX, DHTML, вот это всё), и когда время отклика и интерактивность приложения куда важнее тонкости клиента.
В таких приложениях логика, связанная с организацией взаимодействия с пользователем по понятным, надеюсь, причинам, выполняется на клиенте — отсюда необходимость в контроллерах.
Очень часто из соображений производительности рендеринг HTML из данных также перекладывают на клиента, оставляя на «совести» сервера исключительно реализацию бизнес-логики и доступ к данным. Отсюда — необходимость во view и моделях (которые, строго говоря, view модели).
В случаях, когда интерфейс простой и перезагрузка страницы допустима, то, естественно, эти навороты не нужны. Но тренд-таки уверенно движется в сторону SPA — достаточно, хотя бы, посмотреть на Веб-клиенты почтовиков GMail или Yahoo.
Ему не нужно DOM, ему нужно plaintext + картинки с голыми бабами.
А вы точно не тролль?
Это вся ваша аргументация. Посему возвращается к первому посту — никто не может внятно, техническим языком, обьяснить необходимость использования фреймворков на клиенте.
Вы точно не бот? Я выше приводил внятные аргументы. Или мышки плакали и кололись?
это вообще не аргументы. Аргументировать нужно — какую задачу решают данные фреймворки. Решают задачу — означает что других решений нет либо другие решения неэфективны.
Наличие байдингов и MVC не аргумент потому что наличие или отсутствие чего либо вообще не может быть аргументом.
Я вижу, что вы хотите не понять почему это может быть удобно или полезно, а что это не нужно. Если вам не нужно — не используйте. За сим откланиваюсь ;)
а не надо заковыривать данные в DOM тогда и выковыривать не придется.Та немає нічого поганого викоритовувати DOM як сховище та модель. Просто не треба себе обмежувати всілякими дурницями.
угу, давайте выгрузим все данные с БД в браузер навешаем сотни евентов и будем там манипулировать. Обладатели мобильных браузеров будут счастливы.
То что в этом ничего плохого не значит что это надо тупо делать бес сушественной необходимости.
Навіщо завантажувати всю БД? Ви уважно прочитали мій пост? В будь якій системі, яка відібражає дані користувачу, частка даних все одно переміщується на UI. Для того, щоб ефективно з нею працювати, можна використовувати не ланцюг JSON (XML) -> processing -> templating -> HTML, а JSON (XML) -> templating -> HTML (DOM) -> processing.
судя по всему вы просто не работали над веб приложениями
я работаю с веб приложениями почти столько лет сколько лет эти вебприложения в нашей стране существуют.
Именно поэтому не падок на модные веяния в отличие от новичков, которые не представляют что бывают и другие решения.
Досить мірятися, бо я теж можу розпушити хвоста та попавлінити трохи. Сенсу все одне ніякого немає.
Головне не те, скільки років ви займаєтеся певною технологією, а який практичний шлях пройшли та які висновки зробили. Так от, з точки зору архітектури односторінкових продуктів, найкраща методологія для розбудови UI, на мою думку, буде не чистий MVC, а SVC + reactor.
Плюси — менше коду, більше повторного використання, легше вносити модифікації. Мінуси — важкувато для новачків, особливо джикверістів.
Після звикання, здається дивним, як можна розробляти UI не на реакторах...
Можно посмотреть на примеры ваших творений? За 15+ лет должно было нормально накопиться. Или все в интранете и под NDA?
:( Саме так. Деякі системи взагалі тільки з ліцензією можна побачити.
Це найгірша ситуація, яку тільки можна собі уявити. Зазвичай це інформаційно-аналітичні системи, бюро кредитних історій, медіамоніторинг і так далі.
Якщо є бажання — можу зробити презентацію технологій. Зараз працюю над github.com/s0rr0w/z (документація ще не дописана, займуся найближчим часом). На цьому фреймворці зараз розробляється продукт, поки що одне задоволення.
Спасибо, но вопрос был адресован Леониду Украинскому
Ой...
окей, допустим вам надо сделать дашбард для аналитики, есть M анализруемых продуктов для которых есть N(M) показателей (некоторые показатели могут быть связаны), мы хотим иметь возможность сравнивать для разных продуктов однотипные показатели, визуально они могут быть представлены — таблицей, картой (если гео данные), линейным графиком (для даных развернутых во времени), пай чартом, колоночным чартом (должен быть дрил даун) и еще парочка типов визуализации. для данных представленных во времени мы хотим иметь возможность легко и быстро добавлять всякие линие тренда, медианы, среднее и еще куча всего. плюс показатели мы зотим фильтровать/сортировать в табличке и чтобы сразу это менялось на графиках + есть еще огромное кол во настроек по отображению, и других приблуд .
так как изучается огромное кол-во показателей все должно работать в реальном времени, и интерактивно.
а еще у нашего приложения есть вариация для мобилок, айпадов, и с нашим сервером взаимодействуют другие сервисы.
для такого сценария вы просто не обойдетесь без рест сервера, СПА фреймворка на JS, с нормальным слоем модели со связями, роутингами на клиенте, виджетам, дата биндингами, контролерами и еще кучей всего.
это достаточно небольшое типовое веб приложение
Вообще-то для такого есть коробочные продукты из категории BI
Например у нас используется QlikView
а в проектах которые нам свалили в наследство — Pentaho, который в некоторых тоже заменяем на QlikView
Конечно, если у заказчика нет денех на QlikView, и он хочет по дешевке, самодельный функционал, то... либо отказываться от заказа, либо педалить, причем чтобы в разы вышло дешевле чем покупать серверные лицензии QlikView
Конечно, если у заказчика нет денех на QlikView, и он хочет по дешевке, самодельный функционал, то...кейс с точностью наоборот у клиента более чем достаточно денег, он хотел решение которое максимально удовлетворяло его запросам
конечно бывают всякие потребности и исключения из правил.
но из того что вы описали, QlikView делает практически без программиста.
а уж во что сопровождение самописного аналога выльется потом...
Завжди було цікаво потримати цей QlikView в руках. Особливо цікаво на механізм завантаження даних подивитися. Бо дуже разрекламована цяцька
я пробував його. він вартий своїх грошей.
принаймі якщо б мені сказали написати
есть M анализруемых продуктов для которых есть N(M) ...на чом завгодно, я б крепко замислився.
Зі швидкістю як? Особливо на великих об’ємах, наприклад кредитна історія 1 мільона позичальників разом із платежами, щомісячними зрізами стану рахунків тощо..
Зі швидкістю як?все добре з нею, особливо на великих об’ємах. Там же column-oriented memory db. з можливостю інкрементального поповненя.
історія 1 мільона позичальниківу нас один з проектів — система аналізу даних різних лічильників. за один день — пару сот тисяч записів. зрізи — погодинно, по географії, і т.д.
QlikView, як і взагалі BI для того і існують — для аналізу великих об’ємів данних.
Далі вже — Big Data.
А с математикой там как ? можна ли строить сложные модели на основании анализа различных источников данных ?
не совсем понял что такое «сложные модели» в контексте о QlikView
Вобщем, его можно отнести к классу ru.wikipedia.org/...ss_Intelligence
А Anton Kononenko описал функционал (допустим вам надо сделать дашбард для аналитики ...) который реализован в QlikView лучше всего что я видел. Лучше СКД (Система компоновки данных) в 1С, лучше BI компонент пентахо, джаспера.
Десктопная версия под винду — бесплатна. Причем, она же — инструмент «разработчика» на QlikView. Его файлы потом можно выложить на сервер, который браузеру генерит SPA приложение. Которое и встраивается в свой веб код.
Либо, писать самому этот функционал, как в посте Anton Kononenko
ага, поверх Angular’a написанный.
вы ж смотрите, в этой ветке речь о «зачем ваще нужны фреймворки, если я и так справляюсь?», а не про конкретную задачу и что лучше — самописное или коробочное.
ну, для меня вопросы типа
зачем ваще нужны фреймворки, если я и так справляюсь?выглядят настолько наивными, что я их уже как бы и не замечаю. как детский щебет :)
А также «Зачем iOS, если есть Android», «Зачем Linux, если есть Windows», «Зачем молоток, если есть отвёртка», «Зачем левая рука, если есть правая»...
AngularJS старше и популярней: www.google.com/...;cmpt=q&tz=
Так что нужно спрашивать наоборот: чем не нравился Angular, что нужно было создавать Ember?
чем не нравился AngularНеопределенностью в виде ангулара 2.0.
Там же вроде будет поддержка ECMAScript 6, с бекджеком и классами. Как по мне, так это большой прорыв вперед: значительно улучшенный язык + стандратный фреймворк.
Это ж нужно вкручивать какую то компиляцию в проект
Или подождать 1 год.
Думаешь у всех юзеров через год браузеры будут поддерживать ЕS6?
Это самое ожидаемое событие 2015 года (в разработке браузеров). habrahabr.ru/...ft/blog/247229
Но это же не означает что все ломанутся обновлять свои эксплореры.
IE must die. Long live Spartan.
Никто ж не удивляется, что новые игры поддерживают только DirectX 10(11?). Обновят, никуда не денутся.
Добавляешь простенький детектор фич на страничку и просишь пользователя обновить ослик на православную лисичку/хром. Если не хочет слазить — посылаем в лес =)
Интересно сколько процентов юзерков отвалится. И интересно поддержит ли ЕС6 сафари и когда.
Для ЕС6 есть полифилы или 6to5, не?
Я об этом выше написал, не?
И если есть что же ты предлагаешь обрубать юзеров? Такой противоречивый.
Мне правда тут нужно разжевывать, что ЕС5 еще поддерживать нужно, а ЕС3 — уже нет? Количество пользователей ты можешь посмотреть на caniuse.
Мне правда тут нужно разжевывать, что ЕС5 еще поддерживать нужно, а ЕС3 — уже нет?А я просил тебя такое разжевывать? Ты совсем сам с собой заразговаривался.
Уважаемый анонимус, ты спросил как нормальные люди решают вопрос поддержки эксплореров — ты получил на него ответ. Извини, если по каким-то причинам он тебя не устраивает.
Где это я такое спрашивал? Ты еще и не читатель?
На момент создания Ember никакой неопределенности не было.
Я нифига не шарю в ембере, и мне самому было бы интересно узнать что чем он лучше, но что означает эта фраза «У гугла меньше приложений на ангулар, на ембер их больше!!!»? Типа гугл на ембере написал больше апликух чем на ангулар? Откуда инфа?
Гугл на эмбере ничего не написал, он приобретает компании у которых есть проекты написаны на Эмбер, так вот и получается что у компании гугл больше проектов на ембере чем на ангулар
Все равно непонятно откуда так получается, кто именно эти проeкты посчитал.
Сухих данных нет.
Информацию брал с различных конференций, докладов.
Volodymyr Rudyi
Konstantin Kharitonov
Bogdan Shyiak
anonymous
Konstantin Kharitonov
Владимир Черепинский
Yevhen Terentiev
Євген Козлов
Yevhen Terentiev
undefined pointer
Євген Остроухов
anonymous
Victor Mikhaylov
Anton Fimin
Andrii Katrusha
Агнислав Онуфрийчук
Igor Shymko
Vanya Yani
Igor Shymko
Bogdan Parhomchuk
Sergey Grigoryev
Egon Schiele
Sergey Grigoryev
Дмитро
Андрей Литвинов
Igor Golodnitsky
Bogdan Parhomchuk
Олександр Шпак
Тарас З
Bogdan Shyiak
minodvesP Vasya
Петр Герасимюк
minodvesP Vasya
Kirill Danilov
Dmytro Shchurov
Sergii Voloshyn
Dmytro Lapshyn
Artyom Krivokrisenko
Yury Gavrilenko
Vanya Yani
reality_hacker
Дмитрий Вежнин
Oleksandr Bardanov
reality_hacker
Найкращі коментарі пропустити