LINUX.ORG.RU
ФорумTalks

Немножко про историю популярных инструментов веб-разработки [теория тупости]

 , , , ,


1

2

Прошлая серия:
Откуда растут ноги ненависти к php?

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

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

Давайте подумаем: а что же у нас до WordPress было инструментом для создания бложиков? Ну? Ну?

Идем далее:
https://www.djangoproject.com/weblog/2005/nov/16/firstrelease/ - Django 0.90
https://github.com/django/django/tree/ce079538c66d826be5f0c4260ab4405b7abcbed7 — примерное состояние сорцов перед релизом 0.90

Что представляла собой джанга на момент 2005 года? Платформа для создания CMS некоего регионального новостного сайта (история разработки) и блевотных бложиков, по сути стоящая на трех китах:

— шаблонизатор;
— ORM, поставляющий содержимое из баз данных в шаблонизатор и засовывающих их обратно в базу из форм;
— алгоритмы авторизации и админка для изменения содержимого бложика.

Вы уже снова узнали, что аналогичный инструмент до боли стар и хорошо нам всем знаком. Забавно, что в дичайшую нечитаемую лапшу джангу превратило уже сообщество — оригинальные сорцы имели зачатки лапши только в иерархии полей модели, где создатели почему-то решили логику отображения-контроллера полей в шаблоне (генерации HTML и валидации введенных полей, core/formfields.py) унаследовать от классов с алгоритмами доступа к БД (core/meta.py), в остальном это было простецкое наследование от template.Node (управляющие структуры шаблона) и meta.Model (абстрактной бессмысленной сущности для агрегации полей аля «таблица»), и даже было немало классов без базового класса. Итого 12 тысяч строк с комментами тогда, а сейчас в Django 300+ тысяч строк питона.

Вы уже поняли логику успеха? Делаем инструмент для создания говнобложиков в два клика — миллионы индусов кидаются писать на нем свои говноблоги — на рынке оказывается огромное число кодеров толка «я не умею в PHP, но могу сделать вам сайт на WordPress» или «питон? не, не умею; когда-то слышал про него, но толком не пытался изучить, я пока только на Django научился сайты писать».

С другой стороны — почему бы не позволить людям писать в два клика вебсайты на Go? Или на лиспе. Где там наш Пол Грэм со своим конструктором сайтов на лиспе? В конце-концов, я и другие программисты пишем программы именно для того, чтобы простой человек мог без напряга воспользоваться нашим софтом.

Интересно было бы услышать вашу аналитику о делах недавнего прошлого: Ruby on Rails? Symphony? Я вот пока не понял, почему Laravel нынче стал лидером среди других PHP фреймворков.

★★★★

Последнее исправление: byko3y (всего исправлений: 1)

Я вот пока не понял, почему Laravel нынче стал лидером среди других PHP фреймворков

Уже ж проходили: простота + большое количество возможностей.

fernandos ★★★
()
Ответ на: комментарий от fernandos

Уже ж проходили: простота + большое количество возможностей

И чем эта простота проще десятков аналогичных фреймворков?

byko3y ★★★★
() автор топика

внезапно развился в целую платформу

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

интернет-магазины

Чем принципиально магазин отличается от бложика? Там каталог, и тут каталог.

пока не понял, почему Laravel нынче стал лидером среди других PHP фреймворков

Потому что Symfony слишком сложно. Yii тоже очень популярен, но они не усекли вовремя фишку, что нужно как-то соответствовать стандартам. В частности в Yii2 своя реализация DI и поэтому сторонние пакеты просто так не вкорячишь. Вроде в Yii3 это должны поправить. Но уже не интересно, все перекатились на Laravel.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

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

Смешно. Ты хоть раз в код вордпресса заглядывал? Мне вот доводилось. Больше не хочется. Код вордпресса это просто куча говна. Кто то насрал, а остальные зачем то в ней копаются. По другому о нем не скажешь.

eternal_sorrow ★★★★★
()
Ответ на: комментарий от no-such-file

Совсем даже не внезапно, а в результате удачной архитектуры

WordPress-а? То, чего нет, не может быть удачным или неудачным. Половина файлов на классах, половина файлов на функциях. 3000 глобалов в 280 тыс строк PHP кода. Причем, всего 5 лет назад это было 160 тыс строк — разработка ведется по принципу «докинем мусора в кучу». Это типичный «энтерпрайзный проект», где код никогда не удаляется (код с первой беты до сих пор там), потому что никто не знает, на что влияет этот код и что сломается если его убрать. Даже автор не знает. Особенно автор не знает — у автора всё работает и ему похеру на проблему какого-то юзернейма с LOR-а.

