3 ms·

I'd love to see books, screencasts, or tutorials that talk about doing this beyond the very trivial. I hear people talk about it, but whenever I ask, they can't

by bphogan 11y ago

I'd love to see books, screencasts, or tutorials that talk about doing this beyond the very trivial. I hear people talk about it, but whenever I ask, they can't show me code because reasons. This makes me skeptical. And based on what I see in the wild... lots of loading progress bars, etc, I don't see widespread use of this technique.

timr 11y ago
"This makes me skeptical. And based on what I see in the wild... lots of loading progress bars, etc, I don't see widespread use of this technique." If you're looking for a "big" site that does this, then: Yelp. All of the content on yelp.com is statically rendered, with progressive enhancement. Turn off javascript, site still works. It looks nearly the same, in fact. So go inspect source to your heart's content. There's really no magic to it, and nothing of which to be skeptical: you first generate static HTML and CSS, and you treat javascript as an enhancement to that content, rather than as as the content itself. This is the way things were done for years. It's only since 2013 or so that people have lost track of this "ancient" art.
- bphogan 11y ago
  No, no, I get that. That's how I do my stuff and have always done it. We used to call that "progressive enhancement". But it's easy to say "ehhh just render the whole page statically first then re-render parts in JS". I'd like to see people demonstrating this with modern frameworks and tools. Because without people leading, it'll be JS-rendered static content for years to come.
  - timr 11y ago
    The GP wasn't saying that, as I read it. It was saying: "use progressive enhancement". When you insert new elements in the DOM with JS, you are re-rendering parts of the page. I see no other, non-invented reason that anyone needs to render static content with javascript. Devs do it primarily because they're annoyed that they have to think about AJAX logic, and want to write simpler code -- at the user's expense.

by bphogan 11y ago

timr 11y ago

"This makes me skeptical. And based on what I see in the wild... lots of loading progress bars, etc, I don't see widespread use of this technique." If you're looking for a "big" site that does this, then: Yelp. All of the content on yelp.com is statically rendered, with progressive enhancement. Turn off javascript, site still works. It looks nearly the same, in fact. So go inspect source to your heart's content. There's really no magic to it, and nothing of which to be skeptical: you first generate static HTML and CSS, and you treat javascript as an enhancement to that content, rather than as as the content itself. This is the way things were done for years. It's only since 2013 or so that people have lost track of this "ancient" art.

bphogan 11y ago
No, no, I get that. That's how I do my stuff and have always done it. We used to call that "progressive enhancement". But it's easy to say "ehhh just render the whole page statically first then re-render parts in JS". I'd like to see people demonstrating this with modern frameworks and tools. Because without people leading, it'll be JS-rendered static content for years to come.
- timr 11y ago
  The GP wasn't saying that, as I read it. It was saying: "use progressive enhancement". When you insert new elements in the DOM with JS, you are re-rendering parts of the page. I see no other, non-invented reason that anyone needs to render static content with javascript. Devs do it primarily because they're annoyed that they have to think about AJAX logic, and want to write simpler code -- at the user's expense.