Pull to refresh

Comments 319

Как мне кажется, как раз все наоборот.
В NodeJS с помощью нескольких команд можно за десять минут поднять простой сайт типа блога, и он уже будет с формой входа, с загрузкой изображений, и вполне стильно выглядящий. Представляю сколько бы это заняло у меня лет 10-15 назад.

Ну за 10 лет не скажу, а так чисто за тот же php с Yii. Показываешь ему табличку в базе и он тебе генерит CRUD. Контроллеры, вьюшки. Под ноду такое еще поискать надо, sails.js тебе только апишку даст.
В статье конечно все малость утрировано. Прежде чем брать какой-то стек нужно хорошенько подумать. Если делать блог за сотку, то вряд ли кто-то будет замарачиваться с SPA, SSR и прочим. Можно вордпресс клиенут впарить

Что значит "блог за сотку"?

Нет, это просто означает задешево
Кто сказал, что «сотка» это именно 100 000 RUR, а не 100 USD, например?
за 100р студент установит готовый движок.

Я даже не знаю, специально вы написали RUR, подразумевая, что это 100 RUB, или это была случайность?


Ибо RUR и RUB – разные валюты, одна – советско-российский рубль, а другая – современный рубль, после деноминации, которая как раз на тысячу сократила множитель. Если вдруг кто не знал.


В любом случае, эта последняя буква ещё сильнее увеличивает неопределённость, сотка чего именно имелась в виду. :D

Все правильно сказано — 100 000 RUR. Блог же за «сотку», подразумевая что очень дешево.)
спасибо, добрый человек. Давным-давно, когда мне надо было быстро перевести сумму в USD в рубли, я писал в гугле «100 USD in RUR», потому что гугл так подсказал.
А потом у них синтаксис поменялся на RUB и мне было интересно почему. Недостаточно интересно, чтобы погуглить, но достаточно, чтобы я фоново помнил об этом все эти годы.
Теперь узнал.
«Недостаточно интересно, чтобы погуглить, но достаточно, чтобы я фоново помнил об этом все эти годы.» — гениально сказал
Открывая рублёвый счёт в банке вы возмущаетесь, что номер счёта начинается с xxxxx810, а не с xxxxx643? Если верить википедии, то по ISO 4217 кодами советского рубля были SUR (810).

Единицы измерения «соток» в исходном комментарии не указаны, а значит любые предположения могут быть ошибочны. Для сотрудников минфина или ЦБ РФ «сотка» вполне может и сотней миллионов.

О, про SUR я слышу впервые. Значит, RUR – постоветский российский рубль, но до деноминации.


Я об этом слегка любопытном феномене узнал примерно таким же путём, как и StraNNicK, переводя в гугле валюту на рубли и получив какие-то не очень близкие к реальности цифры.

Какая-то кодогенерация CRUD вдруг внезапно какая-то фича, которую все вокруг пропустили, кроме А. Макарова. Разивайте мысль дальше.
Берете 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$

Я посмотрел прайсинг на сайте. Не всем подойдет фришная в продакшене. Или есть свой хост, то там без ограничений?


Но я обязательно заценю ее, уже не раз слышал про нее :)

sails.js — мы до сих пор это говно выпилить не можем =)) Зачем эта поделка вообще появилась…
Это же была волна новых идей. Никто не понимал какие js фреймворки и как использовать. Все занимали нишу, кто-то тащит лару в js кто-то идейно c#.
Ну JS для фронт-энда, а node.js и deno.land исползуют в бэке
А что с ним не так? Смотрел на этот фреймворк несколько лет назад, когда он только начинал набирать популярность, идея у них была вполне здравая — сделать что-то вроде аналога рельсов из мира руби.
С ним все так, только он умер. Ну то есть 0 движей. Но домен кто-то оплачивет.
Вот вот. Идея была хорошая потому что руби он рейлс и джанго хорошие… а вышла какашка с магией, конвенциями и мать его глобальными переменными боже спаси и сохрани… я рад что оно умерло.
В 2012 году, за вечер сделал одной юридической компании сайт, на Wordpress и нечего все работало отлично, была поддержка 3 языков, поиск, форма обратной связи, при чем я тогда системным администратором работал. До сих пор думаю если не нужно какой то сложной логики или API, то проще установить Wordpress и не париться, хотя сам я сейчас пишу сервисы на Python/Django

Недавно редактировал похожий сайт из 2012 — php+jquery, 3 языка и картинки.
Проблема была в том, что студия, делавшая сайт в 2012, умерла, и её домен продаётся, ну а пока — предлагает оценить дорогих (и не очень) дам вместо информации о бывших создателях сайта.
После удаления 1 строчки сайт продолжает выполнять функции сайта-визитки.
Кажется, я ещё больше полюбил YAGNI.

В NodeJS с помощью нескольких команд можно за десять минут поднять простой сайт типа блога, и он уже будет с формой входа, с загрузкой изображений, и вполне стильно выглядящий. Представляю сколько бы это заняло у меня лет 10-15 назад.


Да ровно столько же.
При использовании языка программирования, который был мейнстримом для веба тогда.

От языка программирования ничего не зависит.

Зависит — от набора используемых вспомогательных библиотек/фреймворков и от того как хорошо вы в этих библиотеках/фреймворках ориентируетесь.

А описанный функционал — заложен в библиотеки/фреймворки еще 20 лет назад.
Но, да, тогда это было в библиотеках/фреймворках — для других языков программирования, которые были в мейнстриме для веба тогда.

Дык жумлу-дрюпал-вордпресс-медиавики бы поставил и вообще ни строчки кода бы не написал.
Вы забли про Ruby on Rails. Почти все ТОПовые фреймворки нашего времени построенные на принципах ROR. Как раз, 10-15 лет назад, когшда JS был только фронтендом, а ноды вообще не существовало.
Кстати да, через месяц именно 15 лет будет с момента выхода Rails 1.0. А то, что автор в 2013 году вместо RoR+emberjs использовал PHP + jQuery, не думал про git, sass, ООП и т.п… ну не знаю, насколько это стоит обсуждения.
Сейчас, как и в 2013-м, на RoR за день без проблем можно сделать сайт, запулить его в облако на Heroku (который у автора на картинке), и он там будет работать. И даже не будет просто так отдавать целые странички с сервера — turbolinks нынче уже идет из коробки.

На днях было 15 лет со дня выхода symfony… А в 2013-м автор вполне мог использовать Symfony 2.0 — 2.4

Да и python также в принципе, можно тоже за минут 10-15 накидать на том же django с rest-ом функциональный готовый к работе сайт или rest api
А зачем REST? Django отлично отдаёт готовые страницы. Но нет, всем нужен REST. Да ещё и в виде DRF. А как посмотришь — проще обойтись без него. Ну вот не нужен этот монстр для большинства случаев, потому что он дублирует половину функций Django, править муторно, а привешивают к нему пару вызовов, с которыми отлично справится и собственный движок Django. Но менеджеры, конечно, лучше знают, что сейчас модно.

Извините, задолбали запросы на использование конкретной технологии там, где она вообще ни зачем не сдалась.
REST здесь имелся именно в смысле REST api. Не спорю насчет отдачи страничек, но за описанные 10 минут, можно к отдаче дополнительно успеть прикрутить api, причем не обязательно на DRF. Опыт действительно показывает, что DRF не нужен на маленьких апишках, где всего пару вьюх, но когда у Вас начинает расти объем сущностей с которыми вы работаете, он позволяет сильно ускорить разработку. Но тут уже возникает вопрос того, что так же как и с обычным функционалом джанго нужно понимать что и где должно вызываться и как должна быть реализована та же бизнес логика.

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

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

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

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

