На чем начинать писать новые Web-проекты?

Лично моё мнение. Если проект большой и с малопрогнозируемыми перспективами расширения, то Perl. Иначе - PHP.

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

я не писал на PHP и Perl и не видел соответствующих бенчмарков. но Perl/PHP не могут быть принципиально быстрее Java, т.к. интерпретаторы. и скорее всего даже гораздо медленнее.

тебе qbasic в самый раз будет судя по всему

мда... вам сударь лечиться надо... судя по всему...

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

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

>Лично моё мнение. Если проект большой и с малопрогнозируемыми перспективами расширения, то Perl. Иначе - PHP.

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

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

Java, Python , Jython

А Java один тормоз-отрисовка интерфейса местами. Хотя вполне сносно работает

> Да, возможно вы правы... надо будет бенчмарки поискать...

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=php&...

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=perl&am...

Тесты, конечно, синтетические, но для общего представления пойдет.

Народ, на чем лучше начинать писать новые Web-проекты?

>Многие прделагают "Ruby on Rails", смотрел я на него - http://www.rubyonrails.org/screencasts - редкостное "Г", не понимаю чего в нем нашли...

Смотреть надо лучше... Ты хоть что-нибудь понял из просмотренного?

>Кто-нибудь может внятно высказать свое мнение? Просьба тех, кто не писал на том что предлагает - не высказываться...

а на чём ты писал раньше?

>IMHO: Java - тормоз... Остается: Perl, PHP...

Java - тормоз??? Ошибаешься. Как раз наоборот. http://shootout.alioth.debian.org

Thanx!

>>Многие прделагают "Ruby on Rails", смотрел я на него - http://www.rubyonrails.org/screencasts - редкостное "Г", не понимаю чего в нем нашли...

>Смотреть надо лучше... Ты хоть что-нибудь понял из просмотренного?

create table "comments" do |t| t.column "body", :text ...

Зачем такими извращенствами делать таблицу?

>а на чём ты писал раньше?

asm, C/C++, perl, php...

>Java - тормоз??? Ошибаешься. Как раз наоборот. http://shootout.alioth.debian.org

Да, с Java я был не прав. Но с другой строны - поддерживать Java хостерам сложнее, и ресурсов она жрет больше...

>create table "comments" do |t| t.column "body", :text ... Зачем такими извращенствами делать таблицу?

В философии ruby как раз нет слова "извращение". Всё делается простым ради разработчика. Screencast-ы показывают лишь то, на что можно поглазеть. Пощупай tutorial-ы - http://wiki.rubyonrails.org/rails/pages/Tutorial

Не стоит делать поспешных выводов...

>asm, C/C++, perl, php...

Хорошо. С ООП, значит, знаком. Ознакомся с принципами MVC в RoR. Не понравится - попробуй Django и python.

Если всё равно не поймёшь, то попробуй framework cakePHP.

На том, что лучше знает команда, и в зависимости от задачи.

Если сайт простой, редко меняющийся, но планируется большое количество пользователей - то Java - ваш выбор (см. LOR). Если много рюшечек и постоянно приделываются новые - то один из динамических языков, у них с деплойментом проще гораздо. Разницы большой между Ruby/Python/PHP/Perl - нету, если грамотно подходить.

Да, производительность динамических сайтов в 95% случаев ограничивается хранилищем данных (SQL-база, DBD, whatever). В таких случаях переход на push-модель (или там апгрейд БД-сервака) помогает гораздо больше, чем переписывание на Java или даже C(++).

В любом случае нужно сначала думать, а потом делать, иначе получится фигня на любом языке (да, да, на Java тоже).

Мне главное скорость работы. Модеоль MVC как я понял скрывает тонкости работы с БД и т.п. Посмотрю на Python...

Python можешь ускорить через psyco. Не могу сказать, будет ли он работать с Django, т.к. не приходилось...

Какой проект собрался писать? Для многопользовательских сайтов действительно лучше java. Статическая типизация, сохранение объектов между http запросами (кстати, кто может сказать, в каких языках есть такая же фича?), виртуальная машина, bytecode компиляция.

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

Проект типа интернет магазина.

Java мне скорее всего не дадут...

Ориентируюсь пока на Python...

> сохранение объектов между http запросами (кстати, кто может сказать, в каких языках есть такая же фича?)

на перле сериализовать объекты куда-нибудь в Apache::Session (или хранить в shared памяти) - как два байта переслать. Я думаю, даже есть какие-нибудь готовые плагины для Catalyst. Есть memcached, опять же.

Уверен, что на всем остальном это тоже реализуется.

Кстати вопрос любителям руби - как там щас с юникодом? Вроде где-то новость пробегала что юникод теперь нативно поддерживается, имею ввиду без всяких костылей типа u'text' (как там точно в руби не знаю)?

Я имел в виду совершенно другую фичу

