321–330 of 333 posts
Earlier quoted context omitted.
You can run React (and everything else) off a CDN.
React runs in the browser. You probably mean serve the files off a CDN
Earlier quoted context omitted.
No, not a SPA. There is a concept of a single file app (SFA). You can share an html file, and that is the application. It can have inlined micro js/css frameworks, or hand-rolled everything. An SFA should be human readable though- viewing the page source is useful. I think it’s a concept worth exploring.
I prefer the denotation of a single file site (SFS). Perhaps alternatively a multi-paged file (MPF), as there might still be multiple such pages on a site, or a site comprised of a mix of MPFs, SPAs, and traditional static single-page URLs.
Earlier quoted context omitted.
If only the Web had a way to make text clickable withtout showing the whole target URL.
The reason is that trolls like to post links to shock sites or a google search for something terrible. Even worse, you could get rickrolled.
[1] http://futureasapresent.org/trinkwasser.html
[2] https://cleantechnica.com/2021/12/18/climate-change-impacts-...
Earlier quoted context omitted.
> Why not leverage and to show them in-place Searchability. You want footnote content to be Ctrl+F-able.
A smart browser could understand footnotes and show them in searches.
Earlier quoted context omitted.
I’d want templating if I’m going to make more than two pages on a site.
HTML has that built in: https://developer.mozilla.org/en-US/docs/Web/Web_Components/... You'd need some JS to make use of them though.
Lovely article and such an interesting way of creating single page apps. I never knew about this usage of the :target selector. I think a major issue with this approach is just practicability - I'd want to write my content in something like markdown and we will anyway need JS to convert the markdown to HTML. I have also been interested in making SPAs, my my way is more traditional. Using javascript for the stitching.…
I’m also more in favor for compiling the MD to HTML once and then serving pure HTML via the CDN. You could still keep it to the two steps you outlined in your blog post by running the build step and deployment using github actions.
Earlier quoted context omitted.
And now it's even less scalable to larger sites because you're forcing the eager loading of resources on pages you'll never click on.
If you are interested in building a single page site, I really doubt that scaling is an issue you'll have to contend with and seems like a waste to even consider it for something so small. If you get hung up scaling a single page, you have other problems
Earlier quoted context omitted.
Showing the capabilities of the web browser as an application target, directly. You have HTML, CSS, and JS available. No build tools required. Take this file and open it with a web browser. Then modify it, and refresh the browser. Distribution and Development for applications is about as straightforward and accessible as it gets.
But what benefit is there for the end user?