Well how is this intended to be 'content manage'd? Through pr's on github?
I think CMS is a poor choice for a name, when there is no interface to 'build' the site's pages. I'd call it something like 'website generator backed by github'.
Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
31–40 of 97 posts
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#32Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#33Earlier quoted context omitted.
Where do we stand on the whole SEO issue at hand? I recall Google experimenting with it a few years ago but have not heard much back since.
Google has been able to handle javascript in pages for a while now: http://searchengineland.com/tested-googlebot-crawls-javascri...
Unfortunately Facebook, Twitter, slack, and others can not ... Yet?
Maybe that's not directly SEO but it is indirectly. Good open graph data makes links, at least on Facebook, arguably more compelling which makes them more likely to be clicked and/or shared which may lead to better SEO
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#34Although this is a cute little project, isn't the name rather misleading?
Instead of a generator isn't this actually a markdown to HTML renderer?
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#35Cool. I'm actually building something very similar @ http://evanplaice.com . I use Markdown/JSON for all of the content. Markdown files can easily be embedded in a page using the directive I wrote. The source is @ http://github.com/evanplaice/evanplaice.com . I'm planning to eventually extract the good bits, and adapt it to work with Jekyll files. Front-matter support is the last major road block. Google shouldn't ha…
You should know that your page was blank for about 20 seconds. I nearly closed it.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#36Although this is a cute little project, isn't the name rather misleading? Instead of a generator isn't this actually a markdown to HTML renderer?
I got rather confused by the title. My first thoughts were:
"A static site generator that runs entirely client-side? How's that possible? Surely it needs to write to the server at some point..."
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#37I know there seem to be two rather large groups on HN, one for proliferation of JS and one against, but at the very least if someone from the latter visits your site, please show something better than an entirely blank page . (I'm speaking of the demo, not the actual site describing it --- although I thought it would be hosted with itself.) As for the idea of turning static content sites into client-side JS-rendered…
> an entirely blank page That's only true if you use 'view source'. If you open up dev tools, all of the elements are rendered in full and live updated as they change. Client-side rendered apps are quickly becoming every-where rendered apps. They can now work isomorphically, on the desktop, and on mobile. > every single visitor has to regenerate it on their machine This is a false premise. For server-side view render…
> We're moving past the days of the static web.
As much as I like site generators and I'd find this a good idea for some purposes I wouldn't state it is a replacement for static sites generators.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#38I guess this technology is promising in a way that it delivers websites to be read by humans only, not the bots. I fail to recognise the practical use of it unless building the most unknown blog in the world, since obviously site on cmsjs is not going to be indexed by google like your ordinary wordpress blog. But, there is something to it. Something important. Blog for humans, readable only by humans, kinda timely in…
google indexes dynamic content no problem
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#39Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#40I think this project is cool but it's all of the problems of dynamic sites with none of the benefits. It's like if you took the worst parts of Jekyll (having to redeploy to update content) and the worst parts of a dynamic single page app (rendering delay), and took both parts. There is no benefit to this sort of infrastructure.