9 ms·

Show HN: CMS.js – Fully Client-Side JavaScript Site Generator

117 points by inflam52 11y ago

fiatjaf 11y ago
Shameless self-promotion: For easy theming, I suggest you to take a look at the Classless Project, which will be super easy to integrate to in your case and will bring many already made themes with it -- and much more to come. The ursprung[2] micro CMS is integrating Classless with success to this day. [1]: https://github.com/websitesfortrello/classless https://github.com/websitesfortrello/classless [2]: https://github.com/onli/ursprung https://github.com/onli/ursprung
- inflam52 11y ago
  Thanks for the suggestion. Looks very cool. I'm definitely going to take a deeper look into this.
- EvanPlaice 11y ago
  Awesome collection. I'll have to find an excuse to use one of these now. The only thing I'd suggest is, use ES6 instead of CoffeeScript or provide an ES5 copy of the code.
  - fiatjaf 11y ago
    There's no code, it's only a collection of themes based on a "standard" template. The CoffeeScript code you see is for the bookmarklet used on the playground. It is old code, coded in a rush, most for proof-of-concept. I'm slowly rethinking this playground and theme development stuff, so this is going to be replaced.
tuananh 11y ago
does it affect site's SEO?
- ivan_ah 11y ago
  Good question. My guess is it will be OK for the text, but links will be out of whack so bots won't really "crawl" the site. Then again, maybe advanced bots will run the js? also, I know words in h-tags are usually "counted" as more important, so that logic won't work with raw .md
  - zwetan 11y ago
    what text ? there is no text, the page is empty, the linking is not the first priority at this point a robot to be able to read the text would already need to run the js in the first place but the concept is interesting let's do a CONTENT management system but be completely invisible to any search bots so our CONTENT never ever get referenced and searchable on the Internet
    - wingerlang 11y ago
      Hasn't crawlers solved this issue? I know google can crawl "js sites", probably especially simple sites like these. It would probably reduce the score though.
    - NocturnalWaffle 11y ago
      Google has been able to handle javascript in pages for a while now.. http://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157 http://searchengineland.com/tested-googlebot-crawls-javascri...
      - zwetan 11y ago
        yeah Google does but what about the 1000s other robots ? sure Google is the bigger one and you have to be referenced on it, but there are also other indexes where you want to be referenced, and those are maybe not using robots as advanced as google. So, as I said, for your normal robot crawler visiting the page, the page is empty, no content. That Google have already solved the problem does not mean that everyone else did. Why do you think prerender.io exists ? to solve that very same problem From a SEO point of view, which was the question I was answering, it is ridiculous to serve a page without content to an indexing robot crawler. -4 ? go all educate (F) yourself :) I mean here a list of active robots crawler https://udger.com/resources/ua-list/crawlers https://udger.com/resources/ua-list/crawlers here an example of how people apply that in practice https://gist.github.com/Stanback/7028309 https://gist.github.com/Stanback/7028309 also last but not least, yeah GoogleBot parse/read JS, but do read their guidelines https://googlewebmastercentral.blogspot.fr/2014/10/updating-our-technical-webmaster.html https://googlewebmastercentral.blogspot.fr/2014/10/updating-... "Make sure your web design adheres to the principles of progressive enhancement" serving a blank page, that you then fill with content using pushState is not what I call progressive enhancement
userbinator 11y ago
I 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 apps, that gets a strong disapproval from me. Why? It's needless complexity (instead of generating the HTML once and storing it on the server, every single visitor has to regenerate it on their machine), bad for accessibility, and very much against the principle of the Web that information should be easily linkable and retrievable. I can understanding using JS to do "app-ish" things that wouldn't be possible with static pages, but this is reinventing the wheel and making it square.
- EvanPlaice 11y ago
  > 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 rendering, the view is tightly coupled to the data. The majority of the payload will be made up of dynamically generated (and non-ideal for caching) HTML structure. When all the user really needs is data. Rendering apps on the client-side allows fetching partials and content data piecemeal, which is ideal for caching. Views can be cached at the HTTP layer, directly in the app, or both. This will be especially useful once HTTP/2 (ie connection persistence) are in common use. ----- We're moving past the days of the static web. Especially, now that it's trivial to pull data from many different sources on the client-side. What really never make sense was rendering the view on both the server-side and client-side (often times using 2 view template engines). Fortunately, that practice is becoming less common.
  - jaequery 11y ago
    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.
