5 ms·

I actually have gone back to writing server-rendered apps like it's 2012 and it's been wonderful. Server-rendered used to mean slow and clunky but I've found t

I actually have gone back to writing server-rendered apps like it's 2012 and it's been wonderful. Server-rendered used to mean slow and clunky but I've found that using Go my page loads are super fast. The inter-page transitions can sting a little on really really slow connections, it's true. But users are much more willing to deal with them if they haven't first been subjected to a minutes-long spinner while the SPA loads up all its libraries and state. A little game I sometimes play is asking fellow developers to try and guess the frontend framework used on one of my apps. They click around for a little while wondering "Angular or React" before I tell them it's actually just some Go templates rendered on the server. It often opens their eyes that the loads were so fast they couldn't actually tell they were happening. SPAs have their place and I've written a lot of them. It's amazing how far you can take server rendering in 2019, though.

GuiA 8y ago
How many "quality of life" features does your website have that require some JavaScript that you end up writing as one off functions/endpoints/etc? (various kinds of autocompletion, live search, notifications, messaging, etc.) I'm all for server side rendering - I maintained several vanilla PHP/HTML/CSS websites in the 2000s, and only used jQuery sparingly when things grew in complexity. I later used Django for many years similarly, and when react/ember/angular/etc. started blowing up is when I started feeling like performance was something we had to worry more about. That being said, server side rendering shows its limits when you build an application with lots of actions your users can perform on the data shown in their window, and reloading the page every time would significantly slow them down. That's when you're tempted to start going the SPA route, but those frameworks tend to be pretty opinionated about how you should structure your code and data, a slippery slope that leads to the stereotypical bloated, unresponsive JavaScript mess some websites have become famous for. There is certainly a balance to be found, but it's a tricky one.
- davidbanham 8y ago
  It depends on the application of course, but some of them do end up sprouting a bunch of little "quality of life" JS functions. Writing these is happily a much simpler experience than it was in 2012! The most complex app I run also has the deepest browser support requirements, back to IE11. That said, I still have document.querySelector in all my target browsers so I find I don't even need jQuery. For autocompletion, datepickers, etc I use drop-in components. These tend to be jQuery based but it's not the end of the world. When I do have a particular view or flow that outgrows the "bits and pieces of JS" phase it's actually pretty straightforward to use a modern UI library like React or Elm on that view alone. Reducing the scope of the area you're using the framework in rather than writing the entire app in it simplifies things pretty dramatically. The JS doesn't need to worry about routing, pushState, etc etc etc. It just deals with its own little patch of DOM and state.
- flukus 8y ago
  Just because you have some interactivity doesn't mean you have to jump to an SPA, vue/knockout work well in the hybrid scenario and then you only have the complexity where it makes sense as well.
- rakoo 8y ago
  I haven't developed any website but my server-side preference would definitely lead me to something that is always server-side-rendered. It's no surprise we all like HN, the experience definitely feels more than good enough. There was a standard (https://tools.ietf.org/html/rfc3229 https://tools.ietf.org/html/rfc3229) to diff pages so that only the delta would be sent to the browser. After that the only missing piece would have been that the browser doesn't refresh the whole page but intelligently re-renders the difference in the DOM, and that would have been the perfect world.
  - jdmichal 8y ago
    I'm really only familiar with ASP.NET, but do other frameworks not include support for partial page rendering? The ASP.NET `UpdatePanel` is simple and even has gracious degradation. (If client doesn't support for whatever reason, it will just revert back to doing full page POST and refresh.) Of course, this is just wholesale replacing a DOM subtree with another. But there's also probably some point where just parsing the new subtree is faster than attempting to create and apply a diff.
- dsego 8y ago
  I can recommend Mithril, which can support a full spa but is also very practical if you just want small parts of the page to be dynamic. It is a great little component based spa library that is small in size and has a simple api. It is very similar to react and doesn't require a compile step.
deleted 8y ago
[deleted]
adamstep 8y ago
Libraries like IntercoolerJS really help with page transitions and other dynamic interactions, while still letting you do all the rendering on the server.
- edwinyzh 8y ago
  I like intercooler.js a lot!
- neillyons 8y ago
  Also https://instant.page/ https://instant.page/. It preloads a page when the user hovers over a link.
