titronfan

phonegap

https://www.youtube.com/watch?v=X_JH1gBJe2E&list=P...

возможно, это вам поможет

import time
from datetime import datetime

while True:
    time.sleep(1)
    now = datetime.now().strftime('%H:%M:%S')
    print(now)

React.js это не только V из MVC, это полноценная библиотека для создания UI компонентов, которая прекрасно работает без M и C из MVC архитектуры (т.е. вместо MVC архитектуры, React-разработчики обычно используют Flux архитектуру). В дополнение к React, для больших приложений имеет смысл использовать GraphQL в качестве data API бэкенда и Relay в качестве управления данными на клиенте (Redux в данном случае скорее всего не понадобится). Пример можно посмотреть здесь => https://github.com/kriasoft/react-starter-kit

Конечно можно. React + Redux и дело в шляпе.
Для роутинга - react-router.
Для сборки/минификации/использования es6 и т.д. - webpack+babel
Для тестов - ммм, пожалуй, "мир реакта" просто сказка в вопросах тестирования. Есть много отличных инструментов.

---
В дополнение к предыдущему ответу: выбирать новую технологию для проекта стоит, только если сроки позволяют ( о чем там в принципе и написано). Использовать react для какой-то отдельной страницы/части можно.

Как сказал, Dan, создатель Redux (примерно, по памяти):

"Если у вас нет времени изучать А, то А не требуется на этом проекте"

Что я не так делаю?

очевидно: сначала считаете, затем проверяете. а не наоборот.

jsfiddle.net/26zzsa40/1

если меняется сам элемент, который слушает какое-либо событие, то юзайте $.on();

$('body').on('submit', '.myTag', function(){});

Почему так?

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

parseFloat ?

Для начала давайте разберемся с тем что такое "правильно". Правильно в контексте вопроса - это максимально гибко. В приведенных вами ссылке "роутер" влияет на то, как будет устроена вся система. То есть в них мы сначала делаем допущение "у нас будут контроллеры, модели и представление, что бы как в рельсах но по другому).

Роутер же не должен ничегошеньки знать о контексте своего использования. Вот это будет правильно. Мы просто должы скормить ему какие-то правила маршрутизации, задающие соответствие "uri => mixed" к примеру, а так же иметь возможность скормить ему строчку что бы тот сказал кого все же вызывать.

Все, на этом зона ответственности "роутера" заканчивается. Грубо говоря самая примитивная реализация роутера:

// наш примитивный роутер
function getRoute(array $rules, $uri) {
     return $rules[$uri] ?? null;
}

// использование роутера
$action = getRoute([
    '/' => 'indexPage',
    '/about' => 'aboutPage',
    '/blog' => 'blogPage'
], '/about');

// больше нам уже роутер не нужен
// вызываем действие
call_user_func($app, $action);

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

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

$rules = [
     [ 'uri' => '/blog/page{pageNumber:\d+}', 'method' => ['GET', 'HEAD'] ]
];

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

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

balance - это не таблица, а поле:
UPDATE table SET balance = balance + 100;

Шифрование - чрезвычайно ресурсовемкая (процессорное время) операция.
На JS будет или подобие шифрования, иллюзия.
Или недопустимо тормозно.

Доверьтесь https.