EvanPlaice 11y ago
Cool. I'm actually building something very similar @ http://evanplaice.com http://evanplaice.com. I use Markdown/JSON for all of the content. Markdown files can easily be embedded in a page using the <ng2-markdown> directive I wrote. The source is @ http://github.com/evanplaice/evanplaice.com 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 have any issue indexing AJAX-loaded content. On my site it's the Angular2 router that's really screwing SEO. You can test it out using the 'Fetch as Google' tool.
- afandian 11y ago
  You should know that your page was blank for about 20 seconds. I nearly closed it.
  - kecks 11y ago
    Took 6 seconds on a Samsung Galaxy S6, Firefox. I definitely would've closed the tab if I hadn't read this.
    - EvanPlaice 11y ago
      The combined size of the concatenated js/css files was 1.7mb before compression. Now, both combined are 366KB respectively. The load time should be much better now.
  - plexicle 11y ago
    Oh, it actually worked? I waited a couple seconds and closed it, assuming it was broken.
  - EvanPlaice 11y ago
    Yes, I know. Emphasis on 'working on.' I haven't gotten to optimization yet.
  - EvanPlaice 11y ago
    Try it again.
sotojuan 11y ago
Good work, but why is client-side JS needed for a simple blog? I thought it was going to be like Jekyll but Node instead of Ruby (so no JS client-side).
- manojlds 11y ago
  You probably want to look at Hexo - https://hexo.io/ https://hexo.io/
  - minhajuddin 11y ago
    You can use Hexo with github pages and have automatic deployments using https://zammu.in/hexo?invitation_code=HNZAMMU https://zammu.in/hexo?invitation_code=HNZAMMU Full Disclosure: I built Zammu.
ommunist 11y ago
I 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 the modern days of senseless content aggregators.
- NocturnalWaffle 11y ago
  Google has been able to handle javascript in pages for a while now: http://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157 http://searchengineland.com/tested-googlebot-crawls-javascri...
