41–50 of 90 posts
Oh it's server side "rendering"?
To me “rendering engine” also means something else. Namely taking html and rendering it to the screen.
Note that rendering to the “screen” really means writing bits at a memory range, which is just one interface for displaying things. Html is another, higher level interface these days.
Earlier quoted context omitted.
Async infrastructure allows your stuff to be sync or async. While sync infrastructure forces your stuff to be sync. If anything sync (not async) infects everything you do. Of course it depends if you call the infrastructure (then it's better for it to be sync) of if the infrastructure calls you (then it's better to be async). Rendering engine is something you rarely call, but it often calls your functions.
Yes, and that’s the worst part of async. That’s why you need to be very strategic about where you introduce it into your code in order to minimize the number of functions it infects, not give up and write a framework that’s all async for no good reason. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
It's not that async infects. It's sync that infects and restricts. We are just used to it by default.
The fact that we started from sync was the cause of all the trouble of rpc because everything outside of CPU is innately async.
So make your utility functions sync whenever you can but make your platforms and frameworks async.
I can't clearly see a use case. I went on to the "why" section but I'm having a hard time trying to understand what this is trying to solve. Perhaps a clear and simple example to see why you would use it could be useful. Also I find it extremely verbose to write HTML the way is shown in the examples at the top. Having used Jinja for a very long time, its simplicity and separation from logic makes it almost (for me) t…
Earlier quoted context omitted.
Yes, and that’s the worst part of async. That’s why you need to be very strategic about where you introduce it into your code in order to minimize the number of functions it infects, not give up and write a framework that’s all async for no good reason. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
Yes. But you should be equally strategic about introducing sync code into your platform. Because making your platform sync basically makes it only be able to call sync functions of your code. It's not that async infects. It's sync that infects and restricts. We are just used to it by default. The fact that we started from sync was the cause of all the trouble of rpc because everything outside of CPU is innately async…
By contrast, calling async code from sync code requires a special blocking wrapper (Python) or unavoidably breaks control flow (JavaScript).
Not clear why HTML rendering needed to be infected with async. None of the example code has a clear need for async - even the `is_admin()` method would be a prefetched property in any reasonable database model.
Imagine you have 2 big components, one fetches from an third-party API and the other from your backend, this way they can load at the same time instead of sequentially.
Earlier quoted context omitted.
Yes. But you should be equally strategic about introducing sync code into your platform. Because making your platform sync basically makes it only be able to call sync functions of your code. It's not that async infects. It's sync that infects and restricts. We are just used to it by default. The fact that we started from sync was the cause of all the trouble of rpc because everything outside of CPU is innately async…
I just completely disagree. Async is syntactic sugar that can be reduced to sync code with callbacks. It doesn’t exist on equal footing. If you want to call sync code from async code, you just… call it. If it performs blocking IO, it’ll block, but that’s exactly what it would do if called from other sync code, too. By contrast, calling async code from sync code requires a special blocking wrapper (Python) or unavoida…
That's exaclty my point. If you don't have async by default in your platform you need to do stupid things to fake it. If function calls and main in Python were innately async you could be calling async code just as easily as sync code.
> [...] or unavoidably breaks control flow (JavaScript).
async/await syntax avoids it completely.
Tbh await should be default function call semantics and there should be special keyword for calling without awaiting. But since we come from sync primitives that would require small revolution that might happen at some point.
> Async is syntactic sugar
You could make sync code be syntactic sugar for await.
Earlier quoted context omitted.
I just completely disagree. Async is syntactic sugar that can be reduced to sync code with callbacks. It doesn’t exist on equal footing. If you want to call sync code from async code, you just… call it. If it performs blocking IO, it’ll block, but that’s exactly what it would do if called from other sync code, too. By contrast, calling async code from sync code requires a special blocking wrapper (Python) or unavoida…
> By contrast, calling async code from sync code requires a special blocking wrapper (Python) ... That's exaclty my point. If you don't have async by default in your platform you need to do stupid things to fake it. If function calls and main in Python were innately async you could be calling async code just as easily as sync code. > [...] or unavoidably breaks control flow (JavaScript). async/await syntax avoids it…
or python could have blessed gevent and done away with all the nonsense.
For those asking the point is being able to do similar to React JSX components, but on the server side. It's so much nicer to use than templates like Django or Jinja (there might be other reasons, but this is quite clearly the goal of htpy and I assume this too).
Just looking at this one briefly it seems to use magic methods on dataclasses. What's the advantage of that over just a function? Seems like unnecessary nesting.