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

http://cdmedia.github.io/cms.js/

by inflam52 • 11 years ago

117 94 11 years ago

cdmedia.github.io

fiatjaf2• 11 years 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

[2] https://github.com/onli/ursprung

inflam5211• 11 years ago

Thanks for the suggestion. Looks very cool. I'm definitely going to take a deeper look into this.

EvanPlaice12• 11 years 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.

fiatjaf2• 11 years 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• 11 years ago

does it affect site's SEO?

ivan_ah• 11 years 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

zwetan4• 11 years 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

zwetan4• 11 years ago

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

onion2k• 11 years ago

A better way of testing the impact of JS on your SEO is to use Google's "Fetch as Google" tool, and use the Fetch And Render mode: https://www.google.com/webmasters/tools/googlebot-fetch

Explanation of it: http://searchengineland.com/how-to-use-fetch-as-googlebot-li...

BHSPitMonkey• 11 years ago

Google renders JavaScript when it crawls.

userbinator• 11 years 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.

EvanPlaice12• 11 years 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• 11 years 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.

yoz-y• 11 years ago

But this is a static site generator. It says so in the title. For dynamic content client & server site rendering makes sense. But there are still many uses for static sites. Blogs, manuals, tutorials pages like Wikipedia, they could and should be rendered once.

lucaspiller• 11 years ago

The majority of the payload will be made up of dynamically generated (and non-ideal for caching) HTML

For a blog or CMS this is probably not the case. The majority of the page is going to be the same for all users. Maybe you have something at the top of tbe page showing the user is logged in, and admin links to edit it, but that's probably about as dynamic as you will get.

Rendering apps on the client-side allows fetching partials and content data piecemeal, which is ideal for caching

Yes.. but why? 99% of websites aren't going to have enough traffic that this would cause load issues on the server. On the client the browser probably does a better job of caching pages than you could.

For something more complicated that a blog or CMS you need to think about security. It's not a trivial task to cache something and securely serve it to only people who have an active session and are authorised to view it.

rimantas• 11 years ago

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

voidr• 11 years ago

Caching cannot help you with initial page loads, which is probably important when you have a content focused sites.

Rendering the content via JavaScript is slower than just having it in your HTML. It's true that JS execution has become insanely fast, however, initial JS execution is not as fast, because it requires that JIT to kick in. Even if JS execution becomes infinitely fast, you still have to work with the DOM, which is horribly slow and there are no known ways to make it fast. Google, Yahoo and others have prove with hard numbers that users care about speed, even when we are talking about milliseconds.

I highly recommend doing some research on how browsers and caching actually work before falling into the pit of false belief.

matallo• 11 years ago

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.

pwg• 11 years 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.

If one attempts to view the demo with client side javascript turned off - one gets a completely blank page. The very point to a static site generator is the word "static" which is generally taken to mean that the actual rendering of the content requires only HTML rendering (no javascript (or php or ??) code execution, server side or client side).

pluma• 11 years ago

React basically invalidates your argument.

Render the client on the server, then push the rendered markup and the client state to the browser where the client takes over again.

This paradigm is fundamentally different from the Angular1-style "render everything in the browser" and "maybe pre-render on the server, then discard that on page load" approach. If anything, it's closer to the traditional "render everything on the server, then apply enhancements in the browser" approach of the pre-SPA days.

dham• 11 years ago

This kind of mindset is the entire reason I wrote "The Sad State of Web Development"

Needless over engineering for displaying text on a page.

S4M• 11 years ago

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.

Yep, and the worse offender seems to be Quora that seems to have its main page receive all its data from java script (which as a side effect makes scrolling annoyingly slow). But it's probably on purpose since they are preventing copy/pasting so it's impossible to quote text from their website without linking to them in some way.

inflam5211• 11 years ago

