What if we've had web development round the wrong way for the last 10 years? | Hacker News Reader

What if we've had web development round the wrong way for the last 10 years?

twitter.com

4 pointstomhamiltons9 comments

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.

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.

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.

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

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.

I don't see what any of this has to do with tracking?

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

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.

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".

Reply on news.ycombinator.com