И нет, это не бесплатно: как и в типичном энтерпрайзе, мертвый груз жрет кучу ресурсов, и сейчас чтобы отдать статичную страничку бложика на WP нужно потратить 15-20 МБ оперативы на каждый запрос.

Также это полная остановка в развитии: WordPress, как и CPython, не обновляется, не улучшается — к ним только слева и справа докидывают аккуратные кучки мусора, а к этим кучкам мусора точно так же справа и слова докидываются кучки поменьше, так, чтобы не трогали старые кучки мусора. И весь этот комок грязи в какой-то момент становится невозможно развивать, например, чтобы портировать на новую платформу.

Чем принципиально магазин отличается от бложика? Там каталог, и тут каталог

Намного более интенсивной логикой. Пользователь интернет-магаза будет искать товар, просмотривать разные «витрины», сравнивать товар, читать отзывы, складывать товар в корзину, оплачивать его самыми разными способами. Например, сейчас уже стала стандартом возможность искать товар по многочисленным свойствам товара плюс полнотекстовый поиск.

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

Потому что Symfony слишком сложно. Yii тоже очень популярен, но они не усекли вовремя фишку, что нужно как-то соответствовать стандартам. В частности в Yii2 своя реализация DI и поэтому сторонние пакеты просто так не вкорячишь. Вроде в Yii3 это должны поправить. Но уже не интересно, все перекатились на Laravel

Спасибо, не понял. К сожалению, я не знаю, что там за стандарты, и почему Symfony сложно, если сам Laravel использует Symfony. Symfony настолько хороша модульностью, что ею пользуются почти все.

byko3y ★★★★
() автор топика
Ответ на: комментарий от eternal_sorrow

Смешно. Ты хоть раз в код вордпресса заглядывал? Мне вот доводилось. Больше не хочется. Код вордпресса это просто куча говна. Кто то насрал, а остальные зачем то в ней копаются. По другому о нем не скажешь

Вот это и есть классический парадокс западной айти-экономики: «либо софтина плохая, либо ею никто не пользуется». Потому правильно говорить так «WordPress — это идеально подходящая под требования рынка куча говна».

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

К сожалению, я не знаю, что там за стандарты, и почему Symfony сложно

Потому что веб-макаки такие. Они мне часто говорили подобное, что надо 5 лет мучений чтобы понять Symfony. «Современные» подходы вроде паттернов и чистого кода они отрицают, ведь деды лапшу писали - значит и они будут так писать. Благодаря вот этим вот сраным вордпрессам.

InterVi ★★★★
()
Ответ на: комментарий от InterVi

Потому что веб-макаки такие. Они мне часто говорили подобное, что надо 5 лет мучений чтобы понять Symfony. «Современные» подходы вроде паттернов и чистого кода они отрицают, ведь деды лапшу писали - значит и они будут так писать. Благодаря вот этим вот сраным вордпрессам

ну так а где ж замена вротпрессу? Чтобы в два клика — и сразу работающий сайт. И без зависимости на облако дяди.

byko3y ★★★★
() автор топика

Вы уже поняли логику успеха?

Она называется «worse is better». Выкатить на рынок говно, которое уже сейчас что-то делает для людей лучше, чем не выкатить, пока не доделаешь до нормального уровня. Потому что если не выкатишь ты, то выкатят твои конкуренты и быстро завоюют рынок, а ты останешься не с чем.

rupert ★★★★★
()
Ответ на: комментарий от byko3y

Они есть, просто популярность не такая. Как насчёт modx? Там ООП и вменяемая структура кода, но глубоко не смотрел.

InterVi ★★★★
()
Ответ на: комментарий от byko3y

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

Пользователь интернет-магаза будет искать товар, просмотривать разные «витрины», сравнивать товар, читать отзывы, складывать товар в корзину, оплачивать его самыми разными способами. Например, сейчас уже стала стандартом возможность искать товар по многочисленным свойствам товара плюс полнотекстовый поиск.

И что? Концептуально это всё тот же каталог.

с поиском он просто ложится, даже при малом трафике

Ложится он потому, что у «вебмастеров» не хватает тямы чтобы проанализировать запросы и накатить нужные индексы. Ну и другие подобные вещи.

