bromzh

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

Если тебе нужен только 1 лэндинг, то просто пиши с нуля, подключай разные js-библиотеки (jquery, angular/knockout/etc для отображения данных), jquery-плагины, и т.д.

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

Мой стек:
1) Grunt, bower - для быстрого равёртывания нового проекта и подключения внешних библиотек.
2) Less - как более удобный инструмент вёрстки
3) jQuery с плагинами (какие - зависит от проекта), normalize.css, modernizr.
4) Github Pages - для просмотра страницы по мере разработки

Собственно, всё сводится к написанию под себя конфига для grunt. У меня он позволяет скачивать зависимости bower'а. Далее, все внешние js и css кидаются во временную папку. Туда же кидаются мои скомпилированные css и js. Далее, если это не production, то каждый файл инжектится отдельно на html-страницу. Если production - всё сжимается до 1-го файла (т.е. на выходе будет 1 js-файл и 1 css-файл) и инжектится только 1 js и 1 css. Все изменения в конфиге bower'a, изменения в css, less и js-файлах отслеживаются. Если они изменились - то grunt автоматом запускает нужные задачи, т.е. при изменении, например, в less-файла, через пару секунд эти изменения будут видны на странице, которая открыта в браузере.

На клиентской стороне (именно html-страницы) лучше использовать какие-нибудь "реактивные" фреймворки: AngularJS, Knockout+mapper plugin, etc. Это избавит тебя от огромной кучи кода обработки событий всяких кнопок, от кучи кода, необходимого для обновления всех данных на странице и т.д. Просто на клиенте надо будет построить некую MVC/MVVM-архитектуру, которая будет обрабатывать данные с сервера и связывать их с различными элементами UI. Собственно, эти фреймворки для этого и сделаны.

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

Knockout + mapper plugin для него. Ну или любой другой реактивный JS-фреймворк.

.delay()
Или используй анимации из GreenSock, там есть задержки для анимаций, и есть плагин, который заменяет стандартную jqery-вскую animate.

Не проще ли открыть код под GPLv3/LGPL (чтобы его не смогли использовать в закрытых проектах) и предусмотреть коммерческую лицензию для закрытых проектов за деньги? Для некоммерческих и открытых проектов разрешить использовать код бесплатно. Плюс, бери деньги за техподдержку. Так сделано у очень многих проектов (Qt, например).
А то вдруг твоё поделие никто покупать не захочет? Большой проект трудно поддерживать маленьким коллективом (в случае открытых исходников многие смогут отправлять пулл-реквесты). А маленький вряд-ли кто-то купит (если он не обладает какой-нибудь супер уникальной фичей).
Ещё можешь посмотреть, как лицензируются большие движки. Некоторые берут процент с продаж продукта. который их использует, некоторые позволяют использовать движки бесплатно до тех пор, пока прибыль или количество установок проекта не превысят определённую планку.
Вообще, чем более либеральная лицензия, тем больше будет желающих использовать твой движок. Деньги, опять же, можно и с ТП получать (как это делают RedHat. nGinx, и прочие).

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

Эту либу точно поддерживает SpringFramework. На счёт чистой Java EE не знаю. Поэтому, у тебя 2 варианта: использовать вебсокеты от спринга, а в остальном юзать Java EE фичи, вроде как есть много туторов, как скрестить EJB и Spring. Ну или используй полностью Спринг заместо Java EE.

А если ты точно знаешь, какой браузер будет у пользователей, то можно и на чистых вебсокетах и Java EE замутить всё.

P.S. Не используй томкат, бери полнофункциональные сервера: Glassfish 4 или WildFly 8 (бывший JBoss).

Вопрос из серии "почему в функциональных языках нет циклов и переменных и как с этим жить". Так вот, жить можно вполне хорошо. Просто немного по-другому.
Советую изучить, что же такое ООП и какое оно бывает. За пару минут можно найти инфу, что в жаваскрипте ООП - прототипное, а в питоне "классоориентированое". Т.е. в первом всё есть объект, и создавать новые объекты можно только клонируя основной объект, все методы и поля ищутся сперва у объекта, а потом у всех его прототипов. Во втором случае есть разделение на классы и объекты - экземпляры этих классов. Там диспетчеризация устроена по-другому: методы и поля ищутся у класса, а потом у всех его предков.
И обходиться без наследования и метаклассов можно довольно легко, если знать, для чего же вообще нужно наследование и метаклассы. Метакласс позволяет манипулировать создаваемым классом на уровне его создания. Т.е. в питоне есть 2 понятия: класс и его экземпляр. В конструкторе класса можно определить поведение создаваемых экземпляров (через __new__ и __init__). Чтобы изменить поведение самого класса (а не его экземпляра) и нужны метаклассы: там, в функциях __init__ и __new__ можно переопределить поведение при создании класса. Так как в жаваскрипте такого разделения нет, то и отпадает само понятие метакласса: каждый объект создаётся путём клонирования от базового объекта (Object в js, хотя можно клонировать и любой другой объект: Array, Function, твой собственный). Такая же фигня и для наследования: там ты просто указываешь, какие поля могут выступать в качестве прототипов для всех "дочерних" объектов, это когда пишешь MyClass.prototype.someMethod = function(args) { ... }. В данном случае, someMethod будет сперва искаться среди самого объекта. Если там такого нет, то ищется в прототипе, т.е. в MyClass. Ну "классы" там объявляются функциями, потому что синтаксис не предусматривает создание класса. Да и то, функция-класс - просто синтаксический сахар: при вызове оператора new MyClass эта функция исполняется и возвращает копию объекта Object, над которой применили некие операции (которые ты как раз и описываешь в ней). Для каждой функции создаётся свой локальный контекст, который хранится в переменной this. Ты можешь в функции-классе описать, какие поля добавить в this, и она вернёт тебе как раз-таки этот изменённый this. Вот в lua нет даже оператора new, и ничего, вполне удобное ООП.

