Блог

Angular hosting server

Ой, почти ничего не умеют. Mixins умеют? Overrides умеют? Hooks умеют? Dependency resolution умеют? Господи, ну хоть статические свойства классов-то умеют? Неа, всё ручками. Пилите, Шура, пилите Вообще очень печально, если вы не можете понять разницу между решениями хайпо-модно-молодёжными и реально полезными. Впрочем, это не только ваша проблема, это общая головная боль по больной на голову индустрии. Чем конкретно крут webpack? По пунктам, если не трудно; бонусные баллы за объективное сравнение с другими решениями.

Подозреваю, что дальше "webpack крут, потому что его Angular же использует! Да чего ж не верить? Печально, что кроме библиотеки виджетов вы ничего не заметили или не оценили. Вы мне сейчас напоминаете этот бородатый анекдот про солидную компанию с богатой историей, которая наймёт на пол-ставки студентов на подработку.

Обещаем доширак сильно не задерживать! У нас с вами очень разные понятия о полноценности таких интересных компонентов, как grids. И об уровне допустимого качества, очевидно.

И даже, рискну предположить, "сёрьезность" компаний мы воспринимаем весьма по-разному; хотя, на мой взгляд, тут дело скорее в задачах, нежели в компаниях. С "бесконечной" прокруткой, страничной подкачкой по запросу и прочими весёлыми штуками. Ну, вот дураки там сидят, не осилили сами-то запилить. Или про один забавный и крайне несолидный НИИ в Швейцарии, который там коллайдеры всякие гоняет туда-сюда, а данных-то с них терабайт или что-то.

Визуализировать надо, для обработки и анализа. Тоже идиоты, ха-ха, да плёвое ж дело самим-то налабать. Или, наконец, про то, как один скромный университет зачем-то захотел, чтобы grids не просто работали даже с клавиатурой, а ещё и с экранными читалками тоже, для слепых.

Ну, это ж вообще любой школьник умеет, чего там делать-то. Мог бы рассказать, но зачем? У вас уже всё солидно, Clarity хватает со всеми багами, значит всем остальным тоже должно хватать. Вообще ни при чём, кроме того, что многие организации до сих пор Windows 7 используют и IE И модернизироваться не собираются. Ну, вам-то там в воображаемом мире конечно недосуг во все такие мелочи вникать. У вас там бабочки порхают, единороги прыгают, и все юзеры только пальчиками в айфоны последней модели тыкают.

Мне всё равно, кто что не умеет. Я отвечал на вопрос: Подобия достигайте, ваше. Тестами закрыть не забудьте только, а то открытий чудных много предстоит.

Опять же из опыта говорю. Да простые, типа таких: Чем они могут оказаться полезны, объяснить или сами догадаетесь? Да вот такой, простой. Класс Foo зависит от класса Bar, и использует Qux. При загрузке класс Foo не создаётся, пока не загрузятся Bar и Qux, со всеми своими зависимостями. И в динамическом языке, ага. Работает уже лет 8. И инструментарием поддерживается для сборки.

А вы дальше там простыни import -ов ручками пишите, удачи. Статические свойства классов. Вы давайте, приводите примеры в ES6, не стесняйтесь. Я-то свои слова подкрепить могу в любой момент, зря что ли этот кусок перелопачивал и тестами закрывал.

битрикс 1с франчайзи torrent

Забавно, у вас так бомбит, что вы скатываетесь в обыкновенное плоское хамство. Вы такой тут опытный эксперт, а все кругом плебеи, голова не жмет? Я вам тут ничего не продаю и ничего доказывать не собираюсь, научитесь для начала манерам, а потом будем пытаться строить диалог. Если же все-таки нужно, гуглите, не стесняйтесь — объяснить как это делается или сами догадаетесь?: Да зачем же скатываетесь, и не выкатывался. Это разве не общепринятый в местных пенатах тон?

Вы будете смеяться, но таки да, опытный эксперт. Про плебеев это вы сами придумали, но мне правда становится чуточку смешно, когда люди начинают спорить со мной о вещах, которые я разрабатывал. На том и закончим беседу, если не возражаете. Про гугля не переживайте, разберусь как-нибудь. А используется этот браузер ещё много где, и использоваться будет ой как долго.

