Hacker News Reader

Comment by ggregoire | Hacker News Reader

> "The one that allows you to improve the quality of your code with unit testing and type checking"

Wait, are we really talking about a static website?

I'm a big fan of React and all the JS ecosystem, but when I need a static website, I just make my bunch of html files (and I copy/paste the same header/footer on each), my css file, eventually 2 lines of JS directly in a <script> tag to toggle a menu on mobile devices, I upload it on S3/CloudFront and that's it.

View on HN

I think we are taking about websites that can be hosted on a static file server like Amazon S3/CloudFront, but which also have all the dynamic features of React available for building a rich and complex UX. For instance, when working with Phenomic (which uses Webpack), it's very easy to add any necessary React components to your project simply with npm install / yarn add. So it's really a marriage of Markdown based content publishing and interactive client-side UX.

I eternally have this misunderstanding. I think static means unchanging.

In this context, it means static HTTP responses, but dynamic HTML/DOM.

I want a word to mean really static.

Hello,

I'm in the core Phenomic team.

The idea in Phenomic is that we generate for each page:

- the HTML entry point, rendered like it would be with ReactDOMServer - the data-requirements of the page

That lets us offer the following: - Any page is accessible directly, without runtime (which has advantages regarding performance and SEO) - Navigation works even if JS is disabled - If JavaScript is enabled, the runtime just loads the minimum required data for the next page to display and renders it

Phenomic really is static, it just uses a few techniques that we learnt from the modern front-end development workflows and capabilities :)

Neat. Thanks for the info!

In this context some HTTP responses are static. The static part of the website.

But the React app can also start consuming all kinds of webservice.

This way (1) a large part of content can be served as prerendered static HTTP responses (HTML, CSS, JS). (2) Static content not initially loaded can be served as JSON (as seen in the presentation). And (3) dynamic content (e.g. real time comments or a chat) can be non-static (one or more webservices, possibly on WebSocket thereby going beyond HTTP).

I think this may be very interesting when "big mostly static content", "need for modern web tech" and "big traffic" meet.

Yes, the word static is a bit overloaded here.

Misused, rather. This is dynamic pages, client side.

I think the whole benefit of a static website generator in general is to avoid the "I copy/paste the same header/footer on each" step, especially copy-pasting the menu/header, as your menu can change as you add new pages / blog posts.

I can see good benefits of having a way to do static site generation with the React ecosystem if you're already familiar with it.

> I think the whole benefit of a static website generator in general is to avoid the "I copy/paste the same header/footer on each" step, especially copy-pasting the menu/header, as your menu can change as you add new pages / blog posts.

If the website is simple, you could use iframes for headers and footers.

Except that iframes introduce additional http requests, difficulties with selecting text and all the other annoyances that come with them.

I'm surprised html doesn't have an include tag.

https://en.wikipedia.org/wiki/Server_Side_Includes

    <!--#include virtual="../snippet.html" -->

Most servers that you would get for a shared host (ie Apache, NGINX) support this.

Whoa. Flashbacks to SHTML.

I'm annoyed but not surprised. This is how a lot of HTML was developed.

First, you have a need. Then you get a crippled native "solution", that emerges from some committee and therefore doesn't really solve anything. In lieu of alternatives, a lot of people use it anyway. Then the problem is ignored long enough so other people come up with hacks to solve the same problem slightly less bad. Then the problem is ignored semi-permanently because 'hey, you can just use one of those hacks!'. (Look up iframe seamless attribute.)

> I just make my bunch of html files (and I copy/paste the same header/footer on each), my css file, eventually 2 lines of JS directly in a <script> tag to toggle a menu on mobile devices

The workflow and output remains largely unchanged, but something like Jekyll would probably make the resulting codebase a little cleaner.

Otherwise, I completely agree. There are better tools for building static sites.

> I copy/paste the same header/footer on each

You could at least use server side includes (SSI) to include those snippets.

Static website generators like Jekyll are pretty cool, though. You should definitely check them out.

I think you're missing the point. You can use all the UI treatments and components, using AJAX if you want to. It basically gives you a lot of options and you're not stuck using jQuery plugins ad hoc when you want to make a customer form or list your latest products with search functionality on a site that is mostly static.

I think the web got complicated when somebody though about users creating content that other user could see. It could have been done with a mailto tag! instead of creating php! :p

And then install mail client plugins that transform all that information and solve mental poker for N participants! Yes!

Yes, I always hear people raving about how awesome their email client's UX is /s

That'd be me; my email-client has Conway's game of life built in ;)

Found the emacs user! ;-)

Close, but no cigar! I wrote my own mail client, inspired by Mutt but extended with a real programming language (lua):

https://lumail.org/

I added a game of life mostly to prove the extensibility covered the screen modes.

Same, but I'm exceptionally lazy so I use SSI to include the footer/header to avoid having to copy/paste code

> I just make my bunch of html files (and I copy/paste the same header/footer on each), my css file, eventually 2 lines of JS directly in a <script> tag to toggle a menu on mobile devices, I upload it on S3/CloudFront and that's it.

You copy/paste code? This is crazy.

There are often of situations where the long term benefits of automating something isn't worth the up front cost.

Throwing together a small static website with a few pages, in my experience, is one of those situations.

But the up front cost of using something like Jekyll is about fifteen minutes of work. Plus you can find a lot of free templates online that make your basic site not look awful.

I know I've spent hours trying to get Ruby setup and figuring our why bundler install failed, so disagree with your "fifteen minutes" comment. Maybe in the best case scenario.

Reply on news.ycombinator.com