У каждого подхода есть и плюсы и минусы. Мне удобно писать в обоих стилях. Единственное, могут возникнуть проблемы, когда в классе вытаешься присвоить полю какую-то функцию (callback). This внутри этого колбека будет иметь локальный контекст этой функции, а объекта, в котором находится это поле. На помощь приходит функция bind.

P.S. Важно понимать, что функции являются объектами (в обоих языках). Но в js использование функций как переменных встречается гораздо чаще. Поэтому, строго говоря, нет никаких методов и полей в js. У объекта просто есть члены, которые могут быть как простыми данными и объектами, так и функциями. Собственно, для питона это тоже верно, ведь сами классы тоже являются объектами (экземпляры типа type). Просто там есть 2 понятия, как бы двухуровневая система. Ну и там куда реже члену объекта присваивают функцию, нежели в JS.

Есть несколько основных варианта организовать вывод части данных.
Вариант №1 - количество элементов на 1-й странице и номер страницы. Это самый негибкий вариант.
Вариант №2 - сдвиг и количество. Задаёшь текущий сдвиг и количество элементов.
Вариант №3 - от и до. Задаёшь, номер начального и конечного элемента.
Пример. Надо получить данные для 3-й страницы.
Для варианта №1 значения будут такие items_per_page = 25; page = 3
Для варианта №2 значения будут такие shift = 50; count = 25
Для варианта №2 значения будут такие from = 50; to = 75

Как это реализовать на практике. (Привожу примеры на питоне и для 2-го варианта)
Вариант на сервере
Я не знаю, какой у тебя язык на серваке и какие технологии ты используешь. Но обычно, если используется ORM, то он позволяет получать записи из БД в определённом промежутке, либо постранично. Тогда код будет таким:

@app.route("/api/items/")
def items():
    shift = request.get("shift")
    count = request.get("count")
    return Item.objects.all().from(shift).to(shift + count)

Ну а из клиента делай ajax-запрос на этот урл с нужными ГЕТ-параметрами, т.е. урл будет выглядеть так: /api/items/?shift=50&count=25. На нажатие кнопки с номером страницы вешай функцию, которая узнает номер страницы и сформирует соотв. запрос

Вариант - на клиенте
Сервер отдаёт сразу все элементы. На клиенте используй angular/knockout/etc. Данные сохраняются в массив моделей (модель соответствует информации для каждой item). Нажатие кнопки с номером страницы не запрашивает данные с серва, а загружает модели выбранного фреймворка в определённом промежутке.

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

Просто цикл for выглядит более ясно и понятно, если надо перебрать некую коллекцию. В случае while можно напортачить с изменением счётчика. While обычно используют, если критерий выхода из цикла - некое логическое значение. А for - если идёт итерация по коллекции (массив или объект).

Вот тут пример отправки:

var bytesToSend = [253, 0, 128, 1],
    bytesToSendCount = bytesToSend.length;

var bytesArray = new Uint8Array(bytesToSendCount);
for (var i = 0, l = bytesToSendCount; i < l; i++) {
  bytesArray[i] = bytesToSend[i];
}

$.ajax({
   url: '%your_service_url%',
   type: 'POST',
   contentType: 'application/octet-stream',  
   data: bytesArray,
   processData: false
});

Сделай так, только наоборот.

eax.me/dracula
Как в JavaScript построить графы,блок схемы и потокы данных ?

Ещё вариант - поднять сервер Python Notebook и рисовать графы в matplotlib и других инструментах.

Но в объектно-ориентированном программировании используется активная модель MVC, где модель — это не только совокупность кода доступа к данным и СУБД, но и вся бизнес-логика. Следует отметить возможность модели инкапсулировать в себе другие модели. В свою очередь, контроллеры представляют собой лишь элементы системы, в чьи непосредственные обязанности входит приём данных из запроса и передача их другим элементам системы. Только в этом случае контроллер становится «тонким» и выполняет исключительно функцию связующего звена (glue layer) между отдельными компонентами системы.

Как это можно было не заметить на википедии?

Сперва реши, какая часть тебе больше нравится - фронтенд или бэкенд. Знать придётся всё, но лучше углубиться в одно направление.
Если выбрал первое - бери готовый сайт, попытайся сверстать так же, без особого подглядывания в исходники. Потом добавляй интерактив на страницу. Потом бери какой-нибудь mvvm-фреймворк на JS и сделай одностраничное приложение. Не забывай учиться, как взаимодействовать с серверной частью. Инструменты: препроцессоры для CSS - Less/SCSS, библиотеки для JS - jQuery, Knockout, Angular, etc.
Если хочешь заниматься бэкендом на питоне - бери и изучай какой-нибудь фреймворк, для начала подойдёт Django. Сперва делай сайт, типа бложека, новостного или магазина. Потом добавляй всякие плюшки - пагинацию, RSS, затем делай REST API, переделай сайт, чтобы он мог подгружать данные без перезагрузки страниц. После этого изучи другой фреймворк , сделай тоже самое на нём. Потом изучай асинхронные штуки, прикрути к твоему сайту чатик. Инструменты - Django/Flask как обычные веб-фреймворки, Twisted/Tornado/asyncio для асинхронных штук. ZeroMQ (или другие MQ), Celery для общения между приложениями. Неплохо научиться работать с разными видами БД: как SQL, так и NoSQL.

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