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).
Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
11–20 of 97 posts
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#12I 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 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.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#13Good 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).
You probably want to look at Hexo - https://hexo.io/
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#14I 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.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#15I 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…
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.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#16I 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…
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.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#17I 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…
> 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.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#18does it affect site's SEO?
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
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...
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#19Earlier quoted context omitted.
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
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
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.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#20Earlier 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…
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.
Google has been able to handle javascript in pages for a while now: http://searchengineland.com/tested-googlebot-crawls-javascri...