Облачные приложение, на чем писать?

Вот кстати к примеру mathematica online очень нравится интерфейс, рисует красивые графики, формулы итд, удобный редактор. Есть ли удобные яп, инструменты для создание нечто подобного? Писать на jQuery интерфейс и весь интерактив как-то не удобно.

Django

Python

Sinatra http://www.sinatrarb.com/

Python же.

Между руби и питоном реальной разницы нет.

Rails не нравится

как-то очень много разных файлов

Хм. C + CGI твой выход! Eddy_Em

А если серьёзно - что за приложени? Поконкретнее

erlang

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

Я не знаю еще что за приложение )) просто хочу научиться разрабатывать облачные приложения на будущее.

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

Ты хоть знаешь чего хочешь?

Да, сейчас я понял что мне нужно поискать UI фреймворк и выбрать между Rails и Django. Извините что запутал )

Так веб является только выводом, сами операции происходят не в вебе. Т.е. им достаточно общаться по api к примеру.

Запили например что то вроде rollapp, это классический пример.

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

Go

на платных облачных IDE?

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

Лично я предпочитаю python, а фреймворков тут достаточно. Django конечно впереди всех

Python.

на чем угодно.

hint: начни с понимания того, что такое «облачное приложение»

Scala. Это мощный язык, и он фигачит по верх быстрой jvm

Scala, Clojure. C++ с Web Toolkit

Джанга с рельсами - это мостры из прошлого поколения веб. Они большие и сложные, т.к. несут в себе роутинг, шаблонизаторы, генерацию html, ORM.

Сейчас же принято генерить html силами браузера. А серверное приложение должно лишь отдавать JSON по REST API.

Поэтому серверную часть можешь писать на чем хочешь. Да хоть на баше по CGI.

Golang!

CL

быстрой

отличная нестареющая шутка!

Еще один купился на маркетоидный бред про облака. На /bin/sh пиши.

ruby наоборот очень понравился

Дважды купился.

Отличные нестареющие свидетели тормозной жавы.

Скала вполне себе вариант, да.

Джанга с рельсами - это мостры из прошлого поколения веб. Они большие и сложные, т.к. несут в себе роутинг, шаблонизаторы, генерацию html, ORM.

Сейчас же принято генерить html силами браузера. А серверное приложение должно лишь отдавать JSON по REST API.

Поэтому серверную часть можешь писать на чем хочешь. Да хоть на баше по CGI.

вумный какой, а что, если серверное приложение предоставляет REST API, то ему ORM никогда не нужен будет? И все сопутствующие библиотеки не нужны для ускорения разработки? Можно на голом C/bash писать легко-поддерживаемые приложения любого масштаба в сжатые сроки?

По теме: Никто не мешает реализовать REST API на Rails, там для этого есть всё, компоненты в которых нет необходимости отключаются, также советую посмотреть на grape gem, это не пустые слова

что сейчас имеем - крупный проект, сервер сайд на Rails, который предоставляет только REST API, никакого html, весь фронтенд на AngularJS, в продакшене больше года, полет нормальный

исключительно на коммон лиспе. ко ко ко.

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

Я всегда пытаюсь понять, когда человек формулирует утверждение, он думает над его обоснованием? Или лишь бы что ляпнуть. В чем сложность, например джанго? Ты в код джанго смотрел? Это модульная библиотека, не нужен шаблонизатор не используй, не нужен ОРМ не используй, нужен только Request, Response и отдача только JSON нет проблем...

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

Отвечу тебе и рельсовому анонимусу выше

Джанга с рельсами научились обслуживать много клиентов на одном cgi/fastcgi/wsgi-подключении? Или, как и раньше, GIL блокирует процесс при всяком сетевом/файловом IO? Подозреваю, что не научились и как и раньше надо создавать батареи из загруженных в память фреймворков.

И знаешь что очень быстро становится решающим фактором в таких батареях с их ростом? Размер каждого процесса! Сравни потребление памяти пула из сотни микрофреймворков и пула из сотни джангорельс с (хах) отключенныим ненужнными компонентами

Это модульная библиотека, не нужен шаблонизатор не используй, не нужен ОРМ не используй

Девочка считает, что при вводе «pypi install django», появляется волшебное окно, в котором галками можно поотключать ненужные компоненты и зависимости. Девочка ошибается.

Windows - это модульная ОС. Не нужен IE - не используй. Не нужна графическая подсистема - не используй.

а что, если серверное приложение предоставляет REST API, то ему ORM никогда не нужен будет?

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

Никто не мешает реализовать REST API на Rails

Никто не мешает реализовать REST_API на калькуляторе с перфокартами. Главное чтобы была поддержка stdio и возможность читать ENV-переменные

GoLang + рекомендации: 12factor.net

Windows - это модульная ОС.

Большего бреда в жизни не видел.

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

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

NodeJS

Nope. Сейчас rails стали вполне модульными и можно выкинуть лишнее или взять готовое https://github.com/rails-api/rails-api. А шаблонизатор для json внезапно тоже нужен, например, тот же jbuilder.