Ну, вот реальность жизни. Если вы хотите писать ES6 код, то вам придётся использовать инструментарий для переваривания этого кода в ES5.

Работает хорошо, протестирована неплохо и сюрпризов не преподносит уже. А вот теперь внимание, вопрос: Вот товарищ выше утверждает, что очевидно. Спасибо за пример, выглядит забавно. Наследуем от функции, которая возвращает функцию-конструктор. Что лучше читается? А если 10 таких mixin? А если все эти классы не пихать в один файл, а разбить для читаемости на отдельные? Мне-то всё равно, загрузчик зависимости отследит и подкачает в нужной последовательности.

Но это ещё полбеды, я могу про overrides рассказать и как оно с mixins сочетается. Или про то, как можно вклиниться в процесс создания класса и декорировать его по необходимости. Или про то, как родительский класс может делать всякие хитрые штуки с наследником.

Или ещё что-нибудь интересное, там. Но вот беда, вся эта полезность ужасно архаична, сомнительна и немодна. Зато работает хорошо. Я и сам писал раньше свою классовую модель с умными примесями, которые позволяли примешивать конфликтующие примеси, но требовали выбирать реализацию при использовании.

Но преимущества TS — решают. Нет, не перестал и вряд ли перестанет. Любая сложная система требует изучения и использования документации, это как бы данность. Когда-нибудь пробовали писать нативное Win32 приложение? Или томик Advanced Unix Programming вместе с батареей манов, если вы с другой стороны баррикад?

Изучать не надо! Оно всё само! Няшная картинка, аж слеза наворачивается. Я вам страшную штуку скажу: Да ладно, чего греха таить, все писали.

Ничего страшного, пройдёт, главное не забыть потом руки помыть. Конечно мелочи, ерунда. Всего-то полмиллиона строк кода в фреймворке надо будет переписать и протестировать, чтобы перестать чувствовать себя калекой. Вот именно такие аргументы вы и излагайте вашим клиентам, когда решите сломать поддержку старого API чуть более, чем полностью, ради абстрактных будущих стандартов, которые ещё и не везде работают. А чтобы не сломать и поддерживать смесь старого с новым, надо малость мозгами пошевелить.

Шевелят активно, но тема чуточку непростая и для решения проблем нужно время. Работающий инструментарий планируют в следующей версии. Горбатого могила исправит. И горбатость ExtJS далеко не в классовой модели. Более вменяемая архитектура потребовала бы в 10 раз меньше кода для того же объёма функционала. Обожаю смотреть, когда сперва обсирают, скажем, Perl за слишком высокую плотность и нечитабельность кода, а потом с умным видом то же самое делают в JavaScript.

Пусть даже и разные люди. Браво, автор! Жжи ещё! Товарищ, верь: В переводе на простой русский язык ваша позиция выглядит примерно так: Бывает также и плотность, которая мне понятна и нравится, и это хорошая, годная плотность.

настройка vps сервера услуги

Почему-то вам даже не приходит в голову, что кому-то может представляться всё с точностью до наоборот. Но вы не переживайте, вкусовщина всегда была и будет фактором при выборе тех или иных технических решений, безотносительно объективных достоинств и недостатков. Какие критерии и методики измерения вы использовали для определения полезности той или иной плотности кода? Поделитесь, будьте добры. Особенно интересно про снижение количества синтаксического мусора и семантической нагрузки в коде, при повышении плотности.

Ещё раз: Можно ссылками на чужие научные работы, тоже хорошо. Пока я вижу только голословные утверждения, основанные на чьём-то мнении. Цикл for и операция map семантически не эквивалентны, скорее даже ортогональны: Цикл for можно прервать заранее, можно изменять значение счётчика внутри цикла, и.

Несущественной деталью поведения эта разница может являться только в тривиальных случаях, которые и так особой смысловой нагрузки не несут. И да, не надо пытаться продать мне функциональный подход. Я функциональщину нежно полюбляю и использую там, где она подходит, уже давным-давно. Методика озвучена, давайте теперь результаты исследований. Желательно опубликованные в научных изданиях, но и предпечатные манускрипты тоже подойдут.

