7 ms·
No Framework Needed
- bbwharris 15y agoI just used middleman http://middlemanapp.com/ 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.
- MatthewPhillips 15y agoI 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.
- timdot 15y agoCan definitely get behind those page-speed comments at the end. Was on a shopping website the other day (large, national site too) and was increasingly frustrated by the 5 second page load. It sounds picky but when you're browsing around, opening up tonnes of tabs, trying to compare products, etc - it really makes you consider going elsewhere. In the end, I probably didn't buy as much as I would have it had been a much faster site.
- wisty 15y agoWouldn'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 15y agoI 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 15y agoOn 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 15y agoI 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 15y agoI 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.
- access_denied 15y agoDreamweaver still requires non-technical people to understand what a <div> is or a ftp. That is not in the realm of possibilities.
- azxcnjdk 15y agoHow would one go about correlating the slightly quicker load time to a 5% improvement in the conversion rate?
- whiskers 15y agoMeasure 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.
- azxcnjdk 15y agoThanks. Wouldn't this need to be done simultaneously? For example, serving half your users methodA and the other half with methodB.
- jonsmock 15y agoYeah, serving up two versions simultaneously and split testing them would be more scientific, but I appreciate the number anyway. It was an after the fact observation rather than an original goal, so I wouldn't expect him to go back and deploy the slower version just to test the number. The hole here is whether or not they unknowingly got a new influx of traffic that was 5% more likely to convert, skewing his final observation, which I would say is unlikely. Your point is good in general, however.
- ptmx 15y agoThat would certainly be better experimental design, since you would be controlling for other factors. On the other hand, precisely measuring the improvement in conversion isn't particularly important in this case; it's already clear that faster is better, so you're not gaining much actionable information from the measurement, whereas you would be giving half of your users a worse experience. In a situation where you were uncertain about which of two methods is better, it would definitely be better to run them in parallel like you've suggested so that you had a fair comparison.
- earnubs 15y agoMT 2.0 FTW!
- earnubs 15y agoCan't tell if you've no sense of humour or never used Movable Type.
- AdrianRossouw 15y agoWe 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-pages/ http://developmentseed.org/blog/2011/09/09/jekyll-github-pag...
- gravitronic 15y agoI'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 15y agoIndeed. 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 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/c422edc3a298674e1240372e3345def7f5d4fdb5 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 15y agoTL;DR: Serving static assets is faster than using ruby to serve those assets. (how did this article get 43 points?)
- victork2 15y agoAt 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 15y agoCan you tell that 37 Signals is gearing up to a new product launch?!
- batista 15y agoYeah, they're gearing up to a new product launch. Is this supposed to be bad? Besides, that only tells up that they post a lot of new content for their blog. Nothing about how this content is voted up on HN --which, I, presume, is simply by folks finding it relevant and upvoting it. Or, do you think that they have their employees doing the voting to their own articles. Because certain people certainly imply that. To which, I respond: 1) HN is a social news site for hackers, people vote on stuff the like, and DHH et co are popular in Ruby/Rails hackers to say the least. 2) HN is a social news site for hackers. You really think a company like 37 Signals thinks they'll gain something regarding new customers by having it's articles linked and discussed here, and so much that they'll devise such a scheme?
- lrobb 15y agoThe next blog post will be about the speedup obtained with serving static assets via CDN?
- ludwigvan 15y agoIt 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."
- drewda 15y agoAny thoughts on 37 Signals's brochure vs. jekyll? https://github.com/sstephenson/brochure https://github.com/sstephenson/brochure https://github.com/mojombo/jekyll https://github.com/mojombo/jekyll
- jasonkester 15y agoIndeed. 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.
- chc 15y agoAlthough 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?
- dpezely 15y agoServing 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.)
- chc 15y agoBut what I'm saying is, doesn't caching accomplish essentially the same thing? You process the resource once, cache the result and serve that. Full static site generation just seems like a more aggressive version of the same thing, and AFAIK you have to give up some of the benefits of being partially dynamic (like the ability to do have a "Latest comments" sidebar without unnecessarily relying on JavaScript).
- conroy 15y agoI 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 http://kyleconroy.com [2] http://twilio.com/engineering http://twilio.com/engineering
- pestaa 15y agoWe 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 15y agoThe classic reference on this topic, Aaron Schwartz's "Bake, Don't Fry", is now ten years old: http://www.aaronsw.com/weblog/000404 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
- skeptical 15y agoI think this is rather ridiculous. May I remind that using a framework to serve a static webpage is a bad idea from the beginning? A few years ago, when server resources were more valuable than they are today, the people at 37signals were preaching about the wonders of dynamic content delivery through rails. Fast forward a handful of years, and suddenly they realize it's a bad idea. What bothers me is the trendy nature of all of it. Both approaches have their own place, as usual there are those who will stick with whatever is hip at a given time.