Программирование, т. 6

хз я вот год  строчу на метеоре на работе, и лучше бы наш проект был на node js, серьезно.

 

Что значит "легче" ?  За сколько месяцев ты напишешь то, что вп предлагает из коробки?

 

А где ты данные хранишь? 

 

Я честно последний раз юзал вп в ~2011, базовый функционал блога думаю меньше чем за неделю. Офк я не собираюсь мутить wiswig редакторы для людей не понимающих html. Данные в монге да.

хз я вот год  строчу на метеоре на работе, и лучше бы наш проект был на node js, серьезно.

А что конкретно не устраивает? Я прост перешел с с php - symphony - twig'a, на метеор и чет те вещи на которые раньше убивал пол дня, сейчас делаются просто одной строчкой. Кароч не жизнь а кайф.

Изменено 5 апреля 2017 пользователем .felix

строчку razverni_facebook_please(); ещё не портировали из рельс?

 

 

Что значит "легче" ?  За сколько месяцев ты напишешь то, что вп предлагает из коробки?

 

А где ты данные хранишь? 

 

Я честно последний раз юзал вп в ~2011, базовый функционал блога думаю меньше чем за неделю. Офк я не собираюсь мутить wiswig редакторы для людей не понимающих html. Данные в монге да.

 

За неделю? С таким функционалом и админкой? Ты слишком наивен и оптимистичен.

А насчет монго , с таким же успехом можно сказать "юзайте mysql и вам даже монго знать не нужно"

 

 

Я прост перешел с с php - symphony - twig'a, на метеор и чет те вещи на которые раньше убивал пол дня, сейчас делаются просто одной строчкой

 

Например? 

хз, базовый функционал блога на джанге за пару часов пилится с нуля ))))))))))))))))))))

 

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

Например? Ну вот эта ебала с табами. Ето ж надо обработчики написать в js'e, выбрать рут, прописать нужными элементам display: none ... А в метеоре ты просто создаешь одну переменную activeTabId, и при клике на кнопки меняешь ее значение, html изменяется сам. Кода в большинстве случаев гораздо меньше, да и телодвижений.

 

Лайв синхронизация с бд на самом деле в большинстве случаев нахрен не уперлась, но когда она нужна, она просто сразу есть. Я например не написал еще ни 1 ajax запроса. Да я вообще походу скоро забуду как их писать . Отрисовывается все вообщем-то быстро, т.к. ты не шлешь постоянно огромные куски html со скриптами, а получаешь только инфу. Хотя это просто роутинг на клиенте с его достоинствами и недостатками, но мне он пока очень нравится.

Изменено 5 апреля 2017 пользователем .felix

Ну вот эта ебала с табами. Ето ж надо обработчики написать в js'e, выбрать рут, прописать нужными элементам display: none ... А в метеоре ты просто создаешь одну переменную activeTabId, и при клике на кнопки меняешь ее значение, html изменяется сам. Кода в большинстве случаев гораздо меньше, да и телодвижений.

 

Какое отношение это к php имеет?

 

Изменено 5 апреля 2017 пользователем fessnik

Я например не написал еще ни 1 ajax запроса. Да я вообще походу скоро забуду как их писать

Ебать обмазываюсь вашими холиварами по поводу ЯП 

Какое отношение это к php имеет?

Такое что там не надо писать model, c ее бойлерплейт геттерами сеттерами, контроллеры на клиенте тоже меньше. Вообщем на meteor'e приложение пишется гораздо быстрее/проще и кода получается меньше, чем на symfony/flask, хотя офк я ниразу не эксперт по этим двум. Хотя большая часть моего восторга из-за того, что я познакомился с фронтэнд фреймворком, в котором очень просто управлять тем, что отрисовано на экране.

 

 

Изменено 5 апреля 2017 пользователем .felix

 

подводный камень №1 - вакансий в 10 раз меньше чем на пхп. В области их просто 0.

Но сейчас я хз зачем вообще изучать все эти Ruby, python'ы, php, когда есть топовый meteor. JS на сервере и клиенте, написать полноценный сайт легче чем на вордпрессе, деданы бэкэнщики нинужны, даж SQL знать нинада. вообщем все для html программистов

 

