Комментарии 319
Как мне кажется, как раз все наоборот.
В NodeJS с помощью нескольких команд можно за десять минут поднять простой сайт типа блога, и он уже будет с формой входа, с загрузкой изображений, и вполне стильно выглядящий. Представляю сколько бы это заняло у меня лет 10-15 назад.
Ну за 10 лет не скажу, а так чисто за тот же php с Yii. Показываешь ему табличку в базе и он тебе генерит CRUD. Контроллеры, вьюшки. Под ноду такое еще поискать надо, sails.js тебе только апишку даст.
В статье конечно все малость утрировано. Прежде чем брать какой-то стек нужно хорошенько подумать. Если делать блог за сотку, то вряд ли кто-то будет замарачиваться с SPA, SSR и прочим. Можно вордпресс клиенут впарить
Что значит "блог за сотку"?
Я даже не знаю, специально вы написали RUR, подразумевая, что это 100 RUB, или это была случайность?
Ибо RUR и RUB – разные валюты, одна – советско-российский рубль, а другая – современный рубль, после деноминации, которая как раз на тысячу сократила множитель. Если вдруг кто не знал.
В любом случае, эта последняя буква ещё сильнее увеличивает неопределённость, сотка чего именно имелась в виду. :D
А потом у них синтаксис поменялся на RUB и мне было интересно почему. Недостаточно интересно, чтобы погуглить, но достаточно, чтобы я фоново помнил об этом все эти годы.
Теперь узнал.
Единицы измерения «соток» в исходном комментарии не указаны, а значит любые предположения могут быть ошибочны. Для сотрудников минфина или ЦБ РФ «сотка» вполне может и сотней миллионов.
О, про SUR я слышу впервые. Значит, RUR – постоветский российский рубль, но до деноминации.
Я об этом слегка любопытном феномене узнал примерно таким же путём, как и StraNNicK, переводя в гугле валюту на рубли и получив какие-то не очень близкие к реальности цифры.
Берете Strapi, там вообще даже показывать ничего не надо. Набиваете структуру и у вас уже API с готовой авторизацией, правами.
sails.js — умер года 3-4 назад. Fastify, Koa, Nest (дурацкое лого с опухшей губой льва). Думаю это единственное, что стоит рассмаривать.
CRUD для ноды — это плохая практика. Очень большой гон идет на ORM, потому что на практике не ясны плюсы этой абстракции.
Тимур преподает очень грамотную теорию и практику по ноде MarcusAurelius наверное, единственный. Советует вместо ORM использовать querybuilder-ы
За сотку я бы заморочился. Для SPA, SSR взял бы Nuxt.js
Берете Strapi, там вообще даже показывать ничего не надо. Набиваете структуру и у вас уже API с готовой авторизацией, правами.
Это только API, а формочки кто делать будет? Админку клиенту? Еще плати 30 баксов в месяц, вешайся на third пати. Ради чего? API быстрей сделать? И gtasby подвизать? Все это из ряда TODO example
Какая-то кодогенерация CRUD вдруг внезапно какая-то фича, которую все вокруг пропустили
Ну так если 10 лет назад она была, а сейчас тебе апи сгенирировать SAAS проектом счастье
На тайпскрипте модельку опишу, дам ее graphql'у через typeORM, подкину генератор под клиент и суп аля зе бест маштабируемое api — готов, бесплатно.
Суть же не в этом, а в колличестве технологий на квадратный сантиметр. Раньше это было просто пыха с файлзиллой. О чем собственно и пост.
Существует множество вещей упрощающих разботку. С этим никто не спорит. Можно сейчас как SAAS себе собрать, все, что хочешь.
CRUD для ноды — это плохая практика
Да, кому нужны эти создай, отредактируй, удали.
Или вы про биг дата / супер хайлоад в вакууме?
Да тогда это не CRUD (хотя это просто use cases на диаграмке, не более), а гордый API layer, за прокси сервером с балансером на контейнеры с микросервисами под очередями и все ради того (утрирую), что бы микрофронтенд мог жить без монолита и деплоиться отдельно по странично и все было супер. Я аж приуныл.
За сотку я бы заморочился. Для SPA, SSR взял бы Nuxt.js
Ну если делать нечего, ради свадебного ателье, фигачить spa и ssr
6 минут с объяснениями, от установки до админки(CRUD) за логином и вьюх для сайта, по айтему. 2010 год.
Мне кажется я вебпак локально дольше разворачивать буду, учитывая, что node, npm уже стоит. И ради чего? На крупном проекте, долгострое да, с крупным заказчиком и супер пупер синьйорами — eсть смысл. А так, если ты мелкая фирма, шлепаешь сайт за сайтом. Какой spa, ssr? :) Я конечно предположу наработку и конвейер с готовыми решениями, но это все тоже самое, просто в профиль и явно дороже по издержкам.
Это только API, а формочки кто делать будет? Админку клиенту? Еще плати 30 баксов в месяц, вешайся на third пати. Ради чего? API быстрей сделать? И gtasby подвизать? Все это из ряда TODO example
Админка и есть strapi. Платить не нужно 30$
Да, кому нужны эти создай, отредактируй, удали.
Вы и описываете CRUD который и ругаете.
Есть много разных задач, проектов и клиентов. Мы сравниваем разных коз
Админка и есть strapi.
Ну вы же понимаете, что админку strapi клиенту сунуть так себе идея? Чисто для себя или под свой единый проект — окей. Хотя, интересно если кто-то так делает.
Платить не нужно 30$
Я посмотрел прайсинг на сайте. Не всем подойдет фришная в продакшене. Или есть свой хост, то там без ограничений?
Но я обязательно заценю ее, уже не раз слышал про нее :)
UPD: Прошу прощения, выше уже говорили про Strapi
Недавно редактировал похожий сайт из 2012 — php+jquery, 3 языка и картинки.
Проблема была в том, что студия, делавшая сайт в 2012, умерла, и её домен продаётся, ну а пока — предлагает оценить дорогих (и не очень) дам вместо информации о бывших создателях сайта.
После удаления 1 строчки сайт продолжает выполнять функции сайта-визитки.
Кажется, я ещё больше полюбил YAGNI.
В NodeJS с помощью нескольких команд можно за десять минут поднять простой сайт типа блога, и он уже будет с формой входа, с загрузкой изображений, и вполне стильно выглядящий. Представляю сколько бы это заняло у меня лет 10-15 назад.
Да ровно столько же.
При использовании языка программирования, который был мейнстримом для веба тогда.
От языка программирования ничего не зависит.
Зависит — от набора используемых вспомогательных библиотек/фреймворков и от того как хорошо вы в этих библиотеках/фреймворках ориентируетесь.
А описанный функционал — заложен в библиотеки/фреймворки еще 20 лет назад.
Но, да, тогда это было в библиотеках/фреймворках — для других языков программирования, которые были в мейнстриме для веба тогда.
Сейчас, как и в 2013-м, на RoR за день без проблем можно сделать сайт, запулить его в облако на Heroku (который у автора на картинке), и он там будет работать. И даже не будет просто так отдавать целые странички с сервера — turbolinks нынче уже идет из коробки.
Извините, задолбали запросы на использование конкретной технологии там, где она вообще ни зачем не сдалась.
При правильно пользовании DRF он работает не сильно медленне, но при этом он значительно повышает скорость и снижает сложность разработки, а при необходимости нужные куски кода переписываются на чистый код без него.
Так что, я Вас прекрасно понимаю как разработчик, когда менеджеры хотят впихнуть технологии и фреймворки которые на слуху, но вообще не нужны для проекта.
Например, чтобы разделить разработку бэка и фронта, а не заставлять фронтов писать серверные вьюхи.
А что они у вас делают?
А что вы называете вёрсткой?
Передают вам html файл с рыбой, вы ставите переменные, циклы, условия и т. п., декомпозируете, а когда они вносят правку в вёрстку повторяете процесс?
Понятно. Я этого лет 15-20 назад наелся. Теперь или фронты осваивают бэк и сами правят шаблоны и т. п., или бэк с фронтом взаимодействуют по API, а фронт отвечает и за SSR если что )
Не согласен: много лишней работы по многократному натягиванию вёрстки на шаблонизатор. Да, где-то можно из диффов между файлами вёрстки быстро понять какие и где файлы шаблонов поправить, но в общем случае надо разбираться каждый раз
Ну вот моды нагружать браузер я не встречал. Мода на различные архитектуры, фреймворки и т. п., которые упрощают (в теории) разработку, а как в целом нежелательный, но допустимый побычный эффект нагружают браузер — это есть.
Я постоянно спотыкаюсь о безумно тормозящие, достраивающиеся во время отображения страницы, которые грузят процессор так, что плакать хочется. Да и память жрут как не в себя. И вот уже машина, на которой отлично идёт разработка серверной части сайта, с трудом отображает страницы этого сайта, хотя в варианте серверной генерации справляется с сайтом на ура.
Собственно, фронтэндер, изучив язык шаблонизатора, легко делает всё сам.
Я же так и сказал: фронты осваивают бэк и сами правят шаблоны
Шаблон — часть бэка, язык шаблонизатора — один из языков бэка.
А если серьёзно, то шаблоны — это как раз фронт-энд. И не важно, где из них собираются стртаницы. Потому что задача программиста бэк-энда — собрать данные и сложить их в пакет для дальней шей сборки страницы, а сборка страницы — это уже фрон-энд.
Ну вот очень многие знакомые фронтендеры не считают натягивание html вёрстки на созданные бэкендером шаблоны фронтенд разработкой — оно не на фронтенде исполняется, при ошибках вызывает 500 Internal Server Error и подобные аргументы.
3. Потому что JS создавался как язык мелкой анимации страницы и получился многословным. А потом стал ещё более многословным, а потом его завернули в несколько слоёв систем безопасности и контейнеров, что так же не повысило его быстродействие, а потом некоторые умники стали писать библиотеки, дублирующие свойства CSS1. Я не шучу, попадалась реализация на JS свойства «position: absolute» на 2000 строк. А потом такое включают в другую библиотеку, которую уже используют, не заглядывая внутрь. И всё ради того, чтобы получить несколько килобайт JSON с сервера и нарисовать те же несколько килобайт HTML, но уже в браузере, хотя можно было посклеивать этот самый HTML на сервере.
В современной разработке на PHP его шаблонизаторские возможности очень часто не используются, вместо них, да, шаблонизаторы на PHP. И часть из них куда удобнее и безопаснее php-шаблонов.
Классическое
<?php echo htmlspecialchars($var, ENT_QUOTES, 'UTF-8') ?>vs
{{ var|escape }}Это не говоря о возможности включить автоэкранирование по умолчанию.
А из архитектуру что осталось от шаблонизатора так это <?php
Это бывший язык-шаблонизатор, а сейчас мультипарадигменный язык общего назначения :)
Основа-то осталась.
В каком смысле? В семействе 7-й версии было огромное количество изменений, нововведений и очистки от старья типа mysql*. Улучшение поддержки типизации, переход от кодов ошибок к исключениям, новые операторы, сахар и т.д., включая буст производительности, по некоторым оценкам, чуть ли не в два раза. Через несколько дней релизится 8-я версия, в которой тоже куча нового + JIT. Да, возможность шаблонизировать средствами самого языка осталась, но это давным-давно не главное.
Да, возможность шаблонизировать средствами самого языка осталась, но это давным-давно не главное.
Более того, эта возможность многими просто не рекомендуется к использованию: и слищком многословна, и небезопасная по умолчанию.
Более того, эта возможность многими просто не рекомендуется к использованию: и слищком многословна, и небезопасная по умолчанию.
Верно. При этом любопытно, что некоторые проекты (например, монструозный Magento) выбирают всё же пользоваться именно ей. Возможно, от нежелания добавлять лишние слои абстракции/библиотеки (в чём можно заподозрить, например, CodeIgniter), хотя в случае того же Magento их там уже столько, что влияние движка шаблонизатора (работа которого, к тому же, кэшируется), наверное, вряд ли можно считать существенным. У меня есть теория, что при достаточно большой популярности инструмента любая его фича будет кем-то использована вне зависимости от её спорности.
При этом любопытно, что некоторые проекты (например, монструозный Magento) выбирают всё же пользоваться именно ей.
Я делал один проект на Magento в 2009 и он мне тогда показался просто тормознутым куском говна. Если его не переписали полностью в новых версиях, то ничего удивительного, что он так и не умеет в нормальные абстракции. Вообще, если вы в период 2005-2009 читали код популярных тогда PHP-проектов (Joomla, Wordpress, Bitrix, Drupal, etc.), то легко понять почему люди массово переходили на другие языки. Всё-таки одно дело, когда ты по-простому делаешь сайтик, как описанный в статье, а другое — когда ты с таким же пофигизмом делаешь CMS или фреймворк. Это получается персонаж для кошмаров.
Я делал один проект на Magento в 2009 и он мне тогда показался просто тормознутым куском говна. Если его не переписали полностью в новых версиях, то ничего удивительного, что он так и не умеет в нормальные абстракции.
С тех пор сильно переписали. Честно, ещё не был с ним знаком в 2009, но когда познакомился — в версиях 1.8-1.9 — это уже был проект вида "абстракции на абстракциях, погоняемых абстракциями на абстракциях, много раз рекурсивно повторить". Суровый такой абстрактный монстр. С версий 2.х было серьёзное обновление фреймворков, но почему-то шаблонизация PHP осталась. Здесь, наверное, надо отметить, что Magento это не среднестатистическая CMS. Wordpress по сравнению с Magento это как муравей в сравнении со слоном. По крайней мере, сегодня.
Всё-таки одно дело, когда ты по-простому делаешь сайтик, как описанный в статье, а другое — когда ты с таким же пофигизмом делаешь CMS или фреймворк.
Не уверен, что всегда дело в пофигизме. Сам неоднократно сталкивался с ситуацией, в которой чистота абстракций и элегантность кода разбиваются о количество и непредсказуемость функциональности. Не уверен, что тот же Magento был бы реализован лучше на Java.
Расскажите — как? Спасибо.
npx create-react-blog react-blog
cd react-blog
npm install
npm startПодробнее тут: github.com/jamesknelson/create-react-blog
Вспомнил тут недавно PHP и спокойненко продолжил на нем делать сайты. Просто со временем образовался небольшой ворох минимального комплекта для запуска и получается вполне шустро и по разработке, и по скорости работы.
Не знаю уж, чем так плох PHP и MySQL — пока этого мне никто объяснить не смог
Но при этом таблица не разваливается при очередном обновлении браузера.
А уж как неограничено применение современных фреймворков, просто сказка, и чем дальше тем страшнее.не помню как там точно: "Шаг влево, шаг вправо — считается побегом. Прыжок на месте расцениваю как попытку улететь в космос."
К сожалению, таблица доставляет проблем, когда вспоминаем о мобильных устройствах, где скажем десктопный блок справа логичнее было бы выводить внизу или во всплывающем меню.
Opera 12 Mobile кажется последний браузер, который нормально умел масштабировать табличные сайты на экране смартфона.
Вполне достаточно отдавать мобильным устройствам отдельную мобильную версию. Это куда надёжнее и куда легче адаптивности.
Я бы не был таким категоричным.
Поддержка, тестирование и добавление нового функционала становятся вдвое затратнее в сложных интерфейсах.
В клиентских приложениях не редко используется комбинированный подход: разные компоненты в зависимости от размера экрана.
И, уже набивавшая оскомину истина: каждой задаче своё решение.
ТБМ, как я стар, когда в «кроватке» середины-конца 90х болтали… легкие чаты, пролезающие через 2400, а не требующие онлайн-линка в 1-2МБита. я совсем не понимаю современные тенденции — это для того чтобы даже мощнейшее железо заставить ползать так, что даже 8088 кажется очень даже быстрой машинкой?
ЛЮДИ, ОЧНИТЕСЬ!
а Илюше — нахрен универсальные на все случаи гробы, которые хреново распознаются везде? нафига эти кучи слоев? информация погружена во все эти обертки, что даже нормально вычитать ее приходится изголяться!!!
Вы же прекрасно понимаете, почему так сложилась история развития веба, да и всей индустрии.
Во второй половине 90х, когда первично появились избытки мощностей, в первую голову процессорных, п-про, пошло такое компонентное чудо как Дельфи. Когда даже совсем безголовый олигофрен, мог тыкая мышкой собрать из компонентов красивое, но медленное приложение и в эти контейнеры сигналов и функций вложить нужную себе функциональность. Пошли производные компоненты и чем дальше тем хуже.
До них был другой подход к работе, есть атомарные компоненты, тот же mfc и между ними требовалось наращивать мясо, т.е. понимать что и как работает и зависит. А теперь даже ТБМный калькулятор занимает сотни мегабайт, требует выход в интернет и еле ползает на тех же смартфонах, которые мощнее суперэвм 20 летней давности, при несопоставимой полезности изделий.
А полезность в чём измеряете? Если в деньгах, которые покупатели готовы платить за изделия, то полезность суперэвм и смартфонов если и несопоставима, то с другой, наверное, стороны, а не той, что вы имели ввиду. Триллион долларов уж точно в год платят за смартфоны.
Вы повторяетесь.
Тогда я снова скажу: вы все прекрасно понимаете. Ответы на «что, как и почему» у вас есть.
И вы ищете не объяснений, не интересных споров, а единомышленников.
Как я понял, вы почему-то очень не любите Delphi.
Но Visual Basic появился раньше и, по слухам, был популярнее Delphi.
Утверждения о тормознутости Delphi голословны.
Delphi всегда был компилируемым языком с приемлемой скоростью и в тормознутости современных сотнемегабайтных калькуляторов он не виноват, они не на нём написаны.
И брюки Delphi превращается, превращается… в веб-приложение!
Сурово ж вас приложило.
Современный же веб не даёт ни простоты (даже статья о том, насколько все это сложно!), ни экономии ресурсов, ни революционного подхода, заставляя разработчиков заниматься практически тем же, чем занимались когда-то суровые MFC-шники, но на более высоком уровне.
15—20 лет назад я ещё как-то мог с вами согласиться, но сейчас таблицами верстать банально сложнее, чем гридами, флексбоксами, или даже простыми блоками. А в большинстве кейсов с адаптивностью — просто невозможно.
Да и как-то не по существу — «ну теперь просто на php я не могу сделать сайт, и надо выбрать какой-то фреймворк: Jango или Express». И как бы автор не нагуглил, что есть Laravel с огромной экосистемой, и скаффолдингами из коробоки под react или vue. Или автор лет 5 назад начал писать статью.
Весь вопрос: вам шашечки или ехать?
Я вас прекрасно понимаю. Сам так начинал проект. И бросал.
Хотите сделать новостной сайт: берёте Wordpress/<другая CMS>, покупаете готовый шаблон, домен и не парьтесь.
Хотите интернет-магазин? И под это готовых решений достаточно. Если не в РФ, то shopify.
Закладываете потенциал, и, вообще, это пет-проект с полным контролем — верной дорогой идёте.
А если хотите меньше париться, то на фронт берёте boilerplate, их достаточно много разных. Там уже есть всё.
Не хотите парится с бэком? headless cms.
Не хотите сильно парится с фронтом? Asp.net, Java jsf (?).
На любой вкус есть решения с разными преимуществами и недостатками.
И ещё добавлю, если не хотите париться с ui, то есть масса вариантов UI-kit: antd, material ui. От Uber тоже есть.
― Вона, опять у нашего барина ипохондрия сделалась!
― Пора. Ипохондрия всегда на закате делается.
― Отчего же на закате, Степан Степанович?
― От глупых сомнений, Фимка. Вот глядит человек на солнышко и думает: взойдёт оно завтра аль не взойдёт?
>Весь вопрос: вам шашечки или ехать?
Ну, судя по тексту — шашечки.
>Как я буду это поддерживать без ООП и вообще нормального разделения кода?
Прежде чем это кто-то будет поддерживать, нужно чтобы это вообще заработало. Поэтому берете то, что знаете, и делаете прототип. Потом выкидываете, и делаете продакшн решение. Вполне возможно, что на совсем других технологиях. А может, его уже другие люди сделают.
У меня на работе как-то была задача сделать ма-а-а-аленький сайт google maps. Не в таких масштабах, конечно, как настоящий, а именно прототип. И могу сказать, что решение взять знакомые технологии, и добавить к ним ровно то, чего в них не хватает (в моем случае картографию и leaflet), и не более — оно самое правильное. И кстати, самый первый прототип был сделан на Apache Flex (Flash). За пару дней.
Единственно, хочу заметить: ипохондрия это != хандра; ипохондрия, это когда человек постоянно выискивает у себя симптомы и признаки несуществующих болезней.
В оригинале была ипохондрия.
Оу, сори. С оригиналом не знаком, просто глаз немного резануло.
Формула любви — один из немногих фильмов производства СССР, которые можно смотреть без крови из глаз даже сейчас. Неисчерпаемый источник цитат на все случаи жизни.
Формула любви — один из немногих фильмов производства СССР, которые можно смотреть без крови из глаз даже сейчас. Неисчерпаемый источник цитат на все случаи жизни.
Это пара «сценарист Григорий Горин — режиссер Марк Захаров»
У них все фильмы подобного качества.
Оставляю комментарий для потомков:
Если вы не мазахист, то никогда, НИКОГДА не берите Liferay (java), его разработали для наказаний
Не хотите сильно парится с фронтом? → Java jsf
Хе. Теперь вы не сильно паритесь, а прямо-таки погрязли в болоте энтерпрайза. И PrimeFaces вас не спасёт. :)
На самом деле, не знаю, что именно теперь стоит использовать для фронта на джаве, уже давно этим не занимался. Какой-нибудь шаблонизатор для спрингового MVC, разве что...
А мониторить кто будет?! Вам ещё графана с каким-нибудь алертингом нужна. А то понадеплоют тут, а ты потом разбирайся.
А ещё обработка ошибок: sentry какой-нибудь.
Мониторинг доступности типа pingdom.
Тесты не затронули. Целый пласт решений.
Анализ уязвимостей.
Тут и дизайн, UI/UX, я тоже потерял, а если о монетизации задуматься, то это вообще пучина!
Тот же sentry в простейшем случае устанавливается практически в одну строчку (https://develop.sentry.dev/self-hosted/)
С приходом контейнеров эра "коробочных решений" как раз в какой-то мере вернулась.
Иногда достаточно написать Docker Compose файл и решение уже почти готово.
Автор явно обошёл стороной облака: вдруг про сайт завтра напишут все мировые сми и туда зайдут десятки миллионов пользователей? Нужно обязательно хоститься в облаке и чтобы работал автоматический скейлинг. Скорее всего k8s станет хорошим решением, в aws можно воспользоваться eks для этого. Также никогда не знаешь, сколько данных придётся хранить, добавим туда интеграцию с s3. Заодно и бэкапы закидывать в glacier deep archive удобно. Кроме этого с
разворачивать всё руками — прошлый век, стоит взять terraform и исполтзовать подход infrastructure as a code. Десятки миллионов пользователей создали терабайты логов и их надо проанализировать? Как хорошо, что это можно обработать в кластере EMR. И это только начало, над cloud native частью стоит поработать, это сейчас очень популярно!
Справедливости ради, некоторые перешли/переходят на совместимые альтернативы или просто не используют.
Первый — про, прежде всего, podman и компанию. А так и lxc только за последнее время несколько постов на Хабре было. И вообще всё это обёртки над cgroups и неймспейсами.
А вот второе — в голове была чистая олдскульщина: проект развёрнут на локальной машине разработчика без какой-либо виртуализации, конейнеризации и автоматизации. На новую машину нужно в строго определенные места склонировать репозитории, пачку /etc/* файлов, отредактировать /etc/hosts, и стандартного пользователя хорошо бы создать. Сделать один раз и забыть на годы может быть, пока не придёт письмо на группу рассылки devs: "в наших конфигах домены example.dev заменены на example.test в связи с тем, что .dev теперь делегируется. Обновите свои локальніе конфиги"
А что не так с вагрантом? Для разработки (под виндой по крайней мере) очень удобно — буквально за день сделал шаблон, и постепенно перетащил все проекты в отдельные виртуалки, при этом у каждой отдельный домен (на основе имени из composer/package.json). Как это сделать на докере сходу не нашел.
https://github.com/nginx-proxy/nginx-proxy вот так например, автоматически изменять конфиги "главного" nginx при старте новых "виртуалок"
Спасибо. Правда судя по беглому взгляду в Windows 10 оно просто так не заведется (hosts как минимум обновлять оно, похоже, не умеет).
А какие есть альтернативы? Firecracker на ум только приходит, но он скорее для FaaS.
Основная проблема, что нет определения понятия «умер» в контексте технологии.
В вышеуказанной статье вывод сделан по одному признаку: на конференции в Питере не было докладов.
но, сделав правильный выбор
и как вы узнаете что вы сделали правильный выбор?
а чем больше технологий, тем выше шанс ошибиться
плюс туториалы сложней релевантные найти, если выбрал одну часть одну, а другую другую
так приходиться полюбому больше информации читать, и выбирать по каким-то критериями
выбор это сложно, это факт
Обилие технологий не должно смущать
почему не должно? кто сказал что не должно? меня смущает, автора смущает
потому что объективно выбор — смущает
он требует ресурсов мозга, это факт
понимаете ли автор, и плюсующие говорят о том что раньше то выбора было меньше, и туториалы читались быстрей, и релевантные причем
а сейчас надо в разы больше инфы перелопатить, ради пустякового дела
я даже не про себя, а давно на веб-разработку забил
в моей области (gamedev и сервера) тоже выбора прилично
А рутина, кол-во используемых технологий, овертаймы, многословность кода, часто переделывать? это по сравнению с вебразработкой в геймдеве как?
* рутина есть везде, и в геймдеве, там же тоже надо отлаживать баги, тестировать, кодить чтото 10 раз что вы уже делали
* кол-во используемых технологий — иногда можно взять чтото простое что работает, иногда приходиться делать серьезный выбор, оценивая очень многое, и в геймдеве часто надо чтото оптимальное, но иногда это оптимальное это долго кодить, и выбирается сначала нечто среднее, или потом переписывается на более оптимальное, другую архитектуру и т.п, и все эти оптимизации они тоже требуют выбора (что делать и когда)
* овертаймы — в геймдеве частые на сколько я слышал, хотя у меня бывают редко потому что я физически не могу авралить часто (голова уже не варит)
* многословность кода (как и качество кода, и кач-во проектирования и тестов) — зависит от опыта разраба, впрочем там где я работал — в основном разрабы сильные, новичков откровенных почти не было, ну и копипаста и лапша в коде конечно бывала но явно меньше чем я видел в (условно) «плохих примерах кода на php\js»
* часто переделывать — см выше — переделывается для оптимизаций, либо для портирования на другие девайсы (мобилки, веб, консоли, пк)
с научной точки зрения, человек может сделать выбор 2мя способами
1) лимбической системой — это псевдо-выбор основнанный на эмоциях, и зачастую в жизни именно он активно работает, например нам нравится какая-то еда, или мы привыкли вставать в опеределнное время и идти на работу, играть в определенные игры, и часто мы перенимаем этот опыт у кого-то, а потом зкрепляем за ним эмоцию и желание действовать также или не действовать
… в примере с технологиями это может быть хайп (ктото гдето написал что это клевая теха), а никак не ваш разумный выбор, и потом есть высокий риск что вы выбрали не корректно, потому что вы то доверились комуто
2) неокортексом — т.е. логическое осмысление множества факторов, но тут проблема — если сравнить 5 технологий (раньше) vs 500 (сейчас) то комбинаторный взрыв мешает сделать логический выбор за разумное время, и в конце концов человек или выбирает нечто «достаточно хорошее» как ему кажется, за N время (не макс время), или тратит слишком много энергии\времени на реально оптимальное решение
поэтому о каком «правильном» выборе может идти речь, если для логического его осмысления неокортексом надо непомерное кол-во энергии
раньше то выбора было меньше, и туториалы читались быстрей, и релевантные причем
Ох, помню сколько я времени убил на выбор стэка для простенького сайта на шаред хостинге: И C, и C++, и Perl, и ещё что-то Остновился на PHP. И это только язык.. А ещё выбор Linux или BSD. В чём под Windows писать код сайта… В чём писать разметку и стили...
Просто автор для первого своего сайта по сути и не выбирал стэк: была одна книжка по ней и делал
А своим клиентам рекомендую нанять другого разработчика для получения красивого и современного результата.
Почему не изучаю зоопарк современных фреймворков и CMS? Да просто не хочется тратить на это время, разработка приложений под Android гораздо интереснее.
Я много чем занимаюсь. Конкретно сейчас математически расчитываю дизайн. Есть в планах и своя штука на которой можно будет накликивать хоть CMS, хоть чат, хоть баг-реткер и тп. Хоть всё это вместе.
Пока только различные отступы.
Четырёхзначная логика необходима для корректных рассуждений. Я думал использовать пролог для валидации доказательств, но похоже он недостаточно силён для анализа произвольных выражений. Так что придётся пилить свой пролог с четырёхзначной логикой и релевантной импликацией.
Не хочу в ПТУ даже преподавать ) Современный PHP не имеет фатальных недостатков в своих нишах, а работать может не только с MySQL. полный переход переход на другие технологии, хоть "хайповые", хоть "мэйнстрим" существующему бизнесу особых плюсов не даст. Точечный — вполне, и давно практикуется, даже до моды на микросервисы.
Мы тут, кстати, на днях хакатонили. Так я прям заскринил, что сделала команда, которая использовала модный стек React+Redux:
Понятно, что ребята не опытные, что дизайнера у них не было, что надо было использовать какой-либо набор компонент. Проблема именно в том, что многие разрабы ведутся на хайп, надеясь, что можно будет не заморачиваясь сделать конфетку за три копейки. Но в итоге оказывается, что кода написано куча, а выглядит всё ещё стрёмно, работает на половину, а время уже всё потрачено и нужно ещё минимум в два раза больше на доработки.
Для сравнения, наше решение на настолько не модном стеке, что организаторы срезали нам баллы за то, что использовали "экзотическую технологию, в которой не разбираемся, которую не используем каждый день":
А победили ребята пилившие на Ангуляре вчетвером:
Итого, можно сказать, что для вкручивания лампочки нужно либо 4 Angular разработчика, либо 1 $mol.
К слову сказать, больше всех успели сделать ребята, что пилили на 1С. Выглядит оно, конечно, "интуитивно понятно". Не заскринил, но 1с-интерфейсы все одинаковые.
может, мне стоит откопать старую книжку по PHP, и сделать всё, как в 2013 годуPHP в этом плане очень подходит, потому что можно поставить самую последнюю версию, например PHP 8.0.0-rc3 и сделать сайт по книжке 2013 года, в которой скорей всего используется PHP 5.5. Реальный пример.
5.3 — я бы сказал язык переродился, но сильных BBC не помню до 7.0. Там скорее желание всё переписать было "по уму" с активным использованием новых возможностей: неймспейсов, нормального ООП, интерфейсов и т. п.
В 5.3-5.4 была история с резким сбросом кучи деприкейтов. В частности ссылки, глобальные переменные и ещё что-то по мелочи. Как следствие вся кодовая база, которая пришла ещё со времен PHP 4 отхватила.
Это разумеется не отменяет того, что глобальные переменные в 2013 это зашквар, но в реальных проектов этого добра было полно.
Я свой сайт написал по книжке году а 2008-2010, там была пятая версия языка. Сейчас без особых проблем мигрировал на хостинг с 7 версией (переписал mysql вызовы только, поддержка закончилась у библиотеки). Так что для простых сайтов это справедливо.
Главное не забыть использовать mysql_connect(), а потом задолбать гугл и тостер вопросами "У меня не работает MySQL что делать".
Я в веб особо не лезу, но со стороны все видится именно так.
Понаплюсовал бы, но тут кармы-шмармы, и я как-то дискриминирован, поэтому просто спасибо, читал с удовольствием.
Если делать всё "по уму", "чтоб пацанам не стыдно было показать", то почти без разницы какой конкретно современный стэк использовать, включая PHP и MySQL. Библиотеки, фреймворки, обёртки, кодогенераторы везде в мэйнстрим сейчас есть. Половина, если не больше современной инфраструктуры language agnostic.
Истинно так!
А чем плох вариант сайта "из коробки"?
Wordpress/bitrix/Joomla + тема по вкусу + доработать напильником, кладём на популярный виртуальный хостинг = обычный типовой сайт! И никакого геморроя!
С каждым годом все больше осознаю, что главное — это КОНТЕНТ! Даже сайт сверстанный черти как, с поехавшей вёрсткой, без мобильной версии и прочих свистоперделок вполне себе будет популярным и посещаемых, если там есть важная и/или нужная информация.
Вспомните старую корзину Вайлдберриз — при оформлении заказа хотелось замучить до смерти того, кто её написал, но многие (и я тоже) ценой невероятных усилий таки оформляли заказ. Почему? Цена, удобная доставка, нет предложения от конкурентов, доверие к крупному ритейлеру. Остальное все от лукавого.
До сайта на ларавел или дотнет надо сначала дорасти! А там уже видно будет на чем и как оно должно работать.
Может, мне позвать в команду пару друзей, чтобы сделать всё правильно вместе?Не забудьте записать друзей на тренинги по agile, scrum, kanban и т.д. Ну и само собой проект в Джире завести надо будет.
Прямо в точку! Именно поэтому я начал работать над проектом viewi https://viewi.net/ чтобы решить эту проблему. Стадия PoC.
Причем на Хроме, правда не самой последней версии. 20 лет прошло, а мы все еще подстраиваемся под версии браузеров, ностальгия…
Можно узнать версию хрома ?
Слишком старая версия, flex is not supported, вам нужно обновить хром
Апдейт: это не флекс, это плагин в хроме, буду решать проблему
Вообще, когда-то в 2008 году мне один программист сказал, что в принципе на PHP можно что угодно написать, хоть аналог Windows. Так ли это, не знаю, сомневаюсь, конечно. Но, однажды, видел сайт с шаблоном, как у проводника Windows, один в один, как на XP.
Хочется «по высоким стандартам»? Так изучите их. Вы не можете за час поднять бек на ноде (или на пару слоев абстракций вверх от ноды) и фронт на каком-нибудь реакте — а я могу, например. Просто вы пытаетесь это сделать без каких-либо знаний, а я и то и другое пару лет назад делал, и таки да, с опытом оно в принципе как раз час и занимает, а остальные время этого «одного дня» — уже на содержимое пойдет.
Но и вариант «просто нафигачить хтмл-страниц и захостить их» тоже работает, и за день можно очень много нафигачить, я проверял (правда, тут совсем другие практические навыки нужны, в основном по работе с шаблонами текста руками).
На самом деле, если руку набить, то всё это делается на автомате почти и быстро. Сложно только в первый раз, особенно если не работал на хорошо обустроенном проекте и результат хороший плохо представляешь.
Шансы, что что-то станет настолько популярным, что появиться коммерческий смысл допиливать меньше 5%.
Увы, но идеальные системы оказываются завершенными к моменту, когда тема себя изжила.
Городские информационные порталы протухли лет 12-15 назад.
В 2013 году я пилил простые сайты на пэхэпэ в одно лицо за пара сотен долларов.
Сейчас одностраничник у нас обойдется тыщь в 170 долларов, 2 месяца, коллектив из 4 инженеров, плюс дизайнер плюс пол менеджера и стек из пол сотни технологий.
И это не плохо.
Главное не уподобляться лирическому герою рассказа.
Есть разница большая между знать язык и делать сайт на голом языке. Конкретно в PHP она смазана немного всякими суперглобалами и стандартными функциями типа header(), но вот, например, знание Java как языка мало поможет перевести сайт с PHP (не на Symfony :)) на Spring. Большую часть времени будешь гуглить как получить распарсить входящий запрос, как установить куки, как сделать запрос к БД и т. п., а не как объявить класс или переменную типизированную
Сделать одну основную страничку несложную, но с современными "маст хэв" типа валидации, авторизации тройкой-пятком способов и т. п. на голом, а потом учить фремворк, чтоб понимать что там плюс-минус под капотом и, главное, а зачем он собственно нужен
Внезапно вы уже можете и бэк и фронт.
С самими инструментами, конечно, тоже придётся ознакомиться, с той же нодой. И реактом каким-нибудь. Но инструменты по важности сильно меньше фундамента.
1. github.com/fossasia/open-event-frontend
2. github.com/fossasia/open-event-server
eventyay.com (где крутится данный фронтенд и бэкенд)
1. edgeryders.eu/t/list-open-source-software-for-resource-scheduling-and-booking/6629/21
2. github.com/coderbyheart/open-source-meetup-alternatives
Немного напоминает историю, что когда делали первые автомобили, то для них все детали были сделаны вручную и подходили только для одной машины. Зато, когда появилась стандартизация, вопрос ремонта и запчастей стал гораздо проще, даже с учетом усложнения самой конструкции автомобиля.
Просто веб вырос и стал годен для разработки полноценных клиент-серверных приложений.
Если нужен простой сайт — берешь и делаешь простой сайт, наличие микроскопа не обязывает забивать им гвозди. На современном фреймворке — если с ним знаком — это даже проще и быстрее, но и по-старинке никто не запрещает.
Я так и не прочитал ответ на «вопрос» — « Хм, не могу же я просто взять PHP и написать на нем несколько страничек вперемешку с HTML. »
Так все же, почему нет?
Но и с фреймворками на самом деле не всё так гладко, как может показаться на первый взгляд. Был у меня коллега, который для решения каких-то прикладных задач, слабо связанных с основным профилем деятельности конторы в целом, решил выучить фреймворк для web-разработки. И по этому поводу выучил...codeigniter. Это я к тому, что не всегда бывает возможно правильно предугадать вектор развития той или иной технологии.
К слову, освоив codeigniter, на другие фреймворки переходить гораздо проще чем с "голого php" — ничего, концептуально противоречащего современным версиям популярных PHP-фреймворков, в нём нет.
Всё просто и одновременно сложно. У лирического героя рассказа присутствует довольно явно выраженная профдеформация в сторону «голый php для школоты, а уважающему себя сеньору нужен более глубокий стек технологий», что и выливается в вышеуказанную несовместимость пушки с воробьями.
Не увидел особой пушки по воробьям. Ну может не за день он это напишет, а за два. Но там текста больше чем реальных размышлений. "Ой, где хранить код" — ну блин, на гитхабе, разрабатывать можно или по облегченному гитхаб флоу, или вообще по принципу "все фигачим в мастер", раз уж разработчик на проекте единственный. Делается репа и заливается код ну за 5 минут.
Так что сарказм статьи понятен, но на самом деле все не так уж страшно. Если знать все используемые технологии, то выйдет не дольше чем на пхп. Если не знать — ну что поделать, я вот PHP не знаю, на нем у меня дольше займет, чем на реакте и шарпе.
по принципу «все фигачим в мастер»Про это там тоже есть. Основной аргумент против — «так не делается». Упор моего изначального комментария был сделан на то, что в случае возникновения описанной в статье ситуации проблему необходимо искать не столько в выбранном стеке инструментов, сколько в самом себе. И не пытаться вместо MVP выдать сразу идеальный конечный релиз продукта, разумеется.
Вы забыли про такие условия как компетенция команды разработки и её мотивация. Если вам удалось собрать хорошую команду и вы хотите её сохранить, то её желание или нежелание попробовать что-то новое может значить больше чем какие-то внешние требования, для реализации которых есть 100500 способов, если речь не идёт о хайлоаде и т. п. В экосистемах любых, наверное, мэйнстримовых и хайповых языков давно есть веб-фреймворки, позволяющие быстро создать веб-приложение с типовыми решения типовых инфраструктурных задач типа авторизации или маппинга реляционных данных на модель.
Суть software, в то что это именно soft. Ошибка в выборе среды разработки/языка/фреймворка/и т.д. несёт потери только времени на разработку. Вам не придётся перепаивать платы, фрезеровать новые корпуса, заказывать пресс-формы. Сделал сайт, попользовался, костылями доделал, что можно. Когда накопилось N проблем, которые нельзя решить на данной архитектуре — берётся новая архитектура и повторяется разработка с начала.
Из опыта, переписывание уже имеющегося проекта с нуля на новой архитектуре ощутимо улучшает понимание и навыки разработчика.
Еще есть аналог как проходить побольше «курсов» чтобы прийти во все оружии и понимать что и зачем, а не решать задачи/проблемы по мере их появления, но при этом так же сидеть и ничего толком не делать.
Если у вас какой-то бакенд, то это уже не маленький сайт.
Может, мне позвать в команду пару друзей, чтобы сделать всё правильно вместе?Это здравая мысль. А еще лучше — подруг :)
Это не типа хорошо, это просто замечательно!
Чтобы ваш сайт стал совсем современным, не забудьте ещё добавить прибитый гвоздями вебфонт на 25 мегабайт с непрописанными фолбэками — нищеброды, которые не проплатили мобильник и вынуждены сидеть на 56кб/с до конца месяца, нам не нужны.
Однако, они могут железно выставить фонт браузера на расово верную Тахому и всё равно прочитать сайт, да ещё и без задуманных вами завитушек над каждой буквой имени директора. Не беда! Просто рисуем спиннер в непрозрачном слое и отключаем скролл, пока не загрузятся все ресурсы, в том числе шрифты, а грузим их так же со скриптов.
Вуаля! Ваш сайт теперь современен как никогда раньше, и заодно защищён от неплатёжеспособных нищебродов с медленными каналами, полуразряженными телефонами, а также подозрительных хакеров, ходящих читать новости компании со включённым NoScript.
Соверменный сайт — это много картинок, растягивающийся дизайн, адаптивная под все девайсы верстка.
КМК имеются в виду «реклама, скрытая реклама, скрытое позиционирование марки, „интересное“, „посмотрите ещё вот это“, „оставьте свой емейл сейчас чтобы быть со скидками“, „напишите свой вопрос мы онлайн!“, трекеры, анализаторы и прочая воронка продаж».
От благодарного пользователя: нет, спасибо. Верните HTML.
много картинок
И всплывающих окон?
Может лучше развернуть Jenkins? Или использовать GitLab, ведь если делать сборку прямо в GitHub, может не хватить бесплатных минут, готовы ли вы доплачивать за это?
Реально крутой сайт выглядит вот так: www.malinov.com/Home/sergeys-projects
Прожить жизнь так, чтобы вот после тебя осталось такое.
статья огонь))
Добро пожаловать, что называется.
Кстати, слышал со временем люди поднабравшиеся всякого такого начинают зарабатывать продажей вот таких готовых решений в стиле all inclusive. В стиле: тебе деньги на сервисы и людей, а ты им кубернетисы, инстану с прометеусом, деплоймент в рандеке, битбакет с разными проектами под фронт и бек, CDN какой до кучи, все задокументировано в какой-нибудь конфлюенс — и обязательно красивые графики посещаемости и доступности каждую неделю.
Короче, холоптное такое дельце, как у нас говорят.
Мне кажется — все логично. Сейчас не нужно делать простенькие сайты. Трудиться для этого. Есть ресурсы, которые за ограниченное время, с хорошим результатом делают это за тебя. Например — tilda.
Остается именно то, что стоит разрабатывать. Т.е. тратить на это время разработчика. Отсюда релевантные (но сложные) инструменты и процессы.
Можно и сейчас на пхп писать странички, но теперь вам всегда будет этого мало. Как только вы прикоснулись к миру этих красивых названий, вы будете знать, что вот сейчас вы пишете страничку на хтмл+пхп, а где-то там есть штука, которая поможет это сделать быстрее, красивее и откроет вам что-то новое. Да ещё и сайт будет быстрее грузиться. Вот только для этого нужно изучить эту технологию (скажем, пусть это будет ReactPHP и его асинхронный цикл), встретить другие сложности, решить другие проблемы. А может, вы вовсе решите сделать блог на Jekyll+Ruby, кто знает.
Я считаю, что это закономерный процесс. (Но я не говорил, что считаю нужными все перечисленные в посте технологии)
Я: Заказчик сам попросил вас именно PWA, а не просто интернет-магазин?
ОНИ: Нет, но мы понимаем, что нужен PWA. Сейчас все делают PWA, так что в первую очередь делаем его, а потом уже полноценный сайт запилим.
Как на медузе.
Если вы не приемлите это видео, лучше почитайте про котиков, или посмотрите статью про восстановление рукописей
https://m.habr.com/ru/post/521870/
IT нужно учиться, открытие! А казалось бы был поваром, закончил пару курсов и бегом по 300 тонн в месяц заколачивать.
Дед говорил — раньше трава была зеленее и вообще как то без ваших сайтов жили.
p.s.
Статья ни о чём — ничего не мешает сделать быстро маленький сайт ещё и лучшего качества.
И уже тем более никто не мешает все делать как в 90-х, распростанять кстати можно через каталоги, а то эти гуглы требуют какой то оптимизации и т.п.
Я бы сделал на php и jquery. А когда/если на этот сайт придут миллионы пользователей — идем к инвестору, берем денег и нанимаем ребят с фреймворками и канбаном.
Солидарен с криком души автора, столько информации надо поглощать, да в прочем — это же интересно! Для любителей самообразования тут целое раздолье!
Все эти реакты с ангулярами на фронте, node js’ы с electron’ами на бэке, для всех найдется что-то интересное. А когда начинаешь погружаться в интересующую сферу — то глаза разбегаются, сколько же нюансов.
Пишу сервер для своей игры и параллельно почитываю книгу Куроуза по сетям, мда, поражаюсь иногда тому, сколько же человечество создало за годы своего существования.
В общем, удачи автору в написании сайта :)
Как раз недавно написал eshop, бек на django, фронт частично на django частично на react, деплой на ansible (nginx + gunicorn + django + postgres + memcached на 1 сервер). Но я не скажу что справился быстро. По моим ощущениям чертовски долго долбался с динамическими кусками на UI, это страница просмотра товара и оформление заказа. Делать перезагрузку на + — из корзины уже вообще не смотрится, так же как на переключение опций товара. На jquery программировать было очень убого, особенно обновление соседних элементов таблице. Нужно было какое-то красивое обновление контейнера целиком. Поэтому втащил реактовые мини-приложения, которые у меня каждое в своем файле, они просто подключаются и рисуют контент часть в body. Конечно несколько api методов пришлось сделать через DRF. Работает и можно расширять. В коде конечно частично каша, надо полностью отделять фронт от бека. Зарабатывает сайт скромно пока что.
А вот кулстори от создателя remoteok, который сделал сайт в 1 php файле и зарабатывает под $60к в месяц с него. Кто из нас дурак, очевидно
imho, проблема выдумана. Если вы уже поработали в "маленьких и средних" компаниях у вас уже сложился некоторый стек технологий. Для описываемой задачи не нужно принимать столько решений, просто берете то что умеете и применяете на практике.
Вопрос о языке коммитов или ветвлении вообще не нужно поднимать если проект изначально не планируется в широкие массы — скорее всего, когда это понадобится вы перепишите 90% кода и смените хотя бы половину применяемых технологий.
А взял бы C# — ничего из вышеуказанного изучать бы не пришлось, т.к. можно и веб компоненты и фронтенд на C# писать
Надо быстро и просто. Просто бы взял bootstrap. Стилизовал. И дальше усложняй как угодно.
Забавно, что в топе за неделю сразу за этим постом идет пост «Мама, я сделал хабр»
Последний абзац напомнил:
Напишу-ка я песню о любви,
Только что-то струна порвалась,
Да сломалось перо, ты прости,
Может, в следующий раз…
А сейчас пора спать…
Потом можно, если потребуется прикрутить и вьюджиес.
Мне кажется смысл поста вовсе не в том что слишком много технологий, большой выбор и так далее.
Смысл в том что чем больше опыта — тем больше сомнений.
Раньше не задумываясь берешь то, что знаешь и пилишь то, что хочешь. Общажный сайт на голом php в блокноте? Легко. Это весело и интересно, ты создаешь своими руками что то новое, не знаешь что из этого получится, и не думаешь как поддерживать это дальше. Зато каждый день видишь как это нечто растет и развивается, как на него приходят люди и пользуются тем что ты сделал. И это вдохновляет.
А сейчас давит груз опыта, который мешает наслаждаться процессом созидания. Ты не хочешь допускать глупых ошибок которые допускал ранее, хочешь сразу сделать всё правильно, продумать архитектуру, стек технологий, этапы реализации и даже выгоду. И глядя на всё это возникает такой шквал сомнений, что просто ни за что не берешься, прекрасно понимаешь что работы очень много, изучить надо кучу всего… И всё, руки опускаются.
Именно это я увидел в посте. Именно это откликнулось во мне.
Автору огромное спасибо, я как про себя прочитал :)
A community fork of Semantic-UI
fomantic-ui.com
Интересно: хоть один из комментаторов возьмёт заказ сколь угодно маленького сайта за 1 день( это 8 часов или 24 с хвостиком ?) Всем прям герои экстремального программирования. Т.е. чтоб всё работало через указанный срок, были реализованы все мааааленькие нюансы заказчика и вас не искали в армиях для доработок.( допустим, что тз есть )
А то вдруг не получится. А если получится, то вдруг будет работать неправильно.
А в чем проблемма PHP? Если же он то нормально спровляется и так)
Он вроде как раз для таких задач заточен (Я не хочу сказать что другие нет, а то закидают меня помидорами :), они так же хорошо годятся для задачи) Но слишком много замарочек… Я по началу сам как то думал вот писать сайт нужно — и то и се и еще что то… И в итоге простенький сайтик писал пол года… И терзал себя мыслями — а вот тут можно сделать лучше — а тут можно оптимизировать — новый фреймворк вышел — о нет js говорят быстрее того же php — php для такой задачи говорят будет работать лучше — фреймворк обновился на новую версию с кучей новых плющек — блин node работает только на одном ядре — о новый релиз laravel — о у ноды есть форки — о мой фреймвор обновился — фреймворки медленые уйду в ванилу — на ноде лучше работает с монго — проблемы с типизацией — js говорят говно — php говорят говно — и все в таком духе ( пока не осазнал ошибки и не написал его за 3 дня) (Сам же пишу на Node писал на PHP — те же проблемы те же задачи — те же решения — вот только методы решения отличаются) Переходить с PHP на Python или Node — а нужно ли?
Свой инструмент для своих задач.
SPA — а нужен ли он? Если нет — то вопрос в всяких фреймворках отпадет сам собой. (Ну можно там мол тот же Vue — а надо ли?)
SSR — если не SPA то вопрос сам отпадет…
Та хоть на CMS Wordpress все сделать — если он хорошо решит поставленую задачу )
На счет Fetch тоже проблем не вижу — разве что писать сайт на какие то IE или Opera mini (от которых уже все отказались)
На счет PUG то как по мне чисто вкусовщина — (его ж то придумали только для упрощения работы написания HTML и как шаблонизатор) есть Emmet для того же упрощения — и пишите хоть на том же чистом HTML.
А то если так замарачиватся — вот мол может PHP (У него же есть Laravel или Symphony и еще куча другого)
Или может все же Node (С express а может koa) А на фронт еще и сервис воркер прикрутить — для работы в офлайне, и PWA сделать… (Сам такой же был) А после Https на http2 перевести — и webSocket прикрутить…
То так можно и вобще задуматся о Cpp Java .Net GoLang Ruby или и вобще о гонке за перфоменсом и уходить в асемблер — ну я думаю вы понимаете ))
Нужно понять задачу — от нее делать решение.
Удачи с проектом )
Развели бардак, понимаешь-ли… куда подевались простые, человеческие болезни?
(с) Интервенция
В чём подвох?
Теперь я не могу сделать даже маленький сайт