31–40 of 221 posts
I can definitely hand generate the small amount of content in it and could work out the contact form easy enough, but having no experience with websites don't know where to start with things like hosting, etc.
Hopefully can learn something here.
I’m skeptical cheap and easy is something inherent with static sites. I think a dynamic setup can have both those qualities, but there isn’t yet CMS/blog software that hits the sweet spot: self-contained, simple to setup, manage, and host.
Indeed. These days we have 24x7 net connections on both our mobiles as well as home LAN/desktop whatever, but you still can't get a single, 1-click, drop-dead simple program that you can use to both author as well as serve web-pages and images right from your own device. Thanks largely to dynamic IPs, NAT, firewalls, ISP upstream throttling and developer apathy (since their livelihood may depend on the complexity of…
People used to do this in the 90s and early 2000s, but it turned out to be a hilariously bad idea security-wise. Even the enthusiasts these days use a dedicated server somewhere in a datacenter. Services like Github Pages and Cloudflare exist for a reason, and it isn't because anyone is trying to gatekeep web hosting.
Earlier quoted context omitted.
Static makes so much sense for sole-author sites with technical owners. Would be great to make the tech more accessible to those without the skills to recompile and deploy. It's such a fast and affordable way to build websites, but existing tools like Hugo assume a lot from users that can put the tooling out of reach. (Enjoyed your write-up too. I wrote the original version of html-to-markdown that you used in your m…
Products like [decap CMS]( https://github.com/decaporg/decap-cms ) try to bridge that gap, but I agree that this space needs to be further developed. In fact I think there needs to be a bunch more work to allow mere mortals to use version control and branch workflows in day to day work.
https://tina.io/blog/Introducing-Editorial-Workflow-Features...
We need more like this that doesn't require a SaaS-backed "business or enterprise plan", though.
I’m skeptical cheap and easy is something inherent with static sites. I think a dynamic setup can have both those qualities, but there isn’t yet CMS/blog software that hits the sweet spot: self-contained, simple to setup, manage, and host.
There is no custom executable to run, there is no need for authentication, there is no need to write files to disk, there is no need to parse user-provided content, there is no need to access a database, there are no custom libraries to update... A static website can literally be "upload and forget", and that simply isn't the case for dynamic sites.
Big fan of NextJS and its static page export for that reason. I build and deploy just static .html/.js/.css to whatever CDN or static webserver of my choice. Since all indivudual pages/routes are pre-rendered during build, the first load is blazing fast and indexable by search engines. Also the way NextJS chunks the .js code and pre-loads contributes to the fast-load experience. For rich functionality you can interfa…
This is incredibly complex for many static site use cases (i.e. blogs, documentation, marketing pages). Most don’t need JavaScript let alone React/JSX/Middleware/SSR/et al. I can’t imagine the long-term maintenance of something with so many moving parts and npm dependencies. Not saying there’s not a use case, but we should KISS before jumping to projects with a 1.8 GiB Git checkout & 828,128 LoC just to make a landin…
I personally don't care for the size of my node_modules folder, storage is cheap. Plus, with a yarn.lock or package.lock you don't have to care about npm dependencies, if you don't upgrade any, your simple `yarn install && next build && next export` will always produce the same result for years to come. The actual export output of NextJS is amongst the smallest you can get - you also get a nice summary of how big the initial load is for every route.
Everything is chunked per route, all js chunks and assets contain their hash in the filename. That is why you can serve all of /_next/static with the `Cache-control: immutable`. This means if you don't update a section of your app, there is not even a need for the client to send GET requests with the `If-modified-since`, means: No additional roundtrip for any chunks. Preloading can be configured, by default its on-link-hover - that is, if your user hovers over a hyperlink/route, nextjs will already fetch the required chunks for that route before the click happens.
Yes, NextJS is not competing with Hugo or other static site generators. It is aimed at tech-savvy people, and only for webapps that will require programming JS.
As an "outsider" who dabbles in wasm I never understood why running custom code on the server to generate "dynamic" webpages would be better then a dumb server which just serves files, and the dynamic part is running in the browser instead (other then that 90's web browsers sucked for this type of stuff). E.g. nothing will ever beat a dumb file server with a cdn in front when it comes to simplicity and scalability.
Not everything can be done in a browser. You might want to store user-submitted content in a database, for example. Or you might want to do authentication. You might want to provide full-text search in a multi-gigabyte dataset. You might want to provide an interface to something which can't be accessed from a web browser. You might want to validate user-provided input. All of those require custom code running on a se…
PS: how complicated that is all depends on the library ecosystem IMHO.
Big fan of NextJS and its static page export for that reason. I build and deploy just static .html/.js/.css to whatever CDN or static webserver of my choice. Since all indivudual pages/routes are pre-rendered during build, the first load is blazing fast and indexable by search engines. Also the way NextJS chunks the .js code and pre-loads contributes to the fast-load experience. For rich functionality you can interfa…
Highly recommended if you want a low maintenance rock solid transmit only website.
Besides my blog, Pianojacq.com is set up much along the same lines, but there is a major difference, it interacts heavily with peripherals (MIDI) and needs a database (locally, not remotely), the end result is a highly interactive but still 100% static website.
As an "outsider" who dabbles in wasm I never understood why running custom code on the server to generate "dynamic" webpages would be better then a dumb server which just serves files, and the dynamic part is running in the browser instead (other then that 90's web browsers sucked for this type of stuff). E.g. nothing will ever beat a dumb file server with a cdn in front when it comes to simplicity and scalability.
I've had sites where I just write in Markdown and rsync it to a webserver. All pages were rendered dynamically. The advantage was that I set it up once then literally never care about a website again and just write in my beloved Markdown. It was great. Until the webhost took away PHP anyway.
If you use Jekyll as static site generator and GH Pages for hosting, it even works out of the box (eg no GH Action tinkering needed, just flip a switch in the GH project settings)
But arguably, a local static site generator workflow works just as well (convert to html locally and upload those files to web hoster instead).
Earlier quoted context omitted.
Indeed. These days we have 24x7 net connections on both our mobiles as well as home LAN/desktop whatever, but you still can't get a single, 1-click, drop-dead simple program that you can use to both author as well as serve web-pages and images right from your own device. Thanks largely to dynamic IPs, NAT, firewalls, ISP upstream throttling and developer apathy (since their livelihood may depend on the complexity of…
Exposing your home devices to the internet is a really bad idea , because it exposes you to doxxing, DDoSing, whatever security issues your 5-year-old smartphone may have, and a plethora of other risks. People used to do this in the 90s and early 2000s, but it turned out to be a hilariously bad idea security-wise. Even the enthusiasts these days use a dedicated server somewhere in a datacenter. Services like Github P…