🔥You Gotta Love Frontend in 2 days. Grab your ticket!
×Закрыть

Будущее web-программирования обьединяющее M+V+C

Я вижу будущее web-разработки — оно прекрасно!

всё из одного места будет разворачивать интерпретатор, например:

newUser{#div1}, showUsers{#singleUser}, getUserInfo{.userInfo}{
name[[A-zА-я]{7}], age[3], salary[\d{4,7}]
}

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

Синтаксис конечно будет сложный, но зато всё в одном месте, не надо будет растраиваться-раздваиваться.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Думал, ну откуда берется столько .... в айти? Или может, троллит?
Открыл профайл автора:

Хочу получать свой кусочек IT-пирога
PHP+JS+вёрстка.
фрилансю, 6 лет трудился преподавателем в Академии ШАГ. Сейчас мне 36

Всё сразу встало на свои места )

Чтобы было больше ада, в этот пост надо добавить ссылку на Emmet

Это прошлое, как раз, от этого и пришли к разделению MVC, как к более поддерживаемому и single responsibility паттерну, новички или не очень опытные разработчики могут писать запросы в базу прямо из view, там же логику — но это очень ужасная вещь с точки зрения исправления ошибок и развития проекта.

На DOU выражение «у этого человека семь пятниц на неделе» имеет свой особый смысл...

Ref: dou.ua/forums/topic/23882

Я вижу будущее web-разработки — оно прекрасно!

Ясно. Осталось постоять с колокольчиком под софтсервом :)
Как на этом «будущем» слепить хотя бы ToDo list? А что по сложнее? Еще и связи через #id? С этого максимум вышел бы какой то очередной табличный процесор или шаблонизатор. Возможно даже ucoz. Каким боком это можно позиционировать как будущее веба хз.

Будет ли такой язык программирования, который вберёт в себя MVC? Т.е. не надо будет думать отдельно про клиентскую часть, и отдельно про серверную.

Будет ли такой язык программирования, который вберёт в себя MVC?

К счастью нет. Даже если бы это было возможно, будем плодить ЯП на каждый архитектурный шаблон?

Т.е. не надо будет думать отдельно про клиентскую часть, и отдельно про серверную.

Как можно тут думать отдельно? То, что сгрузите код в один файл, вместо двух, ничего не по меняет. Все ровно будет два слоя, о которых нужно будет думать, а думать будет легче, когда мухи и котлеты отдельно. И это если не касаться вопросов поддержки кода и коммерческой разработки с разделением ролей. Можно, конечно, попытаться решить некоторые частные задачи, типа автоматизации валидации/синхронизации данных моделей по обе стороны, но это и так уже решалось не одним велосипедом и никак не «языком программирования». Если тут и возможна хоть какая то практическая реализация, то она будет для решения частных задач, и потеряет всякую гибкость, это будет уровень скриптования в cms...

MVC не надо обьединять его надо выкинуть из веба кик наиболее неудобную парадигму. Что касается вышенаписаного то это полная чушь. Попытки декларативного вывода данных предпринимаются давно но ничем хорошим жто не заканчивается. Максимум для построения отчетов. Да и то свмых простых

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

Я никогда не писал интерпретаторов, нужен сильный программист.

Чувак, то что ты написал называется язык предметной области. И если есть конкретная идея, ты бы изложил понятно

«...из одного места... »
это прекрасно

Почему вы спрашиваете? Не помню чтобы я был с ним знаком.

Ссылку на гитхаб в студию

Это в будущем, если Web не постигнет судьба Александрийской библиотеки.
Всякие там YII, Laravel и прочие думаю всё таки соединяться с Vue, Angular в автоматизированном конструировании сайта. Очень уж неприятно разрывать соображалку на бэк и фронт, пусть умный интерпретатор сам это делает.

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

А ничего, что раньше бек и фронт и был соединен? Только не Vue, Angular были интегрированы в фреймворк, а jquery с библиотекой jqueryui и bootstrap. В Yii1 были экстеншны, чтобы настраивать jquery из-под пыховских конфигов и можно было пыхой рендерить готовые стилизованные элементы. Тоже самое и с bootstrap, например, было в SonataAdminBundle для symfony 2, где js бутстрапа можно было кастомизировать (и можно, наверное, до сих пор, бандл все еще поддерживается).

Но время рассудило иначе. Пару лет назад из стандартной поставки symfony убрали assetic bundle, который давал расширенное управление ассетами (css, js, images) как раз для сценария, когда бек и фронт объединены и html, css, js, images приходят целиком из пыховского бекенда. Но они это убрали, судя по всему, из-за большой популярности js фреймворков, которые сами рулят ассетами.

Так что всё новое — хорошо забытое старое. :)

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

До сих пор нету во фреймворках типов полей photo, comment, name и т.д.

Зачем в фреймворках какие то поля и чем это лучше композиции и компонентов? Фреймворк это не cms. Хотите блок комментариев? Пишите компонент, который их реализует, и используйте в проектах, передавайте ему какой то link на его api- неужели написать что то типа

<comments-block link="/discussion/1234"></comments-block>
хуже чем какое то теоретическое месиво еще на одном 100500-м скриптовом языке?

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

пусть этот супер-интерпретатор называется loveWeb (logo: зелёное сердце в центре паутины).
Например я хочу сделать возможность добавления и показа на сайте фоток с комментариями.
вписываю интерпретатору loveWeb

addPhoto, showPhotos
{photo photo, comment comment[\w{1,255}]}

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

Автор видит будущее в xslt-трансформациях, похоже, и его видимо от этого поющит

В одном месте прописывается инструкция для интерпретатора, далее интерпретатор сам заносит/редактирует данные в базе, заполняет/редактирует шаблоны. Программисту не надо бегать по шаблонам, контроллерам, моделям.

автор, а почему ж тогда нам с вами не опустится до машинного кода?
Имхо ваши рассуждения —> бред сидой кобылы, очень мало связанные с реальностью.
Модульность приложения — основа его легкочитаемости, и адекватной и быстрой работы разработчика с ним. Ваш паста код умер ещё до развала союза, смиритесь

Подписаться на комментарии