Перспективные web-технологии

...хорошая стратегия:

C++, Java, Python, JS, Bash - покрывают почти все сценарии...

А что насчёт си без плюсов, востребован где-то помимо драйверов и/или эмбедеда?

На сегодняшный день и в долгосрочной перспективе - Python, PHP, JS.

Java еще бы добавил и C++, а так все

мультимедиа, например. ffmpeg, VLC, gstreamer, их использование, развитие и поддержка...

Только так. Языки глубоко вторичны

А голая практика без теории и безвекторный энтузиазм рождают пехепешников

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

Мир веб-приложений стремительно усложняется, и отлавливать ошибки в движках написанных на ЯП с мягкой типизацией, да еще и без встроенных денежных типов - тихий уж0с и ацкий труд

Ты меня огорчаешь. Похоже, придется вернуться к твоему вопросу о ERP.

Так вот, есть пхп, который хорош для веб-приложений, и есть, например питон, который для веб-приложений не очень, но (тут твой тезис принимаем как есть) хорош для ERP в отличии от пхп. Теперь наступает очень интересный момент: где заканчивается область веб-приложения и начинается область приложения с веб-интерфейсом.

Например, интернет-магазин это веб-приложение, поскольку веба там много, а «бизнес-логики» — мало и она довольно проста.

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

тут вообще индифферентно, либо берешь какой-нибудь wordpress который завтра тебе взломают либо берешь «что угодно» и делаешь сам, ибо у блога сложностей то нет

«что угодно»

т.е. PHP все-таки?

например питон, который для веб-приложений не очень в отличии от пхп

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

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

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

взять тот же mod_wsgi и сделать такую же сотню сайтов сложнее?

т.е. PHP все-таки?

PHP или любой из тысячи языков

покажи мне такой сервис, ну или возьми и сделай, слабо?

берешь VPS за 5$ и делаешь? какой сервис? ты о чем?

А в чем проблема собственно (кроме расхода памяти)? возьми и сделай... слабо... это что, аргументы? тебе надо - ты и делай :)

понимаешь, shared hosting это сервис, который позволяет за небольшие деньги поднять сайтик не программисту. Ты же предлагаешь такому человеку взять VPS и что то там запилить. Python/Ruby не конкуренты PHP в этой нише.

Но вот представте, что вы находитесь в начале пути, что бы вы использовали?

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

Беллмана принцип оптимальности - несколько упаднически, но в целом правильно

Что наиболее попуярно / будеть популярно в булущем, опираясь, например, на фриланс платформы, западный рынок?

Что наиболее популярно в настоящий момент?

Во многом (но сильно субъективно) это постепенный отход (но не игнорирование в качестве клиента) от монструозных экосистем типа windows: стэк линукс, javascript (особенно разработка расширений, плагинов), ну и все, что крутится вокруг серверов, функциональные расширения, XML/XSLT/JSON/YAML, HTML5 (включая разработку desktop-приложений, мобильных клиентов)... Словом все простое, мобильное, открытое, текстовое гибкое, оптимально вмещающееся в принципы SOLID...

и кстати да с появлением предложения линукс контейнеров по $5 ситуация улучшается, VPS все-таки от $20 начинаются

понимаешь, shared hosting это сервис, который позволяет за небольшие деньги поднять сайтик не программисту. Ты же предлагаешь такому человеку взять VPS и что то там запилить. Python/Ruby не конкуренты PHP в этой нише.

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

сайтик не программисту

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

Ты меня огорчаешь

Скорблю больше всех :-)

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

А это из какого пальца высосано?

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

Там где предполагается, что controller модели MVC будет реализован клиентом. То есть если приложение само создает динамический контент и подает готовые (ну или почти готовые) страницы в студию - то это, пользуясь вашей терминологией, - веб-приложение. Но вот если динамический контент страниц создается скриптами клиентской стороны на основании шаблона и данных полученных с сервера (например по REST в формате JSON), то это именно что приложение с веб-интерфейсом, бизнес-логика которого реализована в виде набора веб-сервисов.

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

и в чем из этого PHP плох?

