i can't get it to run.
it's cloned to danielovich.github.io but then it breaks!
:/
Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
41–50 of 97 posts
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#42I 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…
> > 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).
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#43Earlier quoted context omitted.
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
Google has been able to handle javascript in pages for a while now.. http://searchengineland.com/tested-googlebot-crawls-javascri...
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
here an example of how people apply that in practice 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-...
"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
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#44I 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…
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.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#45Cool. 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.
Took 6 seconds on a Samsung Galaxy S6, Firefox. I definitely would've closed the tab if I hadn't read this.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#46Earlier quoted context omitted.
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
Google renders JavaScript when it crawls.
numerous other robots don't
go there http://web.archive.org/web/20160119113309/http://cdmedia.git...
view source, that's what archive.org_bot is referencing eg. no content whatsoever
if/when this site die, when you will browse the link above, you will see a blank page
I would even say that on web.archive.org the effect is even more vicious, if you don't know any better, because you see the page archived you think it is indeed archived when in fact it's not
but don't despair, there are other way to have the exact same result for your SEO
tell me how it is different than rendering the whole page as Flash SWF file ?
GoogleBot can read/parse SWF and even understand when dynamic text/xml is loaded https://googlewebmastercentral.blogspot.fr/2008/06/improved-...
since 2008
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#47Cool. 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…
That is truly terrible user experience. Pure example of form over substance.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#48Cute project I guess, but this is a terrible idea for the web.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#49Earlier 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…
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
#50I 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!