3 ms·

Off load view rendering to the client to lower server costs. Having different teams for front-end and backend so they can work and update at different paces.

by jbob2000 9y ago

Off load view rendering to the client to lower server costs. Having different teams for front-end and backend so they can work and update at different paces. You can update the front end without taking your servers down. Front-end developers tend to be cheaper than full stack or wholly backend devs. (And many backend/full stack devs HATE html/css/js). Depending on your app, you might do way more work on the front end than backend, so it'd be a waste to hire full stack devs only to make them do all front end work. Front-end apps can handle spotty internet connections much better, so they work nicely for websites with a lot of mobile traffic. User experience tends to be snappier since you aren't always waiting for the server to render your view.

nathan_long 9y ago
> Off load view rendering to the client to lower server costs. Another way to lower server costs is to change tools. Eg, Phoenix renders HTML much more efficiently than Rails due to its use of IO lists. http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io-lists-in-phoenix/ http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io... > User experience tends to be snappier since you aren't always waiting for the server to render your view. The "Turbolinks" approach of only re-rendering the `<body>` also makes things feel snappy if the server response is fast. https://changelog.com/ https://changelog.com/ is a site that uses Phoenix + Turbolinks to achieve a snappy user experience with very little JS. The source is at https://github.com/thechangelog/changelog.com https://github.com/thechangelog/changelog.com
- jbob2000 9y ago
  Oh, interesting! Thanks for sharing. But there still is a little bit of server load, whereas front-end has 0. Honestly, unless you're serving billions of pageviews on a very tight budget, I'm not really sure how much of a savings we're talking about here (server side vs. client side rendering).
  - nathan_long 9y ago
    > But there still is a little bit of server load, whereas front-end has 0. That's true. OTOH, using a front-end framework has downsides, too. You have another framework involved, a big pile of JS that must be downloaded, more build tools, maybe you need to render server-side anyway for first page load... > I'm not really sure how much of a savings we're talking about here (server side vs. client side rendering) Yeah, me either. I think "what's the easiest way to get & maintain the desired user experience?" is probably the best question.
    - ccachor 9y ago
      Well, Angular has a very heavy initialization penalty, enough that I know of a few companies that ditched it for React. I'll also add, as your front-end becomes more complex and uses a number of different libraries, the bundle becomes huge. There's ways around this of course, but some of pure JS stuff can get ugly quick.
- ccachor 9y ago
  Pretty badass. In addition to Turbolinks, there is also http://instantclick.io http://instantclick.io that has the benefit of prefetch which helps with perceived snappiness.

nathan_long 9y ago

> Off load view rendering to the client to lower server costs. Another way to lower server costs is to change tools. Eg, Phoenix renders HTML much more efficiently than Rails due to its use of IO lists. http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io-lists-in-phoenix/ http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io... > User experience tends to be snappier since you aren't always waiting for the server to render your view. The "Turbolinks" approach of only re-rendering the `<body>` also makes things feel snappy if the server response is fast. https://changelog.com/ https://changelog.com/ is a site that uses Phoenix + Turbolinks to achieve a snappy user experience with very little JS. The source is at https://github.com/thechangelog/changelog.com https://github.com/thechangelog/changelog.com

jbob2000 9y ago
Oh, interesting! Thanks for sharing. But there still is a little bit of server load, whereas front-end has 0. Honestly, unless you're serving billions of pageviews on a very tight budget, I'm not really sure how much of a savings we're talking about here (server side vs. client side rendering).
- nathan_long 9y ago
  > But there still is a little bit of server load, whereas front-end has 0. That's true. OTOH, using a front-end framework has downsides, too. You have another framework involved, a big pile of JS that must be downloaded, more build tools, maybe you need to render server-side anyway for first page load... > I'm not really sure how much of a savings we're talking about here (server side vs. client side rendering) Yeah, me either. I think "what's the easiest way to get & maintain the desired user experience?" is probably the best question.
  - ccachor 9y ago
    Well, Angular has a very heavy initialization penalty, enough that I know of a few companies that ditched it for React. I'll also add, as your front-end becomes more complex and uses a number of different libraries, the bundle becomes huge. There's ways around this of course, but some of pure JS stuff can get ugly quick.
ccachor 9y ago
Pretty badass. In addition to Turbolinks, there is also http://instantclick.io http://instantclick.io that has the benefit of prefetch which helps with perceived snappiness.