"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/)
"for example putting together a form, and handle the response is easy, but if you have to manage a list of items where the user can add/remove items, or change the schema of items based on a selector (e.g. phone type or address) you have to split the logic, and put some on client side scripts, which can become very messy. not to mention live updates like chat, comments etc.
creating a separate backend and frontend solves this problem, as the backend's responsibility will be only manipulating the database, retrieve data and run jobs providing an api and the frontend's will be the only the representation of these data, providing the user interface. this separation lets developers use different technologies and languages on the two side, as well as specializing in these. for the beginning this approach is a bit hard to learn, but it will worth it on the long run." -/u/bdvx (https://www.reddit.com/r/webdev/comments/cbrdte/html_templating_vs_spa/etifiar/)
Otherwise, if you're starting a fresh project with a separate front-end, this is a good template: https://github.com/gtalarico/django-vue-template/
I came across a few other examples, but they didn't do a good job of displaying the initial value or handling choices with integer values.
Updating specific requirements is something I need to do pretty often, and it's not fun to explain all the Pipenv quirks to the team.
Pip-tools looks like it does everything I need and has fewer quirks, so I ended up making the switch.
Pipenv uses pip-tools under the hood, so the migration to pip-tools was very smooth. The migration process was:
- Copy the dev-packages and packages sections of the Pipfile to their own requirements.in files.
- Run pip-compile
- Copy over the specific versions and hashes from the Pipfile.lock to the generated requirements.txt.
I learned about the "playsinline" fix from here: https://webkit.org/blog/6784/new-video-policies-for-ios/
Adding "playsinline" to my video tag fixed it.
I set up a ESP32 houseplant soil water + temperature + humidity + light sensor that sends me a daily status update message.
Here’s the code for it: https://gist.github.com/pawl/6a408afde1411c6b1f58980e3d1dff83
Here's what I did:
- Purchase the domain using Route53.
- Create two public s3 buckets (www.heckingoodboys.com and heckingoodboys.com)
- Enable "Static website hosting" on www.heckingoodboys.com and redirect to heckingoodboys.com.
- Enable "Static website hosting" on heckingoodboys.com, select "use this bucket to host this website", and use routing rules similar to this:
- Back to Route53 - Create an A record for both www.heckingoodboys.com and heckingoodboys.com using the alias to their respective buckets. (this will be the first option in autocomplete)
Why not just use a CNAME from www.heckingoodboys.com to heckingoodboys.com? AWS says they don't charge for aliases, but they do charge for CNAMEs. So, I used an alias to a bucket instead.