Спасибо, не понял. К сожалению, я не знаю, что там за стандарты

Но мнение имеешь, ага.

Symfony настолько хороша модульностью

Что приходится программировать на yaml как в этой вашей жабе. Они там слишком упоролись в энтерпрайз. Laravel же продвигает config by convention, как в рельсах, т.е. называешь стандартным образом и всё само подхватывается.

no-such-file ★★★★★
()
Ответ на: комментарий от fernandos

Ну, ларавель гораздо сложнее симфони, по крайней мере, сейчас. К счастью, Лара не так популярна в европе, как в РФ.

alexmaru
()
Ответ на: комментарий от no-such-file

Архитектура WP очень удачная. Настолько удачная, что даже при всём том говнокоде WP рулит и педалит

Это называет UX. Если мы говорим о том, что основной пользователь CMS — это ее админ.

И что? Концептуально это всё тот же каталог

«Концептуально» гироскутер — это всё та же кравчучка. Но по факту отличия настолько огромны, что эти две вещи качественно несравнимы. Как я уже написал — первая проблема WP заключается в том, что более-менее значительную нагрузку WP просто не вывезет — я говорю про потолок в десятки одновременно листающих этот магазин сотни уже не вывозит:

https://www.flood.io/blog/scaling-wordpress-from-zero-to-hero

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

Ложится он потому, что у «вебмастеров» не хватает тямы чтобы проанализировать запросы и накатить нужные индексы. Ну и другие подобные вещи

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

Спасибо, не понял. К сожалению, я не знаю, что там за стандарты

Но мнение имеешь, ага

Только по поводу ВротПресса? По поводу ларавельки я сразу дал дисклеймер. Я, например, не знаю, какие в пыхе best practice. В JS могу сказать: иммутабельность (по возможности), функциональное погромирование и интерфейсы-контракты от TS безо всяких там наследований. Например:

https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABABwE4zFAMgQwEYCmANg...

То есть, все дополнительные объявления типов TS генерируют ровно ноль дополнительных конструкций в конечном JS коде.

Я еще нигде в блогах и форумах не встречал подобной декларации best practice для JS. Тем более не встречал таких деклараций для PHP.

byko3y ★★★★
() автор топика
Ответ на: комментарий от alexmaru

Ну, ларавель гораздо сложнее симфони, по крайней мере, сейчас. К счастью, Лара не так популярна в европе, как в РФ

В Европе пишут на симфонии? Я, например, был удивлен, когда узнал, что на микрофреймворке Flask в европе пишут больше, чем на монстре Django, но последний больше популярен в штатах — и это ожидаемая для меня форма рынка.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

t184256 ★★★★★
()
Ответ на: комментарий от t184256

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

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

Последний раз, когда что-то серьезно перетряхивали, поднялся лютый вой. Поскольку огромное число мусора слева и справа уже зависело от мелочей реализации, и потому поотваливалось. Самая главная проблема, крест на его гробе — это сишные расширения, которые не оставляют никаких шансов на развитие, поскольку завязаны на огромную площадь публичного API питона. Не так давно из всего API выделили «сокращенный набор», в который входят только стабильные и поддерживаемые функции, но даже их тысячи.

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Это называет UX

Какой UX, что ты несёшь?

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

А я тебе говорю что вывозит, если руки не из жопы.

(PS: ты б ещё 10-летней давности статью приволок).

можно очень быстро прийти к проблеме протухания кэша

Это кэш для статики. Например на странице продукта кэшируется всё, кроме цены и количества.

Потому что WordPress плохо поддается расширению и модификации

Прекрасно он поддаётся расширению, а модифицировать там ничего не надо. В этом-то и соль.

не знаю, какие в пыхе best practice

При чём тут best practice если ты завёл речь про архитектуру «как нам сделать збс-CMS»? Фактически у тебя два стула: либо пилить свою мини-cms (получится тот же wp вид сбоку), где логика обработки контента отделена от реализации, либо хардкодить логику обработки контента в структуре кода (привет фанатам MVC). Второе конечно возможно, но где ты найдёшь специалистов под это дело? Особенно с бюджетом 3 рубля на всё? Тут symfony не каждый десятый даже осилит просто настроить для хеловорда, а ты хочешь чтобы тебе целый магазин запилили.

no-such-file ★★★★★
()

