Игорь Морев

давайте так, есть два вида задач:

- CPU bound - различные алгоритмы, математика, кодирование/декодирование/шифрование... словом все что нагружает процессор.
- I/O bound - собственно когда у нас идет множество операций с вводом/выводом, где-то 90% задач связанных с WEB и серверной разработкой.

Для CPU bound стоит использовать языки вроде Си, Rust, Dlang, Go и т.д. Словом языки которые компилируются в эффективный машинный код.

Для I/O bound - Go, NodeJS, Erlang, Java.... да в принципе не важно какой язык, главное что бы использовались неблокируемые вызовы и отсутствовали блокировки.

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

Какие языки лучше использовать для этого? Какие не использовать?

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

Еще не стоит забывать о алгоритмах. Они тоже должны быть оптимальны. Например взять простую задачу - кластеризация меток на карте. Представьте что у вас в базе миллион объектов, которые мы должны выводить на карте. Поскольку делать подобное на клиенте будет проблематично - мы должны делать это на сервере и возвращать на клиент ровно столько данных сколько ему нужно.

И на таких объемах даже если бы мы взял Си, если наш алгоритм имеет сложность O(N^2) то как бы ничего тут особо не поделать. И так и так медленно будет. А вот если мы возьмем какие-либо алгоритмы имеющие сложность O(NLogN) то уже возможно что алгоритм этот можно хоть на php/python/ruby имплементить. Так например у меня этот алгоритм реализован на Java и не самым эффективным образом. Справляется.

Еще влияет скорость разработки (всякие ruby/python/node в этом плане хороши), стоимость поддержки (Си поддерживать сильно дороже чем Go например, хотя всегда можно написать все настолько плохо что проще выкинуть чем поддерживать), стоимость разработчиков.... Скажем найти дешевых сильных разработчиков на Go или Rust будет весьма проблематично.

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

Собственно главное правило высоконагруженных систем - нагрузочное тестирование а потом уже оптимизации

У него, в разделе callBacks есть onSlideAfter

default: function(){}
options: function($slideElement, oldIndex, newIndex){ // your code here }
arguments:
  $slideElement: jQuery element of the destination element
  oldIndex: element index of the previous slide (before the transition)
  newIndex: element index of the destination slide (after the transition)

Срабатывает при каждой смене слайда
Полагаю, там в колбэке, можно будет прописать смену бэкграунда

1. Здесь пугают всякими контроллерами, ларавелями. Давайте жить проще. Для начала дадим определение модному слову роутер. Это маршрутизатор. Что делает маршрутизатор? Правильно. Обрабатывает маршруты, являясь связующим звеном. Маршрутом для web сайта принято считать метод запроса [GET, POST, PUT и другие] и компоненты URI.

например: https://ru.wikipedia.org/wiki/URI?foo=bar#title
[схема: https] :// [источник: ru.wikipedia.org] [путь: /wiki/URI] [запрос: ?foo=bar] [фрагмент: #title]

Но для определения маршрута может браться любая другая информация передаваемая серверу, определение выше это лишь наиболее употребляемые параметры.

Сама работа, как правило проста: от клиента приходит запрос, маршрутизатор перебирает все заданные ему пути до первого совпадения. При совпадении вызывается определенная вами функция, которая возвращает ответ клиенту.

2. Он необходим, если в приложении одна точка входа, когда любой запрос приходит на один файл.

3. Простой пример

// файл index.php

// Маршруты
// [маршрут => функция которая будет вызвана]
$routes = [
    // срабатывает при вызове корня или /index.php
    '/' => 'hello',
    // срабатывает при вызове /about или /index.php/about
    '/about' => 'about',
    // динамические страницы
    '/page' => 'page'
];

// возвращает путь запроса
// вырезает index.php из пути
function getRequestPath() {
    $path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);

    return '/' . ltrim(str_replace('index.php', '', $path), '/');
}

// наш роутер, в который передаются маршруты и запрашиваемый путь
// возвращает функцию если маршшрут совпал с путем
// иначе возвращает функцию notFound
function getMethod(array $routes, $path) {
    // перебор всех маршрутов
    foreach ($routes as $route => $method) {
        // если маршрут сопадает с путем, возвращаем функцию
        if ($path === $route) {
            return $method;
        }
    }

    return 'notFound';
}

// функция для корня
function hello() {
    return 'Hello, world!';
}

// функция для страницы "/about"
function about() {
    return 'About us.';
}

// чуть более сложный пример
// функция отобразит страницу только если
// в запросе приходит id и этот id равен
// 33 или 54
// [/page?id=33]
function page() {

    $pages = [
        33 => 'Сага о хомячках',
        54 => 'Мыши в тумане'
    ];

    if (isset($_GET['id']) && isset($pages[$_GET['id']])) {
        return $pages[$_GET['id']];
    }

    return notFound();
}

