Here's my genuine question: it seems like the term 'static site' means something different from my understanding of it in the 00's-a plain HTML page with no server side processing (PHP, ASP, Coldfusion, etc). Is this correct? What exactly are these static sites and why does one need to be "generated" versus crafting your own markup? Time and efficiency or is there more under the hood than I understand?
Thanks!
* include it in the main page
* update the RSS feed
* include it in all the category/tag listings
* if you have prev/next article links, you have to add it to the last article
* included images need to be prepared for web
* if you show a code example, you might want to syntax-highlight it
If you want to change the design, you have to touch all pages (or do search/replace and hope that it doesn't mess anything up)
...
Or you could have a program that you feed text + raw images for your articles and that automatically generates all the necessary files/changes old ones accordingly, based on this input and templates.
The result then can be served by web server that doesn't speak any server-side language.
I do remember a time when the expression "dynamic HTML" was popular to designate HTML+JS. Therefore, "static" may have been used in contrast to "dynamic" to designate plain HTML pages indeed. This is not the case now.
I remember this being a MASSIVE pain. Managing that is a huge benefit. Thanks for the explanation!
They are best when building landing pages, corporate sites, or simple blogs. It's cleaner, lighter and more maintainable than solutions like wordpress, drupal or most cms
Explain they are a doctor/lawyer/trader/etc & they don't want to spend hours getting their site just right & keeping it updated & hacked-free. Put them on a monthly retainer for $X and now you're building up repeat business.
WP is over-used in our industry and I like to see people looking at other options & explaining these to non-tech clients.
Also worth mention is Zoltonic which is an Erlang thing (iirc it also works with Elixir). I've found it pretty easy to get set up with my very baisc understanding of Erlang.
Unfortunately, in the mind of the client static=easy=worth less
The `curl -O https://download.sculpin.io/sculpin.phar` is what you are looking for - call that phar file instead of calling the composer.phar. That's where composer is "embedded"
I'm guessing the embedded Composer may also ignore any locally-set Composer configuration on the dev's own copy of Composer.
One assumes the Sculpin devs do like/appreciate Composer's functionality, since they embed it, but they've opted not to advocate direct use of its interface at all.
I don't mean to be overly critical, it just struck me as somewhat bizarre.