Посмотри еще PHPNuke, это была первая популярная опенсорсная ЦМС. Если удастся нарыть старую версию, ее «архитектурой» не предполагался даже шаблонизатор, это был эталон лапшекода PHP вместе с HTML, и тогда наверное уже было немного JS. Подход «вбил в стену гвоздь - получилась вешалка» в чем-то даже завораживает, если бы не write-only код, и то, что это был эталон дырявости, возможно даже первое веб-приложение из которого и появилась эта тема - ломать сайты, но это не точно, тогда еще были гостевые книги и PHPbb. Несмотря на это, оно было очень популярно, помню в то время массу однотипных сайтов «на нюке», а также, как их постоянно ломали) Там можно было размещать статьи, файлы, перацкую музыку (видео тогда было слишком жирным для инторнетов), ЕМНИП даже был форум. Можно было на все это напялить тему, в общем всё что нужно для пацанского сайта) И кому нужна вся эта архитектура, лол, разве что ломают, и от чрезмерного лапшекода может случиться ступор мозговины. Если что, это был сарказм.

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

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 5)

Твои темы напоминают старую передачу Гордона, когда в два часа ночи он разговаривал с учеными.

chenbr0
()
Ответ на: комментарий от no-such-file

Это называет UX

Какой UX, что ты несёшь?

UX для человека, который на базе WordPress делает сайт. Этот инструмент ведь сделан для непрограмистов, потому это не «интерфейсы программирования».

А я тебе говорю что вывозит, если руки не из жопы.
(PS: ты б ещё 10-летней давности статью приволок)

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

Это кэш для статики. Например на странице продукта кэшируется всё, кроме цены и количества

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

Потому что WordPress плохо поддается расширению и модификации

Прекрасно он поддаётся расширению, а модифицировать там ничего не надо. В этом-то и соль

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

При чём тут best practice если ты завёл речь про архитектуру «как нам сделать збс-CMS»?

Твои слова

Yii тоже очень популярен, но они не усекли вовремя фишку, что нужно как-то соответствовать стандартам. В частности в Yii2 своя реализация DI и поэтому сторонние пакеты просто так не вкорячишь.

Не ты писал, но я отвечал на:

«Современные» подходы вроде паттернов и чистого кода они отрицают

Соответственно, вроде как обсуждение ушло в сторону каких-то там кодерских практик. И я не понял, каких.

Фактически у тебя два стула: либо пилить свою мини-cms (получится тот же wp вид сбоку), где логика обработки контента отделена от реализации, либо хардкодить логику обработки контента в структуре кода (привет фанатам MVC)

Вот эту телегу я периодически встречаю в интернете, и каждый раз недоумеваю. По сути она значит «либо делаем интерпретатор DSL-конфига на PHP, либо делаем саму логику на PHP». А как насчет «генерируем PHP-код по конфигу»? А как насчет подхода «примитивный бэк с несколькими роутами и жирный фронт с SSR отдельных страниц на ноде»? Ведь вся проблема клиенте сервера заключается в том, что это распределенная система, да еще и писанная на куче разных ЯП — сведи большую часть логики на клиенте, минимизируя распределенную составляющую. Вот и все дела. Толстые клиенты были популярны давно, но в какой-то момент (2003-2005 годы) возникла бешенная популярность толстых серверов.

byko3y ★★★★
() автор топика
Ответ на: комментарий от chenbr0

Твои темы напоминают старую передачу Гордона, когда в два часа ночи он разговаривал с учеными

Чем напоминают?

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

chenbr0
()
Ответ на: комментарий от chenbr0

Мысли интересные, но учитывая скорость современного веба, я бы почитал более сжатые лаконичные выдержки

Это интересный тезис. Я тоже его заметил, но я его не понимаю. Ты не можешь разобраться в вопросе достаточно глубоко и основательно со «скоростью современного веба». Я не понимаю news.ycombinator.com, который как раз ориентирован на «скорость современного веба», то есть, когда ты отвечаешь кому-то на комментарий, то у тебя почти нет шансов получить ответ, потому что автор комментария не получит уведомления — а зачем? Автор уже листает сотни других статей и пишет там свои комментарии, ответы на которые он точно так же не прочитает. Я соглашусь, что так прикольно прожигать время, но как у познавательного инструмента эффективность такого общения околонулевая. Даже у того же Гордона темп, на мой взгляд, слишком быстрый — для меня норм сидеть пару-тройку деньков разбираться в одном тезисе. Зрители зомбоящика, естественно, при таком темпе заснут очень быстро, а мне норм.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

