bromzh

0) Сперва почитай это
1) Зачем 2 контроллера? Достаточно 1 контроллера с 2-мя методами в нём.
2) $scope - зло. Используй синтаксис controllerAs
3) После добавления элемента нужно либо возвращать с бэкенда новый список (что не по REST), либо делай запрос (естественно в цепочке промисов). Ведь если данные обновятся с 2-х источников, будет рассинхрон.
4) Не используй $http().success, всегда используй then.
5) <a href="{{x.url}}"> не сработает. Нужна директива ng-href.

Ну а код будет примерно такой:

function myService($http, $log) {
    return {
        addLink: addLink,
        getLinks: getLinks
    };
    
    function addLink(data) {
        $http.post('/api/links', data)
        .then(function (response) {
            $log.log('Success', response);
        });
    }

    function getLinks() {
        $http.get('/api/links')
        .then(function (response) {
            return response.data.records;
        });
    }
}

function MainController(myService) {
    var vm = this;

    vm.addLink = addLink;

    function fetch() {
        return myService.getLinks()
        .then(function (links) {
            vm.links = links;
        });
    }

    function addLink() {
        return myService.addLink({
            'linkname': vm.linkname, 
            'url': vm.url
        })
        .then(function () {
            vm.linkname = '';
            vm.url = '';
            return fetch();
        });
    }
}

angular.module('app', [])
    .factory('myService', myService)
    .controller('MainController, MainController');

<div ng-controller="MainController as main">
    <form ng-submit="main.addLink()">
        Name: <input type="text" ng-model="main.linkname"><br>
        URL: <input type="text" ng-model="main.url">
    </form>
    <hr>
    <ul>
        <li ng-repeat="item in main.links">
            <a ng-href="{{ item.url }}">{{ item.linkname }}</a>
        </li>
    </ul>
</div>

Java, Spark, Jackson, PostgreSQL (он теперь умеет в json- и jsonb-поля), Hibernate, Angular1.x+webpack+es6 или Angular2 + TS.

Сейчас по-многим причинам бэкенд смещается от набора "фреймворк+серверная шаблонизация" к "backend-api+frontend-приложение". Т.е. всё чаще и чаще есть серверное АПИ и фронтенд-приложение, написанное на каком-то фронтенд-фреймворке, и которое запрашивает данные по АПИ и как-то выводит. Обычно, на фронте и на бэке используют разные языки, хотя есть тенденции в области изоморфных приложений, когда и код на бэке и фронте почти не отличается. В этом случае пишут на js.
В других же ситуациях, создавать АПИ можно, в принципе, на чём угодно. Нынче модно брать какой-нибудь Go, т.к. он достаточно быстрый и безопасный. Я бы советовал брать Java+Spark/Java+Spring/Scala+Spray/C# с чем-то. Вакансий по этим языкам особо не убавится в последнее время, а литературы в интернете полно.

Выбор сильно зависит от конечной цели, бэкенд очень многогранен. Java будет хорошим выбором в большинстве областей. Но её долго учить. И даже после основ самого языка придётся изучать инструменты, которые используются в той или иной области. Зато вакансии всегда есть и они обычно более высокооплачиваемые.
Да и вообще, это очень востребованный язык, который используется в самых разных областях (и не только на бэкенде). Ну и java который год на первом-втором месте по популярности и сдавать позиции особо не намерен.
Если хочется что-то по-быстрому, то питон вполне подойдёт.

