3 ms·

Nice article. People sometimes dismiss Django but it’s been around for a while and is certainly the fastest framework for building out new ideas that I’ve seen.

Nice article. People sometimes dismiss Django but it’s been around for a while and is certainly the fastest framework for building out new ideas that I’ve seen. It’s my goto framework for prototyping. I find too many teams are so focused on using the latest fancy frameworks that they spend way more effort to build something using “new stuff” that could have been done in half or a quarter of the time with something like Django. For most projects, simple that’s built and works beats fancy that’s still being built.

postpawl 6y ago
I saw a really good reddit comment about this topic recently (server side templating vs client side). Tl;dr: when things get really interactive/dynamic, the js framework simplifies things. “Server side templating can work really well when the website is static. The problem is that as you add more and more dynamic elements, you either have to go to the server and re-render everything with every change (which can be slow), or you can make the changes on the client side with something like jQuery. But the latter option presents a challenge because you'll eventually find yourself duplicating functionality. For example, imagine a to-do list website that you render on the server with a templating language. It fetches the user's to-do items from the database and then renders the list. Now let's say you want to let a user add a new item without re-rendering the entire page. You could use AJAX to tell the server to add the new item, but now you need to update your UI list accordingly. You could use jQuery to construct a new DOM element and append it, but now that list element exists in two different places: in your jQuery code and in your template on the server. If your website becomes very dynamic, this situation can get really unwieldy from a programming perspective. Both Angular (from what I've read) and React (from personal experience) are highly suitable for creating single page apps, with the goal of creating a dynamic, fast, and maintainable website. There are other benefits, as well as downsides, to using Angular and React, but I hope this clears it up a little bit. Both of them make server side templating unnecessary by moving UI logic/rendering from your server to the client's browser. So a user who visits your React powered to-list website would get the React code as a JS bundle, it would make an AJAX call to your server to get just the data, and then it would render the UI based on the data." -/u/VertiGuo (https://www.reddit.com/r/node/comments/6t22cr/back_end_templating_engine_or_front_end_framework/dlhukkf/ https://www.reddit.com/r/node/comments/6t22cr/back_end_templ...)
- conorgdaly 6y ago
  > You could use AJAX to tell the server to add the new item, but now you need to update your UI list accordingly. You could use jQuery to construct a new DOM element and append it, but now that list element exists in two different places: in your jQuery code and in your template on the server. Your server can just return html which is ready to be inserted into DOM. You don't need to duplicate the node view creation logic client side.
  - postpawl 6y ago
    That can get pretty complicated for pages with a lot of dynamic elements. For example, if you submit a form and have to re-render the form with an error. All the hidden “ready to be inserted into the DOM” elements also need server side code to re-render things the same way. For pages with a lot of dynamic stuff, it might be better to just build it on the client side and use an API with server side validation on the server side.
    - conorgdaly 6y ago
      > All the hidden “ready to be inserted into the DOM” elements also need server side code to re-render things the same way. There seems to be some confusion. With your list example, you still make an ajax call to create a new ToDo, the server returns html which is inserted into DOM. You'll be making an ajax call anyway, except instead of just 200 reponse/json , you'll get html. This is server side rendered. There is no """hidden “ready to be inserted into the DOM” elements""" Yes, forms are something which, depending on complexity, can be better served with SPA type solution. If it's not complex, I'd still keep rendering server side and just add small bit of JS logic to update form header to add/remove to error list and just replace form input field with server response.
      - postpawl 6y ago
        Yeah, the TODO list example probably isn't a good example for a complicated scenario when avoiding server side templating makes sense.

postpawl 6y ago

I saw a really good reddit comment about this topic recently (server side templating vs client side). Tl;dr: when things get really interactive/dynamic, the js framework simplifies things. “Server side templating can work really well when the website is static. The problem is that as you add more and more dynamic elements, you either have to go to the server and re-render everything with every change (which can be slow), or you can make the changes on the client side with something like jQuery. But the latter option presents a challenge because you'll eventually find yourself duplicating functionality. For example, imagine a to-do list website that you render on the server with a templating language. It fetches the user's to-do items from the database and then renders the list. Now let's say you want to let a user add a new item without re-rendering the entire page. You could use AJAX to tell the server to add the new item, but now you need to update your UI list accordingly. You could use jQuery to construct a new DOM element and append it, but now that list element exists in two different places: in your jQuery code and in your template on the server. If your website becomes very dynamic, this situation can get really unwieldy from a programming perspective. Both Angular (from what I've read) and React (from personal experience) are highly suitable for creating single page apps, with the goal of creating a dynamic, fast, and maintainable website. There are other benefits, as well as downsides, to using Angular and React, but I hope this clears it up a little bit. Both of them make server side templating unnecessary by moving UI logic/rendering from your server to the client's browser. So a user who visits your React powered to-list website would get the React code as a JS bundle, it would make an AJAX call to your server to get just the data, and then it would render the UI based on the data." -/u/VertiGuo (https://www.reddit.com/r/node/comments/6t22cr/back_end_templating_engine_or_front_end_framework/dlhukkf/ https://www.reddit.com/r/node/comments/6t22cr/back_end_templ...)

conorgdaly 6y ago
> You could use AJAX to tell the server to add the new item, but now you need to update your UI list accordingly. You could use jQuery to construct a new DOM element and append it, but now that list element exists in two different places: in your jQuery code and in your template on the server. Your server can just return html which is ready to be inserted into DOM. You don't need to duplicate the node view creation logic client side.
- postpawl 6y ago
  That can get pretty complicated for pages with a lot of dynamic elements. For example, if you submit a form and have to re-render the form with an error. All the hidden “ready to be inserted into the DOM” elements also need server side code to re-render things the same way. For pages with a lot of dynamic stuff, it might be better to just build it on the client side and use an API with server side validation on the server side.
  - conorgdaly 6y ago
    > All the hidden “ready to be inserted into the DOM” elements also need server side code to re-render things the same way. There seems to be some confusion. With your list example, you still make an ajax call to create a new ToDo, the server returns html which is inserted into DOM. You'll be making an ajax call anyway, except instead of just 200 reponse/json , you'll get html. This is server side rendered. There is no """hidden “ready to be inserted into the DOM” elements""" Yes, forms are something which, depending on complexity, can be better served with SPA type solution. If it's not complex, I'd still keep rendering server side and just add small bit of JS logic to update form header to add/remove to error list and just replace form input field with server response.
    - postpawl 6y ago
      Yeah, the TODO list example probably isn't a good example for a complicated scenario when avoiding server side templating makes sense.