4 ms·

Literally ANY host that gives you an FTP drop works for static sites. Bluehost Dreamhost Namecheap Godaddy Mom and Pop's Web Hosting Shop etc etc Not sur

by tomc1985 10y ago

Literally ANY host that gives you an FTP drop works for static sites. Bluehost Dreamhost Namecheap Godaddy Mom and Pop's Web Hosting Shop etc etc Not sure why such a topic needs more than about 1 paragraph's worth of commentary. Why does this guy needs support for all these fancy features? It's a static site! Do people simply not pay attention to history? Leave it to the "hackers" to complicate something as simple as static hosting.

rybit 10y ago
So static sites really have come a long way from the 1994 geocities versions. There are people that statically build sites with 1000's of pages. The idea is that you don't need to have the whole backend that we've all built before is growing (look at things like the serverless movement). As soon as you have to do more than a junk website that you check occasionally and care about the actual user experience you need to start considering things like CDNs, cache invalidation (global consistency matters) and C/D integrations. This is why you have a growth of static site hosting services (and hence the article). Some good references: http://www.staticgen.com/ http://www.staticgen.com/, http://jamstack.org/ http://jamstack.org/, https://www.smashingmagazine.com/2015/11/modern-static-website-generators-next-big-thing/ https://www.smashingmagazine.com/2015/11/modern-static-websi... also (talking about 1994 sites): http://www.warnerbros.com/archive/spacejam/movie/jam.htm http://www.warnerbros.com/archive/spacejam/movie/jam.htm is alive
- tomc1985 10y ago
  Those are ages-old issues that have had solutions before the creation of all this fancy tooling. You can invalidate cache with fake (ignored) URL parameters (http://foo.html?hello http://foo.html?hello) or HEAD section declarations. CDNs are no different, your links simply point elsewhere. Presumably some finishing script could capture your CDN'd data and copy everything to the appropriate place. How does continuous delivery integration even have anything to do with transferring files to a hosting drop? How is it that an FTP drop is insufficient for integration testing? A static site host is simply a webserver returning the HTML file you requested, nothing more and nothing less. Everything relevant that the server returns is under the control of the developer who made the page. The things you describe are value-adds; or, as I like to call them: crutches.
  - rybit 10y ago
    Absolutely you can solve this all with your own code. It is totally reasonable. But it is your own code. Which means dev cost & maintenance. Hence there are services for it. Could you set up your own DB? rack and stack your own servers? Absolutely, but AWS is way easier. It is about letting the developer work on the part that matters; not rote problems that have been solved. To specifically address your cache invalidation. (1) you have to manually invalidate _each_ resource. And you have to do that atomically or you run into issues surrounding different versions globally. (2) you release each of your resources to a versioned destination (e.g. <img src="v2/stupidimage.jpg"> -> <img src="v3/stupidimage.jpg">). Again, yes it is straight forward (not to say easy) but it it tedious, error prone and really just annoying to do. Because you actually want to use something like the SHA-1 of the content (better cache hits). Again, you have an issue around the atomic behaviour of updating the site. And then you need to make sure that you set your headers right (which I always screw up). This is your E-Tag and cache control headers. This is to force the browser to do a conditional get request. And continuous delivery is about removing the person from pipeline of push -> deploy. That means that even if you have a script that does your FTP drop, you have to configure that. Easy enough in something like circleCI, travis, or (for the daring) jenkins. But you still have an issue surrounding the atomic actions. FTP uploads _take time_ if you're constantly serving traffic - this could lead to odd problems around "what does the customer see". Those are real issues for sites, usually unreported by the user (They just refresh - but it colors the "feeling" of your site). The other part about this is that it raises the barrier of entry into website development. Should you need a neckbeard and CS degree just to make a site for your mom? Hosting services like gitlab, github pages, netlify, s3 and the likes try to make it easier. Yes - you can solve this all yourself; there are a finite amount of checkboxes you need to...well..check. But like you don't really want to rack and stack all your own servers, do you really want to spend your time thinking about that?
    - tomc1985 10y ago
      I'll agree, cache crap was and still is a pain in the ass to deal with. On the dev cost and maintenance bit -- again, we're talking static sites. If it needs a database it's not static. If cache invalidation is such a big deal, presumably because you need it a ton for something, then I would ask if whatever you are working on is really static? Or is someone just shoehorning dynamic behavior into prerendered HTML? Is the site just incredibly high-traffic? My bigger beef is with this proliferation of unnecessary tooling, how little it actually does, and the amount of learning and knowledge required not just for the process the tool manages, but also for the tool itself and well as its problems. You have to practically be a neckbeard with a BS in big-company bullshit software engineering tools to make the right tooling choices -- not so different from the programming neckbeard (except she's closer to the metal--and the process). As an example, code that I inherited was configured to deploy with Capistrano... which was great, when it worked, but it would fail and all it was really doing was copying files to a new folder, symlinking the "current" folder to this new one, and restarting Apache (by the way-- here's a solution for your atomic copies). Sure, Capistrano abstracted deployment details away, but really, how many were there to begin with? Changing a couple development techniques and reducing deployment to a carefully-written 8-line shell script has eliminated nearly every problem we had related to deployment, reduced the architectural complexity of a part of our operations that we really do not want to care about, and given us something that can be taught to (and reasoned about by) new users in a matter of minutes -- all because we teach and stick close to the actual process of what we're doing. (It is WAAAAY easier to open up the script and say, "so this is where we copy the files over, this is where it decides which files are in the CDN, here's where it looks up that criteria..." than it is to try and guide new technical users through the thicket that is CI documentation)
jlgaddis 10y ago
I do understand the sentiment (my own first thought upon reading the title was "This is something I would've imagined reading 20 years ago!") but apparently it's kind of a fad nowadays to write your blog posts in Markdown, in a versioned repository, and use these tools to publish it to the server. FTP isn't nearly as cool today as it was when I published One of my first static sites circa 1997 (and that is truly a "static" site -- it hasn't been updated since 1998). Why do things the easy way? Everything old is new again, I guess.

rybit 10y ago

So static sites really have come a long way from the 1994 geocities versions. There are people that statically build sites with 1000's of pages. The idea is that you don't need to have the whole backend that we've all built before is growing (look at things like the serverless movement). As soon as you have to do more than a junk website that you check occasionally and care about the actual user experience you need to start considering things like CDNs, cache invalidation (global consistency matters) and C/D integrations. This is why you have a growth of static site hosting services (and hence the article). Some good references: http://www.staticgen.com/ http://www.staticgen.com/, http://jamstack.org/ http://jamstack.org/, https://www.smashingmagazine.com/2015/11/modern-static-website-generators-next-big-thing/ https://www.smashingmagazine.com/2015/11/modern-static-websi... also (talking about 1994 sites): http://www.warnerbros.com/archive/spacejam/movie/jam.htm http://www.warnerbros.com/archive/spacejam/movie/jam.htm is alive

tomc1985 10y ago
Those are ages-old issues that have had solutions before the creation of all this fancy tooling. You can invalidate cache with fake (ignored) URL parameters (http://foo.html?hello http://foo.html?hello) or HEAD section declarations. CDNs are no different, your links simply point elsewhere. Presumably some finishing script could capture your CDN'd data and copy everything to the appropriate place. How does continuous delivery integration even have anything to do with transferring files to a hosting drop? How is it that an FTP drop is insufficient for integration testing? A static site host is simply a webserver returning the HTML file you requested, nothing more and nothing less. Everything relevant that the server returns is under the control of the developer who made the page. The things you describe are value-adds; or, as I like to call them: crutches.
- rybit 10y ago
  Absolutely you can solve this all with your own code. It is totally reasonable. But it is your own code. Which means dev cost & maintenance. Hence there are services for it. Could you set up your own DB? rack and stack your own servers? Absolutely, but AWS is way easier. It is about letting the developer work on the part that matters; not rote problems that have been solved. To specifically address your cache invalidation. (1) you have to manually invalidate _each_ resource. And you have to do that atomically or you run into issues surrounding different versions globally. (2) you release each of your resources to a versioned destination (e.g. <img src="v2/stupidimage.jpg"> -> <img src="v3/stupidimage.jpg">). Again, yes it is straight forward (not to say easy) but it it tedious, error prone and really just annoying to do. Because you actually want to use something like the SHA-1 of the content (better cache hits). Again, you have an issue around the atomic behaviour of updating the site. And then you need to make sure that you set your headers right (which I always screw up). This is your E-Tag and cache control headers. This is to force the browser to do a conditional get request. And continuous delivery is about removing the person from pipeline of push -> deploy. That means that even if you have a script that does your FTP drop, you have to configure that. Easy enough in something like circleCI, travis, or (for the daring) jenkins. But you still have an issue surrounding the atomic actions. FTP uploads _take time_ if you're constantly serving traffic - this could lead to odd problems around "what does the customer see". Those are real issues for sites, usually unreported by the user (They just refresh - but it colors the "feeling" of your site). The other part about this is that it raises the barrier of entry into website development. Should you need a neckbeard and CS degree just to make a site for your mom? Hosting services like gitlab, github pages, netlify, s3 and the likes try to make it easier. Yes - you can solve this all yourself; there are a finite amount of checkboxes you need to...well..check. But like you don't really want to rack and stack all your own servers, do you really want to spend your time thinking about that?
  - tomc1985 10y ago
    I'll agree, cache crap was and still is a pain in the ass to deal with. On the dev cost and maintenance bit -- again, we're talking static sites. If it needs a database it's not static. If cache invalidation is such a big deal, presumably because you need it a ton for something, then I would ask if whatever you are working on is really static? Or is someone just shoehorning dynamic behavior into prerendered HTML? Is the site just incredibly high-traffic? My bigger beef is with this proliferation of unnecessary tooling, how little it actually does, and the amount of learning and knowledge required not just for the process the tool manages, but also for the tool itself and well as its problems. You have to practically be a neckbeard with a BS in big-company bullshit software engineering tools to make the right tooling choices -- not so different from the programming neckbeard (except she's closer to the metal--and the process). As an example, code that I inherited was configured to deploy with Capistrano... which was great, when it worked, but it would fail and all it was really doing was copying files to a new folder, symlinking the "current" folder to this new one, and restarting Apache (by the way-- here's a solution for your atomic copies). Sure, Capistrano abstracted deployment details away, but really, how many were there to begin with? Changing a couple development techniques and reducing deployment to a carefully-written 8-line shell script has eliminated nearly every problem we had related to deployment, reduced the architectural complexity of a part of our operations that we really do not want to care about, and given us something that can be taught to (and reasoned about by) new users in a matter of minutes -- all because we teach and stick close to the actual process of what we're doing. (It is WAAAAY easier to open up the script and say, "so this is where we copy the files over, this is where it decides which files are in the CDN, here's where it looks up that criteria..." than it is to try and guide new technical users through the thicket that is CI documentation)

jlgaddis 10y ago

I do understand the sentiment (my own first thought upon reading the title was "This is something I would've imagined reading 20 years ago!") but apparently it's kind of a fad nowadays to write your blog posts in Markdown, in a versioned repository, and use these tools to publish it to the server. FTP isn't nearly as cool today as it was when I published One of my first static sites circa 1997 (and that is truly a "static" site -- it hasn't been updated since 1998). Why do things the easy way? Everything old is new again, I guess.