- thallian 11y ago
  You could use something like casperjs (http://casperjs.org/ http://casperjs.org/) for a bot (I did this to scrape a proboards forum, worked quite well).
- teen 11y ago
  google indexes dynamic content no problem
unicornporn 11y ago
TiddlyWiki[1], which is a wiki more than a "CMS", has been doing something very close to this for quite some time. I used it for years, but eventually switched back to plain text files for notes. I use Jekyll for blogging and generating my portfolio site too, but right now I can only update my those from my own laptop with my Jekyll install which is not always great. CMS.js would be something else... My dream would be a simple PHP based CMS for my Jekyll install though. [1] http://tiddlywiki.com/ http://tiddlywiki.com/
- inflam52 11y ago
  Very cool. Thanks for sharing! I never saw this. Definitely going to check it out.
weisk 11y ago
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'.
faebser 11y ago
Although 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?
- thenomad 11y ago
  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..."
  - inflam52 11y ago
    Yeah, that was kind of my line of thinking. I wanted to originally call it a static site generator but then got a lot of backlash because it was really "static" because of the Javascript.
teen 11y ago
I 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.
danielovich 11y ago
i can't get it to run. it's cloned to danielovich.github.io but then it breaks! :/
- inflam52 11y ago
  Make sure your config has your Github username and repo name. Looks like it's blank according to the console.
  - danielovich 11y ago
    updated that, still cannot get pages or posts to work. bummer...
    - inflam52 11y ago
      ohhh I see what's going on here. since you cloned the demo, you need to use postsFolder: 'demo/posts' and pagesFolder: 'demo/pages' since they are located inside the demo folder. The demo is setup slightly different than a standard setup since it's in the subfolder.
      - danielovich 11y ago
        You rock! Thank you
    - inflam52 11y ago
      Also make sure you are on editing the config.js gh-pages branch as this is the branch Github uses for hosting. If you want to use the code you have on master, just merge master into gh-pages. If you have any more issues, feel free to email me.
shocks 11y ago
Cute project I guess, but this is a terrible idea for the web.
mikegerwitz 11y ago
I don't want to discourage you, but I also don't want to encourage the proliferation of websites (web apps---as an alternative to actual desktop software---excluded) that require JavaScript to function at all. Sites using JS only cannot be parsed by standard tools---I can't cURL the page, use wget, use a text-mode browser, etc. This fundamentally breaks interoperability, and limits users' freedom to use the tool/browsers they want to use the web. Users who wish to disable JavaScript to browse the web---be it for security, privacy, philosophy[0], or all of these things---are forced to either enable JavaScript or not read your website (I fall into the latter). I write more JavaScript than any other language. I understand the community, and the rationale. But I know enough to know that I should disable JavaScript when browsing the web (except for select cases, and the software must be Free), and I still use command-line tools aggressively, even for the web. Please do your best to respect those who use the web as it was intended. Keep hacking, but consider fallbacks, too! [0]: https://www.gnu.org/philosophy/javascript-trap.html https://www.gnu.org/philosophy/javascript-trap.html
- dyladan 11y ago
  It really depends on the use case. My site[0] works in a very similar fashion to cms.js but if you have javascript disabled it forwards you to the raw markdown file using a simple noscript tag. Sure, it breaks cURL but it's just a personal website so who really cares? [0]: https://dyladan.me https://dyladan.me
  - inflam52 11y ago
    Yeah that was kind of my line of thinking. This is definitely not ready for enterprise level blogs yet...more along the lines of personal sites/small blogs you want to get up and running quickly.
  - mikegerwitz 11y ago
    I get most of my useful information and perspectives from personal websites---be it various well-respected experts in the fields, or people that nobody really knows about, but have great information or perspectives. In software development especially, our community of hackers is our most valuable asset.
sasindu 11y ago
Both the name and description are completely misleading. They suggest that this app is a web UI for managing content and doing what Jekyll does from CLI. But this really is a SPA that can grab markdown files from your Jekyll site hosted on Github or a Apache web server, convert them to HTML and render on client site with JS. What is the point?
programminggeek 11y ago
This looks interesting. I'm not in love with the name. That said, I love all static site generators. Unfortunately, hosting a static site isn't much fun, so I created http://www.statichosting.co http://www.statichosting.co to make it easier. It's in beta and we are getting close to launch, but have a few bugs to work out. Would love to have anyone give feedback on it as it develops.
asimjalis 11y ago
Here is why I like this: It makes publishing to the web trivial.

117 points by inflam52 11y ago

Shameless self-promotion: For easy theming, I suggest you to take a look at the Classless Project, which will be super easy to integrate to in your case and will bring many already made themes with it -- and much more to come. The ursprung[2] micro CMS is integrating Classless with success to this day. [1]: https://github.com/websitesfortrello/classless https://github.com/websitesfortrello/classless [2]: https://github.com/onli/ursprung https://github.com/onli/ursprung

inflam52 11y ago
Thanks for the suggestion. Looks very cool. I'm definitely going to take a deeper look into this.
EvanPlaice 11y ago
Awesome collection. I'll have to find an excuse to use one of these now. The only thing I'd suggest is, use ES6 instead of CoffeeScript or provide an ES5 copy of the code.
- fiatjaf 11y ago
  There's no code, it's only a collection of themes based on a "standard" template. The CoffeeScript code you see is for the bookmarklet used on the playground. It is old code, coded in a rush, most for proof-of-concept. I'm slowly rethinking this playground and theme development stuff, so this is going to be replaced.

tuananh 11y ago

does it affect site's SEO?

ivan_ah 11y ago
Good question. My guess is it will be OK for the text, but links will be out of whack so bots won't really "crawl" the site. Then again, maybe advanced bots will run the js? also, I know words in h-tags are usually "counted" as more important, so that logic won't work with raw .md
- zwetan 11y ago
  what text ? there is no text, the page is empty, the linking is not the first priority at this point a robot to be able to read the text would already need to run the js in the first place but the concept is interesting let's do a CONTENT management system but be completely invisible to any search bots so our CONTENT never ever get referenced and searchable on the Internet
  - wingerlang 11y ago
    Hasn't crawlers solved this issue? I know google can crawl "js sites", probably especially simple sites like these. It would probably reduce the score though.
  - NocturnalWaffle 11y ago
    Google has been able to handle javascript in pages for a while now.. http://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157 http://searchengineland.com/tested-googlebot-crawls-javascri...
    - zwetan 11y ago
      yeah Google does but what about the 1000s other robots ? sure Google is the bigger one and you have to be referenced on it, but there are also other indexes where you want to be referenced, and those are maybe not using robots as advanced as google. So, as I said, for your normal robot crawler visiting the page, the page is empty, no content. That Google have already solved the problem does not mean that everyone else did. Why do you think prerender.io exists ? to solve that very same problem From a SEO point of view, which was the question I was answering, it is ridiculous to serve a page without content to an indexing robot crawler. -4 ? go all educate (F) yourself :) I mean here a list of active robots crawler https://udger.com/resources/ua-list/crawlers https://udger.com/resources/ua-list/crawlers here an example of how people apply that in practice https://gist.github.com/Stanback/7028309 https://gist.github.com/Stanback/7028309 also last but not least, yeah GoogleBot parse/read JS, but do read their guidelines https://googlewebmastercentral.blogspot.fr/2014/10/updating-our-technical-webmaster.html https://googlewebmastercentral.blogspot.fr/2014/10/updating-... "Make sure your web design adheres to the principles of progressive enhancement" serving a blank page, that you then fill with content using pushState is not what I call progressive enhancement

