4 ms·

> Or are we talking about writing sites in meta-languages, that have to be subjected to a translation process to yield code suitable for browsers? It's too lab

by n4bz0r 5y ago

> Or are we talking about writing sites in meta-languages, that have to be subjected to a translation process to yield code suitable for browsers? It's too laborous to handcraft each page, so people would use template engines and things like Markdown -> HTML converters so they would only edit the meaningful part of the page manually. Some also choose to compile a dynamic site into a static site. WordPress plugins allow for that, for instance. Doing so, you get all the advantages of a dynamic CMS, while keeping the ability to serve the site as a bunch of plain HTML files. The process of compiling would be the 'build' step you are wondering about.

denton-scratch 5y ago
Thanks for the reply. > all the advantages of a dynamic CMS I spent ten years making websites using Drupal, which I take it from your context counts as a "dynamic" CMS. FTR, my work was coding; I never got into the trade of making sites by glueing other people's modules together. Well, that kind of site development didn't involve a build step. You could modify the PHP code for a module, load the page in a browser, and immediately see the result of the change. The only things I can think of that required a build step were: * SASS * Some weird Google technology that I avoided like the plague (and that I believe is now considered obsolete) SASS was quite good for making it easier to understand CSS. The need for a build step was annoying, though. My colleagues were also working with some technology with a name beginning with 'R', that generated HTML on the fly, in the browser, using Javascript- not just using templates. I never engaged with it, and I couldn't read the generated code, because you couldn't view the page source. If "dynamic" means "the content comes from a database", as in Drupal or Wordpress, then I think my ignorance is excusable; a Drupal site would behave exactly the same if it consisted entirely of static HTML, JS and CSS. I once worked with a CMS that used a database to hold the content; but which required a "generate" step to turn the database content into static pages, which is what the site actually served. But that wasn't a "build" step, because it ran on the server in the background, every ten minutes or so. The submission page was a Java servlet, but the Java code only ran when you were submitting new content. The generated static pages could be dropped into the document-root of any HTTP server, including ones with no JRE. Of course, the "generate" step here was a convenience, but inessential; the servlet could have converted new content to static markup at the time of submission, rather than on a timer. It was just more efficient to do the whole site at once, rather than rendering each page at the time of submission. This was a large site, with tens of thousands of pages, and many, many comments per page. We considered it a static site.
- n4bz0r 5y ago
  > If "dynamic" means "the content comes from a database", as in Drupal or Wordpress "Dynamic" simply means that you aren't serving a static file from your server, but - in case with Wordpress and Drupal - pulling all the requests through a script that processes them, and returns generated plaintext data (HTML/XML/whatever) every time. If you move the response-generating script/software from your public web server, and only upload plain HTML files there, you get what's called a "static" site. If you don't get why people add an additional "build" step to turn their "dynamic" sites into "static" ones, here are a couple of common selling points: - You get to maintain less moving parts on your "production" server and reduce the load - You can get rid of your public server altogether, and host your "static" site on GitHub pages or a similar 3rd party service. In this scenario, content management and build process would take place on some other (remote or local, doesn't matter), "dynamic" server with the interpreter installed Hope that clears things up a bit. Edit: I failed to mention that most static site generators (I heard of) build the entire site at once. A snapshot of the site (an artifact) is being built, thus the "build step" naming. Edit2: Removed some things that are besides the point.
  - denton-scratch 5y ago
    Thanks for the clear explanation. I understand why one would render the entire database to HTML; that's what we used to do on our servlet-based CMS. What I was unclear about was the static/dynamic terminology. Now it's clear.
    - amatecha 5y ago
      static: HTML, CSS, images, JS, all served from the server's filesystem to the site visitor over the network. no server-side code execution to generate the page content. dynamic: non-HTML server-side code (PHP, Perl, Ruby etc.) is evaluated/executed to generate site content which is then sent over the network to the site visitor. this may involve hitting databases to get content for the requested page, or even make network queries for integrations with other services (social media feeds, payment processor sessions, etc.). the server then returns the generated HTML to the visitor. I just realized these two Wikipedia articles summarize the two different approaches quite well: https://en.wikipedia.org/wiki/Static_web_page https://en.wikipedia.org/wiki/Static_web_page https://en.wikipedia.org/wiki/Dynamic_web_page https://en.wikipedia.org/wiki/Dynamic_web_page