А что они у вас делают?

Либо вёрстку, либо проблемы. Это когда я вообще берусь за сайты. Чаще я занимаюсь обратным процессом — собираю с сайтов данные и укладываю в базу.

А что вы называете вёрсткой?

Свёрстанную страницу, которую я потом режу на блоки для шаблонов. Ну да, ещё какая-то опциональная функциональность, которая работает без перезагрузки страницы.

Передают вам html файл с рыбой, вы ставите переменные, циклы, условия и т. п., декомпозируете, а когда они вносят правку в вёрстку повторяете процесс?

В какой-то степени, да. И в итоге получается сайт, который не требует университетского мэйнфрэйма для просмотра страницы.

Понятно. Я этого лет 15-20 назад наелся. Теперь или фронты осваивают бэк и сами правят шаблоны и т. п., или бэк с фронтом взаимодействуют по API, а фронт отвечает и за SSR если что )

Ну вот я до сих пор считаю, что это лучший вариант. Видел единичные случаи, когда вариант SPA оправдан. Чаще всего — просто мода нагружать браузер как можно сильнее, хотя сгенерировать страницу на сервере ничуть не затратнее, чем тот развесистый JSON, по которому она строится в браузере. А то и вообще пересылается в том самом JSON почти целиком.

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


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

Если нет радикально менять интерфейс каждую неделю, то такие замены не вызывают особых проблем, потому что достаточно взять из готовой свёрстанной страницы только то, что изменилось. Собственно, фронтэндер, изучив язык шаблонизатора, легко делает всё сам. Ему не надо изучать Python или какой-то другой серверный язык программирования, ему достаточно изучить язык шаблонизатора. Который, кстати, в любом случае надо изучать, как бы всё это ни было устроено. У него есть шаблоны, нарезанные фронтэндером, есть язык шаблонизатора, есть набор объектов, попадающих в шаблон. Больше ничего не требуется.

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

Я же так и сказал: фронты осваивают бэк и сами правят шаблоны

Это не бэк, это язык шаблонизатора и только. А какой-нибудь шаблонизатор он всё равно будет использовать.

Шаблон — часть бэка, язык шаблонизатора — один из языков бэка.

Значит, они и так занимаются бэк-эндом, работая в браузере и генерируя страницы по шаблонам и им никуда от этого не деться.

А если серьёзно, то шаблоны — это как раз фронт-энд. И не важно, где из них собираются стртаницы. Потому что задача программиста бэк-энда — собрать данные и сложить их в пакет для дальней шей сборки страницы, а сборка страницы — это уже фрон-энд.

Ну вот очень многие знакомые фронтендеры не считают натягивание html вёрстки на созданные бэкендером шаблоны фронтенд разработкой — оно не на фронтенде исполняется, при ошибках вызывает 500 Internal Server Error и подобные аргументы.

Такое раздедление — «выполняется на сервере — значит бэк-энд» — это уже совсем что-то интересное. Тогда можно отмазаться от всей работы на основании «на сервере сгенерировано — бэк-энд, а я об этот грязный бэк-энд чистые джаваскриптовые ручки пачкать не будут». И, кстати. вёрстку не натягивают на шаблоны, шаблоны из этой вёрстки делают.
UFO just landed and posted this here
1. Я, собственно, и написал, что Python ему изучать не надо, надо только изучить язык шаблонизатора. Вот в случае с PHP ему этот самый PHP, вероятно, изучить придётся. Ну просто потому, что сам PHP есть, был и будет шаблонизатором, как бы ни старались из него сделать язык общего назначения: это заложено в его архитектуре. Хотя некоторые (не будем показывать пальцем на разработчиков Joomla!) умудрились написать на языке шаблонизатора язык шаблонизатора.

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

Тем не менее, PHP — язык-шаблонизатор. И его сейчас костылят ровно так же, как это делают с JavaScript.

Это бывший язык-шаблонизатор, а сейчас мультипарадигменный язык общего назначения :)

Просто его хорошо обвесили костылями. Основа-то осталась. И то, что на нём написали шаблонизаторы, не отмеяет его исходную природу, которая сохранилась. Из молотков можно собрать молоток побольше и потяжелее, но молотками они быть от этого не перестанут.
UFO just landed and posted this here
Основа-то осталась.

В каком смысле? В семействе 7-й версии было огромное количество изменений, нововведений и очистки от старья типа mysql*. Улучшение поддержки типизации, переход от кодов ошибок к исключениям, новые операторы, сахар и т.д., включая буст производительности, по некоторым оценкам, чуть ли не в два раза. Через несколько дней релизится 8-я версия, в которой тоже куча нового + JIT. Да, возможность шаблонизировать средствами самого языка осталась, но это давным-давно не главное.

Да, возможность шаблонизировать средствами самого языка осталась, но это давным-давно не главное.

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

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

Верно. При этом любопытно, что некоторые проекты (например, монструозный Magento) выбирают всё же пользоваться именно ей. Возможно, от нежелания добавлять лишние слои абстракции/библиотеки (в чём можно заподозрить, например, CodeIgniter), хотя в случае того же Magento их там уже столько, что влияние движка шаблонизатора (работа которого, к тому же, кэшируется), наверное, вряд ли можно считать существенным. У меня есть теория, что при достаточно большой популярности инструмента любая его фича будет кем-то использована вне зависимости от её спорности.

При этом любопытно, что некоторые проекты (например, монструозный Magento) выбирают всё же пользоваться именно ей.

Я делал один проект на Magento в 2009 и он мне тогда показался просто тормознутым куском говна. Если его не переписали полностью в новых версиях, то ничего удивительного, что он так и не умеет в нормальные абстракции. Вообще, если вы в период 2005-2009 читали код популярных тогда PHP-проектов (Joomla, Wordpress, Bitrix, Drupal, etc.), то легко понять почему люди массово переходили на другие языки. Всё-таки одно дело, когда ты по-простому делаешь сайтик, как описанный в статье, а другое — когда ты с таким же пофигизмом делаешь CMS или фреймворк. Это получается персонаж для кошмаров.

UFO just landed and posted this here
Я делал один проект на Magento в 2009 и он мне тогда показался просто тормознутым куском говна. Если его не переписали полностью в новых версиях, то ничего удивительного, что он так и не умеет в нормальные абстракции.

С тех пор сильно переписали. Честно, ещё не был с ним знаком в 2009, но когда познакомился — в версиях 1.8-1.9 — это уже был проект вида "абстракции на абстракциях, погоняемых абстракциями на абстракциях, много раз рекурсивно повторить". Суровый такой абстрактный монстр. С версий 2.х было серьёзное обновление фреймворков, но почему-то шаблонизация PHP осталась. Здесь, наверное, надо отметить, что Magento это не среднестатистическая CMS. Wordpress по сравнению с Magento это как муравей в сравнении со слоном. По крайней мере, сегодня.


Всё-таки одно дело, когда ты по-простому делаешь сайтик, как описанный в статье, а другое — когда ты с таким же пофигизмом делаешь CMS или фреймворк.

Не уверен, что всегда дело в пофигизме. Сам неоднократно сталкивался с ситуацией, в которой чистота абстракций и элегантность кода разбиваются о количество и непредсказуемость функциональности. Не уверен, что тот же Magento был бы реализован лучше на Java.

в версиях 1.8-1.9 — это уже был проект вида "абстракции на абстракциях, погоняемых абстракциями на абстракциях, много раз рекурсивно повторить"

Да, он по-моему с самого начала такой был. И это было избыточно. Абстракции хороши, когда от них практический толк есть, а не абстракции ради абстракций.

