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 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.
Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
71–80 of 97 posts
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#72Shameless 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
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.
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.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#73Earlier quoted context omitted.
> > 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…
Even with js turned on, I get a mostly blank page. It chokes on String.prototype.endsWith, which is an ES6 feature not supported by my very-slightly-out-of-date version of Safari. If you want to render your blog in client side js AND use fresh-from-the-oven js features, the least you can do is include a polyfill.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#74Earlier quoted context omitted.
> 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…
> > 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…
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#75Earlier quoted context omitted.
> 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.
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)
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#76Earlier quoted context omitted.
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.
After about 20 seconds of googling chrome: https://www.cvedetails.com/cve/CVE-2011-1186/ firefox: https://www.cvedetails.com/cve/CVE-2015-4509/
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#77Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#78Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#79Earlier quoted context omitted.
Make sure your config has your Github username and repo name. Looks like it's blank according to the console.
updated that, still cannot get pages or posts to work. bummer...
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#80Cool. 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…
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.