Если писать грамотно на jquery то медлено не будет, но очень часто код на jquery это код школоты так как с первого взгляда порог вхождения не высокий. Прошлый век потому что в этом веке стали модны SPA, то есть много логики и в целом кода переехало на клиентсайд (а бэкенд стал stateless — наоборот упростился), это все нужно структурировать, а jquery создан лишь для DOM манипуляции. Еслил хотите jquery это всего лишь винтик в общем стеке.
Поему рискнуть, это как раз самый потенциально толковый интсурмент (особенно для крупных проектов), я их уважаю хотя бы за то что понимают ценностьTypescript (по крайней меня для библиотек/фреймворков).
Если заранее известно что это простая страничка, самодостаточная без шансов на дальнейшее развитие или интеграцию в крупный проект, то никакие горы инструментов не нужны (хотя по мне так подобные простые задачи как раз место, где можно пробовать новые штуки в деле, тк работая с крупными проектами пробовать что-то новое в деле не так просто). Но речь ведь может идти об обносительно комплексных проектах, с длительной стадией разработки и не совсем четкими пдланами на бужующее — в этом случае к выбору инструмента лучше подойти внимательно.
А почему нет, как минимум у вас будет опыт работы с ангуляром2 и далее при выборе инстурментов для новых проектов вы уже сможете решать основываясь на своем опыте, и опыт сам по себе ценен. Только вот вокруг первого ангуляра уже уйма библотек/компонентов, а второй еще этим не особенно оброс, иногда это важный момент (когда нужно быстро что-то сварганить, прототип какой и тд).
Просто: TypeScript, компоненты, директивы, сервисы, контроллеры, роутеры и пр. штуки
Эти штуки помогают структурировать и стандартизировать код, плюсы очевидны, но для мелких одноразовых задач конечно ангуляр может быть не оправдан. Роуты кстати это отдельный компонент, его совсем не обязательно подключать.
TypeScript вообще отдельный разговор с ангуляру не связанный, по очевидным причинам это очень хорошее подспорья для больших проектов где горы кода. MS молодцы что не повелись на все тот же "сахар" в ECMAScript, а решили сдеать по своему.
Кто ангуляр используется знает что лучше вызвать scope.$digest чем $apply если известно что изменения касаются только конкретного scope. То есть запускается обычный таймаут вместо $timeout и потом внутри scope.$digest. А есть еще $evalAsync метод.
Angular Component Router, который во втором ангуляре (но также доступен и в первой версии, где он пока что не слишком стабилен), работает с компонентами. Получается чтобы "по канонам" сварганить страницу нужно как минимум 3 сущности?
внешний компонент который будет взаимодействовать с Router
затем директива которая будет обеспечивать некоторую логику получения данных и тд
затем как миниуму один компонент который будет это логику "рисовать"
Однозначно, я о том и пишу что не тем они занимаются в своих стандартах вот MS и пришлось выдумать TypeScript и разрабытывать его параллельно ECMAScript.
Ваше мнение по поводу использования TypeScript, допусим для крупных проектах с распределенной командой? Разве эти миксины (mixins) не снесут крышу если ими слишком увлекаться (что откуда взялось проследить будет болью ибо все динамично — по канонам скриптинга)? По мне так TypeScript движется в верном направлении, в отлии от ECMAScript которые все добавляют и добавляют «сахара» (хотя TypeScript понимает большинство плюшек новых ES).
Насколько я понял потому что проблема системная, код ведь не сам такой стал, его таким сделали разработчики, которых такое состояние вроде как устраивает.
Не хочу писать много, похоже вы не особо пытались разобраться в ангуляре, а сразу начали его «чинить».
как поступать, когда в загруженном содержимом присутствуют блоки, содержимое которых также загружается или генерируется динамически?
Каждый такой «динамический» блок оформляется директивой, и далее директива сама думает где взять данные для себя (отдельный запрос, reduce из пачки данных, что-то реактивное и тд) и что с ними делать дальше.
к тому же в 1.5 появятся компоненты
Компоненты, которые по сути простая обертка над директивой.
Кроме этого выбор технического вуза тоже о чем-то говорит. Я вот тоже инженер «не программист», больше по части электроники и автоматизации, однако код писать начал еще до университета даже не имея компьютера дома.
Как правило собственная инициатива подразумевает увлеченность, энтузиазм, а такие программисты обычно хорошие, возможно вы просто слишком самокритичны.
Плохие это которых мама/папа заставляют идти в программисты, хорошие программисты сами такими становятся, часто начиная с самого детства по собственной инициативе.
Эти штуки помогают структурировать и стандартизировать код, плюсы очевидны, но для мелких одноразовых задач конечно ангуляр может быть не оправдан. Роуты кстати это отдельный компонент, его совсем не обязательно подключать.
TypeScript вообще отдельный разговор с ангуляру не связанный, по очевидным причинам это очень хорошее подспорья для больших проектов где горы кода. MS молодцы что не повелись на все тот же "сахар" в ECMAScript, а решили сдеать по своему.
Ну а что вы хотило это ведь facebook == php like подход
как раз TS это позволяет делать, это ведь и есть ECMAScript + опциональная типизация
Каждый такой «динамический» блок оформляется директивой, и далее директива сама думает где взять данные для себя (отдельный запрос, reduce из пачки данных, что-то реактивное и тд) и что с ними делать дальше.
Компоненты, которые по сути простая обертка над директивой.
Такое вроде бы обычно называется Generics, «Типы как ограничения» совсем не звучит.
Сейчас похоже qTox самый толковый клиент, кто-то может оценить?