6 ms·

> 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

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

jaequery 11y ago
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.
- NocturnalWaffle 11y ago
  Google has been able to handle javascript in pages for a while now: http://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157 http://searchengineland.com/tested-googlebot-crawls-javascri...
  - greggman 11y ago
    Unfortunately Facebook, Twitter, slack, and others can not ... Yet? Maybe that's not directly SEO but it is indirectly. Good open graph data makes links, at least on Facebook, arguably more compelling which makes them more likely to be clicked and/or shared which may lead to better SEO
  - pauly 11y ago
    I don't think any "physical web" scanners do right now unfortunately, for example https://github.com/dermike/physical-web-scan https://github.com/dermike/physical-web-scan (or search for mobile apps called "physical web"). This completely banjaxed my attempt to make an all front end internet beacon recently.
yoz-y 11y ago
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.
lucaspiller 11y ago
> 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.
rimantas 11y ago
> 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.
- nqzero 11y ago
  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)
  - falcolas 11y ago
    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.
    - EvanPlaice 11y ago
      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.
voidr 11y ago
Caching cannot help you with initial page loads, which is probably important when you have a content focused sites. Rendering the content via JavaScript is slower than just having it in your HTML. It's true that JS execution has become insanely fast, however, initial JS execution is not as fast, because it requires that JIT to kick in. Even if JS execution becomes infinitely fast, you still have to work with the DOM, which is horribly slow and there are no known ways to make it fast. Google, Yahoo and others have prove with hard numbers that users care about speed, even when we are talking about milliseconds. I highly recommend doing some research on how browsers and caching actually work before falling into the pit of false belief.
- ry_ry 11y ago
  To be fair to him, he did specifically mention isomorphic, in which case the js is running on both sides and the idea is that initial load delivers server-generated markup, giving the user content immediately then doing all the databinding later. Also, tricks like that are what users generally recognise as speed - similarly Twitter's optimistic xhr submission appears to work instantly, then goes off and actually does it's thing retrospectively. Fwiw I think a fully client side js cms app is a moderately rubbish idea for a variety of reasons, but js rendering of dynamic content absolutely has merit. It's a little more nuanced than slamming somebody's 'pit of false belief' because they like client view rendering. :)
matallo 11y ago
> We're moving past the days of the static web. As much as I like site generators and I'd find this a good idea for some purposes I wouldn't state it is a replacement for static sites generators.
pwg 11y ago
> > 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).
- tobr 11y ago
  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.
  - inflam52 11y ago
    Thanks for pointing this out. Going to be adding a polyfill for that!
- inflam52 11y ago
  Right, this is exactly why I'm avoiding using the word "static". I began by using that term but have strayed away from it for several reasons.
pluma 11y ago
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.
- EvanPlaice 11y ago
  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.
dham 11y ago
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.

jaequery 11y ago

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.

NocturnalWaffle 11y ago
Google has been able to handle javascript in pages for a while now: http://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157 http://searchengineland.com/tested-googlebot-crawls-javascri...
- greggman 11y ago
  Unfortunately Facebook, Twitter, slack, and others can not ... Yet? Maybe that's not directly SEO but it is indirectly. Good open graph data makes links, at least on Facebook, arguably more compelling which makes them more likely to be clicked and/or shared which may lead to better SEO
- pauly 11y ago
  I don't think any "physical web" scanners do right now unfortunately, for example https://github.com/dermike/physical-web-scan https://github.com/dermike/physical-web-scan (or search for mobile apps called "physical web"). This completely banjaxed my attempt to make an all front end internet beacon recently.

yoz-y 11y ago

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.

lucaspiller 11y ago

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

rimantas 11y ago

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

nqzero 11y ago
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)
- falcolas 11y ago
  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.
  - EvanPlaice 11y ago
    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.

voidr 11y ago

Caching cannot help you with initial page loads, which is probably important when you have a content focused sites. Rendering the content via JavaScript is slower than just having it in your HTML. It's true that JS execution has become insanely fast, however, initial JS execution is not as fast, because it requires that JIT to kick in. Even if JS execution becomes infinitely fast, you still have to work with the DOM, which is horribly slow and there are no known ways to make it fast. Google, Yahoo and others have prove with hard numbers that users care about speed, even when we are talking about milliseconds. I highly recommend doing some research on how browsers and caching actually work before falling into the pit of false belief.

ry_ry 11y ago
To be fair to him, he did specifically mention isomorphic, in which case the js is running on both sides and the idea is that initial load delivers server-generated markup, giving the user content immediately then doing all the databinding later. Also, tricks like that are what users generally recognise as speed - similarly Twitter's optimistic xhr submission appears to work instantly, then goes off and actually does it's thing retrospectively. Fwiw I think a fully client side js cms app is a moderately rubbish idea for a variety of reasons, but js rendering of dynamic content absolutely has merit. It's a little more nuanced than slamming somebody's 'pit of false belief' because they like client view rendering. :)

matallo 11y ago

> We're moving past the days of the static web. As much as I like site generators and I'd find this a good idea for some purposes I wouldn't state it is a replacement for static sites generators.

pwg 11y ago

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

tobr 11y ago
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.
- inflam52 11y ago
  Thanks for pointing this out. Going to be adding a polyfill for that!
inflam52 11y ago
Right, this is exactly why I'm avoiding using the word "static". I began by using that term but have strayed away from it for several reasons.

pluma 11y ago

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.

EvanPlaice 11y ago
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.

dham 11y ago

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.