diff --git a/source/_posts/2019-09-13-live-blogging-symfonylive-london.md b/source/_posts/2019-09-13-live-blogging-symfonylive-london.md index 3dd63c21..b8f15951 100644 --- a/source/_posts/2019-09-13-live-blogging-symfonylive-london.md +++ b/source/_posts/2019-09-13-live-blogging-symfonylive-london.md @@ -317,6 +317,25 @@ framework: ## Feeling unfulfilled by SPA promises? Go back to Twig. (Dan Blows) +A way on the front-end JS, CSS, images at the beginning of the request, sends a HTTP request (XHR/AJAX) to the back-end + +## Why SPAs? +- A way on the front-end JS, CSS, images at the beginning of the request, sends a HTTP request (XHR/AJAX) to the back-end +- no full page refresh +- Supposed to be much quicker +- 'Right tool for the job' - JS on the front-end, PHP on the back-end +- Division of responsibility == faster development +- Reusable API - Api -> Mobile App and SPA - easy to add another consumer +- Easier to debug + +## Why not SPAs? +- Lots of HTTP requests (400 to load the initial page on one project) == slow front end +- Blurred responsibilities == tightly coupled teams +- harder to debug, bugs fall between systems and teams. Huge gap between front-end and back-end, passing responsibilites. +- You can fix these problems in SPAs, but is it worth it? + +## Using Twig as an alternative to an SPA? + ## BDD Your Symfony Application (Kamil Kokot) ## Migrating to Symfony one route at a time (Steve Winter)