Congrats on the launch! I had an initial thought of coming up with a site like this, but decided that providing an open HTML platform was best (hence, https://neocities.org). But I'm happy someone finally scratched the itch.
Random thoughts:
You're going to want to use subdomains for the sites, otherwise all sites are sharing the same domain security model, and you're going to run into problems when (not if, when) a site gets reported for abuse/phishing/spam/ect issues. Path origin security support is years out.
While you're on subdomains, get a wildcard SSL cert and default to it. Neocities started without SSL, and next month I'm paying the price for that sin - we're switching to default SSL and unfortunately it's likely going to break a lot of sites. It's not really a choice anymore, given the political climate and the upcoming pagerank dock from Google.
If the site explodes in popularity, I'm happy to give advice. There's a lot of problems I've solved relating to running a massive web hosting service for a lot of people. Some of it required months of research and some serious firehose drinking to figure out.
Lastly, don't be afraid to ask for money - at least $5/mo, if you go lower you're just crop sharing for the credit card companies. At a bare minimum, throw up a PayPal donation button. I've learned that if you provide a useful service, people will pay you, even if there's an excellent free option. I'd rather pay a small amount to help sustain a service than have it fall apart from lack of funds and/or dev interest. That's a good thing and it's worth something.
To illustrate the importance of at least a donation button: HN users donated over $4000 to us on launch, and I ran the site on that budget for almost two years. Site possibly wouldn't exist today without HN support. Sometimes the comment sections betray this (I'm including myself in this statistic), but kind hearted, wonderful people lurk here.
A year and a half ago, I was looking for a place that would allow me to host a single HTML page for free. A couple of shady free hosting sites later, I came across Neocities. It was a breeze to set up an account there and host a short story of mine in HTML format.
I found myself giving out the link to anyone who'd like to check it out, without needing to e-mail them a PDF (or even worse, a Word document). I like nice typography and readability so sending a simple text file was not the ideal option either. But a link to a page was perfect: it displays well on every device and the page can easily be updated. I wrote the whole thing in Markdown and hacked together a short script to generate HTML from it, which I could easily drag-n-drop to Neocities for quick iteration based on remote people's feedback.
I never wrote again, but if I did, I'd definitely use the same method. An open platform for HTML publishing is essential to keeping the spirit of the minimalist, hyperlink-driven Web alive.
incredible response. Thank you for the effort. Quite an eye opener. Like didn't think about subdomains that way - valuable insight. SSL is top3 on my todo list. Currently I charge extra for the domain - seems to be a simple way of doing it. Donations? Wow didn't think that could be so supportive.
I'll be sure to contact you as soon as the need comes again. You seem to be a valuable resource indeed :)
this sounds interesting. what kind of problems occur in domain hosting? i would assume a lot of them can be solved today with a combination of amazon s3, cloudfront and cloudflare.
even scale probably does not come into the picture.
is it stuff like custom domains (which i assume is nginx+lua magic)
My major critique is that the generated sites are needlessly javascript powered. Right when I saw the "Loading" I thought oh no how many assets are going to be downloaded... for just markdown content.
I guess I'm just an old web 1.0 guy but I just don't see and understand why everything must be done in a super dynamic way. Hell sometimes I like clicking on a link and watching the browser do the loading as it is confirmation for me the thing actually got loaded. Particularly when buying/shopping for stuff (ie traditional POST).
I keep waiting for someone to write a program that consumes as input Markdown text and emits as output a pure HTML/CSS site literally like this http://bettermotherfuckingwebsite.com/ except with the text from the Markdown file instead of swear words. Maybe it could even accept several Markdown files and make them into blog posts or something.
If nobody else does I guess eventually I'll get fed up and build it myself :\
Plenty of static site generators, as they're called, exist to do this. Good jumping-off points would be investigating Jekyll (written in Ruby) and Hugo (written in Golang).
I agree. In Hugo's case there wasn't even a way to generate a completely static website for the longest time (i.e. not a blog or anything like that) and I'm not even sure they've fixed it yet.
You can generate a HTML fragment, or an HTML file, or HTML with table of contents, CSS, and footer, etc. http://pandoc.org/demos.html
It has some pretty heavy dependencies, but so far I haven't found anything better for generating a true static site from Markdown. I probably haven't looked hard enough either.
The only thing more fragile and hard to setup than a static site generator is probably pandoc. All of these are terrible Yak Shaving opportunities. Yet, I still do it.
I use it a lot, I've collected of quite large collection of long form articles/"opinion pieces"/etc from websites and used pandoc to translate them into epub. (after manually pruning some html)
Instead of HTML/CSS why not parse markdown to a something even more direct like terminal output. My biddle application does this. Try it out let me know what you thing. Here are some commands to get started:
git clone git@github.com:prettydiff/biddle.git
cd biddle
node biddle (parses the readme.md file to the terminal)
node biddle get http://example.com/document.md
node biddle markdown downloads/document.md
node biddle markdown downloads/document.md 60 (word wrap at 60 character width)
Pandoc does this. However I've found that you really quickly run into limits. I prefer a slightly-more-elaborate-but-still-no-database solution like Kirby. Throw it onto any budget web hoster with php enabled and you get easy Markdown-based content management, but still separation of content and templates, plugins for a contact form or picture gallery etc.
Lately I was searching for static site generator that would require no configuration. It is written in single file of straightforward go. It gives you just two sections: posts and pages.
If you don't want anything complicated you could actually use Pandoc to generate the HTML for you. Then you could either insert the resulting HTML into a layout template yourself or have Pandoc do it (by creating a template for Pandoc).
EDIT: Oops, Pandoc was already mentioned. I should have refreshed the site.
There is server side templating and asynchronously loaded js. Just because it loads quickly and efficiently and without massive js bloat does not mean it isn't useful or dynamic
yep, i completely agree. The only reason it's JS heavy is because it's a MVP. If this project turns out well it will end up being a simple HTML with bare-minimum javascript.
At first I agreed with many of the other posters, that this just had more overhead than it needed, so I didn't take it seriously.
But when I saw this comment, I got it.
It's an MVP! You launched it before it was ready, but not before you were ready. Which is exactly what we're supposed to do. Grow a thick skin, share it, and take your lumps. This way, your baby will grow up much faster than it would have it you went it alone.
Many of us here, including myself, are too chicken to do that as early as we should. Thank you for showing the way.
> Even though the site is simple development time has been severely dropped thanks to choosing a fairly heavy platform.
I don't think it is because the platform is "heavy" (I assume in productive features) but rather it is what you are probably most recently familiar with.
For example I have built similar CMS tools for internal documentation with Java + Postgres (markdown and mustache.java) in less than a day. The development time was quick because I know Java and SQL... and basic HTML + request response handling.
The fact is it is even easier to pump this stuff out if you don't do Javascript heavy stuff because you can use so many different languages for basic HTTP + HTML + storage. Hell you might even be able to have a RDBMS (like postgres) with a couple plugins itself power the whole thing.
The development time has been severely increased thanks to a poorly choosen and heavy platform.
A Minimum Viable Product could be done in a few minutes with pandoc, a popular and standard tool that supports markdown to html conversation out of the box.
Add a few CSS styles and here you go! Awesome looking static pages, with 0 javascript whatsoever, based on proven battle-tested software ;)
Like any MVP, time to market almost solely depends on your knowledge of the tooling. If the OP is familiar with what they've used, then I'm comfortable trusting that it's faster for them instead of having to learn something new.
I really like your attitude in these comments. Rather than get defensive, you seem to be open to suggestion and not afraid to admit that there may be a better way to do things and that you still have things to learn.
I've learned a great deal reading these comments, so thank you for posting your project.
> I think it's completely fine to use JavaScript here. It would be nice to have instant page pushes.
I'm not sure I follow on the instant page pushes. Are you talking about a little dialog that pops up and "says a new version of the page" kind of thing?
Second is there features you saw that required Javascript (as it appeared to me most could be done with CSS)?
And no I don't think it is "completely fine" to use JavaScript particularly if you are trying to spread the word as quickly as possible and don't care about looks (ie most devices, loads fast, low power). There are also a growing amount of people that have Javascript disabled in general.
One solution is to just send all the linked pages on first load (all the markdown content, so when transitioning they only load images, or of seen before get them "from cache").
I think in this case "page push" means that changes get sent automatically to the client via javascript (as opposed to "pulling" changes by pressing refresh.
Completely useless for static sites, but nice to have while authoring.
I have many informational websites like http://www.krister.ee and sometimes I register domains on a whim when I get a really good idea for a website. I decided to create a simple tool to help manage these microsites and in addition to buying a domain I can immediately fill it with demo-content using markdown.
Before I get into feature creep (hero image, forms, analytics) I'd like to work on reaching an audience. Problem is, I'm not sure who would appreciate it. I know it's a useful tool so any tips on how to spread the word is greatly appreciated.
Your target market is somebody that wants to create lots of minimalist websites quickly. (those creating one personal website whose priority is getting things done likely skip the "evaluate best alternatives" step and go straight to Tumblr/Wordpress or their favourite social network.)
Unfortunately, apart from polymaths that just want to share their expertise on as many discrete subjects as possible which I'm not convinced is the biggest target market, it's probably blogspammers and astroturfers...
I think there is some overlap with Jekyll.
Personally, Jekyll works better for me atm, as it produces static content, can be hosted for free on github or cheaply on s3 and has a bigger community and backing of github engineering. So perhaps, it's worthwhile to try and figure out jekyll-lite or something like that?
For me setting up jekyll was a pain, I had to get ruby, rubygems, jekyll itself and then a manual config intervention to make it work for me.
If this could be simplified that would be a huge improvement.
I personally use Hugo, written in Go rather than Ruby, Jekyll eats up CPU in a very weird way when you run it as a server, don't like my lap on fire after I fire it up. Also love Mkdocs, for static doc creation.
I'm using Jekyll right now and I'm surprised how slow it gets. With only about 20 pages with a few shared includes and a few loops on some pages build times quickly climb to a few seconds. The only advice I'm finding for this issue is to avoid loops and Liquid tags.
It's interesting you'd use jekyll server rather than just to generating static pages. If I wasn't just using an engine server anyway I could see the appeal of hugo.
I don't use the server. It's just when you are working on a static site it's nice to have it constantly update. Hence the server. Hugo auto-reloads the page every time you save. Makes for a good experience to preview what you are doing. Suppose you could use a specific Markdown editor instead to preview the changes.
I've been working on a Jekyll-like system for fun over the past couple of weeks. I've tried to make it as painless to install as possible, but it does require Python 3.
I will look at it anyway, but the #1 issue with hugo/pelican is that they essentially force you into the "you have posts and you have a homepage that embeds posts" logic. It's super annoying.
Jekyll has a ton of issues but it gets it right at least: any page you make becomes a page on the site.
I couldn't agree more – after reading a recommendation for hugo I spent hours browsing its docs thinking "So how the hell do I build a simple static website?!"
It'd be cool to make use of their current templates and input the content in for them then. I have never actually used Jekyll though so I don't know if my understanding translates to practicality or even makes any sense.
Can you give a quick summary of how it works? Who are you using to host? Didn't see any info in the About section.
Realize you're saying you don't want to add any features but some quick mobile optimization to make the links more readable / clickable on a small screen would go a long way.
It's a meteor.js app with React.js at the front. Namecheap to buy domains and Braintree to handle payments. Hosting on Scalingo (awesome service btw). Hmm.. what else.. the chat plugin is tawk.to - be sure to check that out.
I'll be sure to improve the mobile view soon, thanks for the comment!
I can't recall the exact details, but I did try to use as few services as possible. I think the problem was something about how namecheap's pricing model worked. Or was it the site that didn't have a customizeable paying popup. Not sure, tried quite many different services many months ago.
My first thought was Github Pages + Jekyll + a Jekyll template. And then it's been wrapped in a script that has the domain name bonus.
Not saying what you're doing isn't a good idea; I'm just not quite sure where the big distinction (and attraction) is. Is it that the process is more shrink-wrapped?
I've always thought something like this would be useful if properly narrowed to a particular niche, where creating a simple, informational site quickly and easily is useful (i.e. local restaurant menu). Would likely want to include templating of some kind.
This is excellent. There has been a lack of tools to solve this exact problem - wanting to get a basic site up very quickly and cheaply.
Previously the best alternative was a free Firebase/Google account, and then setting up a HTML/CSS site, and deploying it.
This is much faster.
Thank you for building it!
And please, don't be dissuaded by the other commenters. Sure, the market is much smaller than the market that Squarespace et al are targeting, but you're solving your own problem, and there are at least a few others that share that same problem!
Problem this solves: People who want to quickly register a domain and get a text landing page up.
Side note: I wish Medium.com could set up a specific blog post as the home page for a publication with a custom domain
Or I wish I could get a custom domain for Quip.com notes
Sounds like you're looking for something similar to what i just released today. It's a service called Idnty and let's you create a simple and clean personal page in no time. No custom domains yet but it's in the pipeline. Please have a look, https://idnty.me
Really cool. I don't want to create an account just to try it out though, maybe letting users play around until they are satisfied would give a better sign up conversion rate? (Although the video itself is great).
Just a thought, not sure if good or viable. But maybe let users buy their designs for self-hosting would be an idea.
Thanks for some really good feedback! Your idea about signup after trying it out is spot on. I will probably implement that straight away. Self-hosting is interesting as well, never thought of that, but might be an alternative way to go.
And yes, this looks good for me. I won't use it for a personal homepage, I'll use it for other sites, but seems easy to use it for non-personal homepage sites too.
Making a modern, responsive, mobile-aware website seems like a huge learning curve right now.
It would be great if there was a tool that let you use simple markdown, took a few options, and generated beautiful static pages like e.g. Medium with a minimum of hassles.
I guess a lot of people use WordPress with themes, or Weebly, SquareSpace but it still seems pretty complicated.
While Jottit is great and representative of yet another cool thing Aaron contributed to the world, it occasionally goes down for days, or even weeks at a time.
Oh, yeah. It's also currently incredibly slow to load for me. I wouldn't recommend that anyone use it at this point. Just pointing out an example of a similar service for comparison. It doesn't do much, but the UI has some serious polish.
If you want to roll your own, I have a Docker image that pulls Markdown out of git, runs Hugo over it and pushes the site to an S3 bucket. Also works with Bitbucket pipelines so you can get a site rebuild with a simple git push: https://github.com/rabidgremlin/hugo-s3
I have a very small server running Apache, with mod_markdown installed. .md files are rendered as HTML by Apache, and there's a CSS file to tweak if I feel like it.
That's similar to how I used to do it it but I got tired of paying for servers.... plus this approach let me play some "buzzword bingo"
BTW my first Internet facing thing was a CGI-BIN Perl script delivering call records for telcos, way back in 1995. I've been cutting code for 35+ years. Never feel old!
I have several almost-zero-traffic sites running from an Odroid (ARM board) at home. The largest site has only 30k requests in the Apache log for October, but it's a photo gallery, so there's 150GB of pictures behind it. There's also a backup of my desktop, which is another 2TB or so.
I set its ancestor up when I was about 16, using Debian -- and invested a fair amount of time in it, learning a lot.
When I bought it in 2013, the cost of cloud storage for a few years was far greater than the cost of the board + a hard drive, but setting up the obscure hardware took more effort than I expected. Nevertheless, I have no plan to switch to cloud services. I like owning my own stuff, and keeping the flexibility to add whatever service I need on the network at home is very useful. For example, I can SSH into it, and control my fancy central heating system, and a while back I added a UPNP media server, which can stream to a Chromecast.
I run uBlock and got a message saying the site is down. Disabled it and got it to work.
I think one way to differentiate yourself in this kinda area is making it run without any backend tech like jekyll, python, etc. Make it run client-side only. Just my 2 cents.
good point. it's something I myself would also like. I'll have a think about this.
I'll also have a look at ublock. I also use it, haven't had problems. Maybe you tried exactly when the site was down. Had overload problems for a few minutes.
I dunno if it will help, besides maybe for some ideas, but when I created my blog a year or so ago, I wanted something like a site generator without running anything on the backend.[1] I ended up doing everything in CSS/HTML/JS/JSON. JSON is used to store posts. I write a post normally using HTML, then use a tool to format it for JSON. Doing it this way allows my static site to run amazon for dirt cheap. Updating the site is just uploading a new JSON file.
I wish I would've developed it further to allow for markup to be used, but other projects always come up.
Let me suggest Classless Themes[1][2] and its approach to theming that only switches a CSS file to transform the same HTML into multiple different themes. It's ideal for setups like that, where your user want themes, but you can't allow him to touch the HTML templates.
I like to make a markdown as well as a site. It's usually different each time, which keeps things interesting. This isn't a problem for me as the number of sites I make is limited by the number of domains I have.
I'm interested in that domain part. How can I buy a domain through this thing? Will it own my domain or will I be able to move the domain and use it for different things in the future? How?
That's not a markdown problem. Its a consequence of using markdown within a framework, generator, etc that uses frontmatter or an equivalent to define meta data.
Several frameworks and tools allow for markdown and static site rendering that also support an admin UI where one can define this data more easily.
My favorite setup though is middleman + contentful + codeship. Static site generation happens with middleman. Content management happens with Contentful. Publishing happens with codeship.
There's no greater metaphor for the detachment of the tech-elite from the average user than the pervasiveness of Markdown. Its a poor answer to a problem that exists solely because of lack of coordination among the very tech-elite who rely on MD.
An open spec for efficient binary encoding of formatted text is the thing we've needed for 20 years - not more MD tools.
A major point of markdown is that it is not a binary format and can be read anywhere without a dedicated markdown viewer. Personally I absolutely hate rich text editors, because they try to be smart with formatting, text adjacency, and copying.
I have two questions:
1) What's the problem that's being solved?
2) And what's a good answer?
I'm genuinely curious because I've never considered Markdown anything more than a way to more easily render text -- which it seems to do fine. But, maybe I've just exposed myself as an average user..
1) See here[1] - problem very specifically being solved is lack of readability of HTML (and HTML being the only open portable spec for formatted text).
2) A good answer is another, more efficient open spec for encoding formatted text - meaning I can use any app to format my text, then open it in another app and be sure I have full fidelity. This fidelity would be constrained by a requirement of HTML output.
> An open spec for efficient binary encoding of formatted text is the thing we've needed for 20 years - not more MD tools.
How would this improve anything? Is there something about Markdown that makes it inherently inferior that I don't know about? I don't consider myself a tech-elite and Markdown seems just fine to me.
Great idea, but the design would have to be significantly more attractive for me to use it for most of the things that would immediately spring to mind.
That's a solvable problem, though - grab some top-flight themes with appropriate licenses and you're probably good to go!
Markdown has two substantial benefits: Easy to store format that is easy to convert into HTML.
All native support would do is lot in a specific Markdown feature set, specific markdown styling, and specific Markdown syntax.
If you then tried to make a browser supported subset of Markdown that you then allowed to be customised, you'd wind up with so much goop that nobody would be happy.
Random thoughts:
You're going to want to use subdomains for the sites, otherwise all sites are sharing the same domain security model, and you're going to run into problems when (not if, when) a site gets reported for abuse/phishing/spam/ect issues. Path origin security support is years out.
While you're on subdomains, get a wildcard SSL cert and default to it. Neocities started without SSL, and next month I'm paying the price for that sin - we're switching to default SSL and unfortunately it's likely going to break a lot of sites. It's not really a choice anymore, given the political climate and the upcoming pagerank dock from Google.
If the site explodes in popularity, I'm happy to give advice. There's a lot of problems I've solved relating to running a massive web hosting service for a lot of people. Some of it required months of research and some serious firehose drinking to figure out.
Lastly, don't be afraid to ask for money - at least $5/mo, if you go lower you're just crop sharing for the credit card companies. At a bare minimum, throw up a PayPal donation button. I've learned that if you provide a useful service, people will pay you, even if there's an excellent free option. I'd rather pay a small amount to help sustain a service than have it fall apart from lack of funds and/or dev interest. That's a good thing and it's worth something.
To illustrate the importance of at least a donation button: HN users donated over $4000 to us on launch, and I ran the site on that budget for almost two years. Site possibly wouldn't exist today without HN support. Sometimes the comment sections betray this (I'm including myself in this statistic), but kind hearted, wonderful people lurk here.
Good luck.