I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
SPAs fit into the Progressive Web App movement which is about bringing native experience to web. So websites feel like mobile apps that have instant load time.
It can also involve service workers to fetch data in the background and also cache it esp like a feed of posts or photos.
What I like about a SPA is it can be served as a static site on GH Pages or Netlify (if you use a CI build step). So no speed and hosting and security issues that go with having a Node Express app. Just fast static assets served.
I recently moved a project from templating with Mustache to templating with Vue and the move meant I didn't have to think about low level DOM operations to find values on form elements and push the results to an output section. I get to focus on the variables as they are bound to HTML elements.
I do agree with your sentiment. Don't make a web app into a desktop app and don't break if JS can't run.
JS was designed for a philosophy of progressive enhancements. I have a JS book I read which emphasises this at the start. Yet many sites are blank with a warning to enable JS. And sometimes just a blank page! The obsession with JS means sites are unusable if you have an older browser or the developer used only the newest syntax and didn't use babel to get output that works pre-ES2016/ES6
I like using Jekyll for templating in general to avoid JS on the page. Or to just add JS to add sort or filter on say a table.
The main reason I guess I like JS whether SPA or not SPA is that there is no page load when you submit a form or like a photo etc. There is white screen flicker.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
For interest, I added Vue to my jquery mustache site using frontend code only. So adding a script tag loading vue.js and then using a script tag on my HTML page.
This was light as there was no build step and the site was not a SPA yet, just HTML pages with JS added on top. And I could have using jekyll to add consistency so I have Vue load in the head of each page.
And I could have broken my JS into standalone JS files so I can run tests and linting against them.
The thing about the SPA style is that it means you manage your JS deps using a package file and you then import that in each of your scripts. You treat them like modules like in a server side app like an API or CLI. The problem with the browser approach is there aren't imports, just script tags loaded in a certain order.
Having said that there is a newer syntax where a script tag is imported as a module and you can use import x as * from 'jquery' in a JS file and then use it on the frontend! I am have just not tried it yet. But it means better server side feel of development with the frontend usage without making it a SPA.
Instead, we should concentrate on the unique web selling points: its reach, which, more or less by definition, encompasses all native platforms, URLs, which are fantastically useful and don’t work in a native environment, and its hassle-free quality.
The problem with the browser approach is there aren't imports,
Besides type="module" bundlers were introduced to enable "modular JavaScript" - not to support SPA's. If you are using React/Vue your choice (webpack) is essentially made for you - but for anything else I find rollup.js a lot saner especially as it is built around ES2015 modules (esbuild is faster).
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
The part about not using Vue template on the frontend might make sense in certain cases like if you are making tables or you have SSR. But vue supports it and it means you can have a touch of vue to your site without rebuilding it as a SPA so it might still be worth it. Same goes for React and Preact especially. A SPA structure comes with safety but it also has a cost which is the point of the post.
What I meant by the module syntax is that I can use that to get the experience of writing JS tests and imports like in a SPA but without actually structuring as a SPA.
I have heard of Eleventy and Gatsby and others but haven't really tried them
But vue supports it and it means you can have a touch of vue to your site without rebuilding it as a SPA so it might still be worth it.
When using DOM HTML as a template you have to ship and execute runtime + compiler (93kB) rather than just the runtime (65kB) on the client.
When you use a build step to compile the template into a bundle you only need to ship the vue runtime to the client - this isn't the same as building an SPA. At the core of the original article is the notion that it should be a goal to ship and execute less JavaScript on the client.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
I it was pointed out earlier in this thread but there is a major misconception that SPAs are PWAs. A SPA can technically be a PWA, but honestly there is no justification for SPAs in the context of a well written PWA.
The service worker can eliminate the network latency, which means you can ditch the fat, out of shape, slow JavaScript that are popular fast food frameworks. love2dev.com/blog/pwa-spa/
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
SPAs fit into the Progressive Web App movement which is about bringing native experience to web. So websites feel like mobile apps that have instant load time.
It can also involve service workers to fetch data in the background and also cache it esp like a feed of posts or photos.
What I like about a SPA is it can be served as a static site on GH Pages or Netlify (if you use a CI build step). So no speed and hosting and security issues that go with having a Node Express app. Just fast static assets served.
I recently moved a project from templating with Mustache to templating with Vue and the move meant I didn't have to think about low level DOM operations to find values on form elements and push the results to an output section. I get to focus on the variables as they are bound to HTML elements.
I do agree with your sentiment. Don't make a web app into a desktop app and don't break if JS can't run.
JS was designed for a philosophy of progressive enhancements. I have a JS book I read which emphasises this at the start. Yet many sites are blank with a warning to enable JS. And sometimes just a blank page! The obsession with JS means sites are unusable if you have an older browser or the developer used only the newest syntax and didn't use babel to get output that works pre-ES2016/ES6
I like using Jekyll for templating in general to avoid JS on the page. Or to just add JS to add sort or filter on say a table.
The main reason I guess I like JS whether SPA or not SPA is that there is no page load when you submit a form or like a photo etc. There is white screen flicker.
Progressive Web Apps are great!
For interest, I added Vue to my jquery mustache site using frontend code only. So adding a script tag loading vue.js and then using a script tag on my HTML page.
This was light as there was no build step and the site was not a SPA yet, just HTML pages with JS added on top. And I could have using jekyll to add consistency so I have Vue load in the head of each page.
And I could have broken my JS into standalone JS files so I can run tests and linting against them.
The thing about the SPA style is that it means you manage your JS deps using a package file and you then import that in each of your scripts. You treat them like modules like in a server side app like an API or CLI. The problem with the browser approach is there aren't imports, just script tags loaded in a certain order.
Having said that there is a newer syntax where a script tag is imported as a module and you can use
import x as * from 'jquery'in a JS file and then use it on the frontend! I am have just not tried it yet. But it means better server side feel of development with the frontend usage without making it a SPA.That is a misconception that dates back to the App Shell Model.
The core technology for PWAs is ServiceWorker using the Cache to retain the essential parts of an (possibly MPA) web site for offline usage.
Developing Progressive Web Apps (PWAs) Course.
"bringing native experience to the web" is a fools errand.
Web vs. native: let’s concede defeat (2015)
Why Progressive Web Applications Are Not Single Page Applications
FYI: Eleventy was inspired by Jekyll but uses JS instead of Ruby.
That approach isn't recommended:
Why You Should Avoid Vue.js DOM Templates
Besides type="module" bundlers were introduced to enable "modular JavaScript" - not to support SPA's. If you are using React/Vue your choice (webpack) is essentially made for you - but for anything else I find rollup.js a lot saner especially as it is built around ES2015 modules (esbuild is faster).
I don't really understand. The website just tells good solutions, but not really against it.
Thanks for the links.
The part about not using Vue template on the frontend might make sense in certain cases like if you are making tables or you have SSR. But vue supports it and it means you can have a touch of vue to your site without rebuilding it as a SPA so it might still be worth it. Same goes for React and Preact especially. A SPA structure comes with safety but it also has a cost which is the point of the post.
What I meant by the module syntax is that I can use that to get the experience of writing JS tests and imports like in a SPA but without actually structuring as a SPA.
I have heard of Eleventy and Gatsby and others but haven't really tried them
When using DOM HTML as a template you have to ship and execute runtime + compiler (93kB) rather than just the runtime (65kB) on the client.
When you use a build step to compile the template into a bundle you only need to ship the vue runtime to the client - this isn't the same as building an SPA. At the core of the original article is the notion that it should be a goal to ship and execute less JavaScript on the client.
The "Developer Experience" Bait-and-Switch
Any opportunity to complete work at build time that reduces the amount of code needed at runtime should always be taken.
Time and time again Rich Hickey's observation proves to be accurate: Programmers know the benefit of everything and the tradeoffs of nothing.
Many tools are adopted to enhance the "developer experience" while the potential negative consequences downstream are either ignored or downplayed.
I see the solution as quite easy.
Use
*.vuefile, with Parcel. It will internally usevue-template-compiler.Do not put
<template>tag inside Jekyll.I actually followed an approach without a template element so could have skipped the compiler.
I just added v-model etc. to plain html and setup
new Vue(...)at the bottom.Here was the work in progress before moving to SPA
github.com/MichaelCurrin/badge-gen...
I did use vue-markdown tag though which I guess needs the compilation.
Thanks for sharing. I liked the video a lot.
I it was pointed out earlier in this thread but there is a major misconception that SPAs are PWAs. A SPA can technically be a PWA, but honestly there is no justification for SPAs in the context of a well written PWA.
The service worker can eliminate the network latency, which means you can ditch the fat, out of shape, slow JavaScript that are popular fast food frameworks.
love2dev.com/blog/pwa-spa/