6 ms·

Dynamic content.

vatotemking 10y ago
Underrated comment. To expand on this, static website generators are best for generating documentation and small blogs. It falls apart when you have a large often-changing content. This is where PHP is still king of the web.
- guitarbill 10y ago
  > large often-changing content. This is where PHP is still king of the web. PHP is still widely used, but there's a myriad of other contenders: Java, ASP.NET, Python (Django,Flask,etc), Ruby (Rails), Perl, Javascript (Node,etc) and others. I'm not sure about PHP being the "king". PHP might be the most widely deployed thanks to either FB or the huge number of legacy bulletin boards and wordpress sites, but in terms of new deployments does it still dominate? Probably not. (For novices, a static site generator is definitely the way to go, until you run into it's limitations.)
  - vatotemking 10y ago
    Youre right. I think JS has taken over the title, for better or for worse. Even WordPress is migrating to JS with its front end.
  - nucleardog 10y ago
    All of the languages you listed have a way steeper learning curve than PHP. PHP creates a lot of really small steps you can take getting from "I roughly understand HTML" to "I can build a full 3-tier MVC buzzword-of-the-day app.". For anyone not intending to become a full-fledged programmer, but instead just to add a little bit of interactivity/dynamism to their website, it's still the path of least resistance.
    - guitarbill 10y ago
      I'd argue that Javascript (sans all the frameworks and bullshit) will also get you there quicker, because of the intrinsic DOM connection. But yes, backend JS sucks. I also made a start with PHP. Still, PHP has been slow to learn from other languages and frustratingly refused to change established behaviour. I found PHP to be far more "dangerous" for the amateur programmer than other languages. Finally, I switched and never looked back. From teaching beginners, I actually think Python + Flask has a similarly shallow learning curve, but more room to grow and to "do it correctly" (e.g. the templating is much cleaner and the routing much more powerful). I recommend it.
      - spronkey 10y ago
        echo "<h1>hello</h1>" vs... damn, how do you even print a line in Javascript (Node, to be fair)? console.log()? Wait no, that prints to a terminal. Response.write? Oh, wait, I have to implement the http.createServer callback? Yeah ok, oh and it's ... response.print? No, no it's response.write. Oh what it's not working? Oh I need response.end() as well. Hopefully you get the point. (I do agree that PHP without something like Symfony, Yii, ... Laravel, even Cake could be very dangerous, or at least, counter-productive for amateurs trying to learn though)
- foolinaround 10y ago
  > It falls apart when you have a large often-changing content. Today, when one can have workflows via jekyll/git/Continuous deployment, at what frequency of "often-changing" should one move away from static websites to a php based solution?
  - vatotemking 10y ago
    I haven't tried jekyll so I can't really comment on it. Im guessing it only generates the changed files everytime you push to git, no? As for your question, it depends on other factors too. Who are your users, what is your web app, is it an ecommerce site? Is the jekyll/git/CI workflow easier than just pressing a few buttons on the screen everyday? Those are the questions you should ask. jekyll might be obvious for us devs but we are a minority compared to the rest of the population.
  - bbcbasic 10y ago
    Take HN as an example. This can't be done as a static site. Or a simple guestbook or hit counter. Where the lines may blur is JS front end talking to a BaaS... This may make it possible to glue up impressive sites using just HTML and JS with no custom backend requirement.
apotheon 10y ago
For many use cases, this is not relevant to the end result. For many use cases where it is relevant, static site generators like Jekyll can actually imitate "dynamic content" from the perspective of the people running the site. The most important use cases for dynamic content these days are web applications, as distinct from "websites". On the other hand, web applications are also the most important use cases for better development ecosystems than are easily attained with PHP. In my experience and observations, the cases where PHP's easy provision of dynamic content capabilities make the most difference are websites (as distinct from "web applications") on shared hosting platforms or bootstrapped by existing content management systems like WordPress and Drupal (which are, in turn, often easily used because of either hosting platforms specifically for those CMSes or shared hosting providers). NOTE: I'm not sneering at "websites", as distinct from "web applications", as many people who draw such distinctions do. I'm just pointing out there is a distinction to be made between two different types of projects involving deployment of a codebase to a web server. Speaking only of the technology's proximate purpose: in one of these, the primary purpose of it is to make content accessible to the public; in the other, the primary purpose is to make functionality accessible to a userbase.

Dynamic content.

Underrated comment. To expand on this, static website generators are best for generating documentation and small blogs. It falls apart when you have a large often-changing content. This is where PHP is still king of the web.

guitarbill 10y ago
> large often-changing content. This is where PHP is still king of the web. PHP is still widely used, but there's a myriad of other contenders: Java, ASP.NET, Python (Django,Flask,etc), Ruby (Rails), Perl, Javascript (Node,etc) and others. I'm not sure about PHP being the "king". PHP might be the most widely deployed thanks to either FB or the huge number of legacy bulletin boards and wordpress sites, but in terms of new deployments does it still dominate? Probably not. (For novices, a static site generator is definitely the way to go, until you run into it's limitations.)
- vatotemking 10y ago
  Youre right. I think JS has taken over the title, for better or for worse. Even WordPress is migrating to JS with its front end.
- nucleardog 10y ago
  All of the languages you listed have a way steeper learning curve than PHP. PHP creates a lot of really small steps you can take getting from "I roughly understand HTML" to "I can build a full 3-tier MVC buzzword-of-the-day app.". For anyone not intending to become a full-fledged programmer, but instead just to add a little bit of interactivity/dynamism to their website, it's still the path of least resistance.
  - guitarbill 10y ago
    I'd argue that Javascript (sans all the frameworks and bullshit) will also get you there quicker, because of the intrinsic DOM connection. But yes, backend JS sucks. I also made a start with PHP. Still, PHP has been slow to learn from other languages and frustratingly refused to change established behaviour. I found PHP to be far more "dangerous" for the amateur programmer than other languages. Finally, I switched and never looked back. From teaching beginners, I actually think Python + Flask has a similarly shallow learning curve, but more room to grow and to "do it correctly" (e.g. the templating is much cleaner and the routing much more powerful). I recommend it.
    - spronkey 10y ago
      echo "<h1>hello</h1>" vs... damn, how do you even print a line in Javascript (Node, to be fair)? console.log()? Wait no, that prints to a terminal. Response.write? Oh, wait, I have to implement the http.createServer callback? Yeah ok, oh and it's ... response.print? No, no it's response.write. Oh what it's not working? Oh I need response.end() as well. Hopefully you get the point. (I do agree that PHP without something like Symfony, Yii, ... Laravel, even Cake could be very dangerous, or at least, counter-productive for amateurs trying to learn though)
foolinaround 10y ago
> It falls apart when you have a large often-changing content. Today, when one can have workflows via jekyll/git/Continuous deployment, at what frequency of "often-changing" should one move away from static websites to a php based solution?
- vatotemking 10y ago
  I haven't tried jekyll so I can't really comment on it. Im guessing it only generates the changed files everytime you push to git, no? As for your question, it depends on other factors too. Who are your users, what is your web app, is it an ecommerce site? Is the jekyll/git/CI workflow easier than just pressing a few buttons on the screen everyday? Those are the questions you should ask. jekyll might be obvious for us devs but we are a minority compared to the rest of the population.
- bbcbasic 10y ago
  Take HN as an example. This can't be done as a static site. Or a simple guestbook or hit counter. Where the lines may blur is JS front end talking to a BaaS... This may make it possible to glue up impressive sites using just HTML and JS with no custom backend requirement.

apotheon 10y ago

For many use cases, this is not relevant to the end result. For many use cases where it is relevant, static site generators like Jekyll can actually imitate "dynamic content" from the perspective of the people running the site. The most important use cases for dynamic content these days are web applications, as distinct from "websites". On the other hand, web applications are also the most important use cases for better development ecosystems than are easily attained with PHP. In my experience and observations, the cases where PHP's easy provision of dynamic content capabilities make the most difference are websites (as distinct from "web applications") on shared hosting platforms or bootstrapped by existing content management systems like WordPress and Drupal (which are, in turn, often easily used because of either hosting platforms specifically for those CMSes or shared hosting providers). NOTE: I'm not sneering at "websites", as distinct from "web applications", as many people who draw such distinctions do. I'm just pointing out there is a distinction to be made between two different types of projects involving deployment of a codebase to a web server. Speaking only of the technology's proximate purpose: in one of these, the primary purpose of it is to make content accessible to the public; in the other, the primary purpose is to make functionality accessible to a userbase.