Я главную пользу получил от того, как мне все прозрачно расписали про Джангу. Типа так и сказали: вот тут MVC, поц, и сначала ты создаешь миграцию, потом используешь орм, чтобы копаться в БД, затем в шаблоне юзаешь шаблонизатор и прочее... Вот на что-то такое потратить 4 часа жизни я был бы вполне непрочь, прежде чем выходить на работу джун-пхпшником. Возможно это подача материала так сыграла или я уже на похуе усваиваю любое несложное дерьмо, хз. То же самое я подчерпнул из ПХП, практически один-в-один, но как-то всё это было не так просто, как в Джанге, и в ПХП столько фреймвоков, что я не бу какой из них выбирать, плюс каждая первая ЦМСка написана на пхп, просто охуеешь разбираться в нюансах того или иного дерьма. А в питоне для веба только джанга на слуху. Я еще слышал про фалкон и фласк, но только слышал, когда дело доходит до веба, вроде везде в вакансиях пишут Питон-джанга. А вакансий по этому поводу в наших ебаных питерах дохуя вроде

 

Лично я чет хуй знает насчет жс как бекенда. Вообще от бекенда стараюсь нахуй идти, но смотрел пару-месяцев назад какую-то сводку по тому "какой язык на бекенде насколько быстр" и там получилось как-то так:

1. Си(++)? 2. Нода 3. СиШарп 4. ПХП 5. Питон... за жаву не помню, чисто игнорю

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

 

Какое отношение это к php имеет?

Такое что там не надо писать model, c ее бойлерплейт геттерами сеттерами, контроллеры на клиенте тоже меньше. Вообщем на meteor'e приложение пишется гораздо быстрее/проще и кода получается меньше, чем на symfony/flask, хотя офк я ниразу не эксперт по этим двум. Хотя большая часть моего восторга из-за того, что я познакомился с фронтэнд фреймворком, в котором очень просто управлять тем, что отрисовано на экране.

 

Честно не пойму тебя. Ты написал в качестве пример табы, которые нужно переключать jsom , а теперь пишешь про модели, геттеры, сеттеры. Ну и symfony это не все пхп и не самый быстрый по скорости разработки фрейморк в пхп

Лол, че ты ко мне пристал, я не хочу тебе весь вечер доказывать что meteor лучше, тем более опыта в пхп у тебя больше чем у меня в meteor'e. Я просто свое мнение выразил .

 

 

Лично я чет хуй знает насчет жс как бекенда. Вообще от бекенда стараюсь нахуй идти, но смотрел пару-месяцев назад какую-то сводку по тому "какой язык на бекенде насколько быстр" и там получилось как-то так:

1. Си(++)? 2. Нода 3. СиШарп 4. ПХП 5. Питон... за жаву не помню, чисто игнорю

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

Ну прикол метеора в том, что если ты знаешь фронтэнд, то ты автоматом знаешь бэкэнд, Т.к. на бэкэнде по сути там ток БД - хранилище json обьектов, с которыми ты опять же умеешь работать. Хз конечно, возможно ли на этом запилить вконтакте, но думаю для большинства сайтов - отличное решение.

 

 

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

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

 

Ё в ПХП столько фреймвоков

 

Да их дохуя, но опять же на слуху всего несколько самых популярных и выбирать нужно из них особенно джуну, а не из всех-всех что есть на пхп.
На питоне  тоже 10 фреймворков можно найти, но всего парочка популярных.

 

плюс каждая первая ЦМСка написана на пхп, просто охуеешь разбираться в нюансах того или иного дерьма.

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

 

 

Лол, че ты ко мне пристал, я не хочу тебе весь вечер доказывать что meteor лучше, тем более опыта в пхп у тебя больше чем у меня в meteor'e. Я просто свое мнение выразил .

)) Ты просто написал, что задачи которые ты делал в симфони, в метеоре ты делаешь гораздо быстрей, мне стало интересно какие именно задачи и я попросил пример.  Симфони не "самый быстрый для разработки фреймворк" в пхп, мне просто интересно, что именно на стороне бекенда на метеоре ты делаешь быстрей чем на симфони.

 

 

Ну прикол метеора в том, что если ты знаешь фронтэнд, то ты автоматом знаешь бэкэнд

 

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

но это рофл, я на самом деле супер не шарю, чтоб даже пытаться рассуждать об этом