Ну, или хотя бы черновики из подготовки к печати. Тема очень интересная, готов сделать скидку. Сперва вы делаете магические пассы руками и рассуждаете о семантической нагрузке конструкций в общем, потом оказывается, что речь уже идёт о конкретных примерах кода. Так всё же, А или Б сидели на трубе? Давайте уже сойдёмся на том, что никаких доказательств у вас скорее всего нет, и вы пытаетесь притянуть за уши аргументы в пользу своих предпочтений.

Я ничего не имею против ваших предпочтений, даже более того, склонен многие из них разделить, но принимать их как истину без веских доказательств не намереваюсь. Религиозные войны обычно с того и начинаются, что кто-то пытается продать другим людям своих личных тараканов под видом абсолютной истины. Не трогайте моих тараканов, а я не трону ваших. Дело даже не столько в том, что код с JSDoc занимает в 5 раз больше места, сколько в том, что JSDoc не обладает описательной мощностью.

Фактически JSDoc — это кривая статическая типизация для динамического языка. Сейчас есть более вменяемые инструменты статической типизации в виде Flow и TypeScript. Это не значит, что нужно всё бросать и срочно переписывать миллион строк говнокода да-да, мне приходилось погружаться в это чудо с головой.

Но эта вот технологическая устарелось уже даже не на сегодняшний, а на вчерашний день, — причина по которой толковые разработчики не горят желанием выбирать его для будущих проектов. Объектное Реактивное Программирование Там описывается техника, реально позволяющая писать в 10 раз меньше кода, чем в том же ExtJS. Реактивное Программирование даёт хороший буст к производительности программиста и уменьшению багоёмкости производимого им кода.

Это называется "не поддерживается", а не "не работает". И, вообще-то, давно уже существуют способы обойти это ограничение. Если на PHP или каком-нибудь Perl — то вопросов больше. А если на других языках программирования — то возникает вопрос, почему необходимость компиляции исходников для бакэнда — это давно уже считается нормальным, а то же самое для фронтэнда — ужас-ужас.

К чему привык — то и читается лучше, это не показатель. Цитируя любимого домовёнка: Если не поддерживается, то по определению не работает. И не. Конечно существуют. Один из них мы как раз и используем, а именно, собственную систему классов, написанную на чистом JavaScript и обратно совместимую вплоть до чёрти.

Есть и на всём, что угодно. Ой как я люблю вот такие вот обобщения. Круто как, одним махом — эх! Половину индустрии под одну гребёнку и в мусор. Про считается нормальным — это вы вон тем, вышесметённым в мусор расскажите. А потом вас догонят извращенцы, которые на серверной стороне JavaScript пользуют, им тоже расскажите.

Потом и я могу свои пять копеек вставить, если желание не отпадёт. Лично мне IDE вообще до одного места. Я бОльшую часть времени всё равно у браузера в отладчике живу, ну и в консоль одним глазом посматриваю.

Не имею такой привычки. Зато сарказм иногда через край капает, прошу прощения, если невзначай обидел. В намерения не входило. Про PHP я не в курсе, не эксперт. А вот как минимум про Perl и Python вы глубоко ошибаетесь: Ruby тоже, если мне склероз не изменяет. Вы прям мастерски через край сарказмируете, что…… хотя нет, сарказмом тут и не пахнет, ведь этот прием построен на игре между прямым и подразумеваемым смыслами.

Тут скорее самодовольная глумливость и покровительственная хамоватость. Почему же, ещё как входит. Просто как-то так получилось, что на меня обычно падают задачи архитектурного плана, которые требуют переворошить половину кода.

Все люди разные, кому-то нравится блестящие виджеты полировать, а мне вот по душе выжать соки из набора тестов и сделать, чтобы прогон pull request занимал не час, а полчаса. Или отбить в тряпочку все компоненты, чтобы поймать утечки памяти и заткнуть дырки, чтобы больше не текло.