Только одним: сложную бизнес-логику трудно кодировать на ЯП с мягкой типизацией - сильно возрастает количество ошибок и время на их отлов. Иными словами стоимость кодирования возрастает в среднем на 40-50%, а качество сопровождения - наоборот сильно падает. Для финансовых веб-приложений это не приемлемые потери, в отличие от сайтов которые являются изделиями «на раз».

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

Словом, многие компании и сообщества давно пришли к выводу, что для определенного класса финансовых веб-приложений (например для ERP или для решений по интеграции) питон - меньшее из зол.

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

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

Выбрал бы готовое решение и не стал тратить время))

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

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

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

Для таких сайтов проще написать мета-систему, которая будет их генерить пачками и опять-таки не тратить свое время

Ну, собственно битриксовцы и друпаловцы так и поступили, как понимаю. Не?

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

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

я бы не стал делать ставку на пых

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

На самом деле это не совсем так: в моей компании, мне приходится (в том числе) и принимать решения какой проект какими программистами пилить. А у нас есть пыхи, - так что часть проектов попадают к ним.

пользуясь вашей терминологией

Ну, извини.

Там где предполагается, что controller модели MVC будет реализован клиентом.

... а с другой стороны позволяет вместо веб-клиента подключить толстый или мобильный клиент (или все разом!) и ничего при этом не потерять.

В целом именно это и подразумевалось, да. Но есть нюансы. Например.

динамический контент страниц создается скриптами клиентской стороны на основании шаблона и данных полученных с сервера (например по REST в формате JSON)

1. Веб-клиент вполне может быть «толстым» веб-приложением, а не только «скриптами клиентской стороны».

2. Существует разница между веб-интерфейсом, который для людей и REST API, который больше для роботов.

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

В итоге применение «толстого» веб-клиента, так же как и десктопного/мобильного, позволяет выкинуть все что не относится к controller из потока бекенд-фронтенд и существенно сократить его, упростить тот же REST API и т.д.

Это только один момент из многих. Ты вот про поисковики вспомнил, это тоже важно.

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

пользуясь вашей терминологией

Ну, извини.

Там где предполагается, что controller модели MVC будет реализован клиентом.

... а с другой стороны позволяет вместо веб-клиента подключить толстый или мобильный клиент (или все разом!) и ничего при этом не потерять.

В целом именно это и подразумевалось, да. Но есть нюансы. Например.

динамический контент страниц создается скриптами клиентской стороны на основании шаблона и данных полученных с сервера (например по REST в формате JSON)

1. Веб-клиент вполне может быть «толстым» веб-приложением, а не только «скриптами клиентской стороны».

2. Существует разница между веб-интерфейсом, который для людей и REST API, который больше для роботов.

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

В итоге применение «толстого» веб-клиента, так же как и десктопного/мобильного, позволяет выкинуть все что не относится к controller из потока бекенд-фронтенд и существенно сократить его, упростить тот же REST API и т.д.

Это только один момент из многих. Ты вот про поисковики вспомнил, это тоже важно.

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

о чем пыхи не забывают нам напоминать. Постоянно, блин!

Уж точно не тебе лично и уж тоxно не «из вредности». Посмотри, этот раздел полон топиками «хочу на переменках заняццо вебдевом, посоветуйте фреймфорк на петоне». Блин, нам хватает и пыхеров говношлепов!

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

На самом деле, - не существует. API, он всегда не для людей, и не важно какой он: RestFull json/xml или SOAP (который всегда xml)

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

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

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

Уж точно не тебе лично и уж тоxно не «из вредности».

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

Блин, нам хватает и пыхеров говношлепов!

Это точно. Но, что делать? - не все же Дональда Кнута в компании с «Совершенным кодом» держат на полке. :-)

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

У нас на конторе пара пыхов живет, так что - как раз мне.

А, ты про своих. Я подумал, ты про ЛОР.

Но, что делать?

Ничего и не поделаешь. Всегда может быть еще хуже.

На самом деле, - не существует. API, он всегда не для людей,

На самом деле - я специально противопоставил «интерфейс, который для людей» vs API. Поэтому существует.