Вспомнил тут недавно PHP и спокойненко продолжил на нем делать сайты. Просто со временем образовался небольшой ворох минимального комплекта для запуска и получается вполне шустро и по разработке, и по скорости работы.
Не знаю уж, чем так плох PHP и MySQL — пока этого мне никто объяснить не смог

Ну это примерно как табличная вёрстка, которая тоже выглядит намного проще десятикратно вложенных div'ов с тоннами весьма нетривиального CSS'а, но считается «не тру», потому что недостаточно универсальна и покрывает лишь ограниченный набор юзеркейсов.

Но при этом таблица не разваливается при очередном обновлении браузера.
А уж как неограничено применение современных фреймворков, просто сказка, и чем дальше тем страшнее.не помню как там точно: "Шаг влево, шаг вправо — считается побегом. Прыжок на месте расцениваю как попытку улететь в космос."

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

Вполне достаточно отдавать мобильным устройствам отдельную мобильную версию. Это куда надёжнее и куда легче адаптивности.

Я бы не был таким категоричным.


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


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


И, уже набивавшая оскомину истина: каждой задаче своё решение.

Собственно, на мобильных устройствах всё равно надо тестировать, так что особой разницы не вижу.
Это точно, зато с «простейшей» по современным меркам странички браузер как пить дай отгребает гиг озу на то что бы распознать, что наТБМвертили эти ВЕБкодемастеры.
ТБМ, как я стар, когда в «кроватке» середины-конца 90х болтали… легкие чаты, пролезающие через 2400, а не требующие онлайн-линка в 1-2МБита. я совсем не понимаю современные тенденции — это для того чтобы даже мощнейшее железо заставить ползать так, что даже 8088 кажется очень даже быстрой машинкой?
ЛЮДИ, ОЧНИТЕСЬ!
а Илюше — нахрен универсальные на все случаи гробы, которые хреново распознаются везде? нафига эти кучи слоев? информация погружена во все эти обертки, что даже нормально вычитать ее приходится изголяться!!!

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

Во второй половине 90х, когда первично появились избытки мощностей, в первую голову процессорных, п-про, пошло такое компонентное чудо как Дельфи. Когда даже совсем безголовый олигофрен, мог тыкая мышкой собрать из компонентов красивое, но медленное приложение и в эти контейнеры сигналов и функций вложить нужную себе функциональность. Пошли производные компоненты и чем дальше тем хуже.
До них был другой подход к работе, есть атомарные компоненты, тот же mfc и между ними требовалось наращивать мясо, т.е. понимать что и как работает и зависит. А теперь даже ТБМный калькулятор занимает сотни мегабайт, требует выход в интернет и еле ползает на тех же смартфонах, которые мощнее суперэвм 20 летней давности, при несопоставимой полезности изделий.

А полезность в чём измеряете? Если в деньгах, которые покупатели готовы платить за изделия, то полезность суперэвм и смартфонов если и несопоставима, то с другой, наверное, стороны, а не той, что вы имели ввиду. Триллион долларов уж точно в год платят за смартфоны.

Вы повторяетесь.


Тогда я снова скажу: вы все прекрасно понимаете. Ответы на «что, как и почему» у вас есть.


И вы ищете не объяснений, не интересных споров, а единомышленников.

Как я понял, вы почему-то очень не любите Delphi.
Но Visual Basic появился раньше и, по слухам, был популярнее Delphi.


Утверждения о тормознутости Delphi голословны.
Delphi всегда был компилируемым языком с приемлемой скоростью и в тормознутости современных сотнемегабайтных калькуляторов он не виноват, они не на нём написаны.

И брюки Delphi превращается, превращается… в веб-приложение!


Сурово ж вас приложило.

Нет, что-то похожее реально существовало еще в начале нулевых.
Но цимес в том, все эти веб-приложения, которые (заслуженно, не без того) старались охаять выше, построены вокруг хрома, который написан на C++.
А виновата, оказывается, Delphi.

Нельзя даже сравнивать Delphi и современный веб. Во-первых, приложения написанные на нём быстро компилировались, занимали мало места, не требовали многомегабайтного рантайма, и шустро работали даже на Pentium 100МГц с 16 мегабайтами ОЗУ. Во-вторых, компонентный подход Delphi был революционным, и здорово упрощал жизнь разработчику, позволяя быстро спроектировать GUI, а после сосредоточится на основной логике приложения. Что выгодно отличало Delphi от того же MFC, где интерфейс приходилось долго и муторно писать вручную…
Современный же веб не даёт ни простоты (даже статья о том, насколько все это сложно!), ни экономии ресурсов, ни революционного подхода, заставляя разработчиков заниматься практически тем же, чем занимались когда-то суровые MFC-шники, но на более высоком уровне.

15—20 лет назад я ещё как-то мог с вами согласиться, но сейчас таблицами верстать банально сложнее, чем гридами, флексбоксами, или даже простыми блоками. А в большинстве кейсов с адаптивностью — просто невозможно.

При том что все еще можно сделать сайт за один день на Wordpress на том же php и не мучаться.

Да и как-то не по существу — «ну теперь просто на 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 без spring?

с java EE еще можно жить, как по мне, но Spring лучше имхо :)

Друг, я так тебя понимаю! Сам когда-то работал с ним, но выбора не было — работодатель продавал решения на его основе.
Не хотите сильно парится с фронтом? → Java jsf

Хе. Теперь вы не сильно паритесь, а прямо-таки погрязли в болоте энтерпрайза. И PrimeFaces вас не спасёт. :)


На самом деле, не знаю, что именно теперь стоит использовать для фронта на джаве, уже давно этим не занимался. Какой-нибудь шаблонизатор для спрингового MVC, разве что...

А мониторить кто будет?! Вам ещё графана с каким-нибудь алертингом нужна. А то понадеплоют тут, а ты потом разбирайся.

А ещё обработка ошибок: sentry какой-нибудь.
Мониторинг доступности типа pingdom.


Тесты не затронули. Целый пласт решений.


Анализ уязвимостей.

С тестами я даже боялся начинать потому, что не смог бы дойти ни до чего другого, остановившись на серьёзном вопросе, писать ли мне в этом проекте тесты сначала, или потом, и в каком объёме. :)

Тут и дизайн, UI/UX, я тоже потерял, а если о монетизации задуматься, то это вообще пучина!
писать ли мне в этом проекте тесты сначала, или потом

Пока тесты и код в одном коммите — никто и не узнает :) Плюс есть rebase и squash ))

Тот же sentry в простейшем случае устанавливается практически в одну строчку (https://develop.sentry.dev/self-hosted/)
С приходом контейнеров эра "коробочных решений" как раз в какой-то мере вернулась.
Иногда достаточно написать Docker Compose файл и решение уже почти готово.

Вы упустили настройку самого dicker-а на, обычно, ограниченных ресурсах у хостера (по экономическим причинам).

Если речь про VDS какой-то и настройку именно докера, а не оркестрацию контейнеров, то обычно настраивать особо ничего и не надо, кроме установки самого докера.

Автор явно обошёл стороной облака: вдруг про сайт завтра напишут все мировые сми и туда зайдут десятки миллионов пользователей? Нужно обязательно хоститься в облаке и чтобы работал автоматический скейлинг. Скорее всего k8s станет хорошим решением, в aws можно воспользоваться eks для этого. Также никогда не знаешь, сколько данных придётся хранить, добавим туда интеграцию с s3. Заодно и бэкапы закидывать в glacier deep archive удобно. Кроме этого с
разворачивать всё руками — прошлый век, стоит взять terraform и исполтзовать подход infrastructure as a code. Десятки миллионов пользователей создали терабайты логов и их надо проанализировать? Как хорошо, что это можно обработать в кластере EMR. И это только начало, над cloud native частью стоит поработать, это сейчас очень популярно!

Боюсь если сайт не для сбора денег на рекламе, авто-скейлинг лучше не использовать, а то кто знает как потом отдавать эи 10-20 k$ изща habra-эфыекта :)

