4 ms·

I agree with all of those points. But meeting the needs of customers is what I get paid to do. And customers don't want server-side rendered stuff. They hate l

by bphogan 11y ago

I agree with all of those points. But meeting the needs of customers is what I get paid to do. And customers don't want server-side rendered stuff. They hate losing their place when they add a row of data. So what are ya gonna do? See, I hate JS. I think it's terrible. If there were any other choices out there, I don't even think it would still be a thing if there were any other options. But it's a requirement of a modern web developer to know how to do it well. And I'm a web developer. So I'm going to be good at it. At least as good as I can be given the tools I use and constraints I have.

simi_ 11y ago
> But meeting the needs of customers is what I get paid to do That was like being slapped with a good dose of pragmatism – I love it! Wrt the later part of your post, try Dart. It's annoying in entirely new ways, but it does away with a lot of JS pains; it's also mature, powerful, and production-oriented. It even comes with a VM to run it in, so you can pretend it's a real –boy– language. Its obscurity also means that it can be hard to come across help/tools (emacs completion, anyone?), but despite all the shortcomings I enjoy using it, and am happy to back Google's bet on Dart.
- bphogan 11y ago
  Thanks for the recommendation. I'm currently annoying myself by learning Elm. :)
M2Ys4U 11y ago
> But meeting the needs of customers is what I get paid to do. And customers don't want server-side rendered stuff. They hate losing their place when they add a row of data. >So what are ya gonna do? Both. Do the initial render (well, HTML generation) server-side, and update the state client-side when the user performs an action (or receives an event from the server). Use real, accessible URLs for links, and use pushState when updating client-side.
- 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

simi_ 11y ago

> But meeting the needs of customers is what I get paid to do That was like being slapped with a good dose of pragmatism – I love it! Wrt the later part of your post, try Dart. It's annoying in entirely new ways, but it does away with a lot of JS pains; it's also mature, powerful, and production-oriented. It even comes with a VM to run it in, so you can pretend it's a real –boy– language. Its obscurity also means that it can be hard to come across help/tools (emacs completion, anyone?), but despite all the shortcomings I enjoy using it, and am happy to back Google's bet on Dart.

bphogan 11y ago
Thanks for the recommendation. I'm currently annoying myself by learning Elm. :)

M2Ys4U 11y ago

> But meeting the needs of customers is what I get paid to do. And customers don't want server-side rendered stuff. They hate losing their place when they add a row of data. >So what are ya gonna do? Both. Do the initial render (well, HTML generation) server-side, and update the state client-side when the user performs an action (or receives an event from the server). Use real, accessible URLs for links, and use pushState when updating client-side.

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.