Или добавить поддержку accessibility там, где оно в принципе не росло. Такие интересные штуки часто требуют глубокой хирургии, когда кода пишешь мало, а тестов дофига много, и потом гоняешь-гоняешь-гоняешь вдоль и поперёк, чтобы не дай бог что не сломалось.

Можно на месяц-другой занырнуть и морщить лоб, а потом ещё в кучку всё это собирать. И основная работа идёт именно в браузерах, а IDE тут никаким боком не поможет. Ну и баги надо фиксить, куда без. Особенно вызванные вышеупомянутой хирургией, бывает что и пролезают, сколько ни тестируй. Хотя вот иногда и без IDE трудно.

Приблуда, которая тесты через WebDriver гоняет, написана на Java, и надо и её тоже переворошить, чтобы результаты стабильнее возвращались. Глаза в кучу Тут вам бы прикинуть, что возможно есть более эффективные инструменты, не приводящие к продолжительным сессиям отладки после каждой написанной строчки. Понюхал старик Ромуальдыч свою портянку и аж заколдобился… Ну вот, что я могу вам на это сказать?

Видимо, вы какой-то особенный гигант мысли, способный по полутора симптомам и двум строчкам кода вникнуть, решить и пойти. Завидую и преклоняюсь, преклоняюсь и завидую. У меня вот, бывает, дни уходят, да какие дни — недели. Как в том случае, когда невинная вроде на вид JavaScript конструкция роняла процесс IE7 с segmentation fault.

Там тоже в отладчике пришлось пожить, только уже в Visual Studio. Да и ничего, потужился малость и нашёл баг в mshtml. В случае клиентов Sencha это как раз я и ещё несколько таких же болезных. Не использовать отладчик в браузере или не использовать отладчик вообще? В первом случае практика обычная в вашем случае и не применимая в моём; второй случай был бы слишком прискорбным, чтобы о нём думать. Исходники чего, браузеров? Я уже который раз пытаюсь объяснить, что большая часть моего времени уходит на борьбу с браузерами и их различнейшими косяками.

Один и тот же JavaScript код может вести себя по-разному в Chrome и Edge. В какие исходники вы будете смотреть, когда из-за невинного вроде бы изменения конфигурации тестовой системы у вас начинают наглухо зависать тесты в IE11? При прокрутке строк в компоненте Tree с определённой конфигурацией, если прокручивать примерно по 10 строк, то на 20 или 30 строке случается "прыжок" обратно на 10 строк, после чего прокрутка срабатывает нормально.

Это описание из реального тикета, который меня попросили посмотреть. Читайте код, пронзайте силой мысли.

Дружим Angular с Google (Angular Universal) / Хабр

Отладчик не использовать. Удачной охоты, время пошло. Вы мне про Фому, я вам про Ерёму. У вас такая потребность возникает редко, у меня. Просто примите как данность, ладно? Отладка самого браузера в исходниках или машинных кодах тоже бывает иногда — к счастью, редко. В основном отладка нашего кода JavaScript, который ведёт себя по-разному в разных браузерах, из-за особенностей и косяков этих самых браузеров. Я никак не могу взять в толк, каким образом мне помогла бы IDE и каким образом я могу обойтись без отладчика в браузере, если проблема специфична для браузера.

Впрочем, мы уже по десятому кругу повторяем одно и то. Мне уже времени жалко, давайте что-нибудь более интересное обсуждать. Отладчик JavaScript в браузере чем поможет? Ну не знаю, пошагово инструкции пройти или там переменные посмотреть. Прерывание поставить, посмотреть что происходит и откуда что приходит. В DOM заглянуть. Обычная отладка, в общем. Иногда код исполняется одинаково, иногда. Чаще всего проблемы не в исполнении JavaScript кода как такового, а в других частях браузера: Все эти объекты нативные, спецификацией JavaScript не закрыты и отданы на откуп производителям браузеров, иногда возникает разница в поведении.

Ну, и баги тоже бывают, куда без. Отладчик JavaScript как раз и помогает увидеть, как определённые вещи делаются в определённом браузере, и сравнить поведение с другими. Одна из основных задач фреймворка — обеспечение одинаковой работы пользовательского кода во всех поддерживаемых браузерах.

