Как-то это не юзерфрендли. Кто это выдерживает? Ни разу не попал при перемотке. Где первый раз встречается тест?
Удобнее на 200 серий по 5-10 минут разбить? Ну так смотрите по 20 минут в день на 1.5x скорости с перемоткой клавишами-стрелками. Все, кому нужно. Ну и кто не кричит: "Посмотрел 15 минут вступления и мне про JS не понравилось. Значит всё вода и аццкий ужос!". Когда на экране появляется папка tests.
Удобнее вырезать воду и разбить по темам. В образовании тоже есть стандарты. Они так же касаются и планов уроков. Если вступление превышает 5 минут - для видеоурока это смерть. Если урок про php - при чем тут js? Это мне очень помогло.
В основном контенте воды нет. Всё разбито по крупным темам. Это не школьный урок по плану, а свободный стрим по разработке фреймворка с проектом на нём. В начале рассказ про язык PHP, Composer и его фреймворки. Про это надо упомянуть. А то некоторые не знают, чем фреймворки отличаются от библиотек. Мы этот тред и начали как раз с рассуждения, для чего там JS. Воспользуйтесь бинарным поиском, тыкая мышкой по серединам половин. Так найдёте быстрее.
28 минут вступление! Именно так я и сделал. Папка тесты появилась после часа. Речь не об аудитории, а о процессе. Это касается любой подачи материала. Если Вы хотите, что-то до кого-то донести - придется использовать спецприемы, которые усиливают эффект. Ваше получасовое вступление можно спокойно отрезать от ролика. Ни Вы ни Ваш зритель ничего не потеряете - только приобретете. Зритель не устанет, а Вы избежали бы холивара по поводу библиотека/фреймворк.
Вот мы и посмотрели МОЁ ЖЕ видео и можем сравнить с ВАШИМИ фейковыми обвинениями: Моё видео: "у проекта библиотеки внутри проекта, а фреймворк снаружи проекта" Ваш фейк: "у проекта библиотеки внутри проекта, а у фреймворка снаружи" Поэтому неудивительно, что над вашими фразами вместо моих все смеются. Вы всё перевираете вместо цитирования из оригинала. Если увидели разницу, то признайте свою вину за свою неумышленную дезинформацию или умышленную клевету перед читателями форума и телеги. Если не видите, то признайте как данность, что у Вас личные проблемы с восприятием, за намёки на которые Вы уже кинули два страйка.
Ты действительно не видишь проблемы в этой фразе? Серьезно? Она еще печальнее же. --- Добавлено --- Ой, вот скажи, как человек, разбирающийся в том, что внутри, что снаружи, а JQuery это библиотека или фреймворк?
В этой фразе проблемного и печального ничего и нет, кроме тавтологии. Не знаю, что Вам в ней ещё мерещится. "jQuery — библиотека JavaScript, фокусирующаяся на взаимодействии JavaScript и HTML". "ReactJS — JavaScript-библиотека с открытым исходным кодом для разработки пользовательских интерфейсов." "AngularJS — JavaScript-фреймворк с открытым исходным кодом. Предназначен для разработки одностраничных приложений." Всё верно.
@Fell-x27, @ElisDN готов выступить третьей стороной в вашем споре. @Fell-x27, если Вы за конструктивный диалог - за неточность цитаты можно извиниться. От Вас не убудет. @ElisDN, Вы тоже исковеркали смысл фразы:
Да, это оно и есть по направлению потока контроля (control flow) над процессом исполнения: кто кого из них использует. Фреймворк вызывает наш код, помещённый в предоставляемые им места, а наш код уже использует библиотеки: "Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client. A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points." Как и пересказано в видео: Проект внутри себя использует библиотеки, а фреймворк (наоборот как внешний каркас) снаружи запускает наш код. Фреймворк предоставляет нам места и базовые структуры, в которые мы можем вставлять свой код. Кто внутри, а кто снаружи этой пищевой цепи – тот либо фреймворк, либо библиотека. А между ними как раз сам проект. А опытный джентльмен: термины Inversion of Control, Dependency Inversion и Dependency Injection не поймёт.
Эта фраза присутствует в Вашем видео? Это уже домыслы и догадки. Инверсия управления - это как личный и общественный транспорт. По Вашей формулировке получается, что водитель едет в машине, а трамвай - на пассажире.
софистика фреймворк Код (Javascript): var express = require('express'); var app = express(); app.get('/', function (req, res) { res.send('Hello World!'); }); app.listen(3000, function () { console.log('Example app listening on port 3000!'); }); либа PHP: const http = require('http'); const hostname = '127.0.0.1'; const port = 3000; const server = http.createServer((req, res) => { res.statusCode = 200; res.setHeader('Content-Type', 'text/plain'); res.end('Hello, World!\n'); }); server.listen(port, hostname, () => { console.log(`Server running at http://${hostname}:${port}/`); }); что тут кого вызывает и в каком месте должно быть расположено?
По моей формулировке водитель ведёт машину (или трамвай) или педалит велосипед, а эта машина (или трамвай) уже везёт пассажира. Ни трамвай на пассажире, ни водитель на крыше своей машины обычно не едут. Control Flow: Водитель -> Машина -> Пассажир Водитель контролирует весь процесс сам. Он здесь главный. Пассажир инверирует своё желание поводить машину и вместо этого наоборот отдаёт контроль над своей перевозкой и жизнью трамваю и водителю. Желание "поуправляю сам" инвертируется в обратное "пусть поуправляют мной". Это и есть его инверсия контроля над своей жизнью. Control Flow: Фреймворк (Laravel, Lumen) -> Проект (Controllers, Model) -> Библитека (Mailer, Logger, Blade)
Хорошо, гуглить умеешь. А ты хоть раз видел проекты на JQuery? Или знаком с тем фактом, что к ней можно подключать плагины, то бишь, библиотеки, по сути, завязанные на ее "API", пассивно работающие в ее окружении. А насчет того, какая у нее степень инвазивности для проекта, в курсе? Я имею ввиду то, что она его буквально в себе растворяет, потому что так уж вышло, так она работает и из-за этого она почти весь JS заново реализует в себе. По названию таки библиотека, а по факту, ну...фреймворк? То есть JQuery библиотека. Но она, в итоге, "снаружи проекта", и, по твоей классификации, она фреймворк, у нее даже свои библиотеки есть, которые "внутри", но для проекта "ваще снаружи снаружи". Как так, Гуру? Ох уж эти извращенные фантазии, да?
в данном случае http можно заменить чем-то другим, важно что фреймворк в примере только один, и "control flow" тоже один. Так что должно быть снаружи, а что внутри, что бы фреймворк перестал быть либой и занял свое законное место рядом с кодом? Пока я понял что должны быть некие папочки и обвязка запуска кода лежащих в них, дающих нам правильный, фреймворкский "control flow". Но есть тьма примеров, когда никаких папочек нет, наш код стартует этот самый "control flow", но сути дела это не меняет. Посему, согласно аксиоме эскобара, оба варианта той самой фразы имеют одинаковую ценность )
Отличный пример. В простейшем случае http.Server достаточно для примитивного сервера для вывода одностраничника: Код (Javascript): const http = require('http'); const server = http.createServer((req, res) => { res.send('Hello, World!'); }); server.listen(80); Рабочий сервер, но пока примитивный. Но как каркас (фреймворк) для одностраничников он уже сойдёт. Если в проекте страниц больше одной, то придётся дописывать маршрутизатор: Код (Javascript): const http = require('http'); const homeController = (req, res) => { res.send('Hello, World!'); }; const server = http.createServer((req, res) => { if (req.pathname === '/') { return homeController(req, res); } else { res.statusCode = 404; res.header('Content-Type', 'text/plain'); res.write('Not Found'); res.end() } }); server.listen(80); Так уже веселее и работать можно уже полноценно. Например, добавлять другие контроллеры: Код (Javascript): const http = require('http'); const sm = require('sitemap'); const homeController = (req, res) => { res.send('+12'); }; const sitemapController = (req, res) => { http.get('/api//posts', result => { // ... result.on('end', () => { let posts = JSON.parse(result.data); let sitemap = sm.createSitemap({ urls: posts.map(post => { return {url: post.url, changefreq: 'daily'} }) }); res.header('Content-Type', 'application/xml'); res.write(sitemap.toString()); res.end() }) }); }; const server = http.createServer((req, res) => { if (req.pathname === '/') { return homeController(req, res); } else if (req.pathname === '/sitemap.xml') { return sitemapController(req, res); } else { res.statusCode = 404; res.header('Content-Type', 'text/plain'); res.write('Not Found'); res.end() } }); server.listen(80); Но для удобства и гибкости можно дописать свой роутер и добавить обработку ошибок: Код (Javascript): const http = require('http'); const router = require('./router'); router.get('/', (req, res) => { res.send('Hello World!'); }); router.get('/about', (req, res) => { res.send('My Company'); }); const server = http.createServer((req, res) => { let controller = router.parse(req); if (controller) { try { controller(req, res); } catch (e) { res.statusCode = 500; res.header('Content-Type', 'text/plain'); res.write(e.message); res.end() } } else { res.statusCode = 404; res.header('Content-Type', 'text/plain'); res.write('Not Found'); res.end() } }); server.listen(80); Вот так комплект из http.Server с нашим маршрутизатором стал полноценным каркасом для разработки приложений. А каркас в переводе на английский - это как раз и есть фреймворк. И теперь этот большой коллбэк можно вынести в файл app.js: Код (Javascript): const http = require('http'); const router = require('./router'); const createApp = require('./app'); router.get('/', (req, res) => { res.send('Hello World!'); }); const app = createApp(router); const server = http.createServer(app); server.listen(80); Или даже сам http передать внутрь app: Код (Javascript): const http = require('http'); const router = require('./router'); const createApp = require('./app'); router.get('/', (req, res) => { res.send('Hello World!'); }); const app = createApp(http, router); app.listen(80); Или даже не передавать, а перенести все require в app.js: Код (Javascript): const superapp = require('./app'); const app = superapp(); app.get('/', (req, res) => { res.send('Hello World!'); }); app.listen(80); Можем теперь сравнить с express: Код (Javascript): const express = require('express'); const app = express(); app.get('/', function (req, res) { res.send('Hello World!'); }); app.listen(80); Совпадение? Не думаю В итоге что у нас есть в промежуточном коде: Код (Javascript): const http = require('http'); const router = require('./router'); const sm = require('sitemap'); router.get('/', sitemapController); const server = http.createServer((req, res) => { let controller = router.parse(req); if (controller) { try { controller(req, res); } catch (e) { res.statusCode = 500; res.header('Content-Type', 'text/plain'); res.write(e.message); res.end() } } else { res.statusCode = 404; res.header('Content-Type', 'text/plain'); res.write('Not Found'); res.end() } }); const sitemapController = (req, res) => { http.get('/api//posts', result => { // ... result.on('end', () => { let posts = JSON.parse(result.data); let sitemap = sm.createSitemap({ urls: posts.map(post => { return {url: post.url, changefreq: 'daily'} }) }); res.header('Content-Type', 'application/xml'); res.write(sitemap.toString()); res.end() }) }); }; server.listen(80); У нас есть: - Внешний фреймворк, состоящий из сервера http.Server c объектами Request, Response и дописанной библиотеки Router. - Внутрь в роутер этого фреймворка мы подсовываем контроллеры своего проекта. И фреймворк будет их вызывать. - Внутри контроллера sitemapController код проекта уже дёргает методы библиотек sitemap, http.Client или axios. Фреймворк вызывает контроллеры с нашим кодом, а наш код дальше вызывает библиотеки. В итоге: - http.Server наедине - уже можно назвать примитивнейшим фреймворком для одностраничников. - Связка http.Server + Router + App - самодельный полноценный фреймворк для любых проектов. - Express - готовый полноценный фреймворк для любых проектов. - http.Client, Sitemap и Router - узкоспециализированные библиотеки. А http, как видим, является сборником всего подряд.
Есть библиотеки Monolog, Twig, SwiftMailer и тысячи других, к которым можно подключать плагины. Касательно окружения: у многих людей получается одновременно быть сыном для папы и папой для сына, но никто всё равно в иерархии не путается. Плагины к jQuery в основном только присваивают себя как коллбэки jQuery.fn.slider = function (...) лишь чтобы их вызывали по $('#div').slider(). Ну расскажите, как Вы ставите jQuery, как пишете для неё контроллеры, как она бутстрапирует и запускает ваш проект, как сама маршрутизирует запросы. В большинстве проектов jQuery используют лишь как хэлпер для короткого вызова: Код (Javascript): $('.div').hide(); вместо длинного нативного: Код (Javascript): document.getElementsByClassName('div').forEach(function (elem) { elem.style.display = 'none'; }); или для $('#div').on(...) вместо document.getElementById('div').addEventListener(...). И никакой добавочной интеллектуальной пользы не несёт. Ну расскажите нам про суть и различия IoC, DIС и DIP.
Тот дирижёр, который бутстрапирует проект, организовывает процесс и является обвязкой запуска основного нашего кода - то и есть фреймворк. Кто является только исполнителем, который умеет только играть на скрипке или отправлять письма вроде SwiftMailer - тот библиотека. А разбито по папкам или скинуто в одну кучу - не важно. Если наделать просто кучу .html и .php - файлов, перелинковать в <a href="/about.html"> и закинуть на хостинг, чтобы их открывал напрямую Apache - то это проект без фреймворка. Если же поставить Laravel и подсунуть эти файлы в требуемые им контроллеры и представления и прописать маршруты - это тот же проект, но уже под контролем фреймворка. Если у нас эти файлы в public/index.php обслуживает наш код с if { } else if или switch($url), то по сути этот index.php и есть наш самописный фреймворк. --- Добавлено --- У кареты пассажир внутри кареты, а водитель - снаружи.
т.е. любой event dispatcher является фреймворком? А если я к примеру завяжусь на pub/sub редиса, можно ли будет его назвать фреймворком? А крон который стартанет такс в определенное время? И да, тут вроде все в курсе как на js работают фреймворки и что с ними можно делать. --- Добавлено --- О боже мой. Это какие-то священные запретные знания?
Валит! Валит препод! Можеттри? Блин... Ну надо же в разговоре занять типа более авторитетную позицию, встав в менторскую позу Гуру демагогии, что с него взять. Надо проверить, может в видеоуроках где-то есть. Не найдём, надо будет звонить Возняку лично.
Не знаю как у Вас, а у меня flow выполнения всегда такой: Код (Text): HTTP Request └─> Server (Nginx, Apache) Libraries: └─> Framework (App) ─────────────────────────────────> (Router, Logger) └─> Controller (SignUpController) ────────────> (Router, Twig, Logger) └───> Model (SignUpService, User) ────> (Doctrine, Mailer) Если не считать сервера, то фреймворк в коде как раз и является самым внешним шлюзом, в который прилетает запрос. Фреймворк уже его принимает, парсит, маршрутизирует и пробрасывает дальше внутрь и вправо в наш контроллер. Контроллер вызывает модель с бизнес-логикой, которая создаёт пользователя и библиотеками Doctrine и Mailer записывает в БД и отправляет письмо подтверждения. Дальше контроллер либо вызывает рендер представления вызовом библиотеки шаблонизатора, либо при успехе редиректит на адрес, сгенерированный роутером. Так по схеме и получается, что через внешне запущенный фреймворк запрос проходит внутрь до бизнес-логики и добирается до отправки почты вызовом мэйлера.