< ^ txt
Fri 08 Feb 2019 09:26:35 AM EST
Slept from ten-thirty to six-thirty.
High of twenty-three today, and up to a half-inch of snow.
Work:
- Consider subdomains for properties
Done (but no).
- Pull updated Bitwarden image
Done.
- Work on ELK
Done.
Twenty-minute walk at lunch.
Cold, with a brutally strong wind.
Home:
- Do something (wiki?)
Took the first dose of my new BP meds this morning.
This doesn't at all alter my understanding of the issue, but I haven't seen it expressed this concisely anywhere else.
https://www.reddit.com/r/node/comments/6t22cr/back_end_templating_engine_or_front_end_framework/
> With React, you don't need a templating engine because you are essentially using Javascript on the client side to render your HTML. React heavily involves the idea of breaking your UI down into components. So with a templating language, you might have a base layout with a header and a footer. With React, you could have header and footer components that you can then include and use wherever you need it.
> 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.
Thinking about a web-based chat app.
Say you have clients pulling updates (you don't like websockets), how often?
Set a maximum time (one minute?).
If our client sends a new message, turn down that interval (two seconds?).
If our client finds a new message, turn down the interval.
If our does NOT find a new message, turn up the interval, until we hit the maximum.
Watched Netflix.
Servings: grains 5/6, fruit 4/4, vegetables 4/4, dairy 1/2, meat 2/3, nuts 2/0.5
Breakfast: rye break, two eggs, tomato, spinach, banana, apple, coffee
Lunch: banana, apple, carrots, tomato, yogurt
Afternoon snack: bagel with cream cheese, coffee
Dinner: corn chips, hummus
118/75
< ^ txt