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

11–20 of 41 posts

Re: Why WeWork.com uses a static generator

#11

Post by detaro »

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…

> I'd bet the marketing team at wework wishes that they didn't have to redeploy the entire site every time they wanted to change some text.

Do they actually know/notice that they are doing that?

Re: Why WeWork.com uses a static generator

#12

Post by fweespeech »

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…

> For a companies front page, I can see the benefit of generating content once instead of for every client, but what happens when you need to present information beyond the generic? What happens when you need to show a user's order history? Let them change their password? Allow them to see the distance of that run?

Well if you can assume the user has javascript enabled, AJAX is an option.

I'm pretty sure they are talking about generating the majority of the site and filling the details in dynamically as needed.

Re: Why WeWork.com uses a static generator

#13

Post by Albright »

exelius wrote: post #4
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…

The "right" way to do this (edit: this is essentially assumed by the article, so I'm not contradicting it) is to build static sites and use JavaScript to pull in any dynamic information. You run data services that output JSON, then the JS on the page calls those data services and renders the views. This still allows you to reap the benefits of static content (namely CDN distribution / caching) while still maintaining…

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 to have been completely lost on the latest generation of web developers, who cares, right?

Re: Why WeWork.com uses a static generator

#14

Post by tedkimble »

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…

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 discussion is our Form Responder tool, which provides an endpoint for your HTTP forms.

The cool thing is you can connect them to your Jekyll data files and then new form submission data will be committed (appended or set to a key) to that data file. New commits also trigger builds/deploys, resulting in a dynamically-updated static website. (They work across your branches, too, if you need to moderate submissions before merging with production.)

Re: Why WeWork.com uses a static generator

#15

Post by tedkimble »

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…

There's a growing market of tools solving this problem. We launched https://www.staticwebsitemanager.com recently, which provides a CMS on top of your Jekyll static site. Plus, each user transparently gets their own staging branch to make and preview changes without the fear of breaking production. You can have your flexibility too!

Re: Why WeWork.com uses a static generator

#16

Post by captn3m0 »

I run my personal sites and a couple other on static site generators (mostly Jekyll) and it really works out well. The most complicated and interesting case is that of hackercouch.com, where we are running custom Jekyll plugins to even serve an API.

Another website, recently setup for the chennai floods by a friend uses a Google Spreadsheet as a database, but is served as a static site: http://chennairains.org/.

Its far more easy to deploy a static site, they are portable and shifting hosts is far more easier. Your database considerations are slightly less relevant since it only affects deploy speeds, and not your site performance.

Re: Why WeWork.com uses a static generator

#17

Post by sneak »

tedkimble wrote: post #14
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…

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?

Re: Why WeWork.com uses a static generator

#18

Post by exelius »

Albright wrote: post #13
exelius wrote: post #4

Earlier quoted context omitted.

The "right" way to do this (edit: this is essentially assumed by the article, so I'm not contradicting it) is to build static sites and use JavaScript to pull in any dynamic information. You run data services that output JSON, then the JS on the page calls those data services and renders the views. This still allows you to reap the benefits of static content (namely CDN distribution / caching) while still maintaining…

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 differences in browsers/engines/etc. But your servers are doing less work, and the content reaches the customer faster. It's still up to you to optimize your JS (though I guarantee most tracking cookies are taxing JS far more than rendering a few divs will).

Re: Why WeWork.com uses a static generator

#19

Post by thecodemonkey »

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 general and I'm using both Middleman and Sculpin myself.

Other people has seen this problem too, and some user-friendly-ish static site generators have started to surface, but I want to chime in with a solution to that too since I believe that the best way to adopt static site generators is to use the tools that content creators and maintainers already love and are familiar with, e.g. WordPress which now has a whopping 25% marketshare[1].

I built SpudPress[2] with a friend. It is a hosted static site generator for WordPress. We automatically generate a static version of your WordPress site and host in on a super fast CDN. You don't have to worry about any of the edge cases of generating a static copy, we take care of all that automatically for you.

[1] http://ma.tt/2015/11/seventy-five-to-go/ [2] https://spudpress.com

Re: Why WeWork.com uses a static generator

#20

Post by icebraining »

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...
Post reply on HN