Ну иногда видел похожие вещи в коде. Зачастую такой код любят писать c promise.All Читать может и красиво а вот с реверс инженирингом начинается батхерт. Если помнить одно простое правило что промис чейнится можно спокойно писать обычные функции и вызывать цепочку. И вот такой огород не нужен.
Единственное когда я таким вот сам лично грешу это когда пишу стабы для апи которого ещё нет. Так сразу видно другим людям что тут когда-то будет апи вызов.
+1 форматирование не признак. С таким же успехом можно говорить что признак плохого js на сайте, если его прогнали через uglify minify.
Конструкторы сайтов больше созданы для end user'ов, а не программистами для программистов.
А вот один большой недостаток есть который в статье не выделили — accessibility. Сейчас это можно сказать "модно" а конструкторы генерят сайты красивые, но абсолютно не юзабельные людьми с ограниченными возможностями (position absolute тут и вправду главный грех, ибо screen reader's парсят страницы иначе)
Ну при том что рассматривается последняя цифра в очень большом промежутке значений (где закон Берфорда как раз и сияет), можно предположить, что он сработает и тут. Соотношения последних цифр будут другими, но вполне возможно, что график будет очень похожим.
Ну в большинстве случаев хватает java decompiler'a чтобы посмотреть был ли изменён байткод и как именно. Не сталкивался если честно уже давно, что нужно что-то написать, чтобы менять байткод уже после компиляции. Для остального в принципе есть аспекты (если уж сильно трубы горят).
Мне интересно это статья для розжига холивара vcs систем или кто-то просто после пятничного пива упал лицом на клавиатуру и случайно получился этот пост? (статьёй это назвать сложно...)
Сколько хейта в одном комментарии.
А если по существу то ангуляр ничем не хуже эмбера, просто надо писать какие-то тяжёлые вещи включая периодически мозг. В эмбере например поддержка скобок вобще идет отдельной либой на 150 КБ. Конечно ангуляр тоже не сахар ведь все биндинги проверяются с очень маленьким таймаутом, но зато всё в коробке сразу.
Понять где директива а где класс или еще что-то можно абсолютно спокойно. Во первых поддержка в иде. Во вторых можно просто для себя ввести кодстайл и не париться. Так что аргумент про поиски класса в элементах считаю более чем неконструктивным. Сейчас вот проект в котором все поля объектов динамические. Я с генерацией всего этого дела на странице пока что максимум в 400 вотчеров впаялся. Это при наличии 60 полей у объекта и редактируемой привязанной таблицей. Ни от каких байндингов при этом не отказываюсь. Везде ng-model с ng-messages и прочие кастомные директивы. Все бегает, даже на смартфоне (что на самом деле удивило). Яичницу надо делать на умеренном огне, и просто следить.
Было бы гораздо лучше если бы в этом цикле статей показать как сварить спринг приложение самому с нуля, а не поднимать spring boot… У новичков все равно останутся вопросы «как оно работает». Да и бут в продакшн кидать не лучшее решение…
Я после университета конечно благополучно забыл как это правильно делается точно, но хорошо помню, что когда мы с одногруппником рожали свои грамматики, то долго мучались именно с order of operation и скобками. Конечно не могу сказать с уверенностью, но помоему скобки должны всё же учавствовать более одного раза.
Скобки в грамматике в таких конструкциях как раз отвечают за order of operation. Лучше составить грамматику я думаю было бы более больно для синтаксиса. Т.к. под каждый случай прийдётся писать доп. правила для скобок.
Ну JSX опять же таки javascript. Да и под него ещё и скрипт надо тянуть отдельный сверху. Но это скажем так скорее вопрос кто как любит склеивать библиотеки, кто-то всё в кучу кто-то отдельно. А синтаксический цукерман почти у всех схож))
Ну полимер это как бы всё же «чисто» веб компоненты. Никакого больше волшебства фреймворка в нём не происходит. Ангуляр предоставляет больше в данном случае. Сравнивать скорее надо polymer и директивы ангуляра, но опять таки одним лёгким движением руки директива попадает под полный digest cycle агуляра в большинстве случаев, и жить отдельно без него просто не в состоянии. Так что тоже сравнение с трамвайной ручкой получается.
Ну если взглянуть на get started на сайте реакта, то именно html внутри js и виден :)
В этом плане подход ангуляра проще, поскольку он работает внутри самой html страницы из коробки. И если чисто теоретически какой-то умный человек отключит js то хотя бы на странице останется хоть что-то из html, что будет показано.
+1. Прошёл тест, и ради интереса даже для JS. Как всегда поражаюсь. Вопросы вида «Which of these organisations is officially responsible for defining » траляля. Зачем они там? Как будто я от этого стану лучше верстать или писать код.
Не могу не согласиться. Но данный пост в данном контексте описывает в таком случае создание велосипеда и не более. Вот сейчас как раз недавно начался у меня один проект. Была спроектирована бд. С флексфилдами и прочим. Потом пришли люди со сфероконями и сказали что ожидали увидеть таблиц 300 а не 7 таблиц которые позволяют описать любой объект динамически. Т. Е. На грамотно составленную дбишником схему просто люди без технических знаний сказали «г*вно». А в итоге головная боль у людей которым это делать.
Зачем спорить о терминах на собеседовании? Факт останется фактом. Когда дело дойдёт до кода, всех менеджеров и прочих будет интесовать лишь один вопрос «как быстро это сделаешь?», а не разговоры о сфероконях.
Умение из рассказа заказчика извлекать нужные сущности и моделировать их корректным образом и есть искусство аналитика
80/20 в деле. Чаще всего заказчик сам не знает чего ему надобно. И если так дотошно его расспрашивать то скорей всего он просто пойдет в другое место, где ему скажут 3 вещи: да, сделаем, N сумма денег.
Ну иногда видел похожие вещи в коде. Зачастую такой код любят писать c promise.All Читать может и красиво а вот с реверс инженирингом начинается батхерт. Если помнить одно простое правило что промис чейнится можно спокойно писать обычные функции и вызывать цепочку. И вот такой огород не нужен.
Единственное когда я таким вот сам лично грешу это когда пишу стабы для апи которого ещё нет. Так сразу видно другим людям что тут когда-то будет апи вызов.
+1 форматирование не признак. С таким же успехом можно говорить что признак плохого js на сайте, если его прогнали через uglify minify.
Конструкторы сайтов больше созданы для end user'ов, а не программистами для программистов.
А вот один большой недостаток есть который в статье не выделили — accessibility. Сейчас это можно сказать "модно" а конструкторы генерят сайты красивые, но абсолютно не юзабельные людьми с ограниченными возможностями (position absolute тут и вправду главный грех, ибо screen reader's парсят страницы иначе)
А если по существу то ангуляр ничем не хуже эмбера, просто надо писать какие-то тяжёлые вещи включая периодически мозг. В эмбере например поддержка скобок вобще идет отдельной либой на 150 КБ. Конечно ангуляр тоже не сахар ведь все биндинги проверяются с очень маленьким таймаутом, но зато всё в коробке сразу.
Понять где директива а где класс или еще что-то можно абсолютно спокойно. Во первых поддержка в иде. Во вторых можно просто для себя ввести кодстайл и не париться. Так что аргумент про поиски класса в элементах считаю более чем неконструктивным. Сейчас вот проект в котором все поля объектов динамические. Я с генерацией всего этого дела на странице пока что максимум в 400 вотчеров впаялся. Это при наличии 60 полей у объекта и редактируемой привязанной таблицей. Ни от каких байндингов при этом не отказываюсь. Везде ng-model с ng-messages и прочие кастомные директивы. Все бегает, даже на смартфоне (что на самом деле удивило). Яичницу надо делать на умеренном огне, и просто следить.
В этом плане подход ангуляра проще, поскольку он работает внутри самой html страницы из коробки. И если чисто теоретически какой-то умный человек отключит js то хотя бы на странице останется хоть что-то из html, что будет показано.
Зачем спорить о терминах на собеседовании? Факт останется фактом. Когда дело дойдёт до кода, всех менеджеров и прочих будет интесовать лишь один вопрос «как быстро это сделаешь?», а не разговоры о сфероконях.
80/20 в деле. Чаще всего заказчик сам не знает чего ему надобно. И если так дотошно его расспрашивать то скорей всего он просто пойдет в другое место, где ему скажут 3 вещи: да, сделаем, N сумма денег.