Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why WeWork.com uses a static generator

engineering.wework.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Why WeWork.com uses a static generator

#21

Post by thecodemonkey »

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...

That's really cool! I like that. It's nice to see that a platform like Movable Type has had this feature right off the bat for such a long time.

The main reason that we decided to build SpudPress this way, is that you can more or less take your existing WordPress site and instantly make it static.

In contrary to Jeff's Movable Type blog we're taking full advantage of the static pages to host the entire site on a CDN + handle asset cache validation automatically.

Re: Why WeWork.com uses a static generator

#22

Post by [deleted] »

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…

[deleted]

Re: Why WeWork.com uses a static generator

#23

Post by tedkimble »

sneak wrote: post #17
tedkimble wrote: post #14

Earlier quoted context omitted.

There's definitely a point at which an actual web app makes sense. But I think there's also a large category of websites that have been built as dynamic apps even though they’re updated sparingly and only require changes to a few items of content or data. I recently launched Static Website Manager ( https://www.staticwebsitemanager.com ) to help bridge this gap between static and dynamic websites. Relevant to this di…

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...)?

Re: Why WeWork.com uses a static generator

#24

Post by jlg23 »

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 to just favor speed above all else.

Yes, it seems to be all about speed. But there is one more thing that really convinced me already some 15 years ago to migrate a high profile site to static site generation: Security. The attack surface is reduced to your httpd.

PS: The site did not see too many changes and not many editors - hacking a solution in pmake and some perl for editor UI was done in half a day and everyone was happy, including the sys-admin (me, again) who only had to apply security fixes every 2 years.

PPS: Also, another important reason for some, though for me it was only an afterthought, if at all: Sending a static byte array is much, much more energy efficient than scheduling a meeting with your database for every request.

Re: Why WeWork.com uses a static generator

#25

Post by Albright »

exelius wrote: post #18
Albright wrote: post #13

Earlier quoted context omitted.

Using JS to present data moves the work of generating the display of that data from the build process, as with "pure" static site generation, or from server-side code, as with a standard CMS, to the client, where it is most likely to fail in unpredictable ways due to variances in browser JS or CSS engines, network performance, browser extensions, etc, etc. But given that the concept of progressive enhancement seems t…

Well, the key here is that any non-JSON data you pull from a URL should be static. That means it can be cached, and the client should only be pulling a small amount of data that varies based on their account. I wouldn't write an interactive web application this way, but for sites that are mostly content the approach works fine. You still have to test on multiple browsers, and you still have to write code that handles…

> the content reaches the customer faster.

Does it? Is it really slower for your customers to download a server-generated page than for them to download a static page, (probably) download a JavaScript file embedded in the page, execute the JavaScript, then download and process server-generated JSON?

Re: Why WeWork.com uses a static generator

#26

Post by exelius »

Albright wrote: post #25
exelius wrote: post #18

Earlier quoted context omitted.

Well, the key here is that any non-JSON data you pull from a URL should be static. That means it can be cached, and the client should only be pulling a small amount of data that varies based on their account. I wouldn't write an interactive web application this way, but for sites that are mostly content the approach works fine. You still have to test on multiple browsers, and you still have to write code that handles…

> the content reaches the customer faster. Does it? Is it really slower for your customers to download a server-generated page than for them to download a static page, (probably) download a JavaScript file embedded in the page, execute the JavaScript, then download and process server-generated JSON?

Considering they're likely also downloading JavaScript and executing it when using the server-generated page, yes. Let's not pretend it's possible to do everything on the server side. Just now instead of compiling the page in real time when it's accessed, we compile large parts of it long before the user requests it.
Post reply on HN