aaronbrethorst 8y ago
SSR + Pjax + React on the components that really need it seems like a much-simpler combination to me than what seems to be generally considered 'state of the art' these days.
xz0r 8y ago
Are any of your apps public? I want to try using them.
- davidbanham 8y ago
  Yeah, sure thing! https://takehome.io https://takehome.io https://clubman.app https://clubman.app
  - jimbokun 8y ago
    "takehome" seems like exactly the right solution for technical interviews. Have you gotten much traction?
    - davidbanham 8y ago
      Thankyou, I think so too. I find that once a company uses the product, they never stop. The customer base is very sticky. I have also found that I bounce a lot of companies that don't "get it". They don't understand that it's about making things better for candidates and so all they see is Hackerrank with less features. My challenge for growth is finding better ways to explain the ethos and the benefits to those companies.
te_chris 8y ago
This is where Elixir and Phoenix really excels. It just renders pages so damn fast!
gambler 8y ago
>Server-rendered used to mean slow and clunky I don't get why everyone keeps saying this. Is it because of WordPress? In 2005 I used my own MVC framework with ORM and stuff. It was written in PHP. My pages had the usual generation time of 0.03 seconds. And that was with no specialized caching or any crazy optimizations. Even with no AJAX, page loading seemed instant, unless you connected to the server from across the world.
- _pgmf 8y ago
  I completely agree. In 2008 at my first coding job we used plain php/MySQL with no caching and the sites were responsive. Plus they required like zero maintenance! In 2009 I went to work for a Django shop and was introduced to caching, reverse proxies/wsgi servers, templating, etc. It took a long time to buy in to this way of doing things, as it seemed intentionally complicated for no reason. Over time I've learned to appreciate that there are real benefits, but it wasn't immediately obvious to me. Regarding js templating, spa's, and all that stuff: I've tried to keep my previous experience in mind, and be open-minded about the potential benefits of these technologies. But I haven't seen any as yet.
- chasd00 8y ago
  the lighter text means the post has been down voted correct? Why was the parent post downvoted then? They make a perfect point, there's nothing inherently slow about traditional web apps. There's definitely things regarding the UX that traditional server side web applications can't do vs browser side but they can be incredibly fast. one nit pick, what does "server-side rendering", and even "client-side rendering", even mean? The browser renders HTML, it's always client side and it's always outside of the scope of application code. Does "rendering" really mean template parsing?
  - gambler 8y ago
    >one nit pick, what does "server-side rendering", and even "client-side rendering", even mean? The browser renders HTML, it's always client side and it's always outside of the scope of application code. This is an excellent point. Both HTML and JSON are string representations of data structures. Both are eventually transformed and converted to DOM.

GuiA 8y ago

How many "quality of life" features does your website have that require some JavaScript that you end up writing as one off functions/endpoints/etc? (various kinds of autocompletion, live search, notifications, messaging, etc.) I'm all for server side rendering - I maintained several vanilla PHP/HTML/CSS websites in the 2000s, and only used jQuery sparingly when things grew in complexity. I later used Django for many years similarly, and when react/ember/angular/etc. started blowing up is when I started feeling like performance was something we had to worry more about. That being said, server side rendering shows its limits when you build an application with lots of actions your users can perform on the data shown in their window, and reloading the page every time would significantly slow them down. That's when you're tempted to start going the SPA route, but those frameworks tend to be pretty opinionated about how you should structure your code and data, a slippery slope that leads to the stereotypical bloated, unresponsive JavaScript mess some websites have become famous for. There is certainly a balance to be found, but it's a tricky one.