казахстанский хостинг игровых серверов

PS на всякий случай поясняю — это шутка, в незнакомом проекте я за такой поиск бага не возьмусь. Вот в знакомом — другое. Впрочем, код и правда весь доступен для просмотра, вместе с тестами и прочей обвязкой, так что если будет интерес покопать весьма нетривиальные проблемы, заходите.

Отлично, по первому пункту возражений не возникло. А теперь маленький ньюанс: Пол-дела сделано, осталось уговорить Рокфеллера. Это был такой забавный косяк в нашей реализации Jasmine, вылезший во время очередного раунда профилировки: Специально даю контекст, чтобы было понятно: Я никогда не утверждал, что IDE не будет полезна. Я всего лишь утверждал, что IDE не так полезна мнекак может показаться вам с вашей точки зрения. Ну вот, просто ради мысленного эксперимента допустите, что у нас с вами совершенно разные задачи?

Angular SEO на хостинге Firebase - Блог Front-End Developer'а

Ваша IDE умеет запускать код в десятке различных браузеров, ослеживать разницу поведения и решать, в каком случае и как эту разницу обойти? Подскажите, что это за волшебная IDE. Это больше говорит о низком качестве вашего QA. Либо о высоком качестве QA этого самого Unity, чем бы оно ни. Согласен, но эта идея была построена на неверной посылке: Это не совсем так, существуют плагины Sencha для популярных IDE.

Не могу сказать, насколько они хороши или плохи, так как сам ими не пользуюсь. К сожалению, это факт — работа разработчика фреймворка мало пересекается с работой собственно пользователей этого фреймворка. Я пытаюсь этот разрыв сокращать, периодически работая над какими-то персональными проектами на базе Ext JS; dogfooding очень помогает лучше понять болевые точки пользователей. Про IDE я в курсе, большинство моих коллег тоже ими пользуются — если не ошибаюсь, в основном JetBrains.

По крайней мере последнюю пару лет, раньше я действительно больше занимался разработкой и меньше улучшениями. Как человеку, съевшему три собаки на отладке и тестировании кода, такая мысль прийти мне в голову не может в принципе. И в этом тоже, но скорее дело в специфике ваших приложений.

Если вам не нужно работать с клавиатурой, фокусом и соблюдать требования по доступности, то это снимает изрядную долю проблем. Наш фреймворк должен всё это обеспечивать, и ситуация усложняется многократно. Ваша преданность делу Microsoft достойна уважения, но предположительные причины оной восхитительно сомнительны и чрезмерной весомостью не располагают.

Засим позвольте откланяться и не задерживать вас более от дел солидных своей непредусмотрительно бессмысленной светскою беседой. А по делу, то вам IE поддерживать надо, то не надо? Или инструмент расово неверный и религия не позволяет? А по делу, IE нам поддерживать надо и поддерживаем. Даже распоследняя версия фреймворка работает в IE8 и тесты проходят большей частью.

А вот TypeScript нам нафиг не упал по многим разным причинам, в. И я пытаюсь донести простую мысль, что не надо пытаться чесать всех под одну гребёнку и уповать на панацею от абсолютно всех болячек имени доброго и бескорыстного доктора Майкрософта. Просто ради понимания моей перспективы, представьте что всё наборот, я работаю в Microsoft и жить не могу без TypeScript.

Как-то вы так лихо перескочили с фразы " большинство проблем решаются с помощью TS" на "всем TS, я создал, кто не в TS, тот лох". TS вполне себе годный инструмент хоть это и MS и со своими задачами справляется ну просто на ура.

Никто никому ничего не продает и уж тем более не гонит на святую сенчу: А вот вы пишите, TS не упал. И я знаю, что вы таки знаете толк в велосипедах: Так что нет уж, пардоньте. Это не я прыгаю. Я просто пытаюсь отбиваться от товарищей, назойливо тыкающих в лицо разными Авторитетными Решениями. Вот, хорошее замечание. Теперь сделайте следующий шаг и допустите, что существуют и другие годные инструменты, справляющиеся со своими задачами так же на ура.