userbinator 11y ago

I 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 apps, that gets a strong disapproval from me. Why? It's needless complexity (instead of generating the HTML once and storing it on the server, every single visitor has to regenerate it on their machine), bad for accessibility, and very much against the principle of the Web that information should be easily linkable and retrievable. I can understanding using JS to do "app-ish" things that wouldn't be possible with static pages, but this is reinventing the wheel and making it square.

EvanPlaice 11y ago
> 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 rendering, the view is tightly coupled to the data. The majority of the payload will be made up of dynamically generated (and non-ideal for caching) HTML structure. When all the user really needs is data. Rendering apps on the client-side allows fetching partials and content data piecemeal, which is ideal for caching. Views can be cached at the HTTP layer, directly in the app, or both. This will be especially useful once HTTP/2 (ie connection persistence) are in common use. ----- We're moving past the days of the static web. Especially, now that it's trivial to pull data from many different sources on the client-side. What really never make sense was rendering the view on both the server-side and client-side (often times using 2 view template engines). Fortunately, that practice is becoming less common.
- jaequery 11y ago
  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.

EvanPlaice 11y ago

Cool. I'm actually building something very similar @ http://evanplaice.com http://evanplaice.com. I use Markdown/JSON for all of the content. Markdown files can easily be embedded in a page using the <ng2-markdown> directive I wrote. The source is @ http://github.com/evanplaice/evanplaice.com 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 have any issue indexing AJAX-loaded content. On my site it's the Angular2 router that's really screwing SEO. You can test it out using the 'Fetch as Google' tool.

afandian 11y ago
You should know that your page was blank for about 20 seconds. I nearly closed it.
- kecks 11y ago
  Took 6 seconds on a Samsung Galaxy S6, Firefox. I definitely would've closed the tab if I hadn't read this.
  - EvanPlaice 11y ago
    The combined size of the concatenated js/css files was 1.7mb before compression. Now, both combined are 366KB respectively. The load time should be much better now.
- plexicle 11y ago
  Oh, it actually worked? I waited a couple seconds and closed it, assuming it was broken.
- EvanPlaice 11y ago
  Yes, I know. Emphasis on 'working on.' I haven't gotten to optimization yet.
- EvanPlaice 11y ago
  Try it again.

sotojuan 11y ago

Good work, but why is client-side JS needed for a simple blog? I thought it was going to be like Jekyll but Node instead of Ruby (so no JS client-side).

manojlds 11y ago
You probably want to look at Hexo - https://hexo.io/ https://hexo.io/
- minhajuddin 11y ago
  You can use Hexo with github pages and have automatic deployments using https://zammu.in/hexo?invitation_code=HNZAMMU https://zammu.in/hexo?invitation_code=HNZAMMU Full Disclosure: I built Zammu.

ommunist 11y ago

I 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 the modern days of senseless content aggregators.

