4 ms·

What if we don’t “hydrate” pages with sketchy workers at all? What if we started with the glass already full, like a server we control sending full web pages to

What if we don’t “hydrate” pages with sketchy workers at all? What if we started with the glass already full, like a server we control sending full web pages to the client? That would even stop breaking browser navigation. What if we learned what stateless request/response protocol means? Imagine the possibilities.

jjgreen 6y ago
Heresy, what you suggest could lead to web-pages which work without JavaScript; then how could we implement non-consensual tracking and monetisation.
- gregjor 6y ago
  Good point. I hadn’t thought about user experience. Actual users might object to pages that don’t have a loading spinner and random freezes. They might object more to not having personalized ads and invisible tracking, everyone is so used to that now.
  - scolvin 6y ago
    I don't see what any of this has to do with tracking?
scolvin 6y ago
Well the problems with conventional server side rendering (django, jinja, rails) are well documented (they're the reason (in part) people build react, angular etc.): * UI get's intertwined with logic and DB access * monolithic applications * UI developers have to have access to the full server side application I guess overall I wasn't suggesting this approach as an alternative to traditional django-eske apps, but rather to CRA-eske single page app platforms.
- gregjor 6y ago
  Django is not even a player. Look at Java, C#, and PHP, those are the big server-side tools. Rails, just barely. Logic and state are intertwined with UI in React/Angular apps, without the well-understood structure and techniques that can make server-side code manageable with clear separation of concerns. That happens because of the client-side frameworks, and limitations of focusing skills on the client side. Every server-side framework has supported templates for front-end developers, for a long time. There’s no reason someone focused on the UI has to know any more about the database and business logic working with traditional server-side rendering than they do with React or Angular.
scolvin 6y ago
why are cloudflare workers any more "sketchy" than AWS, azure or GCP?
- gregjor 6y ago
  Farming business logic out to a service you don’t control, asynchronously, and then paying by request is sketchy to me. On AWS, GCP, Azure I can run a server I configure, manage, and control. I can run as many as I need, automate provisioning and configuration, and still maintain control. I could make the case that Javascript is a sketchy language for implementing business logic but that’s a matter of taste.
  - scolvin 6y ago
    Then luck you can (and I do) run Rust on cloudflare workers :-) I would argue your case for cloudflare workers being "sketchy" only applies if you're confident you're better at "automate provisioning and configuration" than cloudflare. In the end you have two choices: run your own hardware and networking, control everything; or, use a "cloud" infrastructure provider and accept you don't really have control. Once you've given up fundamental control of the hardware networking and OS, I don't really see the advantage of managing provisioning and configuration. I definitely don't see a sensible argument that not doing so is "sketchy".

jjgreen 6y ago

Heresy, what you suggest could lead to web-pages which work without JavaScript; then how could we implement non-consensual tracking and monetisation.

gregjor 6y ago
Good point. I hadn’t thought about user experience. Actual users might object to pages that don’t have a loading spinner and random freezes. They might object more to not having personalized ads and invisible tracking, everyone is so used to that now.
- scolvin 6y ago
  I don't see what any of this has to do with tracking?

scolvin 6y ago

Well the problems with conventional server side rendering (django, jinja, rails) are well documented (they're the reason (in part) people build react, angular etc.): * UI get's intertwined with logic and DB access * monolithic applications * UI developers have to have access to the full server side application I guess overall I wasn't suggesting this approach as an alternative to traditional django-eske apps, but rather to CRA-eske single page app platforms.

gregjor 6y ago
Django is not even a player. Look at Java, C#, and PHP, those are the big server-side tools. Rails, just barely. Logic and state are intertwined with UI in React/Angular apps, without the well-understood structure and techniques that can make server-side code manageable with clear separation of concerns. That happens because of the client-side frameworks, and limitations of focusing skills on the client side. Every server-side framework has supported templates for front-end developers, for a long time. There’s no reason someone focused on the UI has to know any more about the database and business logic working with traditional server-side rendering than they do with React or Angular.

scolvin 6y ago

why are cloudflare workers any more "sketchy" than AWS, azure or GCP?

gregjor 6y ago
Farming business logic out to a service you don’t control, asynchronously, and then paying by request is sketchy to me. On AWS, GCP, Azure I can run a server I configure, manage, and control. I can run as many as I need, automate provisioning and configuration, and still maintain control. I could make the case that Javascript is a sketchy language for implementing business logic but that’s a matter of taste.
- scolvin 6y ago
  Then luck you can (and I do) run Rust on cloudflare workers :-) I would argue your case for cloudflare workers being "sketchy" only applies if you're confident you're better at "automate provisioning and configuration" than cloudflare. In the end you have two choices: run your own hardware and networking, control everything; or, use a "cloud" infrastructure provider and accept you don't really have control. Once you've given up fundamental control of the hardware networking and OS, I don't really see the advantage of managing provisioning and configuration. I definitely don't see a sensible argument that not doing so is "sketchy".