davidbanham 8y ago
It depends on the application of course, but some of them do end up sprouting a bunch of little "quality of life" JS functions. Writing these is happily a much simpler experience than it was in 2012! The most complex app I run also has the deepest browser support requirements, back to IE11. That said, I still have document.querySelector in all my target browsers so I find I don't even need jQuery. For autocompletion, datepickers, etc I use drop-in components. These tend to be jQuery based but it's not the end of the world. When I do have a particular view or flow that outgrows the "bits and pieces of JS" phase it's actually pretty straightforward to use a modern UI library like React or Elm on that view alone. Reducing the scope of the area you're using the framework in rather than writing the entire app in it simplifies things pretty dramatically. The JS doesn't need to worry about routing, pushState, etc etc etc. It just deals with its own little patch of DOM and state.
flukus 8y ago
Just because you have some interactivity doesn't mean you have to jump to an SPA, vue/knockout work well in the hybrid scenario and then you only have the complexity where it makes sense as well.
rakoo 8y ago
I haven't developed any website but my server-side preference would definitely lead me to something that is always server-side-rendered. It's no surprise we all like HN, the experience definitely feels more than good enough. There was a standard (https://tools.ietf.org/html/rfc3229 https://tools.ietf.org/html/rfc3229) to diff pages so that only the delta would be sent to the browser. After that the only missing piece would have been that the browser doesn't refresh the whole page but intelligently re-renders the difference in the DOM, and that would have been the perfect world.
- jdmichal 8y ago
  I'm really only familiar with ASP.NET, but do other frameworks not include support for partial page rendering? The ASP.NET `UpdatePanel` is simple and even has gracious degradation. (If client doesn't support for whatever reason, it will just revert back to doing full page POST and refresh.) Of course, this is just wholesale replacing a DOM subtree with another. But there's also probably some point where just parsing the new subtree is faster than attempting to create and apply a diff.
dsego 8y ago
I can recommend Mithril, which can support a full spa but is also very practical if you just want small parts of the page to be dynamic. It is a great little component based spa library that is small in size and has a simple api. It is very similar to react and doesn't require a compile step.

deleted 8y ago

[deleted]

adamstep 8y ago

Libraries like IntercoolerJS really help with page transitions and other dynamic interactions, while still letting you do all the rendering on the server.

edwinyzh 8y ago
I like intercooler.js a lot!
neillyons 8y ago
Also https://instant.page/ https://instant.page/. It preloads a page when the user hovers over a link.

aaronbrethorst 8y ago

SSR + Pjax + React on the components that really need it seems like a much-simpler combination to me than what seems to be generally considered 'state of the art' these days.

xz0r 8y ago

Are any of your apps public? I want to try using them.

davidbanham 8y ago
Yeah, sure thing! https://takehome.io https://takehome.io https://clubman.app https://clubman.app
- jimbokun 8y ago
  "takehome" seems like exactly the right solution for technical interviews. Have you gotten much traction?
  - davidbanham 8y ago
    Thankyou, I think so too. I find that once a company uses the product, they never stop. The customer base is very sticky. I have also found that I bounce a lot of companies that don't "get it". They don't understand that it's about making things better for candidates and so all they see is Hackerrank with less features. My challenge for growth is finding better ways to explain the ethos and the benefits to those companies.

te_chris 8y ago

This is where Elixir and Phoenix really excels. It just renders pages so damn fast!

gambler 8y ago

>Server-rendered used to mean slow and clunky I don't get why everyone keeps saying this. Is it because of WordPress? In 2005 I used my own MVC framework with ORM and stuff. It was written in PHP. My pages had the usual generation time of 0.03 seconds. And that was with no specialized caching or any crazy optimizations. Even with no AJAX, page loading seemed instant, unless you connected to the server from across the world.

_pgmf 8y ago
I completely agree. In 2008 at my first coding job we used plain php/MySQL with no caching and the sites were responsive. Plus they required like zero maintenance! In 2009 I went to work for a Django shop and was introduced to caching, reverse proxies/wsgi servers, templating, etc. It took a long time to buy in to this way of doing things, as it seemed intentionally complicated for no reason. Over time I've learned to appreciate that there are real benefits, but it wasn't immediately obvious to me. Regarding js templating, spa's, and all that stuff: I've tried to keep my previous experience in mind, and be open-minded about the potential benefits of these technologies. But I haven't seen any as yet.
chasd00 8y ago
the lighter text means the post has been down voted correct? Why was the parent post downvoted then? They make a perfect point, there's nothing inherently slow about traditional web apps. There's definitely things regarding the UX that traditional server side web applications can't do vs browser side but they can be incredibly fast. one nit pick, what does "server-side rendering", and even "client-side rendering", even mean? The browser renders HTML, it's always client side and it's always outside of the scope of application code. Does "rendering" really mean template parsing?
- gambler 8y ago
  >one nit pick, what does "server-side rendering", and even "client-side rendering", even mean? The browser renders HTML, it's always client side and it's always outside of the scope of application code. This is an excellent point. Both HTML and JSON are string representations of data structures. Both are eventually transformed and converted to DOM.