Why WeWork.com uses a static generator
engineering.wework.com
Why WeWork.com uses a static generator
1–10 of 41 posts
Re: Why WeWork.com uses a static generator
#2I'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 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?
I feel old and crotchety, but I just find it a bit strange that as we get more and more obsessed with data, this emerges; something that seems less that optimal for dealing with it. They make the comparison themselves, but it seems like reverting from "Web Applications" back to "Web Sites" and just filling it with API calls to actual Web Apps.
Re: Why WeWork.com uses a static generator
#3I'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…
[deleted]
Re: Why WeWork.com uses a static generator
#4I'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 some dynamic content.
But basically, you do it this way to avoid pulling data that isn't user-specific from the database. It's far more efficient to build a header + page + footer once at build time than to have every client have to do that on access -- even if you have 100+ variations of your site that need to be compiled and updated on any change in the shared content. Storage and compute resource are trivially cheap if they don't scale exponentially with number of users.
Yeah, it's more work for your developers, but it saves your DBAs a LOT of work by reducing the volume of data served from the database. And at the end of the day, it's full-stack effort that counts -- I'd rather have my developers spend 2x the time to build a system than have my DBAs fighting fires because the site went down. With a static site, you can set it to read-only mode if the traffic gets to be too much, and the static content will be handled by the CDN (which can almost certainly handle any load).
Re: Why WeWork.com uses a static generator
#5Looks 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.
Re: Why WeWork.com uses a static generator
#6Looks 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 agree it's less flexible but another benefit is that it's very easy to secure in contrast to a full CMS.
Re: Why WeWork.com uses a static generator
#7Looks 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…
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).
Re: Why WeWork.com uses a static generator
#8I'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…
To me the logic is simple: It's more efficient to build the site when its content changes (very infrequently) rather than when its viewed (very frequently). Yes various forms of caching can allow you to scale the dynamic model quite far, but scaling gets so much simpler when you move into the static world.
In answer to your questions, the general idea is you have a static site, and a powerful API. The power of the JavaScript engine in modern browsers allows you to build your entire application to run in the browser, sending asynchronous requests to your API as is required. You're essentially just removing the Python/PHP/etc. middleware layer many sites have traditionally had.
Re: Why WeWork.com uses a static generator
#9Looks 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.
Re: Why WeWork.com uses a static generator
#10Looks 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'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.