Да богов побойтесь, Сенча ни разу не святая и Ext JS полный говна кусок. Никакого другого мнения вы от меня никогда не услышите. Не совсем понимаю спектр вопроса. Лично я пробовал, или команда Ext JS? Правда, потом открыл для себя свет исуса прелести полностью динамической типизации, переметнулся на тёмную сторону и взад больше не смотрел.

Остальные товарищи по команде тоже пороху нюхали изрядно; начальник наш вообще эксперт по Java, большой поклонник C и адепт Microsoft по самое не балуйся. И внедрять пробовали, точнее играться. И с TypeScript, и с другими штуками. Не дают они никаких весомых преимуществ с нашей позиции: Единственный безопасный выход, это оставаться в рамках ES5 и не рыпаться хотя бы до момента, когда старые браузеры отвалятся.

Да чего далеко за примерами ходить, ребята из соседнего отдела уже года три как периодически порываются выкинуть нафиг YUI compressor и заменить его на хвалёный Google Closure compiler. Баги лезут как зелёные черти после пол-литры, аж в глазах рябит. ES6-то тоже поддерживать надо, но как это сделать, чтобы не сломать весь мир — это как раз и есть вопрос на миллион.

Я extjs в последний раз видел в третьей версии и с тех пор больше видеть не хочу: Есть мнение, что грид не должен всего этого уметь.

Angular SEO на хостинге Firebase

Берёте грид, помещаете в него поля ввода и всё. Ну если готовое из коробки работает ровно как вам нужно — это замечательно. Но зачастую требования немного другие и допиливание такого "швейцарского ножа" под себя сравнимо по трудоёмкости с написание велосипеда. При всём заочном уважении, есть мнение, что мсье не знает, о чём говорит. От слова "чуть более, чем полностью".

И всё. Мисье, представьте себе, тоже разрабатывал. Так более аргументированно вы не можете ответить? Могу. Ваш категоричный тон и авторитетные пассы руками два сообщения назад говорят о том, что вы очевидно уверены в своём глубочайшем знании предмета и полной непогрешимости. Хотя если я всё же ошибся и вам действительно интересно, то могу объяснить, почему нельзя просто взять и поместить поля ввода в grid, и всё.

С подробностями и путями решения проблем. Мне, разумеется, интересно. Иначе бы не спрашивал. Моя уверенность строится не на самомнении или религии, а на анализе различных архитектур. А моя уверенность строится на многолетнем опыте разработки той самой Ext JS, включая практически всю поддержку accessibility: Во всех компонентах, в.

Фактически в двух разных фреймворках, которые нынче сливаются в. Которые для поддержки этой accessibility мне пришлось очень глубоко переделывать, иначе ни черта не работало, так как изначально всё проектировалось для тыкания мышками или пальчиками. И суммируя этот многолетний опыт каждодневного бития башкой в бетонную стену, я вам говорю: Так вот, начнём с design pattern.

Keyboard interactionраздел про редактирование данных. Суммируя по-быстрому, нам нужно, чтобы:. Если вы просто добавите поля ввода в ячейки grid, при этом не озаботившись обработкой событий и состояний, то grid не будет в курсе ни о начале редактирования, ни о конце.

Если случился, то пиши пропало — фокус улетел и состояние сломано. Если даже ничего не пропало, то по стандарту рекомендуется заворачивать навигацию с последней ячейки последней строки на первую ячейку первой строки. Всё это требует от grid быть в курсе, что такое редактирование данных в нём же, и даже более того: Далее можно упомянуть такие дружественные к разработчику штуки, как возможность определять тип виджета для редактирования ячейки text input, text area, combo, etcи картинка усложняется.

Далее мы можем вспомнить о том, что данные нужно не просто редактировать в памяти, а ещё неплохо было бы оповещать какие-нибудь сторонние объекты о том, что редактирование записи состоялось. Для этого как минимум нужно понимать, когда у нас редактирование смещается с одной строки на другую, а ещё лучше, иметь возможность организовать транзакционный подход с атомарным подтверждением или отменой изменений.