Какую именно? Я жаву с веб-стороны не знаю совсем (EJB вот писал разок - ужоснах, имхо - overengineered оно ужасно).

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

> http://www.rubyonrails.org/screencasts - редкостное "Г", не понимаю чего в нем нашли...

Мне показался весьма симнатичным, в частности идея с MVC.

Если писать не черз жопу, то без разницы на чем.

Если без разницы на чём, то это будет уже чережжёпу.

+1

В php, например, при каждом запросе каждый раз считывается И обрабатывается скрипт __С САМОГО НАЧАЛА__, что создаёт лишнюю нагрузку. Насколько я знаю, в java servlets этого нет. Хотелось бы услышать разъяснения от java-разработчиков. svu, выдели время на ликбез! :-)

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

> В php, например, при каждом запросе каждый раз считывается И обрабатывается скрипт __С САМОГО НАЧАЛА__, что создаёт лишнюю нагрузку. Насколько я знаю, в java servlets этого нет. Хотелось бы услышать разъяснения от java-разработчиков. svu, выдели время на ликбез! :-)

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

Короче, ты не владеешь вопросом. Зачем же тогда отвечаешь?

Скрипт компиляется каждый раз только если это "обычный" CGI. Сейчас так никто не делает.

В технологии mod_$whatever (где $whatever =~ /php|perl/) скрипты _не_ перечитываются на каждый запрос. Они компилируются (в байткод) один раз на старте apache worker-а. Про руби не знаю, но, думаю, оно там так же.

В fastcgi жизненный цикл скрипта вообще "вечно", т.е. нет даже ограничения MaxRequestsPerChild.

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

Какие по вашему мнению наиболее существенные преимущества Python по сравнению с PHP / Perl?

>Короче, ты не владеешь вопросом. Зачем же тогда отвечаешь?

Я не спорю, не гуру. Но тема мне интересна, поэтому считаю нужным поддерживать дискуссию.

>В технологии mod_$whatever (где $whatever =~ /php|perl/) скрипты _не_ перечитываются на каждый запрос. Они компилируются (в байткод) один раз на старте apache worker-а.

Откуда такая информация? Я знаю, что для php есть такие bytecode-компиляторы, как ZendOptimizer, eaccelerator. Заявляют, что последний имеет лучший прирост производительности, но в реальных проектах динамическая php-страница уникальная => байткод компиляция на основе atime не эффективна, т.к. уходит много процессорного времени на саму комплияцию в байткод.

Короче, пошёл за svu :-)

Также подскажите плз. - какой шаблонизатор лучше для Python?

Я использовал только Smarty под PHP, есть ли под Python что-то работаюшее быстрее чем Smatry под PHP?

Лучше почитать тут http://wiki.python.org/moin/LanguageComparisons

>есть ли под Python что-то работаюшее быстрее чем Smatry под PHP?

А зачем тут скорость? Ищи удобство.

>>есть ли под Python что-то работаюшее быстрее чем Smatry под PHP? >А зачем тут скорость? Ищи удобство.

Мне нужно максимально быстро работать c шаблонами на Python, при этом не могу использовать C и не стандартные модули Apache.

От шаблонизатора ничего особенного не нужно, желетельно чтобы он поддерживал if/else/циклы - т.е. например я ему отдал массив, а он его раскрутил в таблицу...

Главное - скорость, хотельсь бы что-то быстрее Smarty(PHP)...

>Мне нужно максимально быстро работать c шаблонами на Python

Как было сказано в постах выше, шаблонизатор создаёт так называемые кеш-файлы. Производительность шаблонизатора не имеет особого значения, т.к. кеш создаётся 1 раз. В большинстве шаблонизаторов кеш-файлы представляют собой смесь кода с html, которые обрабатываются интерпретатором. Поэтому скорость шаблона во многом зависит от производительности интерпретатора.

Если будешь писать с помощью Django фреймворка, то можно использовать его template engine. В ином случае - pyTemple

>В php, например, при каждом запросе каждый раз считывается И обрабатывается скрипт __С САМОГО НАЧАЛА__, что создаёт лишнюю нагрузку.

посетите Zend.com - вы очень удивитесь ;)

>Как было сказано в постах выше, шаблонизатор создаёт так называемые кеш-файлы. Производительность шаблонизатора не имеет особого значения, т.к. кеш создаётся 1 раз. В большинстве шаблонизаторов кеш-файлы представляют собой смесь кода с html, которые обрабатываются интерпретатором. Поэтому скорость шаблона во многом зависит от производительности интерпретатора.

>Если будешь писать с помощью Django фреймворка, то можно использовать его template engine. В ином случае - pyTemple

Фреимфорки я скорее всего не буду использовать вообще, буду писать на чистом Python + шаблонизатор. Т.к. фреймворк в любом случае = какой-то процент лишнего кода = потеря скорости...