Real-time - это, наверное, long-polling, когда сервер и клиент подолгу держат соединение открытым, в противовес обычному вебу, где 1 запрос открывает соединение, ждёт ответа и сразу закрывает его. Для этого обычно используют многопоточные и/или асинхронные штуки.
Со стороны клиента это реализуется через WebSocket (современный вариант), либо другими хитрыми методами. Протокол websocket поддерживают многие браузеры, однако есть SockJS, который в случае чего прозрачно меняет протокол на другой доступный. Там же есть ссылки на реализацию этого протокола для других языков.
Со стороны сервера:
Для питона - это tornado и asyncio (только для 3-й ветке, включён в стандарт). Можно писать в коллбечном стиле, можно в обычном с использованием корутин (сопрограмм). Tornado умеет sockjs, вебсокет есть для обеих вариантов.
Java сама по-себе многопоточна, поддержка websocket включена в стандарт JavaEE. Помимо этого есть решения для спринга. Это удобно, потому что нужен всего 1 фреймворк и для обычной части сайта (если такая есть), и для его асинхронной части. Есть очень производительный сервер netty с неблокирующим вводом-выводом и апи к нему.
И т.д.
В принципе, почти для каждого языка есть свой неблокирующий сервер и фреймворк к нему. Просто смотри на тот язык, который удобнее и для которого есть большая инфраструктура.

1) общие принципы: habrahabr.ru/post/144011
2) узнать на чём сайт и гуглить уже более конкретно

То MVC, которое в вебе - это неправильное MVC, там, например, модели не оповещают представления, как должны. Это по-хорошему надо называть MVP.
Да и понятие ООП тоже сильно размыто. Реальное ООП - это smalltalk, а не то что в пхп или яве.

Увы, путаницы тут очень много. И к тому же, ООП слабо связано с веб-программированием в целом. Писать веб-приложухи можно в любом стиле, причём другие парадигмы ближе к вебу, нежели ООП.
Разобраться что и как помогает практика, тогда ты сам начинаешь понимать, что и где лучше использовать. Достаточно прочитать несколько статей, чтобы вникнуть в суть, а потом только практика поможет.

с какого языка тогда начать?

python, ruby, java, nodejs, go. Тут от задачи зависит, бэкенды тоже разные бывают. Для игрового сервера лучше одно, для REST-сервиса - другое, для чего-то по типу push-уведомлений или онлайн--чата - третье. Уточни, что именно ты хочешь, я подскажу конкретнее.

Ты ещё не умеешь программировать (и искать в интернете, ведь тут такие вопросы задают минимум по 1 разу в неделю), но уже решил, что питон - это несерьёзный несовременный язык. Видимо по этим причинам он самый популярный язык для обучения в технических вузах США.
Зачем тебе чужое мнение? Ты вполне самостоятельный!

Выбирай Java

https://ejudge.ru/wiki/index.php/%D0%A1%D0%B8%D1%8...

Делать в 2014 году набор компонентов с привязкой к ПХП... Печальный вуз.

Просто посмотри отношение количества идиотских вопросов к общему по ПХП и, например, по питону/руби/яве на тостере.

Эскобар.жпг. Оба ужасны.
Посмотри, как это реализовано в нормальных фреймворках.

Если тебе нужен только 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. Собственно, эти фреймворки для этого и сделаны.

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

Вот бы еще кто подсказал аналог phpDoc комментария "@property Bar1 bar1" для автокомплита в PyCharm.

Docutils, Pycharm умеет её анализировать. Разметка там в нормальном RestructuredText. Плюс, есть отличная система документации Sphinx.
Вот пример оформления docstring для функции:

def public_fn_with_sphinxy_docstring(name, state=None):
    """This function does something.

    :param name: The name to use
    :type name: str
    :param state: Current state to be in
    :type state: bool
    :returns:  the return code
    :rtype: int
    :raises: AttributeError, KeyError

    """
    return 0

Или, более компактно:

def public_fn_with_sphinxy_docstring(name, state=None):
    """This function does something.

    :param str name: The name to use
    :param bool state: Current state to be in
    :returns:  int - the return code
    :raises: AttributeError, KeyError
    """
    return 0

Кроме того, в 3-й ветке питона есть поддержка аннотаций типов (можно указывать тип аргументов функции и возвращаемый тип). Pycharm это тоже понимает.