
Show HN: CMS.js – Fully Client-Side JavaScript Site Generator - inflam52
http://cdmedia.github.io/cms.js/
======
userbinator
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
> 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.

~~~
rimantas

      > They can now work isomorphically, on the desktop, and on
      > mobile.
    

So can plain HTML. Without any needless scripting.

    
    
      > We're moving past the days of the static web.
    

We are not. Maybe you are, we can wait till you come back.

    
    
      > Especially, now that it's trivial to pull data from many
      > different sources on the client-side.
    

HTML is even more trivial.

~~~
nqzero
HTML (or more specifically HTML+css, and how they interact with and render in
the browser) are anything but trivial. javascript (the language, not the JIT)
is relatively simple in contrast

client side rendering + json apis on the server are the holy grail of openness
(esp with an MIT licensed client)

~~~
falcolas
Building a webpage node by node from within Javascript does not lessen the
complexity of HTML and CSS, it simply adds to it. You're doing the exact same
things - creating DOM nodes with attributes - but with yet another level (or
5) of indirection.

~~~
EvanPlaice
The point is, generate views ONLY on the client.

Excess layers of indirection come when you try do view generation on both the
server and the client.

Many server frameworks currently follow this approach. Generate the view
scaffold using templates on the server-side. Then request partials
asynchronously on the client and generate additional views client-side using a
completely different framework.

Shifting all of the view generation to the client frees up the back-end devs
to focus all of their time/effort on the important part. Building and scaling
the data infrastructure.

Not to mention, shifting the view layer client-side reduces resource
requirements on the back-end.

The previous generation of front-end SPA frameworks frankly sucked in terms of
performance, leading to a bad user experience. There were 2 primary reasons
why. All data persistence/binding happened directly on the DOM, and all
execution was handled on the main execution thread.

The latest generation greatly improves the experience by using new techniques
such as data persistence/diffing via the virtual DOM, and handling all non-
rendering logic on a background worker thread.

------
mikegerwitz
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)

~~~
roblabla
I'm pretty sure there's no "intended way" to use the web. The developer of the
website dictates this. If he wishes to use JS-only, that is his choice. He may
lose you as a user/reader, but he certainly is using the web "as intended".

The choice to block JS seems a bit weird to me. JS, to my eyes, is very
different to binary code running in userland. It is a sandboxed language with
very clear restrictions to what it may do, it is easily read and verified
(view source, pass it through a prettifier, and all that's left to fix is the
variable names), and even hackable (we get a JS console in browsers).

What is it that makes JS so dangerous it must be blocked 100% ?

~~~
dyladan
Many browser exploits that break out of the sandbox take advantage of
javascript. Disabling it prevents entire classes of exploits. Also, a lot of
ad networks use javascript as a tracking tool.

~~~
dyladan
After about 20 seconds of googling

chrome:
[https://www.cvedetails.com/cve/CVE-2011-1186/](https://www.cvedetails.com/cve/CVE-2011-1186/)

firefox:
[https://www.cvedetails.com/cve/CVE-2015-4509/](https://www.cvedetails.com/cve/CVE-2015-4509/)

~~~
andrewstuart2
I don't think most people would consider 2011 recent.

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

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

~~~
thallian
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
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.

------
sotojuan
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
You probably want to look at Hexo - [https://hexo.io/](https://hexo.io/)

~~~
minhajuddin
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.

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

------
fiatjaf
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)

~~~
EvanPlaice
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
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.

------
EvanPlaice
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
You should know that your page was blank for about 20 seconds. I nearly closed
it.

~~~
kecks
Took 6 seconds on a Samsung Galaxy S6, Firefox. I definitely would've closed
the tab if I hadn't read this.

~~~
EvanPlaice
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.

------
unicornporn
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
Very cool. Thanks for sharing! I never saw this. Definitely going to check it
out.

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

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

------
tuananh
does it affect site's SEO?

~~~
zwetan
do a view source and take a guess, off course it will affect the SEO

but hey no problem it's JS, so to correct that SEO problem they will probably
do a whole render of the page server-side with something like PhamtomJS and
serve those "special" pages to bots

which I think is totally insane

~~~
BHSPitMonkey
Google renders JavaScript when it crawls.

~~~
sergiotapia
Source please.

~~~
ajdlinux
[https://googlewebmastercentral.blogspot.com.au/2014/05/under...](https://googlewebmastercentral.blogspot.com.au/2014/05/understanding-
web-pages-better.html)

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

------
danielovich
i can't get it to run.

it's cloned to danielovich.github.io but then it breaks!

:/

~~~
inflam52
Make sure your config has your Github username and repo name. Looks like it's
blank according to the console.

~~~
danielovich
updated that, still cannot get pages or posts to work.

bummer...

~~~
inflam52
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
You rock! Thank you

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