Сейчас я нашел: ClearSilver, Cheetah, pyTemple... Что из этого лучше (наиболее производительнее) - кто использовал? Также вопрос: ClearSilver тредует какую-то предврительную его сборку? Т.е. просто положив что-то в свою директорию у хостера его не удастя использовать?

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

Ну что за юношеский максимализм - получить наибольшую производительность.

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

Комплекс тормозючего питона?

>>Java - тормоз??? Ошибаешься. Как раз наоборот. http://shootout.alioth.debian.org

>Да, с Java я был не прав. Но с другой строны - поддерживать Java хостерам сложнее, и ресурсов она жрет больше...

IMHO на LOR'е Java дискредитировала себя ;)))

Куча ошибок, пожирание памяти, тормоза ;)

Последние посты в разделе Linux-org-ru только об этом. Хотя может быть просто "кто-то не умеет готовить котят"? ;)

>Ну что за юношеский максимализм - получить наибольшую производительность. >А можно нескромный вопрос - для чего? А то, глядишь, и свой собственный http-сервер писать прийдётся под задачу...

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

>Комплекс тормозючего питона?

Всмысле? Я на Python пока не много писал, но судя по всему он бысрее PHP и в некоторых случаях Perl'а...

> Нужно чтобы скрипт уверенно работал при ~50 запросах в секунду, при этом ему надо общаться с БД и генерить HTML по шаблонам.

Рендеринг довольно сложной странички (исходник шаблона - ~100kb) с помощью Template::Toolkit занимает около 40 миллисекунд реального времени на довольно загруженной (load average > 6) машине, FreeBSD/Apache1.3/mod_perl 1.2.сколько-то, 2xXeon.

ClearSilver, XSLT или JIT-компилированный HTML::Template быстрее от двух до пяти раз.

ИМХО, у тебя будет гораздо больше проблем с тем, чтобы заставить базу данных работать с такой скоростью (это же сотни запросов в секунду, да?).

>ИМХО, у тебя будет гораздо больше проблем с тем, чтобы заставить базу данных работать с такой скоростью (это же сотни запросов в секунду, да?).

Обрашения к базе будут кешироваться и реально будут нужны только в 40% обрашений к скрипту.

>ClearSilver, XSLT или JIT-компилированный HTML::Template быстрее от двух до пяти раз.

ClearSilver можно использовать если просто положить его в каком-то виде в свою директорию у хостера? Или надо его именно у хостера собирать?

>Рендеринг довольно сложной странички (исходник шаблона - ~100kb) с помощью Template::Toolkit занимает около 40 миллисекунд реального времени на довольно загруженной (load average > 6) машине, FreeBSD/Apache1.3/mod_perl 1.2.сколько-то, 2xXeon.

А не тестировалась ли Smatry(PHP) случайно на этой машине? Smatry(PHP) быстрее или медленнее?

Web-разработка на Джава тербует хорошего бэкграунда. Фрэймворков много и все они делают примерно одно и то же но немного по-разному. "Удобные" фрэймворки реально тормозят, а быстрые требуют гораздо большего скилсета\затрат времени на разработку. В джава-мире принято мыслить паттернами и абстрагировать данные от способа их хранения, пересылки и\или выборки. Если нет такого мышления, то весь джава-инструментарий будет казаться ненужным, "мешающим танцевать" и напрасно пожирающим ресурсы (именно то из-за чего джава и "тормозит").

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

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

А производительность надо мерить не одного запроса, а под нагрузкой. Если это Веб-БД, то под нагрузкой узким местом станет СУБД и уже не так важно будет, что там за скрипты: перл, джава или пхп.

>IMHO на LOR'е Java дискредитировала себя ;))) Куча ошибок, пожирание памяти, тормоза ;)

Сам говорил, что виновато то, что находится между стулом и клавиатурой. А теперь говоришь обратное :) Уж тем более на WebSphere java не может тормозить.

>Сам говорил, что виновато то, что находится между стулом и клавиатурой. А теперь говоришь обратное :) Уж тем более на WebSphere java не может тормозить.

а что-ж ты весть пост не доцитировал? ;)

>Последние посты в разделе Linux-org-ru только об этом. Хотя может быть просто "кто-то не умеет готовить котят"? ;)

??? ;)

+1

еще кучу всякой хрени изучить надо : Inversion of Control(Dependancy Injection), Design Patterns ~ 15 штук, MVC, Workflows ,сама джава не маленькая, стандарты: Servlets, Jsp, Java Beans, Jaxb, JSF ,+ фреймворк (Spring, Stripes, Wicket, Rife, Webwork, Tapestry, Java Server Faces.... запутуться можно с выбором) + желательно EJB

только изучать это все - полгода уйдет.

>Нужно чтобы скрипт уверенно работал при ~50 запросах в секунду

http://www.o3magazine.com/pastissues/issue5/ скачай pdf, почитай статью про "TurboGears: Deployment and Scaling".

:)

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

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

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