Thanks for all the feedback! Yeah, this is definitely next on the list of bugs to fix. I definitely respect your opinion. I really looking a way to accomplish this problem from a different perspective using just client-side technologies. It would have been nearly impossible to accomplish this without the aid of Javascript unfortunately (besides just having static HTML of course but that wouldn't be any fun would it!)

plexicle2• 11 years ago

Big proponent of JS myself.

I totally agree with you here.

EvanPlaice12• 11 years ago

Cool. 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 <ng2-markdown> 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 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.

afandian2• 11 years ago

You should know that your page was blank for about 20 seconds. I nearly closed it.

kecks• 11 years ago

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

plexicle2• 11 years ago

Oh, it actually worked? I waited a couple seconds and closed it, assuming it was broken.

EvanPlaice12• 11 years ago

Yes, I know. Emphasis on 'working on.' I haven't gotten to optimization yet.

EvanPlaice12• 11 years ago

Try it again.

opiotrek• 11 years ago

That is truly terrible user experience. Pure example of form over substance.

jackmoore• 11 years ago

I see you are getting some negative feedback, haha. I think the main problem at this point isn't due client-rendering, but the large prerequisite files. Gzipping your JavaScript would trim a MB or more. Putting the static assets on a CDN (or enabling gzip yourself) would cut the render time by 2/3rds.

Semantic UI adds 700KBs of CSS, which seems like a lot more than your site should need. Even if this were a static rendered site, the browser would delay rendering anything until the CSS was downloaded.

EvanPlaice12• 11 years ago

Haha. I figured 'working on' would signal that this isn't 'production ready' yet.

Guess I should choke down my excitement and stay in stealth mode until I'm ready next time.

The entire app is server-less and hosted on a S3 bucket.

Gzipping the content should be an easy addition to the build process.

I'm using approximately 2% of what Semantic-UI is capable of. Fortunately, Semantic-UI provides a set of tools to trim it down to a production-ready bundle.

In addition, Google will likely trim more of the fat from Angular2 in upcoming releases.

The big one I'm concerned about is Rxjs. The size of the lib is massive considering it only provides support for observables and observable extensions.

Trust me, I'm painfully aware of how slow it is right now.

Thanks for the feedback though. I do appreciate it.

EvanPlaice12• 11 years ago

Feel free to try it again. The css and js are now merged and concatenated into one and gzipped. Total size of both is now 366KB

The time to bootstrap the app is about 1.5 seconds. There's room for improvement but I don't expect any massive gains since I can't isomorphically pre-render without a server back-end.

sotojuan• 11 years 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• 11 years ago

You probably want to look at Hexo - https://hexo.io/

minhajuddin• 11 years ago

You can use Hexo with github pages and have automatic deployments using https://zammu.in/hexo?invitation_code=HNZAMMU

Full Disclosure: I built Zammu.

ommunist• 11 years 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.

thallian• 11 years ago

You could use something like casperjs (http://casperjs.org/) for a bot (I did this to scrape a proboards forum, worked quite well).

teen3• 11 years ago

google indexes dynamic content no problem

unicornporn• 11 years 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/

inflam5211• 11 years ago

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

weisk• 11 years 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• 11 years 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• 11 years 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..."

inflam5211• 11 years 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.

teen3• 11 years 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.

danielovich3• 11 years ago

i can't get it to run.

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

inflam5211• 11 years ago

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

danielovich3• 11 years ago

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

bummer...

shocks• 11 years ago

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

mikegerwitz2• 11 years 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

dyladan4• 11 years 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

inflam5211• 11 years 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.

mikegerwitz2• 11 years 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.

roblabla• 11 years ago

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

dyladan4• 11 years ago

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.

PavlovsCat• 11 years ago

Going from a web of documents to black boxes that put pixels on the screen is regression plain and simple. Use it when necessary for the things that cannot be otherwise done, but don't ruin a good thing that works fine just because you can. Thanks.

s986s• 11 years ago

There is an intended way though. Html documents allow for parseable data. We are lucky google now runs javascript, but javascript pages are very similar to flash pages.

inflam5211• 11 years ago

Thank you I really appreciate your feedback! I definitely understand and respect your view on accessibility for those not using Javascript. I was just trying to approach the problem from a different perspective...seeing if there was a way to do accomplish this using just client-side technologies. I'm definitely going to consider looking into fallbacks if they are possible.

sasindu• 11 years 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• 11 years 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 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• 11 years ago

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

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

Related Stories