WordPress делает порядка сотни запросов к БД на каждый запрос от клиента.

Это не супер много. Я видел и по 300 у одной ЦМС.

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

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

Короче много где крутится это и подобное bloatware, я бы не был так категоричным с «только фреймворки, иначе работать не будет»)

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от goingUp

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

Можно. https://dzone.com/articles/36-million-queries-per-second-with-mysql-on-a-sing

Cores 224 virtual
RAM 224 GB
Storage GCP Standard SSD

Действительно, можно. И всего-лишь $100 за день пользования. Я все-таки подразумевало какие-то варианты с прикладной ценностью, а не «разорю бизнес, но нагрузку выдержу». Там разработка кастомного решения за месяц окупит весь хостинг.

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

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

byko3y ★★★★
() автор топика

Давайте подумаем: а что же у нас до WordPress было инструментом для создания бложиков? Ну? Ну?

В те времена было 3 цмски для РНР: джумла, друпал и вордпресс.

Джумла имела переусложненный код, но за счет мегапопулярного модуля ПХПШоп было много написано интернет-магазинов. То есть если нужно было сделать что-то стандартное, то делалось быстро и дешево. Если что-то надо было сделать уникальнее, то сразу было сложно.

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

Вордпресс оказался более понятным и на нем дешевле можно было сделать сайты. А еще было много модулей. Установил -> натянул шаблон -> получил деньги. Весь секрет успеха – деньги :-)

Что представляла собой джанга на момент 2005 года?

На тот момент из альтернатив написать что-то для веба на питоне был zope/plone. Для меня, перешедшего из мира РНР эта штука была слишком сложной

С другой стороны — почему бы не позволить людям писать в два клика вебсайты на Go? Или на лиспе.

  1. Много ли shared хостингов поддерживают Go или лисп?
  2. Зачем писать на Го то, что уже есть и довольно неплохо работает? Ниша занята. Потребности в чем-то новом нет.
  3. Не знаком с лиспом, но из-за того, что он редко где используется, могу предположить, что у него довольно мало готовых модулей, которые можно использовать повторно + разработка чего-либо занимает много времени.
dicos ★★
()
Ответ на: комментарий от dicos

На тот момент из альтернатив написать что-то для веба на питоне был zope/plone. Для меня, перешедшего из мира РНР эта штука была слишком сложной

К сожалению, ничего не знаю про plone/zope.

Много ли shared хостингов поддерживают Go или лисп?

Как правило, у хостеров динамики 2004-2005 года было нормой поддерживать PHP-Perl, плюс CGI и/или даже апачевый модуль под питон/руби.

https://web.archive.org/web/20040711235225/http://ipowerweb.com/products/webh...
https://web.archive.org/web/20150713153933/http://www.1and1.co.uk/hosting-lin...

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

https://news.netcraft.com/archives/2004/01/21/fastest_growing_large_hosting_c...

То есть, делай свой CGI бинарник лиспа/го, и запускай на здоровье в 2005 году.

Зачем писать на Го то, что уже есть и довольно неплохо работает? Ниша занята. Потребности в чем-то новом нет

На самом деле ниша полупустая, но бесплатно сообществу коммерсов никто не подарит годное решение. Одним ключевых из факторов, приведших к популярности Python/Ruby/PHP была бесплатность и опенсорсность онных — дареному коню в зубы не смотрят. Пока корпорации развивали альтернативные проприетарные решение, которые были таки лучше бесплатных — бесплатные тупо захватывали рыночек. Прям-таки ярчайший пример — это Pascal: получив монополию Borland начало стричь деньги вместо того, чтобы наращивать аудиторию, и уже к нулевым паскаль фактически вымер в индустрии — не потому что он прямо-таки был сильно хуже, а потому что никто не хотел платить тысячу+ долларов за лицензию на делфи, даже без возможности воспользоваться альтернативным компилятором просто чтобы скомпилировать уже созданное на делфи кем-то поделие.

byko3y ★★★★
() автор топика

Нашел интересную цитату:

CMS ненужно?

А как наличие фреймворка избавляет от отсутствия из коробки таких вещей как менеджмент юзеров, страниц, разделения ролей, системы авторизации? Делаем всё это - получаем каркас CMS

