Why WeWork.com uses a static generator • Hacker News Board

Re: Why WeWork.com uses a static generator

#31

Post by desp » Wed, Dec 09, 2015, 10:03 PM UTC

orestes910 wrote: post #2

I'm still struggling to get on board with this. It seems to just favor speed above all else. I found the linked article at http://www.smashingmagazine.com/2015/11/modern-static-websit... to be a bit more helpful in pitching the case, but even so it seems like just pulling the complexity of dynamic sites into the build stage of the static ones all because writing efficient DB queries is "hard". For a companies front p…

> it seems like reverting from "Web Applications" back to "Web Sites"

I want to push back against this idea that "Web Applications" represent uniform forward momentum for the web, while "Web Sites" are somehow archaic. This seems to be a fairly common perception, but it strikes me as a false dichotomy.

Both are distinct and useful things. Static site generation isn't a good solution for interactive applications – conversely, React is a poor choice for building low-interactivity web pages.

EDIT: Improved blockquote formatting.

Re: Why WeWork.com uses a static generator

#32

Post by lfx » Wed, Dec 09, 2015, 10:05 PM UTC

oconnor663 wrote: post #30

> One key requirement for us when evaluating different static site generators was the ability to hit an API endpoint and dynamically generate static pages based on the data returned. ...dynamically generate static pages?

Yes. Putting in other words - caching (well, some sort).

Re: Why WeWork.com uses a static generator

#33

Post by jnbiche » Wed, Dec 09, 2015, 10:14 PM UTC

oconnor663 wrote: post #30

> One key requirement for us when evaluating different static site generators was the ability to hit an API endpoint and dynamically generate static pages based on the data returned. ...dynamically generate static pages?

Basically, this means you hit an API endpoint that returns an array of JSON objects, each of which is used to generate an HTML page.

Contentful offers this as a service, along with web frontends for updating the data for those APIs.

Re: Why WeWork.com uses a static generator

#34

Post by chriswarbo » Wed, Dec 09, 2015, 10:47 PM UTC

kavok wrote: post #9

tarr11 wrote: post #5

Looks like the engineers made this decision: "If you consider the amount of information that changes on a daily, or even weekly basis on a site like wework.com, it is actually quite wasteful to have a server process each and every request that comes through." A better solution for a marketing site is to use a CMS (doesn't really matter which - Wordpress, Rails, etc) and then use a CDN like Cloudflare to proxy static…

With some static site generators you don't have to redeploy the entire site. Just the changed files. You can rapidly update the site with no issues. I'm not sure if a CMS is really a good solution for a site that changes infrequently or when updates typically require developer interaction anyways.

> With some static site generators you don't have to redeploy the entire site. Just the changed files.

My static site does this. I use make.

Re: Why WeWork.com uses a static generator

#35

Post by gry » Wed, Dec 09, 2015, 11:03 PM UTC

icebraining wrote: post #20

thecodemonkey wrote: post #19

Static websites are great of course, and the article outlines that nicely. The problem that I've been facing personally is that most of the times, the people who are updating and maintaining content on marketing websites are not developers. So having to use the command line for static site generators such as Jekyll or Middleman is just not a good experience. Don't get me wrong, I LOVE static site generators in genera…

Movable Type, one of the original blogging platforms, worked (and works) exactly like that, though it also supports dynamic publishing. For example, Jeff Atwood's blog has always been statically generated: http://blog.codinghorror.com/coding-horror-movable-type-sinc...

So is Daring Fireball.

https://daringfireball.net/colophon/

Re: Why WeWork.com uses a static generator

#36

Post by gotchange » Wed, Dec 09, 2015, 11:09 PM UTC

oconnor663 wrote: post #30

> One key requirement for us when evaluating different static site generators was the ability to hit an API endpoint and dynamically generate static pages based on the data returned. ...dynamically generate static pages?

Apparently, their API is structured to work on a per web page basis or even a higher level than that but I could be mistaken.

Re: Why WeWork.com uses a static generator

#37

Post by Dr_tldr » Wed, Dec 09, 2015, 11:18 PM UTC

Some serious questions:

1. Why not just use fs.writeFile to create all the site info as json files as either a one off or a chron job, then run a gulp task to either use something like jade or else roll your own rendering to put the JSON in the right place on the page, then output the result as html to a public folder, set up an express static server and have a catch-all splat after it for 404s? What am I missing here?

2. If your site is fairly static like WeWork's, why not just have it as a SPWA, set all the links to retrieve a JSON file from the static server and process them on the front end? You could even use history.pushState and checking window.url to make sure that history works and links would load the right thing.

3. When someone logs in, are you doing a DB lookup then serving their dashboard page statically (somehow, for some reason...), or does this static build only apply to part of your page and not others?

4. Could everything Roots does be replaced by one 6 line gulp task? Not trying to be mean, just wondering if its target userbase knows what gulp is.

Re: Why WeWork.com uses a static generator

#38

Post by gotchange » Wed, Dec 09, 2015, 11:22 PM UTC

tarr11 wrote: post #5

Looks like the engineers made this decision: "If you consider the amount of information that changes on a daily, or even weekly basis on a site like wework.com, it is actually quite wasteful to have a server process each and every request that comes through." A better solution for a marketing site is to use a CMS (doesn't really matter which - Wordpress, Rails, etc) and then use a CDN like Cloudflare to proxy static…

This is an abstraction problem and can be fixed easily. The team has to build an interface for the non technical folks at the organization exposing the bits of the API that they deem necessary and appropriate and then handle the complex stuff behind the scene communicating back and forth with other parts of the stack.

Re: Why WeWork.com uses a static generator

#39

Post by sneak » Thu, Dec 10, 2015, 1:44 AM UTC

tedkimble wrote: post #23

sneak wrote: post #17

Earlier quoted context omitted.

It looks awesome, and I've been thinking about building a tool just like this one around Jekyll myself. The pricing is a bit steep - I would be fine with $15/mo/account but I have a half-dozen sites to manage and more all the time. Some of them are low enough traffic that $180/year isn't really justified. Thoughts?

Thanks, and totally understandable. I'm still considering what to offer in a more affordable plan for these types of low-usage/low-traffic sites. Would you be opposed to a plan that limited based on usage (the number of commits, which our service triggers builds/deploys/etc...)?

Yeah, absolutely. I wouldn't need more than 50-100 all year across all my sites.

Re: Why WeWork.com uses a static generator

#40

Post by bobfunk » Tue, Dec 15, 2015, 6:26 PM UTC

Dr_tldr wrote: post #37

Some serious questions: 1. Why not just use fs.writeFile to create all the site info as json files as either a one off or a chron job, then run a gulp task to either use something like jade or else roll your own rendering to put the JSON in the right place on the page, then output the result as html to a public folder, set up an express static server and have a catch-all splat after it for 404s? What am I missing her…

For point 1 - that will give you way worse performance than WeWork's current setup, since all requests will have to go back to your origin where your express server is running in order to determine if it's a static request or a dynamic request.

With netlify this happens at the CDN PoP which makes a huge difference for a site with a global audience like WeWork.