// метод, который отдает заголовок и содержание для маршрутов,
// которые не существуют
function notFound() {
    header("HTTP/1.0 404 Not Found");

    return 'Нет такой страницы';
}


// Роутер
// получаем путь запроса
$path = getRequestPath();
// получаем функцию обработчик
$method = getMethod($routes, $path);
// отдаем данные клиенту
echo $method();

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

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

index.php
about.php
contact.php
...

Это олдскульная структура, в новых проектах почти не применяется.

foundation.zurb.com/emails.html

Как на этом сайте?
seolead.pro

seolead.pro/wp-content/themes/seolead/js/pollyfill.js сам скрипт.

<div id="introR" class="super_back"><canvas id="pollyfill-canvas"></canvas></div>

блок для вывода.

html5.by/blog/scroll-effects

Скажу как вижу со своей горы. Мне как веб-разработчику js-приложения - самый простой путь к созданию мобильных приложений. А учитывая еще что они кроссплатформенные, то казалось б цены им нету. Но на самом деле приложения такие работают медленнее и не имеют достаточно хорошего доступа к железу. Я пробовал Ionic, Cordova и f7. И все они еще далеки от возможностей нативной разработки. А без этого большие игроки рынка не откажутся от нативной разработки в пользу кроссплатформенной.
Так что на данный момент это просто возможность для создания дешевого приложения с простым функционалом под все платформы за короткое время. В будущем, если появится действительно хороший инструментарий, вполне может заменить нативную разработку.

Попробуйте пока поиграться с ним, сделать какие-нибудь тривиальные вещи...и возможно вы влюбитесь в это прекрасное творение как и я =) В действительности же, я не знаю, что значит "пора", для людей которые зарабатывают программированием. Могу лишь предположить, что для вас важно, чтобы проект уже был стабилен, и глобальных изменений не вносилось, дабы много раз "не перелопачивать" код. Но это уже поздняя бета, к тому же разработчики не раз говорили, что если изменения и будут, то это скорее дополнение и расширения существующей версии. Еще один, как я считаю, немаловажный плюс, как сообщество отреагировало на выпуск беты: Яков Фейн уже написал книгу по Angular-у, а человек, вроде, серьезный, стал бы он давать то, что не будет работать уже завтра?Думаю - нет. Есть уважаемые youtube блогеры, которые уже сняли материал, к примеру: thenewboston, Mindspace. Так же проводилось множество конференций именно после выхода беты.

Я же человек, который занимается программированием всего-лишь 5 месяцев, мой основной ЯП - java. Для того, чтобы зарабатывать этим ремеслом мне необходимо продемонстрировать свои навыки, и вот для этой цели я разрабатываю свой "универсальный магазин", а-ля catalog.onliner.by + еще одно крыло, в виде админки всего сайта. Сейчас мой стек: back-end: Spring MVC +Secutiry, Jpa(Hibernate), front-end: Angular 2(хотя сначала был 1-ый). Да, у меня были проблемы,допустим, с тем как сделать динамический роутинг, или организовать взаимодействия между различными элементами router-outlet, что решилось с помощью удобнейших провайдеров( фабрик в 1-ом ангуляре), валидация форм, сортировка данных, можно перечислять и перечислять задачи. Но все же решаемо, тем более когда вы во фронденде не первый день. Но какое же удовольствие ты получаешься при разработке на этом языке, вместе с java, Typescript+Angular 2 ... типизированность, замечательная структурируемость и модульность, приложение у меня уже довольно-таки большое, конечно, по сравнению с корпоративными оно должно казаться небольшим, если не меньше, но в ветвях своего приложения ориентируешься относительно быстро,изменения кода почти безболезненны, хотя ,наверное, это всего-лишь мой стиль написания кода...но помню пытался, что-то похожее начать делать на Jquery...не знаю как лучше это обозвать, скорее: лапша и все больно менять.
Возможно я и потратил немного времени на изучение Angular-a, столкнулся с некоторыми проблемами,писал сюда, на SO, на github разработчикам, но я думаю, что это вполне нормально для нового ЯП?)

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

Можете выполнить такие задачки на чистом JS, к примеру:
1. ToDo-лист с сохранением задач в localStorage (пример).
2. Интерактивный календарь с возможностью добавлять события на любую дату.
3. Система тестирования/анкетирования с хранением вопросов и вариантов ответов в JSON.
4. Простая игра (тетрис, змейка, рулетка, крестики-нолики и т.д.) с использованием Canvas/SVG.
5. Калькулятор (обычный, кредитный и т.д.).