NocturnalWaffle 11y ago
Google has been able to handle javascript in pages for a while now: http://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157 http://searchengineland.com/tested-googlebot-crawls-javascri...
thallian 11y ago
You could use something like casperjs (http://casperjs.org/ http://casperjs.org/) for a bot (I did this to scrape a proboards forum, worked quite well).
teen 11y ago
google indexes dynamic content no problem

unicornporn 11y ago

TiddlyWiki[1], which is a wiki more than a "CMS", has been doing something very close to this for quite some time. I used it for years, but eventually switched back to plain text files for notes. I use Jekyll for blogging and generating my portfolio site too, but right now I can only update my those from my own laptop with my Jekyll install which is not always great. CMS.js would be something else... My dream would be a simple PHP based CMS for my Jekyll install though. [1] http://tiddlywiki.com/ http://tiddlywiki.com/

inflam52 11y ago
Very cool. Thanks for sharing! I never saw this. Definitely going to check it out.

weisk 11y ago

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'.

faebser 11y ago

Although 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?

thenomad 11y ago
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..."
- inflam52 11y ago
  Yeah, that was kind of my line of thinking. I wanted to originally call it a static site generator but then got a lot of backlash because it was really "static" because of the Javascript.

teen 11y ago

I 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.

danielovich 11y ago

i can't get it to run. it's cloned to danielovich.github.io but then it breaks! :/

inflam52 11y ago
Make sure your config has your Github username and repo name. Looks like it's blank according to the console.
- danielovich 11y ago
  updated that, still cannot get pages or posts to work. bummer...
  - inflam52 11y ago
    ohhh I see what's going on here. since you cloned the demo, you need to use postsFolder: 'demo/posts' and pagesFolder: 'demo/pages' since they are located inside the demo folder. The demo is setup slightly different than a standard setup since it's in the subfolder.
    - danielovich 11y ago
      You rock! Thank you
  - inflam52 11y ago
    Also make sure you are on editing the config.js gh-pages branch as this is the branch Github uses for hosting. If you want to use the code you have on master, just merge master into gh-pages. If you have any more issues, feel free to email me.

shocks 11y ago

Cute project I guess, but this is a terrible idea for the web.

mikegerwitz 11y ago

I don't want to discourage you, but I also don't want to encourage the proliferation of websites (web apps---as an alternative to actual desktop software---excluded) that require JavaScript to function at all. Sites using JS only cannot be parsed by standard tools---I can't cURL the page, use wget, use a text-mode browser, etc. This fundamentally breaks interoperability, and limits users' freedom to use the tool/browsers they want to use the web. Users who wish to disable JavaScript to browse the web---be it for security, privacy, philosophy[0], or all of these things---are forced to either enable JavaScript or not read your website (I fall into the latter). I write more JavaScript than any other language. I understand the community, and the rationale. But I know enough to know that I should disable JavaScript when browsing the web (except for select cases, and the software must be Free), and I still use command-line tools aggressively, even for the web. Please do your best to respect those who use the web as it was intended. Keep hacking, but consider fallbacks, too! [0]: https://www.gnu.org/philosophy/javascript-trap.html https://www.gnu.org/philosophy/javascript-trap.html

dyladan 11y ago
It really depends on the use case. My site[0] works in a very similar fashion to cms.js but if you have javascript disabled it forwards you to the raw markdown file using a simple noscript tag. Sure, it breaks cURL but it's just a personal website so who really cares? [0]: https://dyladan.me https://dyladan.me
- inflam52 11y ago
  Yeah that was kind of my line of thinking. This is definitely not ready for enterprise level blogs yet...more along the lines of personal sites/small blogs you want to get up and running quickly.
- mikegerwitz 11y ago
  I get most of my useful information and perspectives from personal websites---be it various well-respected experts in the fields, or people that nobody really knows about, but have great information or perspectives. In software development especially, our community of hackers is our most valuable asset.

sasindu 11y ago

Both the name and description are completely misleading. They suggest that this app is a web UI for managing content and doing what Jekyll does from CLI. But this really is a SPA that can grab markdown files from your Jekyll site hosted on Github or a Apache web server, convert them to HTML and render on client site with JS. What is the point?

programminggeek 11y ago

This looks interesting. I'm not in love with the name. That said, I love all static site generators. Unfortunately, hosting a static site isn't much fun, so I created http://www.statichosting.co http://www.statichosting.co to make it easier. It's in beta and we are getting close to launch, but have a few bugs to work out. Would love to have anyone give feedback on it as it develops.

asimjalis 11y ago

Here is why I like this: It makes publishing to the web trivial.