Это - да, но надо иметь ввиду что html5 имеет более мощный механизм для хранения данных связанных с сессией пользователя

Это - да, но надо иметь ввиду что «давычтонаделали?? уминяфсесъехало!!! (ie6)», шел, ты не поверишь, 2014 год.

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

если гуй не очень перегружен

Понятно, что если система проста, то и интерфейса сложного она не потребует. Но ERP — это был твой пример явно сложной системы. Хотя тут я и о мобльном клиенте не думал бы даже, разве для пары отдельных задач.

Это - да, но надо иметь ввиду что «давычтонаделали?? уминяфсесъехало!!! (ie6)», шел, ты не поверишь, 2014 год.

Ты не поверишь, - но ишак не одного тебя задолбал!))

Еще момент — иногда данные сесии вычисляются на сервере, и хранить их желательно на сервере

Сессия всегда хранится на сервере, - на клиенте только хэш идентификатора сессии. Но я и не говорил про данные сессии, - я говорил про данные связанные с сессией. Например, про закэшированный курсор. Это реально может помочь, когда дело касается, например, справочных данных. У меня на одном из проектов нагрузка на ноды упала на ~10-15% после такого финта. Ну и конечно, там можно хранить предпочтения, указанные зверьком в диалоге настроек (что бы не хламить БД на сервере).

хотя бы чтоб избавиться от постоянных проверок ввода

Ну не знаю... я использую для проверок как раз скрипты клиента. Конкретно, - фреймворк js/dojo. А на сервере уже делаю валидацию полученного документа. Полет нормальный.

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

Знаешь, а вот Альфа-Банк подумал... И Одноклассники тоже. Видимо они знают чего-то, чего не знаем мы с тобой.))) У ОК-клиента, кстати сказать, именно что веб-интерфейс и наверное даже Кордова.

Битриксовцы и друпаловцы слепили эпичное говно :) Но с точки зрения маркетинга - безупречное

Сессия всегда хранится на сервере... Но я и не говорил про данные сессии, - я говорил про данные связанные с сессией.

Само собой.

Знаешь, а вот Альфа-Банк подумал... И Одноклассники тоже

Только вот еще было: «разве для пары отдельных задач».

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

У ОК-клиента, кстати сказать, именно что веб-интерфейс

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

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

ps: проще говоря, читай веб-интерфейс == веб-гуй; веб-интерфейс != веб-api. Еще раз извини за неточность.

Битриксовцы и друпаловцы слепили эпичное говно

Поэтому все и пишут собственных «убивцев б-трикса», если ресурсы позволяют.

эпичное говно

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

битрикс ... >эпичное говно

Кому-то психологически комфортнее потыкать мышкой

Кому-то - написать несколько строчек кода.

Ты о чем, не о битриксе ли? Что же там делается в несколько строчек кода/кликов мышкой?

Что же там делается в несколько строчек кода/кликов мышкой?

ничего, использую иногда когда заказчик настаивает, сложность вполне сравнительна с изготовлением такой же системы на фреймворке :) но маркетинг/реклама решают.

Я так сильно не согласен с urmen, но вот с этим постом согласен почти полностью.

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

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

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

Яваскрипт умеет в жёсткую типизацию.
И пыха, емнип, тоже

Яваскрипт умеет в жёсткую типизацию.

js> if (0 === 0.0){ print("Не-а, это не жесткая типизация!"); }
Не-а, это не жесткая типизация!

js> if (0 == 0.0){ print("Не-а, это совсем не жесткая типизация!"); }
Не-а, это совсем не жесткая типизация!

И для сравнения в питоне:

In [1]: if 0 is 0.0:
   ...:     print "Странно, куда девалась строгая типизация?"
   ...: else:
   ...:     print "А вот в питоне есть строгая типизация"
   ...:     
А вот в питоне есть строгая типизация

use strict, Luke
И вывод на принтер уже не в моде, кидай алерты или пиши в консоль

И да, в яваскрипте нет целочисленных типов, не те задачи он решает

я за node, т.к. прекрасный язык (javascript), и, после применения ноды, возвращаться на костыли поверх CGI нет никакого желания.

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

прекрасный язык (javascript)

4.3