Here is why I like this: It makes publishing to the web trivial.
Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
81–90 of 97 posts
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#82Earlier 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...
Also make sure you are on editing the config.js gh-pages branch as this is the branch Github uses for hosting. If you want to use the code you have on master, just merge master into gh-pages. If you have any more issues, feel free to email me.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#83Earlier 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.
Yes, Google can index the site. But it will still suffer in SEO since Google penalizes sites that take a long time to load.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#84I 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
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.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#85Earlier 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.
Yes, you can use HTML/CSS rendered views on mobile but they pale in comparison to native UIs.
The latest app frameworks decouple client-side application logic from the view rendering layer. Meaning you can use the same application logic on your web app as you use on mobile EXCEPT the view on mobile will be rendered natively. Not through a hacky, slow, inconsistent embedded web view. Native native.
If the approach is successful as the framework devs expect, mobile app development (and the app ecosystem as a whole) will go the way of the dinosaur.
Pulling data from many sources on the server requires proxying requests to third parties and providing inline caching of the responses for performance reasons. Despite the fact that the source you're proxying to likely already implements their own caching strategies.
Have fun addressing bugs caused by cache invalidations when you're dealing with multiple caching layers.
Not to mention the increased memory/computation footprint incurred from hosting the equivalent of a database view of an entire third party service on your backend.
Or, you could just request the data directly on the client side.
That's what I mean when I say 'reduced complexity.' Unless you consider setting up CORS whitelisting and some AJAX requests to be really difficult. Then, carry on.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#86Earlier 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)
Exactly. Have fun trying to do feature detection for compatibility purposes on the server-side based on user agent strings.
Because... those never lie. /s
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#87Earlier quoted context omitted.
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
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.
Which is why I use the noscript fallback. I'm just saying it's not worth my time to worry overmuch about supporting everybody's use case on a personal blog full of half-completed thoughts. Nobody is trying to automate anything using my site and if they are then I feel bad for them. If javascript is on my site is fine, if not then you can see the markdown files. I'm not worried about anybody else.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#88Earlier quoted context omitted.
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)
Building a webpage node by node from within Javascript does not lessen the complexity of HTML and CSS, it simply adds to it. You're doing the exact same things - creating DOM nodes with attributes - but with yet another level (or 5) of indirection.
The point is, generate views ONLY on the client.
Excess layers of indirection come when you try do view generation on both the server and the client.
Many server frameworks currently follow this approach. Generate the view scaffold using templates on the server-side. Then request partials asynchronously on the client and generate additional views client-side using a completely different framework.
Shifting all of the view generation to the client frees up the back-end devs to focus all of their time/effort on the important part. Building and scaling the data infrastructure.
Not to mention, shifting the view layer client-side reduces resource requirements on the back-end.
The previous generation of front-end SPA frameworks frankly sucked in terms of performance, leading to a bad user experience. There were 2 primary reasons why. All data persistence/binding happened directly on the DOM, and all execution was handled on the main execution thread.
The latest generation greatly improves the experience by using new techniques such as data persistence/diffing via the virtual DOM, and handling all non-rendering logic on a background worker thread.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#89Earlier 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…
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 o…
Angular2 is following the exact same approach. Although the isomorphic bits aren't production ready yet.
Basically Angular2 renders a completely interactive view that captures any user events that occur while the app is bootstrapping in the background. Once the app is loaded, the events are replayed to make the user experience consistent.
React and Angular2 are fundamentally just different flavors of the same underlying infrastructure. React is more de-centralized and composition based. Angular2 is more centralized, monolithic, OOP, architecture based.
They have even eluded during presentations that the 2 core dev teams have been in direct contact to work out some technical details.
From what I've heard, Ember.js uses these same approaches. Kinda makes me question how much of this started with Ember and was later adoped by React and Angular.
Re: Show HN: CMS.js – Fully Client-Side JavaScript Site Generator
#90Cool. 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.
Yes, I know. Emphasis on 'working on.' I haven't gotten to optimization yet.