5 ms·

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

by tarr11 11y ago

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 pages and speed things up. It's fast, efficient, and flexible. The solution wework used optimizes for performance but reduces flexibility. 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.

seanwilson 11y ago
I agree it's less flexible but another benefit is that it's very easy to secure in contrast to a full CMS.
jnbiche 11y ago
It's definitely possible to have the best of both worlds, and services like Contentful and Prismic.io are leading the way there, with easy-to-access Web interfaces to JSON-based content, which is then easily rendered using a static-site generator. Combined with triggers from a host like Netlify, and it's very easy to redeploy whenever a marketing person makes a change using the Web backend (and some static site generators do incremental builts).
kavok 11y ago
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.
- chriswarbo 11y ago
  > 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.
bosdev 11y ago
I'm not sure what "redeploy the entire site every time they wanted to change some text" means. When you use a continuous integration tool you don't ever have to manually touch the deploy process, it can happen immediately after you make your change (if you so wish). The marketing team makes a change, the change goes live on the site. The only difference between this and any other CMS are the technical advantages.
detaro 11y ago
> 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?
tedkimble 11y ago
There's a growing market of tools solving this problem. We launched https://www.staticwebsitemanager.com 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!
deleted 11y ago
[deleted]
gotchange 11y ago
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.

by tarr11 11y ago

seanwilson 11y ago

I agree it's less flexible but another benefit is that it's very easy to secure in contrast to a full CMS.

jnbiche 11y ago

It's definitely possible to have the best of both worlds, and services like Contentful and Prismic.io are leading the way there, with easy-to-access Web interfaces to JSON-based content, which is then easily rendered using a static-site generator. Combined with triggers from a host like Netlify, and it's very easy to redeploy whenever a marketing person makes a change using the Web backend (and some static site generators do incremental builts).

kavok 11y ago

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.

chriswarbo 11y ago
> 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.

bosdev 11y ago

I'm not sure what "redeploy the entire site every time they wanted to change some text" means. When you use a continuous integration tool you don't ever have to manually touch the deploy process, it can happen immediately after you make your change (if you so wish). The marketing team makes a change, the change goes live on the site. The only difference between this and any other CMS are the technical advantages.

detaro 11y ago

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

tedkimble 11y ago

There's a growing market of tools solving this problem. We launched https://www.staticwebsitemanager.com 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!

deleted 11y ago

[deleted]

gotchange 11y ago

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.