Метеор хунта, получаешь кастрированную солянку с кучей ограничений, где не развернуться нормально. Либо юзаешь что дают, либо идешь нахуй. По сравнению с кастомным набором либ вообще не боец (но это и скилла большего требует офк).

 

По поводу фронта и бэка - без познаний в бэке (ноде) никуда не уедешь. Шарахаться можно и нужно от всяких пхп/руби/питонов и подобной еботы, которая тебе ничем не поможет в развитии JS. А вот уметь ебашить простенькую бэк-енд прослойку для работы с каким-нибудь API и улучшением стабильности/скорости фронта - мастхэв.

 

Я вот сейчас пилю новый фронтенд. Там потребуется просто неебическое количество дерганья данных по ajax с кучи разных внутренних сервисов, причем речь о весьма больших объемах данных, которые надо фильтровать и так далее. Почти у всех этих самых сервисов отсутствует гибкое API, то есть тебе в основном будут посылаться большие куски коллекций, вместо каких-то изысканно отфильтрованных ништяков. В итоге я буду пилить бэкенд на ноде, который во первых будет предоставлять все базовые бэк-ту-фронт ништяки (аля вебсокеты и все такое) и во вторых служить неким агрегационным query-сервисом, который будет собирать кучу данных с различных сервисов и обрабатывать их (фильтрация и все такое) и затем посылать только нужные и красивенько упакованные данные фронтенду. В итоге с таким сервисом какой-нибудь отфильтрованный список репортов будет весить меньше сотки килобайт, а если бы фронт дергал все данные напрямую, то он бы мог принимать по несколько метров (а то и десятков) и затем мучительно все это дело фильтровать, убивая браузер (наш легаси фронтенд, написанный еще года 3 назад, делал такую еботу, на годовых репортах там дергалось на 20+ метров JSON данных и затем эта хуйня обарабывалась огромным пластом кода с кучей циклов, хром на макбуках повисал на минуту+      ).

Изменено 5 апреля 2017 пользователем suez

Метеор хунта, получаешь кастрированную солянку с кучей ограничений, где не развернуться нормально. Либо юзаешь что дают, либо идешь нахуй. По сравнению с кастомным набором либ вообще не боец (но это и скилла большего требует офк).

 

По поводу фронта и бэка - без познаний в бэке (ноде) никуда не уедешь. Шарахаться можно и нужно от всяких пхп/руби/питонов и подобной еботы, которая тебе ничем не поможет в развитии JS. А вот уметь ебашить простенькую бэк-енд прослойку для работы с каким-нибудь API и улучшением стабильности/скорости фронта - мастхэв.

 

Я вот сейчас пилю новый фронтенд. Там потребуется просто неебическое количество дерганья данных по ajax с кучи разных внутренних сервисов, причем речь о весьма больших объемах данных, которые надо фильтровать и так далее. Почти у всех этих самых сервисов отсутствует гибкое API, то есть тебе в основном будут посылаться большие куски коллекций, вместо каких-то изысканно отфильтрованных ништяков. В итоге я буду пилить бэкенд на ноде, который во первых будет предоставлять все базовые бэк-ту-фронт ништяки (аля вебсокеты и все такое) и во вторых служить неким агрегационным query-сервисом, который будет собирать кучу данных с различных сервисов и обрабатывать их (фильтрация и все такое) и затем посылать только нужные и красивенько упакованные данные фронтенду. В итоге с таким сервисом какой-нибудь отфильтрованный список репортов будет весить меньше сотки килобайт, а если бы фронт дергал все данные напрямую, то он бы мог принимать по несколько метров (а то и десятков) и затем мучительно все это дело фильтровать, убивая браузер (наш легаси фронтенд, написанный еще года 3 назад, делал такую еботу, на годовых репортах там дергалось на 20+ метров JSON данных и затем эта хуйня обарабывалась огромным пластом кода с кучей циклов, хром на макбуках повисал на минуту+      ).

И че, какой формат API будет? GraphQL?

https://spb.hh.ru/vacancy/19384143

во бля охуенная компашка 

 

 

 

 

на годовых репортах там дергалось на 20+ метров JSON данных и затем эта хуйня обарабывалась огромным пластом кода с кучей циклов

 

сука лол. а че такого

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

1+ минута это такая хуета)

 

Я на практике был на заводе где юзали 1с, так там иногда могло все минут на 10-20 зависнуть, можно было пойти кофе попить