Вы совершенно правы. Можно сделать без js, от слова совсем. И начиная делать проект я и пошла по этому пути. Но потом начался тот момент, что js нужен. Там где появляется интерактивность в дело вступал в js.
На каком-то этапе мне захотелось, чтобы данные обновлялись без перезагрузки страницы. И снова был вариант прикручивать js скрипт. В какой-то момент я поняла, что количество сторонних разрозненных скриптов растет в прогрессии под мои хотелки, что отнимает время на внедрение, поддержку и сказывается на весе самой страницы. Поэтому пришла к фреймворку, который снимает часть вопросов.
А так вы правы — можно обойтись без фреймворка.
Зря вы так.
Если посмотреть туториалы по связке 2 означенных вещей — везде будет то, что они работают на одном домене в разных вариациях, но нигде нет подсказки как их подружить вместе в части роутов.
Может и извиащение, но в начале пути это ставит в тупик
Спасибо! Такого примера не хватало, когда я делать начинала.
Почему-то все всегда опускали этот момент.
Но разделение на фронт и бэк, сейчас думаю, правильнее. Две независимые сущности — при замене одной не страдает другая.
Но еще раз спасибо за статью!
koa смотрела уже под занавес всех экспериментов. Каюсь, но запала в нее вникать уже не хватило.
Loopback тоже смотрела. Не помню что меня в нем остановило. Что-то точно было. Может не то место и время, может мало примеров, может быть отсутствие чего-то нужного. Я к нему 3 раза пыталась подступиться. Не нашли взаимности. А потому с бэкенд пошла по пути наименьшего сопротивления в итоге.
ReactNative не смотрела. По краю я уже завязала ходить. Я уже доя себя остановилась на определенном стэке, так, что дальше тут в глубину буду копать.
Есть. Так как это кусочек самого начала проекта, то dashboard будет включать в себя все, что будет относиться к работе админки. Поэтому да, выглядит странно со стороны сейчас. Я могу за выходные привести эти кусочки в порядок и отдельным моментом выложить на github, если есть интерес к этому.
HelloWorld — это из разряда тестирования мотошлема на производстве в идеальных условиях и без боковых ударов.
Пример, который дает представление о некотором взаимодействии системы — это из разряда Sharp-testing — это уже не идеальные условия, а условия приближенные к реальным ситуациям. Извините за аналогию, но спросоня ничего другого в голову не приходит. Это краткий ответ на ваш вопрос — в чем отличие.
Ко второй части — я в начале бреющего полета. В конце подведу итоги. Но в моем случае мерилом сложности-простоты является затраченное время на реализацию. Не тупой копипаст, а именно с пониманием что и как работает и что же я такое понатворила. Если вы поделитесь своим видением того как правильнее было бы раскрыть заголовок, то я учту это на будущее для работы над ошибками.
Да тут не за что :)
Но вообще интересно. Почему-то в моей голове до сих пор есть убеждение, что зарегистрироваться можно было только имея инвайт.
А вы вот сейчас мне обратное показали.
Теперь вот вместо сна буду думать почему же я думала неправильно :)
Не обращала на это внимания. Удивительный сбой, потому, что я прекрасно помню время, место и какие дела я отложила, когда мне пришло приглашение. И было это в 2012 году :)
Первый Angular медленно но верно подводят сейчас ко второму. 1.5 если посмотреть — туда уже и частично роутинг пытаются впихнуть улучшенный и ведут по написанию к стилю angular2.
Но не срослось у меня с ним, так как для моего понимания — двойка более структурированная. Мне в ней проще ориентироваться, потому, что для меня она легко читается и я мало времени трачу на то, чтобы понять откуда и куда растут ноги.
C backbone то же самое, что и с react — для меня это оказалось сложной задачей — вмешивать разметку в срипт.
Такая методика у меня стойко ассоциировалась с женской логикой — она есть, но понять ее невозможно.
Я уже в течении трех месяцев провожу эксперименты. Я долго решала на чем делать бэкенд, с прицелом на будущее. И изоморфный meteor пощупала. Не понравилось, что там mongo. Хотя они сейчас и собираются внедрять graphql, но это тоже все еще неясно и непонятно как будет работать. Помучила Spring. Он чудесен с моей точки зрения, но активное внедрение множества компонентов, которые дублируют друг друга — это ад. Плюс не все четко отлажено, и у меня начали вылезать баги с передачей-получением запросов. То кодировка шалила, то еще что-то.
В плане api под backend был интересен sailsjs. Но, к сожалению у него достаточно неповоротливые разработчики и некоторые баги они очень долго не фиксят. Плюс одна единственная книжка по этому фреймворку и не очень понятная для меня документация свели на нет мой интерес.
И это то, что я сейчас вспомню, что я тестила все по той же схеме :)
Так как воспитывалась я преимущественно папой и в квартире, которая больше напоминала сервисный центр, чем квартиру, то перебрать варианты, попробовать, поменять местами, снова попробовать, разобрать, собрать, включить, потом поискать еще более оптимальный вариант решения — это мой вариант поиска решений. И, когда я писала статью я правда пыталась показать, что простая задачка из простой, но реальной жизни может быть решена достаточно быстро. а при условии отсутствия навыков я считаю, что это вообще спринтерский забег.
И заранее приношу извинения всем, кому мне так хотелось бы поставить плюсик в комментарий — я не успеваю поймать тот момент, когда моя карма это позволяет :)
Я не знаю откуда у вас сложилось такое представление. Но я не буду просить цитат :)
И я искренне не понимаю как вы не зная моих задач уже судите, что все это отличается от того, что предлагает framework. Вот тут мне бы уже хотелось услышать ваши логические рассуждения :)
Да, у меня в голове есть свои задачи. Вы совершенно правы. Точнее задача-то одна — сделать проект, который делаю.
Прежде чем хвататься за Angular 2 я попробовала сделать минимальные примеры на React, Ember, Backbone, VueJs, Angular1.4 и даже Aurelia потестила. Решала ту же задачу, которая здесь описана в статье.
Не являясь программистом я только на решении определенной проблемы могу понять насколько легко или сложно дальше у меня этой пойдет и какие подводные камни есть. Пример HelloWorld и ToDo списки так любимые — не показательны в силу их отдаленности от столкновения с более-менее реальным миром.
Но, подозреваю, что вам не интересен мой ответ, вы судите с позиции какой инструмент для своей работы вы бы хотели завелосипедить, а я сужу с позиции — какой инструмент лучше всего мне помогает велосипедеть свой проект. И какой инструмент позволяет мне не тратить месяцы на то, чтобы понять принцип работы этого самого инструмента.
При условии, что инструментов много, они растут как грибы после дождя, правда погибают тоже достаточно быстро, то можно свой проект пичкать постоянно чем-то новым. Я придерживаюсь того, что внедренние сторонних фич оно как правило грозит тем, что в момент, когда разработчикам надоест с ними возиться — это будет неприятный казус и потому, выбираю минимально-необходимое кол-во инструментов. Вот потому в статье Angular2 (и даже не JS), потому тут нет React c его просто безумным количеством библиотек на каждый чих, на которые нужно много времени на изучение, нет Ember и так далее. А есть то, что самодостаточно без различных дополнительных танцев с бубном.
Но это мой взгляд и это для меня так.
Не одной крови :) Агентства работают с 3-6 проектами одновременно и из разных областей, а вот со стороны заказчика менеджер работает в одной области. И задачи разные.
Агентству нужно получить клиента и хороший бюджет, заказчику потратить деньги и получить эффективность.
Ну где же тут одной крови? :)
На каком-то этапе мне захотелось, чтобы данные обновлялись без перезагрузки страницы. И снова был вариант прикручивать js скрипт. В какой-то момент я поняла, что количество сторонних разрозненных скриптов растет в прогрессии под мои хотелки, что отнимает время на внедрение, поддержку и сказывается на весе самой страницы. Поэтому пришла к фреймворку, который снимает часть вопросов.
А так вы правы — можно обойтись без фреймворка.
Если посмотреть туториалы по связке 2 означенных вещей — везде будет то, что они работают на одном домене в разных вариациях, но нигде нет подсказки как их подружить вместе в части роутов.
Может и извиащение, но в начале пути это ставит в тупик
Почему-то все всегда опускали этот момент.
Но разделение на фронт и бэк, сейчас думаю, правильнее. Две независимые сущности — при замене одной не страдает другая.
Но еще раз спасибо за статью!
Loopback тоже смотрела. Не помню что меня в нем остановило. Что-то точно было. Может не то место и время, может мало примеров, может быть отсутствие чего-то нужного. Я к нему 3 раза пыталась подступиться. Не нашли взаимности. А потому с бэкенд пошла по пути наименьшего сопротивления в итоге.
ReactNative не смотрела. По краю я уже завязала ходить. Я уже доя себя остановилась на определенном стэке, так, что дальше тут в глубину буду копать.
Пример, который дает представление о некотором взаимодействии системы — это из разряда Sharp-testing — это уже не идеальные условия, а условия приближенные к реальным ситуациям. Извините за аналогию, но спросоня ничего другого в голову не приходит. Это краткий ответ на ваш вопрос — в чем отличие.
Ко второй части — я в начале бреющего полета. В конце подведу итоги. Но в моем случае мерилом сложности-простоты является затраченное время на реализацию. Не тупой копипаст, а именно с пониманием что и как работает и что же я такое понатворила. Если вы поделитесь своим видением того как правильнее было бы раскрыть заголовок, то я учту это на будущее для работы над ошибками.
Но вообще интересно. Почему-то в моей голове до сих пор есть убеждение, что зарегистрироваться можно было только имея инвайт.
А вы вот сейчас мне обратное показали.
Теперь вот вместо сна буду думать почему же я думала неправильно :)
Но не срослось у меня с ним, так как для моего понимания — двойка более структурированная. Мне в ней проще ориентироваться, потому, что для меня она легко читается и я мало времени трачу на то, чтобы понять откуда и куда растут ноги.
C backbone то же самое, что и с react — для меня это оказалось сложной задачей — вмешивать разметку в срипт.
Такая методика у меня стойко ассоциировалась с женской логикой — она есть, но понять ее невозможно.
Я уже в течении трех месяцев провожу эксперименты. Я долго решала на чем делать бэкенд, с прицелом на будущее. И изоморфный meteor пощупала. Не понравилось, что там mongo. Хотя они сейчас и собираются внедрять graphql, но это тоже все еще неясно и непонятно как будет работать. Помучила Spring. Он чудесен с моей точки зрения, но активное внедрение множества компонентов, которые дублируют друг друга — это ад. Плюс не все четко отлажено, и у меня начали вылезать баги с передачей-получением запросов. То кодировка шалила, то еще что-то.
В плане api под backend был интересен sailsjs. Но, к сожалению у него достаточно неповоротливые разработчики и некоторые баги они очень долго не фиксят. Плюс одна единственная книжка по этому фреймворку и не очень понятная для меня документация свели на нет мой интерес.
И это то, что я сейчас вспомню, что я тестила все по той же схеме :)
Так как воспитывалась я преимущественно папой и в квартире, которая больше напоминала сервисный центр, чем квартиру, то перебрать варианты, попробовать, поменять местами, снова попробовать, разобрать, собрать, включить, потом поискать еще более оптимальный вариант решения — это мой вариант поиска решений. И, когда я писала статью я правда пыталась показать, что простая задачка из простой, но реальной жизни может быть решена достаточно быстро. а при условии отсутствия навыков я считаю, что это вообще спринтерский забег.
Не знаю как у других, но я искренне боялась писать на хабр.
Коленки до сих пор дрожат :)
Я не знаю откуда у вас сложилось такое представление. Но я не буду просить цитат :)
И я искренне не понимаю как вы не зная моих задач уже судите, что все это отличается от того, что предлагает framework. Вот тут мне бы уже хотелось услышать ваши логические рассуждения :)
Да, у меня в голове есть свои задачи. Вы совершенно правы. Точнее задача-то одна — сделать проект, который делаю.
Прежде чем хвататься за Angular 2 я попробовала сделать минимальные примеры на React, Ember, Backbone, VueJs, Angular1.4 и даже Aurelia потестила. Решала ту же задачу, которая здесь описана в статье.
Не являясь программистом я только на решении определенной проблемы могу понять насколько легко или сложно дальше у меня этой пойдет и какие подводные камни есть. Пример HelloWorld и ToDo списки так любимые — не показательны в силу их отдаленности от столкновения с более-менее реальным миром.
Но, подозреваю, что вам не интересен мой ответ, вы судите с позиции какой инструмент для своей работы вы бы хотели завелосипедить, а я сужу с позиции — какой инструмент лучше всего мне помогает велосипедеть свой проект. И какой инструмент позволяет мне не тратить месяцы на то, чтобы понять принцип работы этого самого инструмента.
При условии, что инструментов много, они растут как грибы после дождя, правда погибают тоже достаточно быстро, то можно свой проект пичкать постоянно чем-то новым. Я придерживаюсь того, что внедренние сторонних фич оно как правило грозит тем, что в момент, когда разработчикам надоест с ними возиться — это будет неприятный казус и потому, выбираю минимально-необходимое кол-во инструментов. Вот потому в статье Angular2 (и даже не JS), потому тут нет React c его просто безумным количеством библиотек на каждый чих, на которые нужно много времени на изучение, нет Ember и так далее. А есть то, что самодостаточно без различных дополнительных танцев с бубном.
Но это мой взгляд и это для меня так.
Агентству нужно получить клиента и хороший бюджет, заказчику потратить деньги и получить эффективность.
Ну где же тут одной крови? :)