Live data from Hacker News

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

cdmedia.github.io

61–70 of 97 posts

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

#61

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…

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

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.

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

#62
post #54

Earlier quoted context omitted.

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 m…

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.

citation for your exploits claim ? you've worded it in an awkward manner that makes it sound like a red herring

specifically, are there javascript-only (or js+css+html only) exploits in recent chrome or firefox ?

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

#63

Earlier 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…

> 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

#64
post #54

Earlier quoted context omitted.

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 m…

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

#65
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?

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

#66

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/brow…

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 m…

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.

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

#67

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…

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

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

#68

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…

Big proponent of JS myself.

I totally agree with you here.

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

#69
post #34

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?

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

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.

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

#70
post #52

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/brow…

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

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.
Post reply on HN