Ты (на самом деле, как многие) путаешь фреймворк и набор библиотек. Как раз каркас CMS — это и есть фреймворк. Можно в словарь глянуть, как framework переводится

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Как правило, у хостеров динамики 2004-2005 года было нормой поддерживать PHP-Perl, плюс CGI и/или даже апачевый модуль под питон/руби.

РНР на хостинге работал без каких-то проблем вообще.

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

Апачевский модуль для python/ruby для shared хостинга был, но для самых дорогих тарифов. Разница в тарифах была прямо ощутимая.

То есть, делай свой CGI бинарник лиспа/го, и запускай на здоровье в 2005 году.

CGI – устаревшая технология смысла сейчас использовать всем нет. Есть технологии uwsgi и awsgi, нет проблем писать сайты используя эти технологии. На Go точно пишут сайты.

На самом деле ниша полупустая, но бесплатно сообществу коммерсов никто не подарит годное решение.

Я не совсем понял что именно не хватает для заполнения ниши, если не трудно, можешь объяснить подробнее?

Одним ключевых из факторов, приведших к популярности Python/Ruby/PHP была бесплатность и опенсорсность онных

Спорное утверждение, РНР стал популярен, так как он создавался для веба и его было просто использовать. Python/Ruby языки программирования с простым синтаксисом.

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

Я наблюдал другую картину: на дельфи, в основном, писали интерфейсы для DBF базы данных. В это же время появился дотнет, на котором удобнее было писать программы для виндовс. А сетевые базы данных и MS Access забрали себе часть ниши по хранению и обработке баз данных. Дельфи просто оказался ненужен.

dicos ★★
()
Ответ на: комментарий от dicos

РНР на хостинге работал без каких-то проблем вообще

Особенно когда тебе нужно PHP 5, а у прова только 4.

CGI довольно тормозной из-за того, что при каждом вызове скрипта интерпретатор запускается заново

Лучшее, что было доступно в ИндусТрии того времени — это FastCGI, где процесс просто не перезапускался, а использовался заново. У всех интерпретаторов того времени (Perl, PHP, Ruby, Python) гибкость крайне низка и ты не мог просто «вызвать функцию» в новом потоке или тем более асинхронно выполнять несколько зеленых потоков.

$ echo "for run in {1..100}; do python -c \"print('ok')\"; done" > pythonX100
$ chmod +x pythonX100
$ time ./pythonX100 > /dev/null
real	0m1.296s
user	0m0.982s
sys	0m0.303s

В принципе, на уровне нескольких сот запросов в секунду это пофик. Обычный PHP ложился где-то в районе тысячи. По этой причине проблема «WordPress делает 200 запросов к БД на один запрос клиента» не так отсвечивала, и тогда зачем чинить то, что не ломалось? Для 99% сайтов этого и так более чем достаточно. У LOR, по моим подсчетам, порядка 2 запросов в секунду в хороший вечер (если я ничего не перепутал и на самом деле это не 2 тысячи).

CGI – устаревшая технология смысла сейчас использовать всем нет. Есть технологии uwsgi и awsgi, нет проблем писать сайты используя эти технологии. На Go точно пишут сайты

В 2005 году-у-у! Альтернатива была только одна — покупать виртуальный или выделенный сервер, и там уже запускать любой софт, какой только хочешь.

Я не совсем понял что именно не хватает для заполнения ниши, если не трудно, можешь объяснить подробнее?

Инструментов типа эрланга, только с человеческим лицом, чтобы реализовывать распределенные системы, которыми веб и является по сути. PHP/Ruby/Perl отказываются от своего состояния, но потребность в онном никуда не девается, потому перекладывается на внешние БД разной степени кривизны, из которых разве что MyISAM разрабатывался специально для веба — всё остальное является вариациями совы на глобусе. Службы очередей сообщений - это тоже БД.

Спорное утверждение, РНР стал популярен, так как он создавался для веба и его было просто использовать. Python/Ruby языки программирования с простым синтаксисом

Контрпримеры: ColdFusion; ASP, которое использовало JS для серверного скриптинга до того, как это стало модно.

Я наблюдал другую картину: на дельфи, в основном, писали интерфейсы для DBF базы данных. В это же время появился дотнет, на котором удобнее было писать программы для виндовс. А сетевые базы данных и MS Access забрали себе часть ниши по хранению и обработке баз данных. Дельфи просто оказался ненужен

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

РНР на хостинге работал без каких-то проблем вообще

