No Framework Needed

http://37signals.com/svn/posts/3103-no-framework-needed

by themcgruff • 14 years ago

115 58 14 years ago

wisty• 14 years ago

Wouldn't caching do a similar thing? I guess you'd have the complexity of removing it from the devserver (so you don't have to wait for the cache to invalidate to see changes), and cache invalidation is always ugly.

Wait, I didn't read the bit about JS and CSS aggregation. OK ... but surely there's other ways.

gpapilion• 14 years ago

I think this is "caching", with extremely high latency. And, truthfully for most marketing materials the latency isn't an issue, since approval time are probably much higher.

Really to only reason you'd choose a dynamic language for marketing materials is to ensure link and image relational integrity. (people are bad at this, computers are good)

tommyd• 14 years ago

On the last big site I worked on, we used nginx as a reverse proxy to Apache. That way, nginx respects the cache headers you send out and so nearly every request is served straight from its cache pretty much instantly, and you can have a highly dynamic page without having to worry excessively about performance as long as the response time if you do happen to hit an invalidated cache isn't unreasonable. Seems like a good approach to me if the site requires a dynamic back-end and also requires very high performance, as long as there's nothing on the page which needs to be personalised on the server side (i.e. can't be personalised via AJAX).

Not read the article so not sure if this has anything to do with their reasons for using plain HTML (which, of course, has its place!)

randomdata• 14 years ago

I find it interesting that the static website ever went out of favour for this kind of site. The simplest approach is usually the best.

I have one website that is compiled using make and sed. Tools most programmers already have on hand. It took no virtually no time to setup and it gets the job done quite gracefully, while still leaving room to be integrated into a more complex system should the future site's needs dictate it.

mseebach• 14 years ago

I think the evolution was driven by the desire to have non-technical people be able to maintain websites. The easiest way to do this is a web app, and once you have a web app, making the entire site dynamic is (a) easy (b) opens the door to tons of shiny possibilities.

Obviously, there were significant efforts in the maintainable static site space, such as FrontPage and Dreamweaver, but I think those ultimately lost out to the flashiness of dynamic websites.

azxcnjdk2• 14 years ago

How would one go about correlating the slightly quicker load time to a 5% improvement in the conversion rate?

whiskers• 14 years ago

Measure your conversion rate for a statistically significant amount of time.

Deploy new version of site that is 0.5 seconds faster to load.

Measure your conversion rate for a statistically significant amount of time.

Compare conversion rates.

azxcnjdk2• 14 years ago

Thanks. Wouldn't this need to be done simultaneously? For example, serving half your users methodA and the other half with methodB.

apl2• 14 years ago

Nitpick: You'd have to test the difference between before and after at a certain level of significance, not just establish estimates for before and after. Different things.

patio113• 14 years ago

This will not, in fact, produce reliable results. Your conversion rate will tend to change over time anyhow regardless of the "treatment" option in the second "statistically significant amount of time", because your conversion rate is sensitive to things like e.g. traffic mix, PR, and whatnot which are not uncorrelated with when you take the measurements.

This is why we don't do medical trials by giving people aspirin, measuring symptoms, then giving the same people a sugar pill, then measuring symptoms again. Instead, we give different people the two treatments at the same time, such that one population functions as a control group for the other. This is the essence of A/B testing, too.

The right way to measure this if you want reliable results is to put a load balancer or something in front of the page at issue and split half the people into the old architecture and half the people into the new architecture, then measure their conversion rates simultaneously. 37Signals knows this, and they allude to it in their blog post. That's OK though. You don't need to apologize for not gathering good data on whether making your site faster is better. Testing costs money, and testing known-to-be-virtually-universally-superior things is rarely a good allocation of resources.

You just probably shouldn't attribute your increase in conversion rates to the change you made without testing.

earnubs2• 14 years ago

MT 2.0 FTW!

earnubs2• 14 years ago

Can't tell if you've no sense of humour or never used Movable Type.

bbwharris• 14 years ago

I just used middleman http://middlemanapp.com/ for this exact purpose. A lot of sites don't really need a database, and they don't need to be incredibly dynamic. Most Who, What, When, Where, Why questions can be answered statically.

AdrianRossouw• 14 years ago

We discovered this too, when we switched from Drupal to using Jekyll hosted on github [1]

It is pretty crazy how much simpler you can go with some things.

[1] http://developmentseed.org/blog/2011/09/09/jekyll-github-pag...

gravitronic• 14 years ago

I've been looking at doing the same thing myself. I noticed you don't have comments on your blog. I guess the solution would be a 3rd party plug-in like disqus?

sc68cal• 14 years ago

Indeed. Myself, it took me too long to pair down my site.

First I went from Wordpress+MySQL down to a Bottle+Redis (https://github.com/sc68cal/homepage/tree/bottle+redis) based site.

This article then inspired me to go a step further and use Jekyll (https://github.com/sc68cal/homepage/commit/c422edc3a298674e1...). My Jinja2 templates translated to Liquid with minimal effort.

I'm much happier with it, and plan to get back into writing.

mceachen• 14 years ago

TL;DR: Serving static assets is faster than using ruby to serve those assets.

(how did this article get 43 points?)

victork2• 14 years ago

At the risk of being downvoted, there's a big herd of 37signal followers on HN. Every article they post get a lot of points...

Anyway I agree with your TL;DR, not much to see here!

tomblomfield• 14 years ago

Can you tell that 37 Signals is gearing up to a new product launch?!

lrobb• 14 years ago

The next blog post will be about the speedup obtained with serving static assets via CDN?

ludwigvan• 14 years ago

It is news when arguably a company that created the most well known web framework posts a blog entry titled "No framework needed". If you look for a TL;DR it would be "Use the right tool for the job. Do not be dogmatic about your technological choices."

drewda2• 14 years ago

Any thoughts on 37 Signals's brochure vs. jekyll?

https://github.com/sstephenson/brochure

https://github.com/mojombo/jekyll

apgwoz• 14 years ago

Doesnt' jekyll do precompilation? Brochure, being an actual rack app will do dynamic rendering of the templates.

drewda2• 14 years ago

Ah, makes sense. Thanks.

jasonkester2• 14 years ago

Indeed. It has always amazed me that so many people treat their static content as something that needs to involve a database.

Look at how many blog entries come through here and have the entire site fall over from a few thousand people going to read them. Somewhere there's a poor slicehost instance performing "select * from blog_entry where key like '10_reasons_rails_is_awesome'" thousands of times in a row until something melts.

Worse, the proposed solution when this happens is to add caching.

No, the thing to do would be to add a .html file to your webserver. I defy anybody to find a modern web server that can't serve a static file a thousand times per second from the smallest VPS slice on the market.

It's a solved problem. But people keep unsolving it.

chc2• 14 years ago

Although I take your point that people do a lot of needless computation these days, I don't quite understand the dig at caching. Isn't adding an HTML file to your server just manual caching?

dpezely2• 14 years ago

Serving static files is more about pre-processing, or rather:

Don't do at run-time what can be done at compile-time.

This doesn't need to be any more manual that the labor involved in uploading content into a CMS or data store by another name (e.g., blog engine). It's more of a substitution of one task for another.

I prefer to think of the static HTML approach as the difference between using Makefiles versus a shell script for compiling code. Once you understand that the shell script will duplicate nuances that 'make' offers, use of Makefiles for compiling code usually gets viewed as the better approach. (There are always edge-cases, of course.)

jasonkester2• 14 years ago

Pretty much. Only chances are it's not actually manual, either.

The way I do this for the CMS/Blog stuff on my products is to set up a 404 handler that looks for urls that seem like they should be blog entries. So if it sees a request for the non-existant http://mysite.com/blog/caching_is_awesome.html, it'll do a quick check for that article in the database, and if necessary create the static .html file before redirecting to it.

It's a little nicer than caching because you only need ever lookup/create the thing once each time it changes. From there, it's just the webserver being a webserver. No need to involve any application layer at all.

patio113• 14 years ago

I defy anybody to find a modern web server that can't serve a static file a thousand times per second from the smallest VPS slice on the market.

Apache 2, with KeepAlive on, using the MTM that will be installed if you have PHP running on your system. Specifically, when you try serving a static file a thousand times per second to a thousand clients, your first 150 clients are going to saturate all available worker processes for 15 seconds, then your next 150 clients are going to saturate all available worker processes for 15 seconds, then ... most of your users will see their browsers timeout and it will appear that the server has crashed.

n.b. This is the default configuration you'll get if you do weird crazy things like "sudo apt-get install apache2 php5" on Ubuntu.

Edit: Added victim site below if you want to test this.

http://50.57.160.126/

[Edit the second: I fail at reading comprehension of my config file at 4:30 AM, and underestimated the number of simultaneous connections it could take at once. Still, I'm pretty certain this is technical reality after the numbers are corrected.]

windsurfer2• 14 years ago

I was under the impression that the 15 seconds timeout for php was if a page took longer than that to load, apache would kill it. I thought the worker processes would be available to serve content immediatly after its done serving a page.

kijin2• 14 years ago

Regarding your second edit:

If anyone actually tried to run Apache/mpm_prefork with "MaxClients 150" on an average Linode or cheap dedicated server, they'd OOM and start thrashing as soon as someone started requesting a couple dozen PHP pages -- even if the rest of the requests were to static resources. That's just another way to get yourself DoS'd. Received wisdom on the Linode forums is that you should handle no more than 10-15 simultaneous connections if you're stuck with Apache/mpm_prefork and PHP. So your original point stands.

NameNickHN• 14 years ago

> Worse, the proposed solution when this happens is to add caching. > > No, the thing to do would be to add a .html file to your webserver.

Isn't adding an html file the same as caching? Only with different tools? I see no difference between writing a blog article in an html editor -> saving it to a html file -> uploading it to the server, and writing a blog article in a blog software -> save it to the database -> publish it as html file.

T-hawk• 14 years ago

> It has always amazed me that so many people treat their static content as something that needs to involve a database.

It's not static. Maybe the text is, but the entire HTML document is plenty dynamic. You always have your list of recent blog posts, often some dynamically calculated dates ("posted yesterday 25 hours ago"), some quote-of-the-day or other banner, and maybe advertisements. Personal blogs might be able to get away with HTML, but at a corporate level (even company-blogs like MSDN's) that doesn't fly, where tons of hands are in the pot all with their own widgets and contributions that must automatically go on every page of a site.

What you really want is a CMS with a compilation step that outputs static HTML each time something changes. That gives you the flexibility of database-driven CMS with the runtime performance of static HTML.

sudonim• 14 years ago

I'd argue that you can get away with it in many cases.

* Disqus for comments. * You re-generate the static site on every deploy. "Recent" can be regenerated every new post. * It's easy to convert a date into "2 days ago" with javascript. * Quote of the day, or other banner can be javascript too. * Advertisements are almost always javascript.

Im not seeing the need for a database in anything you described.

aethr• 14 years ago

> What you really want is a CMS with a compilation step that outputs static HTML each time something changes. That gives you the flexibility of database-driven CMS with the runtime performance of static HTML.

Did you just define "caching"?

mattbee• 14 years ago

I disagree that high-performance blogs are a solved problem in distros - depends on who's linking to you.

Wordpress on Apache melts on a small VPS under a few hundred hits per second, using gobs of memory for each call. So you turn on supercache etc. and it gets a little better, for a lot of application complexity.

Now put varnish in front, override some of the cache-ability headers from your application, and my experience is that when e.g. Stephen Fry's twitter links to the site, your site becomes CPU or network-bound instead.

From memory, from maintaining a friend's site, the number of simultaneous connections to melt down the server (using siege, on a 4GB system) were something like 300 connections without any optimisation, double that if Wordpress had spat out .html files and Apache was serving, but with Varnish in front, it started to slow down at around 2000 connections.

There's a reason you want to serve your application from a database - it's nice and easy to change your pages on the fly, but serving static files through Apache is hardly the best you can do for optimisation.

z92• 14 years ago

This single comment taught me more than the original article.

cageface• 14 years ago

Thanks to modern JS & HTML, static sites can also be a lot more dynamic than the boring old static sites of the past. You can integrate things like DISQUS without any dynamic content at all.

edanm• 14 years ago

Any time I set up a new website, I use WordPress with a theme from WooThemes. It's just the easiest thing to set up and make beautiful. A thousands times easier than using static html to make sites.

And ease of initial deployment is the only thing that matters to most of the population. The fact that this configuration may theoretically break one day? Who cares, as long as it takes me 3 hours to get it up and it's fixable.

MatthewPhillips• 14 years ago

I love this approach. I'm working on rewriting one of my webapps and I'm taking this concept to the extreme.

The website part will have no backend. Just static files served by Nginx. Even much of the data can be served from .json files. Where true dynamic content is needed, search for example, a minimal API will serve that content, sitting on another server, on another domain.

conroy• 14 years ago

I switched both my blog [1] and our engineering blog [2] over to Jekyll and couldn't be happier. It's incredibly easy to deploy (we push our blog straight to S3) and working locally is a breeze.

[1] http://kyleconroy.com

[2] http://twilio.com/engineering

pestaa• 14 years ago

We don't see the exact numbers on the technical side, and my hunch is that pretty much all of the 500ms was saved because of client side optimization.

He mentions spriting some images, that only saves several HTTP requests, often translating to 200-3000ms quicker total load time. (Note that we're talking about full page load times, from the first DNS query to DOM ready.)

I agree Ruby is terribly slow at initializing, but it is not going to be the bottleneck when you run your own dedicated boxes (and 37signals does).

Good job on increasing the conversion rate, by the way.

Edit: Also, it doesn't matter if you precache or cache on-the-fly. You should be serving the homepage from memory (and any static pages for that matter).

mmahemoff• 14 years ago

The classic reference on this topic, Aaron Schwartz's "Bake, Don't Fry", is now ten years old: http://www.aaronsw.com/weblog/000404

"Now, a number of tools are challenging that assumption. Movable Type, the program that runs this weblog, has a series of Perl scripts which are used to build your webpage, but the end result is a bunch of static pages which are served to the public."

These days, you can do so much more with off-the-shelf client-side components too, e.g. comments via Disqus et al, tracking via Analytics et al. It's really the best approach for most

No Framework Needed

Related Stories