I agree. I don't think they should write a custom website to host their articles. I'm perfectly happy reading Ghost or WordPress.com articles as long as the site is well designed to fit the content.
While Medium is a very beautiful, well designed site, it doesn't work equally well for every kind of content out there. Technical content with code snippets are one of the least-suitable type of content for Medium.com design.
No matter how much thought is put into the design of the site, Medium's design is still designed to be a one-size-fit-all kind of product, and well, that means no matter how high quality their design is, it is still taking a somewhat "highest-common-denominator" approach to the design.
I'm not saying you have to build a server to host your blog. You can host it on AWS or elsewhere if you get a lot of traffic. It's not that hard to get a domain name, host it somewhere, and write some HTML code.
Yes, it could be difficult and a lot of work if you think you need embedded videos that autoplay and follow readers as they scroll down trying to escape that and the pop up pestering them to subscribe.
Hosting it somewhere on your own will not give you good analytics, a good clean theme, and a CDN. A wordpress does. You're going for a ton of extra work.
AWS is madness for personal projects. You don't seem to realize how bad you're about to be bankrupt when an article hit the front HN page. If you have a high quality picture, a gif or a video, it's game over.
"You don't seem to realize how bad you're about to be bankrupt when an article hit the front HN page."
I've had a couple of AWS-hosted pages make it to the HN front page.
I don't recall my S3 bill going up to any significant degree, much less bankrupting me.
S3 bandwidth is $0.023/GB at the most expensive tier. It's hard to imagine bankruptcy resulting from any text-oriented site, even if it does hit the HN home page. Maybe if you're hosting hours of HD video or something.
Also, I've never had any trouble using CDNs from an S3 page. Details?
Bandwidth is $0.090 per GB. (You mixed it up with the storage price that is $0.023/GB).
Let's say the site is 1MB to deliver. That's nothing fancy, lots of text, css, logos, headers.
For 100k viewers, that's about 100GB of traffic, or $9 dollars.
How do you bankrupt yourself with your blog from there: By multiplying it.
1) You've got more than this single article => triple it.
2) You've got medias (picture/gif/video) that take 3MB => quadruple it.
3) My traffic stats don't account for bots/crawler => You're at the mercy of them or any dude who "ab -n 1000000 yoursite.com/logo.png"
A bill of hundreds of dollars for a personal blog might not scare a HN silicon valley engineer making $15k a month but that's much more than enough for the rest of the world. Even in western Europe, don't expect the disposable income to be much more than $100 a month.
Hosting a web site for a blog is expensive? A local webhost offers 75GB of transfer for $6 a month, with the highest transfer day per month dropped completely. If you want a CDN on top of that, it's a whopping $1 per month per 10GB.
you could easy have a web server with thousands of visitors running on a rasbery pi. i would say a week end project to set it up or one hour if you already are familiar with web servers.
I'm curious about this. If you have a purely static site, what would be the major bottleneck for a front-page-reaching site hosted on a raspberry pi? I'm thinking things like compression would eat up a lot of its CPU, but you seem to know more about this than me.
A solid 3,000-word article with enough CSS to make the page look nice will fit comfortably in 20-30KB gzipped. A Raspberry Pi could handle on the order of tens of requests per second (tens of thousands per hour).
A fluffy 500-word Medium-style article with 1-2MB of JavaScript serving no apparent purpose and 5-10MB of animated GIFs would be another story.
A realistic static site will have multiple css, a logo, potential images in the headers/footers/sides, links to the other top read articles with icons, pictures/schemas/drawing/photos in the content.
That sets any stupid article at a 500kB bar.
I have no doubt that a HN engineer can publish a single .txt file and force gzip-9 compression, however that's not an acceptable blog by any standard.
Last I checked, compression wasn't supported by all browsers all the time. It needs to be done dynamically depending on the settings the browser allows.
nginx or varnish can do that (with more or less correct rules).
In practise, I usually disable compression everywhere and let the CDN handles it.
The CDN is configured to compress on the fly and I am very confident that CloudFlare/Akamai are doing that much better than a broken snippet of nginx settings from stack overflow.
As one would expect, S3 can certainly support various browsers. It ends up being just like content negotiation, in that you have multiple representations that could be served from a particular resource, depending on what headers are sent.
I'm not sure if it's still like that, since I'm not using S3 for that right now.
I'm not an expert by any means, but I think you can manually gzip your content and add rewrite rules to Apache (don't know about other servers) to use the .gz versions. I think this is the only way for compressed content to be cached by Apache, but I'd love to learn if I'm wrong here.
While Medium is a very beautiful, well designed site, it doesn't work equally well for every kind of content out there. Technical content with code snippets are one of the least-suitable type of content for Medium.com design.
No matter how much thought is put into the design of the site, Medium's design is still designed to be a one-size-fit-all kind of product, and well, that means no matter how high quality their design is, it is still taking a somewhat "highest-common-denominator" approach to the design.