So I haven't done web development since the early 2000's when I transitioned into becoming a technical PM and recruiter full time, nothing more than tweaking something in my blog theme (changing a font or a link color). Therefore, I am way behind the times.
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?
Static site generators are used to speed up the process of development in terms of being able to code it as you would a dynamic site, but "compiling" down to a production-ready static site with minified code. A lot of them allow you to do things like including partials, string interpolation, using middleware and pre-processors, etc.
if you write html files individually, you'll have to update the navigation of each file when you add a new page. Same issue with categories, tags etc. SSGs just make it a bit easier to manage that stuff, and provide a framework to add other functions - markdown support, rss, sitemaps etc
It's also cool because you can prototype on a static site and think about the design like it is dynamic (eg, not doing a cut and paste of page layout). Then the migration to a proper framework like Symfony, or Silex is much simpler as you can always move the templates over (but you'll still need some tweaking).
A static site still designates a site with no server-side processing, just serving of (static) content. As for it being plain HTML, no, it can be full of JS, videos, whatever, it's still static.
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.
Time and efficiency is the main point. Take a blog: if you write it entirely by hand and add an article, you now have to:
* 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.
Static site generators don't have server side processing.
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
I love sculpin! I'm biased (I wrote the original getting started guide).
Modern PHP is one of the best places to be doing web development in 2015.
PHP has a huge external perception bias from how awful it was up to 2011, and it doesn't help that 80% of PHP programmers you will run into are woefully unaware of modern PHP tools and techniques so they keep writing mangled messes.
Sculpin wraps the really nice templating engine Twig and you basically get all the features it provides, and the extensibility is really powerful. Sculpin let's you leverage all the components and packages for templates, i18n and perhaps more complex use cases.
I'm not sure why you want speed for generation of static content but if that is a constraint... I doubt that you will find better performance in node or ruby over PHP5.6 or PHP7.
So... PHP has the features, speed, and packages. What's the reason not to pick it? The syntax?
Speed would definitely play a part if I wanted to integrate any CI deployment for a large site. My experience with PHP was never very good in the past, and after switching to Node, I haven't looked back. It had an inconsistent API, was unpredictable, etc. But then again, it has been awhile since I've used it. If it has gotten better since then, that's awesome. I should take another look at it.
API is still inconsistent as hell, if you are curious.
Actually, I would say both blaming (a couple of years ago) and praising (right now) PHP are a matter of fashion and nothing more. PHP was and still is pretty simple and practical tool to use, but core developers were and still are making ridiculously stupid design choices which they generally think of as a "compromise" and which no other programming language designers I know of currently make. So, if you are looking for good design in a language — PHP is still a disaster, I assure you.
What actually changed for good is not the language itself (which has changed, but the quality is questionable anyway), but infrastructure. Now we have HHVM, Composer, better libraries (Sculpin being a nice example, by the way), FIG-standards. It's far from Node or Python in a sense of tools and libraries available, but significantly better than it was some 4 years ago. And deploying it is still much easier than Python, Ruby or Node, so that makes a reasonable choice overall.
> So, if you are looking for good design in a language — PHP is still a disaster, I assure you.
PHP is like an unholy blend of Python and JavaScript with Perl syntax rules. If there's some feature you like in one of these languages, PHP probably has a slightly-confusing variant of it.
It has first-class function support (more-or-less), closures, classic OO, dynamic OO, reflection, namespaces, exceptions, auto-resolution of missing classes, generators, iterators, something like eval(), etc.
For software that embeds Composer, it's a little odd that it's "quick start guide" and general installation instructions don't include a typical Composer-based installation option, or mention Composer usage at all, instead seemingly opting for quite a non-standard "sculpin.json/sculpin.lock"-based approach.
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"
No that's what I mean. Assuming you have Composer installed, and are accustomed to a Composer-centric workflow, running a curl command and then a separate phar file (albeit one containing Composer) is an unusual break from that.
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.
Freelancer Tip: This is a really good option for that professional who just wants a business card site & thinks they need WP so they can "update the content" on their $10,000+ professional design.
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.
I can get behind this. Hosting a WordPress is too inefficient for a website with just a /index /about and /contact.
Most businesses go without updating their websites for months/years, if we find a way to sell static websites to clients that would be a step forward.
Unfortunately, in the mind of the client static=easy=worth less
This is just a sales problem though - you don't sell a "static website" you sell the development, management and hosting of their site and that's where you build your margin.
If you need some content management and like Sculpin then check out Concrete 5, they're both based on Twig and Symfony components, but Concrete 5 has the CMS features you might expect a customer to ask for.
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.
28 comments
[ 3.0 ms ] story [ 82.2 ms ] threadHere'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!
I remember this being a MASSIVE pain. Managing that is a huge benefit. Thanks for the explanation!
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.
* 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.
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
Also, the speed of the language is completely irrelevant for a static site generator.
Modern PHP is one of the best places to be doing web development in 2015.
PHP has a huge external perception bias from how awful it was up to 2011, and it doesn't help that 80% of PHP programmers you will run into are woefully unaware of modern PHP tools and techniques so they keep writing mangled messes.
Sculpin wraps the really nice templating engine Twig and you basically get all the features it provides, and the extensibility is really powerful. Sculpin let's you leverage all the components and packages for templates, i18n and perhaps more complex use cases.
I'm not sure why you want speed for generation of static content but if that is a constraint... I doubt that you will find better performance in node or ruby over PHP5.6 or PHP7.
So... PHP has the features, speed, and packages. What's the reason not to pick it? The syntax?
Actually, I would say both blaming (a couple of years ago) and praising (right now) PHP are a matter of fashion and nothing more. PHP was and still is pretty simple and practical tool to use, but core developers were and still are making ridiculously stupid design choices which they generally think of as a "compromise" and which no other programming language designers I know of currently make. So, if you are looking for good design in a language — PHP is still a disaster, I assure you.
What actually changed for good is not the language itself (which has changed, but the quality is questionable anyway), but infrastructure. Now we have HHVM, Composer, better libraries (Sculpin being a nice example, by the way), FIG-standards. It's far from Node or Python in a sense of tools and libraries available, but significantly better than it was some 4 years ago. And deploying it is still much easier than Python, Ruby or Node, so that makes a reasonable choice overall.
PHP is like an unholy blend of Python and JavaScript with Perl syntax rules. If there's some feature you like in one of these languages, PHP probably has a slightly-confusing variant of it.
It has first-class function support (more-or-less), closures, classic OO, dynamic OO, reflection, namespaces, exceptions, auto-resolution of missing classes, generators, iterators, something like eval(), etc.
http://www.phptherightway.com is a good start. I would also look at the Symfony 2 framework and even try this as a learning resource: http://symfony.com/doc/current/create_framework/index.html
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.
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.
Unfortunately, in the mind of the client static=easy=worth less
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.