Программирование согласно контракту на JVM

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

Современный PHP без фреймворков

Вот и получается что если фреймворком называть структуру взаимодействия модулей и обслуживающие функции, то каждое приложение, где они явно выделены можно называть «фреймворк» + «бизнес логика». А именно это похоже и предполагается теми, кто пишет что автор написал свой фреймворк. Но решение автора его самого в архитектуре не ограничивает, а даёт свободу выбора. В этом вроде и есть главный интерес

Современный PHP без фреймворков

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

Современный PHP без фреймворков

Это так странно, что любое приложение с внятной архитектурой в этом обсуждении называют(или подразумевают) фреймворком. Это проблема понимания и терминологии, я бы фреймворком только каркас для множества приложений называл, а не архитектуру одного проекта с реализацией базовых кусков.

Пора убить веб

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

Ускоряем разработку с помощью интерактивных блоксхем

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