Это тоже чуточку выходит за рамки понимания отдельного поля ввода, даже очень умного. Далее мы можем вспомнить о случаях, когда набор данных не влазит в экран и нужна прокрутка по горизонтали или, ещё хуже, по вертикали с динамической подкачкой данных с сервера. И чтобы табуляция по полям редактирования работала и в этом случае. И что юзеры имеют привычку начать редактировать ячейку, а потом кликнуть мышкой в другую часть страницы и фокус улетает, а это надо отрабатывать без потерь.

И это даже без учёта специфичных браузерных приколов, типа отсутствия нормальных фокусных событий в Firefox до недавнего времени или идиотской отработки mousedown на scrollbar в IE. И тем более без учёта возможности использовать в качестве редактора какого-нибудь HtmlEditor на базе iframe, а там с фокусными событиями отдельный многоцветный коленкор. Вот берёте все эти конфликтующие требования, смешиваете, помещаете в горшочек и поливаете-удобряете несколько лет, а на выходе как раз получается что-нибудь типа Ext JS grid.

С фичами, плагинами, блекджеком и шлюхами. Безумно сложно, но работает и даже вполне быстро для своих возможностей и уровня совместимости со всем, что движется. Я помню, когда сам был пионером, мы в таких случаях говорили: На таких зайчиков в Долине насмотрелся до тошноты, тут каждый первый стартапчик состоит из этих н баца гениев и потрясателей мироздания.

Выпрыгивают на сцену и вещают, точно как в мультике: Потом обычно налетают лбом на суровую реальность, отскакивают и прыгают в другую сторону. Собственно, именно так и получилось с Ext JS. Автор библиотеки дорастил её до версии 3, продал инвесторам за кучу денег.

Инвесторы наняли зайчиков, те наобещали с три короба с высокой сцены и поскакали лабать версию 4. До основанья всё разрушили, а затем внезапно выяснилось, что свой, новый, мир построить в сроки не удаётся. Потому что, как известно, п деть это не мешки ворочать. А дальше история: Ext JS 4. Вот с тех пор и подчищаем, пытаемся выполнить ещё тогдашние обещания. На мой взгляд даже неплохо получилось, но хайпаровоз уже давно уехал.

Только полезные. Конкретно этот я не считаю полезным, ибо слишком ограничивает возможные решения одним конкретным. Давайте попробуем сами запроектировать поведение Это стандартное поведение, работающее и вне гридов. Хотя оно и не очень удобное. Какие виджеты помечтил — такие и. Но после команды "npm start" он отлично работает, и на локальном сервере он запускается на компьютере. Я думаю, что хостинг-сайты автоматически найдут файл index. Отправьте свое приложение Angular 2 в Firebase с помощью следующих простых шагов: Сначала создайте проект с помощью Angular CLI.

Получить дополнительную информацию здесь https: Откройте консоль Firebase в https: Он откроет браузер и попросит вас проверить подлинность. Войдите в свою учетную запись Firebase. После этого вы можете закрыть окно браузера. В командной строке вы получите сообщение о том, что логин был успешно выполнен. Прежде всего, вас спрашивают, какие из функций клиента Firebase вы хотите использовать.

Вы должны выбрать опцию "Хостинг: Затем клиент Firebase спросит, какую папку использовать для развертывания. Angular команда использует NodeJS, чтобы помочь вам сделать что-то вроде теста вашего javascript или вытащить файлы и настроить все необходимое для запуска небольшого веб-сервера. Итак, все, что вам действительно нужно для "AngularJS app", - это 2 файла: Кроме того, любой веб-сервер, на котором будут размещаться статические файлы, будет работать в основном. Я понимаю, что нам нужно, чтобы nodejs запускал приложение Angularjs, так что у хостинг-провайдера установлены node.

Нет, AngularJS не требует выполнения node. Просто учебник, который вы используете для изучения AngularJS, может использовать node.

Deploy angular app to IIS

AngularJS - это технология клиентской стороны, поэтому для запуска конкретного сервера не требуется. И поскольку вы используете ASP. Net для развертывания вашего приложения. Вы можете посмотреть мою недавнюю разработку ASP. Посмотрите другие вопросы по метке angularjs или Задайте вопрос. Toggle navigation qa. Вопросы Теги Регистрация.