Особенно когда тебе нужно PHP 5, а у прова только 4.

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

В принципе, на уровне нескольких сот запросов в секунду это пофик. Обычный PHP ложился где-то в районе тысячи. По этой причине проблема «WordPress делает 200 запросов к БД на один запрос клиента» не так отсвечивала, и тогда зачем чинить то, что не ломалось? Для 99% сайтов этого и так более чем достаточно. У LOR, по моим подсчетам, порядка 2 запросов в секунду в хороший вечер (если я ничего не перепутал и на самом деле это не 2 тысячи).

Я бы не сказал, что быстродействие сайтов упирается именно в язык программирования, скорее запросы в базу данных «съедают» много процессорного времени. Я бы сказал, что язык программирования для сайтов – это уже дело наличия готовых решений и квалификации исполнителя.

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

Какие виды сайтов/ресурсов не хватает, чтобы люди массово их заказывать? Интернет-магазины? Соц. сети? Игры?

Контрпримеры: ColdFusion; ASP, которое использовало JS для серверного скриптинга до того, как это стало модно.

ASP использовался только на windows server платформе, эту систему тогда считали не сильно надежной. На сколько я помню, ColdFusion стоил довольно дорого. По моим ощущениям на ColdFusion было приятнее делать сайт, чем на ASP.

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

Возможно, я переход с дельфи на дотнет видел со стороны только.

dicos ★★
()
Ответ на: комментарий от dicos

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

У питона такой проблемы нет в принципе, он всегда ходит только со всей стандартной либой. Потому хрен его всунешь в эмбед.

Я бы не сказал, что быстродействие сайтов упирается именно в язык программирования, скорее запросы в базу данных «съедают» много процессорного времени. Я бы сказал, что язык программирования для сайтов – это уже дело наличия готовых решений и квалификации исполнителя

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

Какие виды сайтов/ресурсов не хватает, чтобы люди массово их заказывать? Интернет-магазины? Соц. сети? Игры?

А, ты об этом. Ну да, кризис: игры новые не разрабатываются, соцсети новые не появляются. Я все-таки имел в виду технологическую составляющую, а не коньюктурную.

На сколько я помню, ColdFusion стоил довольно дорого. По моим ощущениям на ColdFusion было приятнее делать сайт, чем на ASP

Он и сейчас дохрена стоит, хотя почти никому не нужен. Ну и да, на то время на ColdFusion было приятнее делать сайт, чем на PHP. Но времена меняются, ColdFusion почти не развивается.

byko3y ★★★★
() автор топика
Ответ на: комментарий от grem

Хочу список популярных CMS (не статики), написанных не на php

Выше написали Zope/Plone. И я не понимаю, чем тебе не нравятся генераторы статики — они взлетят даже на самом-присамом дешманском хостинге. Это если мы говорим про CMS, а не про интернет-магазины, которые вообще из другой категории.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Маловато :(

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

grem ★★★★★
()
Ответ на: комментарий от grem

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

Форум с регистрацией — это максимум «нестатика». То, что пыховый мусор несочетаем и динамику хрен состыкуешь со статикой — ну что ж, индустрия сделала свой выбор в пользу «зато у нас работа никогда не закончится». То есть, выгоднее продать сто лампочек с ресурсом 1000 часов, чем сделать одну лампочку на 100 тысяч часов.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Не понимаю, чем ты недоволен, тем что довольна индустрия и удовлетворяет свои насущные потребности?

Ну сделай такую «лампочку», я не против.

grem ★★★★★
()
Ответ на: комментарий от grem

Не понимаю, чем ты недоволен, тем что довольна индустрия и удовлетворяет свои насущные потребности?

Да, индустрия удовлетворяет свои потребности — создавать ВВП. Что ровно противоположно удовлетворению человеческих потребностей.

Ну сделай такую «лампочку», я не против

Пф-ф-ф, ты за кого меня держишь? Я же ни копейки не зарабатаю на этом. А потому свой проект и делаю в виде костылей для мейнстрима, а не пытался «сделать правильно». Но понимать суть явлений не помешает, в любом случае. Хотя бы чтобы понимать, что «я делаю это, потому что в нынешнем рынке нет особого выбора», а не «я делаю это, потому что это удобное, надежное, проверенное решение». Хотя, некоторые программисты предпочтут убиться, чем признать очевидную истину, которую они и сами понимают.

byko3y ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.