by n4bz0r 5y ago

denton-scratch 5y ago

Thanks for the reply. > all the advantages of a dynamic CMS I spent ten years making websites using Drupal, which I take it from your context counts as a "dynamic" CMS. FTR, my work was coding; I never got into the trade of making sites by glueing other people's modules together. Well, that kind of site development didn't involve a build step. You could modify the PHP code for a module, load the page in a browser, and immediately see the result of the change. The only things I can think of that required a build step were: * SASS * Some weird Google technology that I avoided like the plague (and that I believe is now considered obsolete) SASS was quite good for making it easier to understand CSS. The need for a build step was annoying, though. My colleagues were also working with some technology with a name beginning with 'R', that generated HTML on the fly, in the browser, using Javascript- not just using templates. I never engaged with it, and I couldn't read the generated code, because you couldn't view the page source. If "dynamic" means "the content comes from a database", as in Drupal or Wordpress, then I think my ignorance is excusable; a Drupal site would behave exactly the same if it consisted entirely of static HTML, JS and CSS. I once worked with a CMS that used a database to hold the content; but which required a "generate" step to turn the database content into static pages, which is what the site actually served. But that wasn't a "build" step, because it ran on the server in the background, every ten minutes or so. The submission page was a Java servlet, but the Java code only ran when you were submitting new content. The generated static pages could be dropped into the document-root of any HTTP server, including ones with no JRE. Of course, the "generate" step here was a convenience, but inessential; the servlet could have converted new content to static markup at the time of submission, rather than on a timer. It was just more efficient to do the whole site at once, rather than rendering each page at the time of submission. This was a large site, with tens of thousands of pages, and many, many comments per page. We considered it a static site.

n4bz0r 5y ago
> If "dynamic" means "the content comes from a database", as in Drupal or Wordpress "Dynamic" simply means that you aren't serving a static file from your server, but - in case with Wordpress and Drupal - pulling all the requests through a script that processes them, and returns generated plaintext data (HTML/XML/whatever) every time. If you move the response-generating script/software from your public web server, and only upload plain HTML files there, you get what's called a "static" site. If you don't get why people add an additional "build" step to turn their "dynamic" sites into "static" ones, here are a couple of common selling points: - You get to maintain less moving parts on your "production" server and reduce the load - You can get rid of your public server altogether, and host your "static" site on GitHub pages or a similar 3rd party service. In this scenario, content management and build process would take place on some other (remote or local, doesn't matter), "dynamic" server with the interpreter installed Hope that clears things up a bit. Edit: I failed to mention that most static site generators (I heard of) build the entire site at once. A snapshot of the site (an artifact) is being built, thus the "build step" naming. Edit2: Removed some things that are besides the point.
- denton-scratch 5y ago
  Thanks for the clear explanation. I understand why one would render the entire database to HTML; that's what we used to do on our servlet-based CMS. What I was unclear about was the static/dynamic terminology. Now it's clear.
  - amatecha 5y ago
    static: HTML, CSS, images, JS, all served from the server's filesystem to the site visitor over the network. no server-side code execution to generate the page content. dynamic: non-HTML server-side code (PHP, Perl, Ruby etc.) is evaluated/executed to generate site content which is then sent over the network to the site visitor. this may involve hitting databases to get content for the requested page, or even make network queries for integrations with other services (social media feeds, payment processor sessions, etc.). the server then returns the generated HTML to the visitor. I just realized these two Wikipedia articles summarize the two different approaches quite well: https://en.wikipedia.org/wiki/Static_web_page https://en.wikipedia.org/wiki/Static_web_page https://en.wikipedia.org/wiki/Dynamic_web_page https://en.wikipedia.org/wiki/Dynamic_web_page