Долой backend! Все делаем на javascript в frontend.
 

Все мы прекрасно знаем, что есть frontend и backend, программирование на стороне клиента и сервера. Чаще всего для создания вебсайта требуются специалисты по mysql, php, javascript, html, css. Многовато будет. Вот хотя бы избавиться от пары языков например php и sql. Без sql не обойдешься, но по крайней мере можно ограничиться самым минимальным набором команд, как делает facebook, у них запросы самые простые ключ-значение.
Далеко не каждыЙ программист знает как работает жесткий диск и что влияет на время выполнения запроса, сложный sql запрос может оказаться очень медленным.
От php уже избавился node.js, но он работает только со своим сервером и специалистов не так много и они дорогие. Когда вся функциональность находится в одном месте это значительно упрощает сопровождение программы.
Хотелось бы иметь такую систему:
1 программирование происходит на стороне клиента, возможно с использованием frameworks
Angular (2,1), React, Vue.js, Ember, Meteor.
2 используется обычный хостинг или сервер. Фактически программист может даже не знать о серверной стороне, для него процессор оперативная память и диск сервера это всего лишь расширение браузера.
Сделать это совсем не трудно с помощью ajax. Но защититьjavascript код принципиально не возможно так что система получается неприемлимой с точки зрения безопасности. Можно использовать препроцессор, писать все на javascript, а потом генерировать код на php (или другом языке). Препроцессор может делать много других полезных вещей:
1 Проверять качество javascript, html, css кода.
2 Проверять комментированность кода и вообще соблюдение принятого корпоративного стандарта программирования
3 Проверять защищенность от sql инекций и cross site scripting.
4 Генеририровать автоматическую настройку на размер экрана.
5 Генерирвать простейшую мобильную версию.
6 Оптимизировать скорость загрузки страницы. Например удалять из js библиотек (jquery, angular и тд) не используемые функции, выполнять загрузку по мере просмотра страницы. Очень эффективно также сначала загружать относительно небольщие изображения худшего качества, например, меньшего разрешения или в формате gif .
Выглядит система примерно:
так программист на js имет набор операторов обращения к памяти сервера: оперативной ,
файлам на диске, базам данных, журналируемым хранилищам (redis, memcached). Можно вообще каждой переменной, массиву и объекту js поставить в соответствие переменную, массив или объект на серверной стороне с таким же именем. Те чтобы серверная часть была как можно менее заметна.
Кое что в этом направлении уже сделано:
Javascript parser, compiler and interpreter written in PHP
http://sstur.github.io/js2php/demo/
https://github.com/jakubkulhan/js2php

Хотелось бы знать Ваше мнение по всему выщемзложенному.
Предлагаю основать open source проект и разработать такую систему.

Хорошая шутеичка братан =)

отвечай по существу братан.

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

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

А зачем пароль? Атакующий тот же пользователь, а подключение к базе от имени владельца. Но в случае формирования запросов сервером пользователю даже структура таблиц неизвестна, а в случае формирования запросов клиентом, вы не то что структуру вываливаете на общее обозрение, но еще и связи.

Без пароля не выйдет получить данные. А что даст знание структуры?

Я не очень хорошо знаком с хакерскими атаками на базы данных.

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

Страшна SQL инъекция, а для ее предотвращения входные данные которые являются параметрами запроса обязательно подвергают фильтрации, их экранируют и т.п., что исключить подстановку в запрос запроса от атакующего.

В случае если клиент формирует запросы, о какой фильтрации может идти речь? А как быть с закрытыми для пользователей разделами, доступами и правами, запрос к этим данным тоже клиенту формировать?

В сети полно описания об инъекциях баз данных, читайте например на хакер.ру.

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

Он ему и нафик не нужен. А соединение с базой данных с другими паролями не возможны, если только не добавить нового пользователя. Пароль пользователя, по которому он регистрируется на сайте к соединению с БД никакого отношения не имеет.

Вы путает мух с котлетами.

У нас с Вами взаимонедопонимание. Я не предлагал отказываться от ограничения доступа. Эта функция обязательна. Многим нужен многоуровневый доступ пользователей к базе данных. Разные группы пользователей могут выполнять разные запросы и получать доступ к разным данным. Эта функция обязательна. Правами root пользуется только ограничитель доступа.