4 ms·

> Why not have a simple client side method for this? Like writing a line of js?

by fooker 2y ago

sbarre 2y ago
A line of JS that has to run through the Javascript interpreter in your browser rather than a simple I/O operation? If internally this gets optimized to a simple I/O operation (which it should) then why add the JS indirection in the first place?
- fooker 1y ago
  > simple I/O operation That’s the reason it doesn’t get implemented. Nobody wants the simple I/O operation based inclusion. The moment you try to propose it, there’ll be demands to add conditional logic or macros. More relevant for the web is instantiating html templates, which will undoubtedly get piled onto such a feature. And pretty soon you have yet another: > interpreter in your browser Might as well use the one already there.
rbanffy 2y ago
A block of in-line JavaScript stops the renderer until it runs because its output cannot be determined before it completes.
- bawolff 2y ago
  So would any form of html inclusion.
  - rbanffy 1y ago
    Unless the renderer starts after all HTML is retrieved, or the container element has a defined size.
    - bawolff 1y ago
      In which case you have reinvented the <iframe>
- lelanthran 2y ago
  > A block of in-line JavaScript stops the renderer until it runs because its output cannot be determined before it completes. I do it in a way that doesn't stop the renderer.
DemocracyFTW2 2y ago
The difference between "a line of JS" and a standardized declarative solution is of course that a meek "line of $turing_complete_language" can not, in the general case, be known and trusted to do what it purports to do, and nothing else; you've basically enabled any kind of computation, and any kind of behavior. With an include tag or attribute that's different; it's behavior is described by standards, and (except for knowing what content we might be pulling in) we can 100% tell the effects from static analysis, that is, without executing the code. With "a line of JS" the only way, in the general case, to know what it does is to run it (an infinite number of times). Also, because it's not standardized, it's much harder to save to disk, to index and to archive it.

> Why not have a simple client side method for this? Like writing a line of js?

by fooker 2y ago

> Why not have a simple client side method for this? Like writing a line of js?

A line of JS that has to run through the Javascript interpreter in your browser rather than a simple I/O operation? If internally this gets optimized to a simple I/O operation (which it should) then why add the JS indirection in the first place?

fooker 1y ago
> simple I/O operation That’s the reason it doesn’t get implemented. Nobody wants the simple I/O operation based inclusion. The moment you try to propose it, there’ll be demands to add conditional logic or macros. More relevant for the web is instantiating html templates, which will undoubtedly get piled onto such a feature. And pretty soon you have yet another: > interpreter in your browser Might as well use the one already there.

rbanffy 2y ago

A block of in-line JavaScript stops the renderer until it runs because its output cannot be determined before it completes.

bawolff 2y ago
So would any form of html inclusion.
- rbanffy 1y ago
  Unless the renderer starts after all HTML is retrieved, or the container element has a defined size.
  - bawolff 1y ago
    In which case you have reinvented the <iframe>
lelanthran 2y ago
> A block of in-line JavaScript stops the renderer until it runs because its output cannot be determined before it completes. I do it in a way that doesn't stop the renderer.

DemocracyFTW2 2y ago

The difference between "a line of JS" and a standardized declarative solution is of course that a meek "line of $turing_complete_language" can not, in the general case, be known and trusted to do what it purports to do, and nothing else; you've basically enabled any kind of computation, and any kind of behavior. With an include tag or attribute that's different; it's behavior is described by standards, and (except for knowing what content we might be pulling in) we can 100% tell the effects from static analysis, that is, without executing the code. With "a line of JS" the only way, in the general case, to know what it does is to run it (an infinite number of times). Also, because it's not standardized, it's much harder to save to disk, to index and to archive it.