Каюсь, очень хотел упомянуть, но забыл!
Вот именно поэтому написание статьи нужно было начать с установки и настройки task tracker!
UFO just landed and posted this here
В 2020 докер уже мёртв, разве нет?
А что вместо докера использовать?
UFO just landed and posted this here
UFO just landed and posted this here
Его не убили, он просто умер. Но поскольку заменить особенно нечем (тут я не силен если честно), то все продолжают им пользоваться с надеждой, что родится какая-то новая технология.
UFO just landed and posted this here

Справедливости ради, некоторые перешли/переходят на совместимые альтернативы или просто не используют.

UFO just landed and posted this here

Первый — про, прежде всего, podman и компанию. А так и lxc только за последнее время несколько постов на Хабре было. И вообще всё это обёртки над cgroups и неймспейсами.


А вот второе — в голове была чистая олдскульщина: проект развёрнут на локальной машине разработчика без какой-либо виртуализации, конейнеризации и автоматизации. На новую машину нужно в строго определенные места склонировать репозитории, пачку /etc/* файлов, отредактировать /etc/hosts, и стандартного пользователя хорошо бы создать. Сделать один раз и забыть на годы может быть, пока не придёт письмо на группу рассылки devs: "в наших конфигах домены example.dev заменены на example.test в связи с тем, что .dev теперь делегируется. Обновите свои локальніе конфиги"

А что не так с вагрантом? Для разработки (под виндой по крайней мере) очень удобно — буквально за день сделал шаблон, и постепенно перетащил все проекты в отдельные виртуалки, при этом у каждой отдельный домен (на основе имени из composer/package.json). Как это сделать на докере сходу не нашел.

Спасибо. Правда судя по беглому взгляду в Windows 10 оно просто так не заведется (hosts как минимум обновлять оно, похоже, не умеет).

Я dnsmasq использую, чтобы все запросы **.test на докер шли

А какие есть альтернативы? Firecracker на ум только приходит, но он скорее для FaaS.

Основная проблема, что нет определения понятия «умер» в контексте технологии.


В вышеуказанной статье вывод сделан по одному признаку: на конференции в Питере не было докладов.

UFO just landed and posted this here
Обилие технологий не должно смущать. Выбрать фреймворк под задачу в 2020, очевидно, сложнее, чем в 2000 — но, сделав правильный выбор, развернуть решение и получить результат зачастую удается в разы быстрее.

p.s. вдогонку к готовым cms типа вордпресса, если вдруг хочется попроще в плане архитектуры — любой статический генератор (gatsby, etc.), который даже на условные github pages из коробки встает (а это значит — без геморроя весь CI, мало ли в резюме показать :) ), решает описанную задачу.

но, сделав правильный выбор

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

Обилие технологий не должно смущать

почему не должно? кто сказал что не должно? меня смущает, автора смущает
потому что объективно выбор — смущает
он требует ресурсов мозга, это факт

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

я даже не про себя, а давно на веб-разработку забил
в моей области (gamedev и сервера) тоже выбора прилично
UFO just landed and posted this here
А рутина, кол-во используемых технологий, овертаймы, многословность кода, часто переделывать? это по сравнению с вебразработкой в геймдеве как?

* рутина есть везде, и в геймдеве, там же тоже надо отлаживать баги, тестировать, кодить чтото 10 раз что вы уже делали
* кол-во используемых технологий — иногда можно взять чтото простое что работает, иногда приходиться делать серьезный выбор, оценивая очень многое, и в геймдеве часто надо чтото оптимальное, но иногда это оптимальное это долго кодить, и выбирается сначала нечто среднее, или потом переписывается на более оптимальное, другую архитектуру и т.п, и все эти оптимизации они тоже требуют выбора (что делать и когда)
* овертаймы — в геймдеве частые на сколько я слышал, хотя у меня бывают редко потому что я физически не могу авралить часто (голова уже не варит)
* многословность кода (как и качество кода, и кач-во проектирования и тестов) — зависит от опыта разраба, впрочем там где я работал — в основном разрабы сильные, новичков откровенных почти не было, ну и копипаста и лапша в коде конечно бывала но явно меньше чем я видел в (условно) «плохих примерах кода на php\js»
* часто переделывать — см выше — переделывается для оптимизаций, либо для портирования на другие девайсы (мобилки, веб, консоли, пк)
UFO just landed and posted this here
еще хочу дополнить, отвечу на свой комментарий

с научной точки зрения, человек может сделать выбор 2мя способами
1) лимбической системой — это псевдо-выбор основнанный на эмоциях, и зачастую в жизни именно он активно работает, например нам нравится какая-то еда, или мы привыкли вставать в опеределнное время и идти на работу, играть в определенные игры, и часто мы перенимаем этот опыт у кого-то, а потом зкрепляем за ним эмоцию и желание действовать также или не действовать
… в примере с технологиями это может быть хайп (ктото гдето написал что это клевая теха), а никак не ваш разумный выбор, и потом есть высокий риск что вы выбрали не корректно, потому что вы то доверились комуто
2) неокортексом — т.е. логическое осмысление множества факторов, но тут проблема — если сравнить 5 технологий (раньше) vs 500 (сейчас) то комбинаторный взрыв мешает сделать логический выбор за разумное время, и в конце концов человек или выбирает нечто «достаточно хорошее» как ему кажется, за N время (не макс время), или тратит слишком много энергии\времени на реально оптимальное решение

поэтому о каком «правильном» выборе может идти речь, если для логического его осмысления неокортексом надо непомерное кол-во энергии
раньше то выбора было меньше, и туториалы читались быстрей, и релевантные причем

Ох, помню сколько я времени убил на выбор стэка для простенького сайта на шаред хостинге: И C, и C++, и Perl, и ещё что-то Остновился на PHP. И это только язык.. А ещё выбор Linux или BSD. В чём под Windows писать код сайта… В чём писать разметку и стили...


Просто автор для первого своего сайта по сути и не выбирал стэк: была одна книжка по ней и делал

Я тоже сделал свой первый сайт на чистом PHP + JS около 20 лет назад. Через несколько лет свои наработки превратились в собственную CMS. Сейчас это ретро никому не нужно, кроме меня. Поэтому я, использую свои наработки, только для себя. За несколько часов делаю простой сайт и back-end для мобильного приложения.
А своим клиентам рекомендую нанять другого разработчика для получения красивого и современного результата.
Почему не изучаю зоопарк современных фреймворков и CMS? Да просто не хочется тратить на это время, разработка приложений под Android гораздо интереснее.
Сейчас придет Дмитрий Карловский и покажет как на моле за сутки сделать вебсервис, где можно жестами для вебки двигать картой в браузере.
UFO just landed and posted this here

Я много чем занимаюсь. Конкретно сейчас математически расчитываю дизайн. Есть в планах и своя штука на которой можно будет накликивать хоть CMS, хоть чат, хоть баг-реткер и тп. Хоть всё это вместе.

UFO just landed and posted this here

Пока только различные отступы.
Четырёхзначная логика необходима для корректных рассуждений. Я думал использовать пролог для валидации доказательств, но похоже он недостаточно силён для анализа произвольных выражений. Так что придётся пилить свой пролог с четырёхзначной логикой и релевантной импликацией.

Не хочу в ПТУ даже преподавать ) Современный PHP не имеет фатальных недостатков в своих нишах, а работать может не только с MySQL. полный переход переход на другие технологии, хоть "хайповые", хоть "мэйнстрим" существующему бизнесу особых плюсов не даст. Точечный — вполне, и давно практикуется, даже до моды на микросервисы.

Мы тут, кстати, на днях хакатонили. Так я прям заскринил, что сделала команда, которая использовала модный стек React+Redux:


Заголовок спойлера


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


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


Заголовок спойлера


А победили ребята пилившие на Ангуляре вчетвером:


Заголовок спойлера



Итого, можно сказать, что для вкручивания лампочки нужно либо 4 Angular разработчика, либо 1 $mol.


К слову сказать, больше всех успели сделать ребята, что пилили на 1С. Выглядит оно, конечно, "интуитивно понятно". Не заскринил, но 1с-интерфейсы все одинаковые.

может, мне стоит откопать старую книжку по PHP, и сделать всё, как в 2013 году
PHP в этом плане очень подходит, потому что можно поставить самую последнюю версию, например PHP 8.0.0-rc3 и сделать сайт по книжке 2013 года, в которой скорей всего используется PHP 5.5. Реальный пример.
ух, сколько нам приносил «радости» переход с 5.1 на 5.2, а потом на 5.3… помнится, именно 5.3 — прилично поменялся язык. Поэтому до сих пор есть сайты на 5.2, потому что «и так работает до обновления»

5.3 — я бы сказал язык переродился, но сильных BBC не помню до 7.0. Там скорее желание всё переписать было "по уму" с активным использованием новых возможностей: неймспейсов, нормального ООП, интерфейсов и т. п.

В 5.3-5.4 была история с резким сбросом кучи деприкейтов. В частности ссылки, глобальные переменные и ещё что-то по мелочи. Как следствие вся кодовая база, которая пришла ещё со времен PHP 4 отхватила.


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

А, может почти не заметил потому что всегда активно боролся с деприкейтами. Хотя как-то выиливал на новом для себя проекте PHP4 конструкторы в процессе перевода с 5.6 на 7.0

Я свой сайт написал по книжке году а 2008-2010, там была пятая версия языка. Сейчас без особых проблем мигрировал на хостинг с 7 версией (переписал mysql вызовы только, поддержка закончилась у библиотеки). Так что для простых сайтов это справедливо.

У меня до сих пор сайт на PHP 4.4 dev. В своё время переход на PHP 5 не удался… А теперь уже утекло слишком много времени. Сервер поменять страшно. Ну и по старой админской привычке «работает, не трожь»… До сих пор боюсь этой «радости» перехода.

Тут уже лучше не переходить, а написать всё с нуля. Только, конечно, без того зоопарка, как у автора поста. Что-нибудь поменьше взять, покомпактнее.

Главное не забыть использовать mysql_connect(), а потом задолбать гугл и тостер вопросами "У меня не работает MySQL что делать".

Я просто переписал на mysqli_connect(), там почти тоже самое.
Вах! Вы сделаль мой день!
Я в веб особо не лезу, но со стороны все видится именно так.
Понаплюсовал бы, но тут кармы-шмармы, и я как-то дискриминирован, поэтому просто спасибо, читал с удовольствием.
Да автор какой-то странный, делает из мухи слона. Он бы ещё начал микросервисную архитектуру разворачивать для своего новостного блога города. Все эти инструменты же сделаны для конкретных задач. Для него подошёл бы тот же самый wordpress. А он начал забивать гвозди микроскопом, и жаловаться, что что-то тяжеловато.
UFO just landed and posted this here
А чёрт! Для меня было слишком тонко :D.
Для автора подошел бы и Wix.com (или его аналоги).
Так и написал бы что нет опыта разработки с нуля, всё для тебя подготавливали. После первого раза разработки с нуля в любой средней/большой конторе вопросов в принципе не возникает. Берёшь то что удобно и быстренько херачишь сайт не заморачиваясь вообще ни о чём. Новые технологии позволяют не писать кучу кода которую тебе нужно будет написать на ПХП, тут уже всё готово бери и используй. И исходя из опыта могу сказать что вообще не важно на чём писать, главное это на чём умеешь хорошо, чтоб не изучать туеву хучу новых инструментов.

Если делать всё "по уму", "чтоб пацанам не стыдно было показать", то почти без разницы какой конкретно современный стэк использовать, включая PHP и MySQL. Библиотеки, фреймворки, обёртки, кодогенераторы везде в мэйнстрим сейчас есть. Половина, если не больше современной инфраструктуры language agnostic.

Истинно так!
А чем плох вариант сайта "из коробки"?
Wordpress/bitrix/Joomla + тема по вкусу + доработать напильником, кладём на популярный виртуальный хостинг = обычный типовой сайт! И никакого геморроя!


С каждым годом все больше осознаю, что главное — это КОНТЕНТ! Даже сайт сверстанный черти как, с поехавшей вёрсткой, без мобильной версии и прочих свистоперделок вполне себе будет популярным и посещаемых, если там есть важная и/или нужная информация.


Вспомните старую корзину Вайлдберриз — при оформлении заказа хотелось замучить до смерти того, кто её написал, но многие (и я тоже) ценой невероятных усилий таки оформляли заказ. Почему? Цена, удобная доставка, нет предложения от конкурентов, доверие к крупному ритейлеру. Остальное все от лукавого.


До сайта на ларавел или дотнет надо сначала дорасти! А там уже видно будет на чем и как оно должно работать.

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

самый лучший комментарий! жаль не могу плюсануть.
Может, мне позвать в команду пару друзей, чтобы сделать всё правильно вместе?
Не забудьте записать друзей на тренинги по agile, scrum, kanban и т.д. Ну и само собой проект в Джире завести надо будет.
Конечно, и мне стоит знания освежить! Нашёл курсы на Нетологии за 55 000, если друзей четверо, то выйдет всего 220 000 рублей. Плюс за Джиру по 7 долларов. Недорого, главное побыстрее найти инвестора!
Лучше бросить дурацкую идею создавать сайт и сразу начать с курсов по созданию сайтов.

Создать таки сайт, записываю все действия, и продавать как курс.

Создать сайт, где будут продаваться курсы по созданию сайтов с курсами…

Ну, мастер-классы по ведению мастер-классов были не редкостью.
Но бум инфоюизнеса и инфоцыганства вроде бы уже прошел.

Но бум инфоюизнеса и инфоцыганства вроде бы уже прошел.


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

Прямо в точку! Именно поэтому я начал работать над проектом viewi https://viewi.net/ чтобы решить эту проблему. Стадия PoC.

Плывущая верстка родом из 2000-х, мммм, найс


Причем на Хроме, правда не самой последней версии. 20 лет прошло, а мы все еще подстраиваемся под версии браузеров, ностальгия…

Можно узнать версию хрома ?

Слишком старая версия, flex is not supported, вам нужно обновить хром

Апдейт: это не флекс, это плагин в хроме, буду решать проблему

Дак в том-то и дело что я не должен обновлять версию годовой давности как в 2000-х потому-что что-то там не поддерживается, ибо это и есть та кросс-браузерность, о которой все мечтали. И да, flex поддерживается, выше уже сказали.
Issue with browser's extensions has been resolve. Спасибо Acuna за помощь.
Подтверждаю, дело было в очередном корявом расширении
UFO just landed and posted this here

Good catch, спасибо, повторюсь, PoC версия

UFO just landed and posted this here

Коротко о том, почему все эти фпшные "монады" — сложные, но везде рекламируются.

Тогда почему не брать Spring Boot? Много чего есть просто в коробке с ним)
Подобный агрегатор новостей делал тоже, куда городские события подтягивал с разных RSS-лент других сайтов. Публиковались новости в черновики, потом я их редактировал и включал на сайте. Каждодневная эта процедура заняла меня тогда на целых полтора года. Потом, внезапно, все перешли читать новости в телегу и к сайту у народа интерес пропал.

Вообще, когда-то в 2008 году мне один программист сказал, что в принципе на PHP можно что угодно написать, хоть аналог Windows. Так ли это, не знаю, сомневаюсь, конечно. Но, однажды, видел сайт с шаблоном, как у проводника Windows, один в один, как на XP.

Время некромантии, сейчас этого всего очень не хватает, пока спасаюсь только inoreader'ом. Статьи нынче фильтровать уже очень сложно, слишком много источников и чаще всего они так сделаны, что внутри фильтрацию не задать, да и ходить каждый день проверять 20+ сервисов/блогов, можно чекнуться

Так и не понял, что мешает автору в 2020 году склепать сайт, который в своем минимальном воплощении всё так же представляет собой набор html-страниц (plaintext), как и в 1994 году.

Хочется «по высоким стандартам»? Так изучите их. Вы не можете за час поднять бек на ноде (или на пару слоев абстракций вверх от ноды) и фронт на каком-нибудь реакте — а я могу, например. Просто вы пытаетесь это сделать без каких-либо знаний, а я и то и другое пару лет назад делал, и таки да, с опытом оно в принципе как раз час и занимает, а остальные время этого «одного дня» — уже на содержимое пойдет.
Но и вариант «просто нафигачить хтмл-страниц и захостить их» тоже работает, и за день можно очень много нафигачить, я проверял (правда, тут совсем другие практические навыки нужны, в основном по работе с шаблонами текста руками).

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

Будьте проще.
Шансы, что что-то станет настолько популярным, что появиться коммерческий смысл допиливать меньше 5%.
Увы, но идеальные системы оказываются завершенными к моменту, когда тема себя изжила.
Городские информационные порталы протухли лет 12-15 назад.

Мне интересна тема локальных городских медиа. Что на ваш взгляд пришло на смену городским информационным порталам?

UFO just landed and posted this here
Или «Типичный ххх» там же
Справедливости ради, на той же голой ноде можно сделать сайт так-же как раньше делали на PHP, а то и проще. И без какого-либо оверинжиниринга. Но если бы такой подход был достаточно хорошим, вам бы не понадобилось переделывать старый…
Акценты расставлены не правильно.
В 2013 году я пилил простые сайты на пэхэпэ в одно лицо за пара сотен долларов.
Сейчас одностраничник у нас обойдется тыщь в 170 долларов, 2 месяца, коллектив из 4 инженеров, плюс дизайнер плюс пол менеджера и стек из пол сотни технологий.

И это не плохо.
Я думаю, что одностраничник обойдется в те же пару сотен. Стек из пары сотен технологий — и что с того? В 2013 году для запиления сайта ведь не нужно было собирать кастомное ядро, apache из исходников и vlan'ы прописывать? Раньше «под капотом» тоже было много чего спрятано. Сейчас — больше. Но упарываться во всё не обязательно.
Одностраничник обойдется в 0 рублей 0 секунд, он в качестве дефолтного примера с фреймворком идет.
А можно вообще мышкой в конструкторе за три бакса накликать.
Те, кто умеет в фреймворк — ему одностраничник не нужен. Те, кому нужен — не умеют, но у них найдется несколько денег. Думаю, они договорятся ;)
А какой минимальный набор сейчас нужно изучить начинающему в веб строительстве? Бэк и фронт?
Я думаю, что можно взять любые технологии из тех, что упоминаются в статье, и из тех, что не упоминаются. Или даже любой курс на Udemy или Coursera. До поры до времени никакой разницы в технологиях заметно не будет. Я бы выбирал те, где документация проще читается.

Главное не уподобляться лирическому герою рассказа.
Наверное имелось ввиду другое. Что проще — учиться делать на голом на php или сразу учить какой-то фреймворк?
UFO just landed and posted this here
UFO just landed and posted this here

Есть разница большая между знать язык и делать сайт на голом языке. Конкретно в PHP она смазана немного всякими суперглобалами и стандартными функциями типа header(), но вот, например, знание Java как языка мало поможет перевести сайт с PHP (не на Symfony :)) на Spring. Большую часть времени будешь гуглить как получить распарсить входящий запрос, как установить куки, как сделать запрос к БД и т. п., а не как объявить класс или переменную типизированную

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

Полностью с вами согласен.
Добавлю ещё такие забавные линки:
BackEnd
FrontEnd
HTML, CSS, JS.
Внезапно вы уже можете и бэк и фронт.
С самими инструментами, конечно, тоже придётся ознакомиться, с той же нодой. И реактом каким-нибудь. Но инструменты по важности сильно меньше фундамента.
UFO just landed and posted this here
аахахаа я помню один слезный ишью на гихабе, где чувак недоумеевал. Он 10 лет писал под пресс и темы и плагины в блокноте, а ему теперь сказали изучай вебпак и реакт, потому что теперь никак))) Он там просто в истерику впал. Жить то теперь как.
UFO just landed and posted this here
А можно сначала погуглить, может такое уже кто-то делал, например
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

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

И сколько деталей от БМВ подходит к Тойоте и наоборот?
Если заедите в гаражный автосервис, то будете удивленны сколько запчастей от ВАЗа можно запихать в БМВ или Тойоту.
Не так и мало. Датчики разнообразные, фильтра, подшипники, ремни навесного, лампочки, предохранители, провода и многое другое.
Обычно так — одна модель, одно поколение, чуть разные года выпуска — запчасти разные.
UFO just landed and posted this here
UFO just landed and posted this here
Нужно заранее предусмотреть будущую гетерогенность микросервисов и впихнуть MQ и Kafka до кучи, ведь когда хайлоад придёт — это будет некогда делать. А, и мастер-мастер репликацию с шардированием, и везде HA proxy, чтобы ни в коем случае нигде SPOF не образовался.

Просто веб вырос и стал годен для разработки полноценных клиент-серверных приложений.


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

Я так и не прочитал ответ на «вопрос» — « Хм, не могу же я просто взять PHP и написать на нем несколько страничек вперемешку с HTML. »
Так все же, почему нет?

Всё просто и одновременно сложно. У лирического героя рассказа присутствует довольно явно выраженная профдеформация в сторону «голый php для школоты, а уважающему себя сеньору нужен более глубокий стек технологий», что и выливается в вышеуказанную несовместимость пушки с воробьями.
Но и с фреймворками на самом деле не всё так гладко, как может показаться на первый взгляд. Был у меня коллега, который для решения каких-то прикладных задач, слабо связанных с основным профилем деятельности конторы в целом, решил выучить фреймворк для web-разработки. И по этому поводу выучил...codeigniter. Это я к тому, что не всегда бывает возможно правильно предугадать вектор развития той или иной технологии.

К слову, освоив codeigniter, на другие фреймворки переходить гораздо проще чем с "голого php" — ничего, концептуально противоречащего современным версиям популярных PHP-фреймворков, в нём нет.

Возможно и так. Сложно сказать, поскольку с web-разработкой я связан менее, чем никак.
Всё просто и одновременно сложно. У лирического героя рассказа присутствует довольно явно выраженная профдеформация в сторону «голый php для школоты, а уважающему себя сеньору нужен более глубокий стек технологий», что и выливается в вышеуказанную несовместимость пушки с воробьями.

Не увидел особой пушки по воробьям. Ну может не за день он это напишет, а за два. Но там текста больше чем реальных размышлений. "Ой, где хранить код" — ну блин, на гитхабе, разрабатывать можно или по облегченному гитхаб флоу, или вообще по принципу "все фигачим в мастер", раз уж разработчик на проекте единственный. Делается репа и заливается код ну за 5 минут.


Так что сарказм статьи понятен, но на самом деле все не так уж страшно. Если знать все используемые технологии, то выйдет не дольше чем на пхп. Если не знать — ну что поделать, я вот PHP не знаю, на нем у меня дольше займет, чем на реакте и шарпе.

Хранение кода в контексте рассказа это как раз меньшее из зол. Начинается всё с того, что герой выбирает между несколькими разными способами сделать сайт. Реально можно взять для этого что угодно из перечисленного: хочешь — Symphony, хочешь — Node.js, а хочешь — связку Python + Django. Любой вариант так или иначе подходит. Вместо этого разработчик начитает метаться между всеми зайцами сразу, и результат оказывается закономерным.
по принципу «все фигачим в мастер»
Про это там тоже есть. Основной аргумент против — «так не делается». Упор моего изначального комментария был сделан на то, что в случае возникновения описанной в статье ситуации проблему необходимо искать не столько в выбранном стеке инструментов, сколько в самом себе. И не пытаться вместо MVP выдать сразу идеальный конечный релиз продукта, разумеется.
Так же не понимаю, кто вам запретит (ну кроме заказчика разве что, но из контекста заказчик — автор статьи). Pet проекты как и 10 лет назад прекрасно пишутся за вечер, единственное что изменилось — теперь есть пара вспомогательных инструментов которые не так уж сложно освоить за вечер — как то composer в случае PHP и npm в случае JS.
На мой взгляд, автор начал разработку не с того конца. Мне почему-то всегда казалось, что выбор инструментов разработки должен исходить из требований к ПО (бизнес требований, требований пользователя, функциональных требований и т.д.).

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

Автор полон сомнений. Ему не стек выбрать хочется, а уверенность получить в том, что силы будут потрачены не зря.
Суть software, в то что это именно soft. Ошибка в выборе среды разработки/языка/фреймворка/и т.д. несёт потери только времени на разработку. Вам не придётся перепаивать платы, фрезеровать новые корпуса, заказывать пресс-формы. Сделал сайт, попользовался, костылями доделал, что можно. Когда накопилось N проблем, которые нельзя решить на данной архитектуре — берётся новая архитектура и повторяется разработка с начала.
Из опыта, переписывание уже имеющегося проекта с нуля на новой архитектуре ощутимо улучшает понимание и навыки разработчика.
Не обязательно. Я вот в статье себя узнал, хотя вебом не занимаюсь и автор пишет немного о другом. Для меня это скорее перфекционизм/максимализм. Вместо того чтобы взять какой нибудь игровой движок и начать делать хоть что-то, я изучаю и разворачиваю дома связку confluence + jira + bitbucket как минимальный набор где вести документацию, ставить себе ленивому задачи и учиться работать в команде. Запускаю это все в связке между собой, с доступом через nginx, настроив https + бекап всего этого. Т.е. желание создать максимально правильную рабочу среду, прежде чем приступить, еще даже не поняв: «а то к чему я собираюсь приступать мне вообще интересно будет или нет»?

Еще есть аналог как проходить побольше «курсов» чтобы прийти во все оружии и понимать что и зачем, а не решать задачи/проблемы по мере их появления, но при этом так же сидеть и ничего толком не делать.
Маленький сайт — это HTML для браузера по стандартам W3C.
Если у вас какой-то бакенд, то это уже не маленький сайт.

Html может быть на десятки тысяч страниц, а form — обычный! Html и он предлагает бэкенд. Может один простой php скрипт, но бэкенд

Может, мне позвать в команду пару друзей, чтобы сделать всё правильно вместе?
Это здравая мысль. А еще лучше — подруг :)
Просто выросли требования. Откройте сайт за 2013 год — скорей всего, он будет выглядеть убого.
UFO just landed and posted this here
По нему и видно, что сайт старый. Соверменный сайт — это много картинок, растягивающийся дизайн, адаптивная под все девайсы верстка.
UFO just landed and posted this here
Зачем, если он отлично выполняет свою функцию?
UFO just landed and posted this here

Это не типа хорошо, это просто замечательно!


Чтобы ваш сайт стал совсем современным, не забудьте ещё добавить прибитый гвоздями вебфонт на 25 мегабайт с непрописанными фолбэками — нищеброды, которые не проплатили мобильник и вынуждены сидеть на 56кб/с до конца месяца, нам не нужны.


Однако, они могут железно выставить фонт браузера на расово верную Тахому и всё равно прочитать сайт, да ещё и без задуманных вами завитушек над каждой буквой имени директора. Не беда! Просто рисуем спиннер в непрозрачном слое и отключаем скролл, пока не загрузятся все ресурсы, в том числе шрифты, а грузим их так же со скриптов.


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

Соверменный сайт — это много картинок, растягивающийся дизайн, адаптивная под все девайсы верстка.

КМК имеются в виду «реклама, скрытая реклама, скрытое позиционирование марки, „интересное“, „посмотрите ещё вот это“, „оставьте свой емейл сейчас чтобы быть со скидками“, „напишите свой вопрос мы онлайн!“, трекеры, анализаторы и прочая воронка продаж».
От благодарного пользователя: нет, спасибо. Верните HTML.
много картинок

И всплывающих окон?
Почему-то, только мельком упомянут CI/CD, deployment, release management. К этому вопросу нужно тоже серьезно подойти. Возможно выбор GitHub не достаточно хорошо обдуман.

Может лучше развернуть Jenkins? Или использовать GitLab, ведь если делать сборку прямо в GitHub, может не хватить бесплатных минут, готовы ли вы доплачивать за это?

Есть же github actions, я растовый петпроект собираю без проблем

UFO just landed and posted this here
А как же микросервисы? Неужто ли для каждой новой фичи пересобирать весь проект.
В последнее время все поделия в интернете, любой сложности вызывают тошноту. Просто монбланы бессмысленности. Растрачивание себя.
Реально крутой сайт выглядит вот так: www.malinov.com/Home/sergeys-projects
Прожить жизнь так, чтобы вот после тебя осталось такое.
Чувак бери Dart, он умеет и в backend and frontend, а еще aot компиляция, в нативный код, закинул на сервер и все))
статья огонь))
Получается «продолжение следует»? Окей, мы ждем
Ну вот автор и узнал про глубину значения слов «архитектура веб-приложения». Когда приложение маленькое и простое — то и архитектура у него укладывается в условный php+mysql с фронтом без мудреных скриптов. А если начать закладывать решения под еще не поставленные перед вами проблемы (типа хранения кода, пул реквестов, мониторинга, деплоя свежих версий и так далее) — то и архитектура предсказуемо усложняется.
Добро пожаловать, что называется.

Кстати, слышал со временем люди поднабравшиеся всякого такого начинают зарабатывать продажей вот таких готовых решений в стиле all inclusive. В стиле: тебе деньги на сервисы и людей, а ты им кубернетисы, инстану с прометеусом, деплоймент в рандеке, битбакет с разными проектами под фронт и бек, CDN какой до кучи, все задокументировано в какой-нибудь конфлюенс — и обязательно красивые графики посещаемости и доступности каждую неделю.
Короче, холоптное такое дельце, как у нас говорят.

Мне кажется — все логично. Сейчас не нужно делать простенькие сайты. Трудиться для этого. Есть ресурсы, которые за ограниченное время, с хорошим результатом делают это за тебя. Например — tilda.


Остается именно то, что стоит разрабатывать. Т.е. тратить на это время разработчика. Отсюда релевантные (но сложные) инструменты и процессы.

UFO just landed and posted this here

Насчет 10 лет не знаю, но 14 лет назад плац подметали ломом. Так что, похоже, и там технологии меняются

Это скорее местные традиции: где-то зубной щеткой, где-то ломом, а где-то граблями… :)
Понимаю автора. Но в статье не сделан вывод — бывают времена, когда не знаешь, с какого бока подступиться к новым технологиями, появившимся на рынке за то время, пока ты за ним не следил. Но и 10 лет назад было то же самое, и это хорошо, что такая тенденция сохраняется. Это значит, что появляются новые вещи, совершаются скачки, появляются новые ниши. Хотя иногда хочется, чтобы время текло чуть помедленнее, чтобы было, как в киберпанке — чтобы вокруг уже стояли дома в сотни этажей, а люди всё ещё звонили по старой мотороле, ну вы поняли — технологический экстремум. Всем не хочется уходить с тёплой насиженной технологии, хочется, как в игре, продолжать и продолжать её развивать. Но другие люди приходят с другими идеями и забирают рынок.
Можно и сейчас на пхп писать странички, но теперь вам всегда будет этого мало. Как только вы прикоснулись к миру этих красивых названий, вы будете знать, что вот сейчас вы пишете страничку на хтмл+пхп, а где-то там есть штука, которая поможет это сделать быстрее, красивее и откроет вам что-то новое. Да ещё и сайт будет быстрее грузиться. Вот только для этого нужно изучить эту технологию (скажем, пусть это будет ReactPHP и его асинхронный цикл), встретить другие сложности, решить другие проблемы. А может, вы вовсе решите сделать блог на Jekyll+Ruby, кто знает.
Я считаю, что это закономерный процесс. (Но я не говорил, что считаю нужными все перечисленные в посте технологии)
Да ещё и сайт будет быстрее грузиться.
Вот этого-то и не наблюдаю. А наблюдаю прямо обратное: сайт с 10 кБ текста, а то и меньше, делает сотни запросов и грузит 10+ МБ. И на мобильном интернете это не очень.
Помню, был некоторое время безработным, пришёл на «собеседование» к 22-летним парням (мне самому столько же), у которых своя «веб-студия» — пообщались, всё нормально. И Первым проектом дали задачу сделать PWA-приложение небольшого интернет-магазина (местный магазин одежды). Также добавили, что у них с этим проектом проблемы в плане сроков и их недоделанное решение пришлось выбросить и надо писать с нуля (и закончить за 2 недели). Я говорю — так, может, не PWA, а просто на Yii2 + pjax + flexbox быстро накидаю просто рабочее решение, чтобы показать можно было заказчику, а потом уже допиливать потихоньку. Челы переглянулись и сказали, мол, «PHP сейчас не нужен, можешь rest api написать на нем, но на фронте нужен nuxt.js и PWA».
Я: Заказчик сам попросил вас именно PWA, а не просто интернет-магазин?
ОНИ: Нет, но мы понимаем, что нужен PWA. Сейчас все делают PWA, так что в первую очередь делаем его, а потом уже полноценный сайт запилим.
И что? Почему подобное так часто попадает в топ хабра? Любим поныть на пустом месте?

Как на медузе.


Если вы не приемлите это видео, лучше почитайте про котиков, или посмотрите статью про восстановление рукописей
https://m.habr.com/ru/post/521870/

UFO just landed and posted this here
Я тут решил сделать что-то типа простого блога. Взял просто HTML файл, запихнул туда текст и зааплоадил. Когда записей будет слишком много, просто разобью на очередную страницу. Когда я это сделал, озирался по сторонам, чтобы убедиться, что никто не видит. Заняло минут 5-10. Никакого кода, за исключением CSS и HTML, поддерживать не надо. Знаю точно, что ничего не сломается: JavaScript'а ни одной строчки; серверного кода ни одной строчки. Появилась удивительная легкость в членах тела.
UFO just landed and posted this here
А теперь вам надо сделать теги, автоматическую генерацию оглавления для статей побольше

Я на работе для таких вещей пользуюсь заклинанием:

Заголовок спойлера
нет, [вам это] не надо

Я угадал заклинание под спойлером и довольно улыбаюсь. :)

UFO just landed and posted this here

IT нужно учиться, открытие! А казалось бы был поваром, закончил пару курсов и бегом по 300 тонн в месяц заколачивать.

Лет 10 назад я сделал электровелосипед из старого Туриста, стартёра и аккумулятора от копейки. А сейчас делаю электромобиль с расчетом на сертификацию для дорого общего пользования…
UFO just landed and posted this here
UFO just landed and posted this here

Дед говорил — раньше трава была зеленее и вообще как то без ваших сайтов жили.
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к в месяц с него. Кто из нас дурак, очевидно

А зачем поддерживать сервер, если можно в Google Apps Engine или Lambda все положить. Взял шаблон и всё. Сервер нужно апгрейдить постоянно и т.п. На простых хостингах это вроде как не нужно, конечно.
Не понимаю в чем посыл статьи. Хотите простенький сайт? пожалуйста, пишите как удобно. Хотите свистелки-перделки? Пожалуйста, в статье их куча. Выбирайте инструменты под задачу, а не потому что об этом все говорят.

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


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

Ну, я несколько со своей стороны — жаба+томкат+(жсп или хсл+хмл) — чем плохое решение? Я понимаю, что здесь некое сьезжание с фронтенда на бэкенд. Но все же

А взял бы C# — ничего из вышеуказанного изучать бы не пришлось, т.к. можно и веб компоненты и фронтенд на C# писать

Пост о том когда много знаешь и умеешь, то простое можешь сделать сложным. :)

Надо быстро и просто. Просто бы взял bootstrap. Стилизовал. И дальше усложняй как угодно.

Забавно, что в топе за неделю сразу за этим постом идет пост «Мама, я сделал хабр»

Последний абзац напомнил:


Напишу-ка я песню о любви,
Только что-то струна порвалась,
Да сломалось перо, ты прости,
Может, в следующий раз…
А сейчас пора спать…

Плохие решения. Надо брать руби и рельсы, добавить к ним постгрес и эрспеки.
Потом можно, если потребуется прикрутить и вьюджиес.
Прочитал пост и как-то немного защемило в душе…
Мне кажется смысл поста вовсе не в том что слишком много технологий, большой выбор и так далее.
Смысл в том что чем больше опыта — тем больше сомнений.
Раньше не задумываясь берешь то, что знаешь и пилишь то, что хочешь. Общажный сайт на голом php в блокноте? Легко. Это весело и интересно, ты создаешь своими руками что то новое, не знаешь что из этого получится, и не думаешь как поддерживать это дальше. Зато каждый день видишь как это нечто растет и развивается, как на него приходят люди и пользуются тем что ты сделал. И это вдохновляет.
А сейчас давит груз опыта, который мешает наслаждаться процессом созидания. Ты не хочешь допускать глупых ошибок которые допускал ранее, хочешь сразу сделать всё правильно, продумать архитектуру, стек технологий, этапы реализации и даже выгоду. И глядя на всё это возникает такой шквал сомнений, что просто ни за что не берешься, прекрасно понимаешь что работы очень много, изучить надо кучу всего… И всё, руки опускаются.
Именно это я увидел в посте. Именно это откликнулось во мне.
Автору огромное спасибо, я как про себя прочитал :)
Самое забавное, что многие так и работают, — как мартышки используют модные технологии ради технологий, а не ради практичности, т.е. там, где они действительно нужны

Интересно: хоть один из комментаторов возьмёт заказ сколь угодно маленького сайта за 1 день( это 8 часов или 24 с хвостиком ?) Всем прям герои экстремального программирования. Т.е. чтоб всё работало через указанный срок, были реализованы все мааааленькие нюансы заказчика и вас не искали в армиях для доработок.( допустим, что тз есть )