Because Fresh is so reliant on dynamic server side rendering, it is imperative that this is fast. This makes Fresh very well suited for running on the edge in runtimes like Deno Deploy, …. This results in rendering happening physically close to a user, which minimizes network latency.
This is conflating speed with latency. Server-side rendering is expensive, but it doesn’t matter much how far away you put it because there’s just one request-response per page-load (for HTML, ignoring other resources.) Edge deployment becomes a boon when there are a lot of request-response cycles invoked by client-side logic.
I think a framework like this will help improve the adoption (at the end, you need some product to drive the adoption of a language like RoR for Ruby or Flutter for Dart) but I am sad that the only “official” way so far to deploy your code is using their hosting platform.
I believe one can just point the deno binary at a thing and run it. There’s no magic, you could make a Dockerfile with like 3 lines and host it on fly.io or whatever
I am still baffled that sending fully formed HTML to the browser is now called “server side rendering”. The rendering is really still happening in the browser, you are concatenating strings. That’s all.
it’s a well understood nomenclature, it’s the rendering of either javascript or the serverside logic to HTML… what you’re referring to is the rendering of HTML to formatted text in the browser
Concatenating strings in not rendering. I understand how strings get concatenated to form HTML or JS files. We used to do that back in the CGI days. We did not call it rendering then because it is not rendering. It is string concatenation.
JSX is more than string concatenation. There’s a lot of app logic going on, and transformations like escaping.
CG isn’t the only domain that gets to use the term “rendering”, and other domains aren’t obliged to give it an exactly parallel definition. (After all, if you’re cooking, rendering means separating out the fat from the meat!)
More to the point, you could say the browser isn’t doing the rendering, it’s just transforming HTML to instructions in some graphics API, which are then rendered by a window server. Or that the window server is just generating display-lists to be rendered by the GPU…
JSX is more than string concatenation. There’s a lot of app logic going on, and transformations like escaping.
by that definition logging is now rendering too. Just because you have control structures to concatenate text fragments you are not rendering in a computer context.
CG isn’t the only domain that gets to use the term “rendering”, and other domains aren’t obliged to give it an exactly parallel definition.
The point is that it is not a different domain. I think it is just people trying to make something sound more fancy and new. Nothing new here. You are doing all the business logic on the server and create an HTML page based on that. That is literally how the web began. It does not matter if you do it via Typescript or cgi invoking /bin/bash.
(After all, if you’re cooking, rendering means separating out the fat from the meat!)
Sure, this is computing though.
More to the point, you could say the browser isn’t doing the rendering, it’s just transforming HTML to instructions in some graphics API, which are then rendered by a window server. Or that the window server is just generating display-lists to be rendered by the GPU…
The browser is sending the primitives to draw to the underlying layers of the OS. Just like a rendering job would do. I think it is a lot more in-line with the definition I am referring too.
I both love and hate and love your stubborn, old-man-yelling-at-clouds sounding comments. (Not saying you’re such, or the comments are, just that they look like that to me).
So why do I love your comment?
First, you’re completely correct, and the term rendering has somewhat specific meaning, just like you describe. And “server-side rendering” isn’t rendering at all, it’s, as you’ve said, “concatenating strings into HTML on the server”.
So yes, the term is a misnomer in that sense. I’m not sure what would be a proper term. “Server-side concatenation” perhaps? Let’s go with that for now, to be in line with your original comment.
So why the distinction now, from “traditional” server-side concatenation of strings? You likely do know, but for any new kids around here, we started doing web pages by concatenating strings on the server. And the trends of the last decade and half or so on the web - which is close to half of web’s life-span, we have been increasingly using the “client-side” of the thing.
And only when we moved parts of that client-side thing to the server, did the thing again become “server-side concatenation”.
The distinction would probably be in that, that the “traditional” server-side-assembled pages would be written explicitly so - parts of code to be executed and strings to be concatenated on the server, and only the final end-result (the fully formed HTML) is sent to the client. And this new variant of “server-side-concatenation” web is primarily written to be concatenated on the client, not on the server. And despite of writing the code in that fashion - strings to be concatenated on the client - we reverse the thing once more and concatenate it on the server (as we used to).
So now the hate part.
On the one hand, your calling out of “rendering” to actually mean “string concatenation” is technically fully correct. Just like people calling the “cloud” other peoples’ computers. Or “web 3.0”, or a lot of things on the web.
On the other hand, the way I read your comment is you puny young web “developers” are just concatenating strings, that’s all. Back in my day, we used to do the real rendering . I am certain it’s likely not what you’ve meant, but it just sounded that you dismissed 3 decades hard work on making the world wide web serve us best (there’s an old-geezer term for ya!) as “string concatenation”.
Now, that said, I, again, love the comment. Because A lot of the time, talking to people, they give it so much importance, they think we’re doing something extremely complex and magic-like, when most of the time, we’re doing barely more then picking stuff out of a database and concatenating HTML.
I could go on with the love-hate-love-hate thing. Let’s stop here though. As a final thought, after all I’ve written, I think I mostly like your comment, and as someone who’s good at this tech because I’m (relatively) good at math, “technically” correct is the best kind of correct.
Look, no matter how much you want to try to force new meanings onto perfectly-well-understood words, “rendering” will always be something you do to animal fats and only that thing. Come up with some other term to describe what you do in graphics programming.
(or accept that words can acquire new meanings, and that “render” in the sense of “render a template + data to produce HTML” has been provably in use for at least 17 years at this point and likely longer)
I personally am not a fan of linguistic prescriptivism. Rendering is the term for a lot of things. For example, melting down fat, or to return something. Render, according to Merriam-Webster, also means to cause to be or become, which is apt description of what these servers are doing.
I am more baffled at what is actually meant by it than with the misleading nomenclature.
I agree the word rendering is misused, but it’s not quite just string concatenation either. There is a subtle difference. What they mean is not simple html templating by string concatenation. But rather create a whole model of rendered webpage (as in the proper use of the word, a Document Object Model) with all its state and quirks, possibibly do a bunch of operations and mutations on it, then send a representation of it over the wire. The representation is a string. HTML and JavaScript. But it is just used as a protocol to send it to the client. Note that the DOM contains functionality itself that can be called, and access its own state.
While react was created to solve the problem of efficiently update only parts of a page and keep the state in check, it is ultimately accepting defeat. It builds on the premise of a rendered web page being this opaque thing that we should not have direct manual control over, but rather build technologies that use it and just embrace the explosion of complexity. I personally don’t believe this direction will take us anywhere. The introduction of this submission hit the nailed on the head. I was super hyped for something simple, to the point and useful. Only to have my expectation shattered. They identified the problem flawlessly, they laid out the solution design… but in the end they chose this hopeless technology and mindset.
This is conflating speed with latency. Server-side rendering is expensive, but it doesn’t matter much how far away you put it because there’s just one request-response per page-load (for HTML, ignoring other resources.) Edge deployment becomes a boon when there are a lot of request-response cycles invoked by client-side logic.
I think a framework like this will help improve the adoption (at the end, you need some product to drive the adoption of a language like RoR for Ruby or Flutter for Dart) but I am sad that the only “official” way so far to deploy your code is using their hosting platform.
Yes, that’s what I thought too. The new open source feels like it is becoming the freemium model. “freemium source”, you heard it here first folks.
But, all sarcasm aside, I do also feel glad that the money goes to the people who actually build the things and write the code.
I believe one can just point the deno binary at a thing and run it. There’s no magic, you could make a Dockerfile with like 3 lines and host it on fly.io or whatever
There’s no vendor lock-in nowhere. Just run the Deno runtime wherever, however you want.
I htink they meant Deno Deploy, from the example project.
I am still baffled that sending fully formed HTML to the browser is now called “server side rendering”. The rendering is really still happening in the browser, you are concatenating strings. That’s all.
it’s a well understood nomenclature, it’s the rendering of either javascript or the serverside logic to HTML… what you’re referring to is the rendering of HTML to formatted text in the browser
this article might help you understand it more clearly: https://www.freecodecamp.org/news/what-exactly-is-client-side-rendering-and-hows-it-different-from-server-side-rendering-bd5c786b340d/
This is what rendering means in my world https://en.wikipedia.org/wiki/Rendering_(computer_graphics)
Concatenating strings in not rendering. I understand how strings get concatenated to form HTML or JS files. We used to do that back in the CGI days. We did not call it rendering then because it is not rendering. It is string concatenation.
JSX is more than string concatenation. There’s a lot of app logic going on, and transformations like escaping.
CG isn’t the only domain that gets to use the term “rendering”, and other domains aren’t obliged to give it an exactly parallel definition. (After all, if you’re cooking, rendering means separating out the fat from the meat!)
More to the point, you could say the browser isn’t doing the rendering, it’s just transforming HTML to instructions in some graphics API, which are then rendered by a window server. Or that the window server is just generating display-lists to be rendered by the GPU…
by that definition logging is now rendering too. Just because you have control structures to concatenate text fragments you are not rendering in a computer context.
The point is that it is not a different domain. I think it is just people trying to make something sound more fancy and new. Nothing new here. You are doing all the business logic on the server and create an HTML page based on that. That is literally how the web began. It does not matter if you do it via Typescript or cgi invoking /bin/bash.
Sure, this is computing though.
The browser is sending the primitives to draw to the underlying layers of the OS. Just like a rendering job would do. I think it is a lot more in-line with the definition I am referring too.
I both love and hate and love your stubborn, old-man-yelling-at-clouds sounding comments. (Not saying you’re such, or the comments are, just that they look like that to me).
So why do I love your comment?
First, you’re completely correct, and the term
renderinghas somewhat specific meaning, just like you describe. And “server-side rendering” isn’t rendering at all, it’s, as you’ve said, “concatenating strings into HTML on the server”.So yes, the term is a misnomer in that sense. I’m not sure what would be a proper term. “Server-side concatenation” perhaps? Let’s go with that for now, to be in line with your original comment.
So why the distinction now, from “traditional” server-side concatenation of strings? You likely do know, but for any new kids around here, we started doing web pages by concatenating strings on the server. And the trends of the last decade and half or so on the web - which is close to half of web’s life-span, we have been increasingly using the “client-side” of the thing.
And only when we moved parts of that client-side thing to the server, did the thing again become “server-side concatenation”.
The distinction would probably be in that, that the “traditional” server-side-assembled pages would be written explicitly so - parts of code to be executed and strings to be concatenated on the server, and only the final end-result (the fully formed HTML) is sent to the client. And this new variant of “server-side-concatenation” web is primarily written to be concatenated on the client, not on the server. And despite of writing the code in that fashion - strings to be concatenated on the client - we reverse the thing once more and concatenate it on the server (as we used to).
So now the hate part.
On the one hand, your calling out of “rendering” to actually mean “string concatenation” is technically fully correct. Just like people calling the “cloud” other peoples’ computers. Or “web 3.0”, or a lot of things on the web.
On the other hand, the way I read your comment is you puny young web “developers” are just concatenating strings, that’s all. Back in my day, we used to do the real rendering . I am certain it’s likely not what you’ve meant, but it just sounded that you dismissed 3 decades hard work on making the world wide web serve us best (there’s an old-geezer term for ya!) as “string concatenation”.
Now, that said, I, again, love the comment. Because A lot of the time, talking to people, they give it so much importance, they think we’re doing something extremely complex and magic-like, when most of the time, we’re doing barely more then picking stuff out of a database and concatenating HTML.
I could go on with the love-hate-love-hate thing. Let’s stop here though. As a final thought, after all I’ve written, I think I mostly like your comment, and as someone who’s good at this tech because I’m (relatively) good at math, “technically” correct is the best kind of correct.
Look, no matter how much you want to try to force new meanings onto perfectly-well-understood words, “rendering” will always be something you do to animal fats and only that thing. Come up with some other term to describe what you do in graphics programming.
(or accept that words can acquire new meanings, and that “render” in the sense of “render a template + data to produce HTML” has been provably in use for at least 17 years at this point and likely longer)
I personally am not a fan of linguistic prescriptivism. Rendering is the term for a lot of things. For example, melting down fat, or to return something. Render, according to Merriam-Webster, also means
to cause to be or become, which is apt description of what these servers are doing.I am more baffled at what is actually meant by it than with the misleading nomenclature.
I agree the word rendering is misused, but it’s not quite just string concatenation either. There is a subtle difference. What they mean is not simple html templating by string concatenation. But rather create a whole model of rendered webpage (as in the proper use of the word, a Document Object Model) with all its state and quirks, possibibly do a bunch of operations and mutations on it, then send a representation of it over the wire. The representation is a string. HTML and JavaScript. But it is just used as a protocol to send it to the client. Note that the DOM contains functionality itself that can be called, and access its own state.
While react was created to solve the problem of efficiently update only parts of a page and keep the state in check, it is ultimately accepting defeat. It builds on the premise of a rendered web page being this opaque thing that we should not have direct manual control over, but rather build technologies that use it and just embrace the explosion of complexity. I personally don’t believe this direction will take us anywhere. The introduction of this submission hit the nailed on the head. I was super hyped for something simple, to the point and useful. Only to have my expectation shattered. They identified the problem flawlessly, they laid out the solution design… but in the end they chose this hopeless technology and mindset.
I don’t really care about the framework, but that logo as the top is really cute.
Everywhere the Deno mascot shows up is extremely cute :) E.g. the ones here and this loading animation.
If someone makes a package that combines Deno and Go, its mascot will probably cause me to die of cute-overload.